Chapter 16 — Teaching This Logic to Others¶

Systems fail socially more often than they fail logically.

You can design a clean decision machine—clear failure, clear artifact, enforceable constraint—and still watch it collapse because:

people don’t share the same frame
authority is ambiguous
incentives oppose enforcement
the system threatens identity or status
artifacts feel like surveillance

This chapter is about transferring the logic of System Design Lens to humans, in real organizations, without turning it into jargon or ideology.

The Failure This Chapter Prevents¶

Observable failure: a good system design fails adoption because the reasoning discipline isn’t shared, and the system becomes either misunderstood, resisted, or turned into ritual.

Symptoms:

people “agree” but behave as before
adoption varies wildly by team
the system gets simplified into slogans
leadership mandates compliance to compensate
the system becomes a political symbol

Root cause:

the system’s operating logic is not taught as a decision discipline; it is taught as process.

What You Are Actually Teaching¶

You are not teaching steps.

You are teaching four mental moves:

Anchor in observable failure
Name the decision being optimized
Control something real (object of control)
Force inspectability and constraints, with misuse awareness

If learners walk away with those moves, they can evaluate and design systems without you.

If they walk away with terminology, they will cargo-cult.

The Teaching Order (Do Not Change)¶

Teach in this sequence because it follows how systems become misused:

Failure → prevents abstract motivation
Decision → prevents “alignment” theater
Artifact → prevents meetings-as-systems
Constraint → prevents optional systems
Misuse model → prevents naive rollout
Adoption path → prevents authority fantasies

If you start with artifacts or templates, you will teach compliance.

The Minimal Teaching Kit¶

To teach this logic, you need only three things:

a one-page cheat sheet (the dimensions and rules)
one real example system (good or bad) to decompose
one local failure to use for a small invention exercise

Everything else is optional.

How to Teach Without Jargon¶

Jargon is not evil; it’s just a common failure mode. Use plain language first.

Translate the canonical dimensions into everyday questions:

Failure: “What’s repeatedly going wrong?”
Decision: “What decision do we keep avoiding or re-litigating?”
Object of control: “What can we actually change?”
Artifact: “What proof will we leave behind?”
Constraint: “What rule forces the tradeoff?”
Misuse: “How will this get gamed or turned into theater?”
Adoption: “Who can really enforce this?”

Only introduce canonical terms after the questions are understood.

The Core Classroom Exercise: Decompose a Familiar System¶

Pick something everyone experiences (for engineers, common choices are: sprint planning, incident response, architecture review, on-call handoff).

Run this exercise:

Write the system name on a board.
Ask: “What decision is it supposed to optimize?”
Ask: “What artifact proves it happened?”
Ask: “What happens when it doesn’t happen?”
Ask: “How is it commonly misused?”

You will usually discover:

the decision is unclear
artifacts are weak or unused
enforcement is social, not structural
misuse is common and unspoken

That discovery creates readiness for redesign.

The Adoption Reality Rule: Authority Before Elegance¶

People will adopt systems they can enforce.

If you teach people to design constraints without teaching authority boundaries, you will train frustration.

Always teach this sentence:

“If you can’t enforce it, it’s not a rule, it’s a wish.”

Then teach adoption design:

start where authority exists
prove value quickly
expand only when constraints can still be enforced

Teaching Through Artifacts (Best Method)¶

Artifacts are teachable because they are inspectable.

When introducing a system, teach by showing:

one real artifact produced by the system
a before/after example (bad vs good artifact)
how the artifact changes a real decision

This avoids ideological debates and keeps learning concrete.

Artifact coaching pattern¶

“Show me the last 3 artifacts this system produced.”
“Point to the decision in each.”
“Show what changed because of it.”

If they can’t, the system isn’t functioning.

Training Misuse Awareness Without Cynicism¶

Misuse modeling can sound negative. Frame it as engineering:

“Every system has failure modes.”
“We want predictable failures, not surprising ones.”

Teach misuse with three lenses:

busy-team misuse (time pressure)
leadership misuse (legibility and control pressure)
political misuse (status, veto, shielding)

Then teach one mitigation type:

change the artifact
change the constraint/default
change authority boundaries

Avoid moralizing (“people are bad”). Focus on incentives and defaults.

The Two Common Teaching Traps¶

Trap 1: Teaching as “compliance”¶

People learn to fill forms and follow rituals.

Result:

adoption looks high
decision quality doesn’t improve
cynicism grows

Avoid by:

requiring evidence of decision improvement as success criteria.

Trap 2: Teaching as “framework identity”¶

People start saying “we’re a ____ organization.”

Result:

system becomes untouchable
critique becomes heresy

Avoid by:

teaching systems as tools with expiry and review rules.

The Facilitation Script (Field-Usable)¶

Use this script in workshops and real meetings.

Opening¶

“What failure are we seeing repeatedly?”
“Which decision keeps breaking because of it?”

Specification¶

“What will we control directly?”
“What artifact will prove the decision happened?”
“What constraint forces the tradeoff?”
“What default triggers if we avoid the decision?”

Misuse and adoption¶

“How will this get turned into reporting?”
“How will busy teams weaken it?”
“Who can adopt and enforce this first?”

Close with a commitment¶

“What’s the smallest run we can do this week?”
“What decision will change if it works?”

How to Measure Teaching Success¶

Do not measure “understanding.”

Measure behavior change:

Can people write an observable failure statement?
Can they name a decision type quickly?
Can they produce an inspectable artifact without prompting?
Can they propose a constraint with a default?
Can they name likely misuse?

If they can do those, they’ve learned the logic.

The Non-Negotiable Rule Introduced Here¶

You are not done teaching until learners can design a minimal viable system without you:

one decision
one artifact
one constraint + default
one misuse warning
one adoption path

If they need you to interpret the system, you taught dependence, not capability.

Exit Condition for This Chapter¶

Run a 60–90 minute session where a group:

Decomposes one existing system using the canonical dimensions
Identifies two misuse modes currently occurring
Designs one Minimal Viable System improvement (artifact + constraint + default)
Commits to running it once within a week

If they can do this, the logic has transferred.