Chapter 10 — System Decomposition¶

When someone says “we should use X” (a framework, method, operating model), you need a way to evaluate it without relying on reputation, persuasion, or aesthetics.

System Decomposition is that method.

It forces a system to reveal:

what failure it targets
what decisions it optimizes
what it directly controls
what it produces as evidence
how it enforces constraints
how it breaks when misused

If the system can’t answer these, it’s not robust enough to trust.

The Failure This Chapter Prevents¶

Observable failure: teams adopt or argue about systems based on identity (“we’re an OKR company”), fashion, or superficial similarity, then discover incompatibilities only after costly rollout.

Symptoms:

adoption is driven by executive preference or peer imitation
implementation debates focus on ceremony and tooling
the system is defended despite weak outcomes (“we’re doing it wrong” forever)
the organization can’t explain why the system works (or doesn’t)

Root cause:

systems are chosen without decomposing their operating logic.

What System Decomposition Is¶

System Decomposition is a structured way to reconstruct a system’s design from first principles.

It works on:

published frameworks
internal processes
“how we do things here”
implicit cultural defaults

The outcome is not a critique. It’s a specification:

“This system is a machine that optimizes decision X by controlling object Y, producing artifact Z, under constraint C, and it fails when misused in these ways.”

The Decomposition Dimensions¶

Decompose every system across these 10 dimensions.

1) Problem frame¶

What failure does the system reduce?
Where does that failure appear (strategy, discovery, delivery, cooperation, evolution)?

2) Primary object of control¶

What does it directly manipulate?
goals, work items, interfaces, domains, constraints, incentives, information flow

3) Unit of analysis¶

Individual, team, multi-team, org, ecosystem/market

4) Causality model¶

Linear, feedback loops, constraints/flow, evolution/selection, socio-technical

5) Decision type optimized¶

priority, scope, ownership, sequencing, investment, diagnosis, repair

6) Artifacts¶

What does it produce that can be inspected and challenged?

7) Vocabulary & boundary rules¶

What must be named precisely?
What vague thinking is disallowed?
What does the system refuse to talk about?

8) Operating mode¶

One-off vs continuous
Slow strategic vs fast operational
Facilitation-heavy vs solo-usable

9) Failure & misuse model¶

How does it degrade when misapplied?
What anti-patterns does it attract?

10) Adoption path¶

Who can use it first successfully?
Minimum viable use
Time to first value

Step-by-Step Decomposition Procedure¶

Step 1: State the system in one sentence¶

Use this format:

“System X optimizes __ decisions by controlling _, producing artifacts, under ___ constraints.”

If you can’t write this, you don’t understand the system yet.

Step 2: Identify the target failure¶

Write the observable failure the system claims to address.

If the system claims to address everything, treat that as a warning sign: it is either a worldview or a consultancy product.

Step 3: Identify the decision output¶

Force one primary decision type.

If multiple decisions appear, choose the one that most determines outcomes, and treat the others as secondary.

Step 4: Identify the object(s) of control¶

Name 1–2 objects. If you end up with 5+, you’re describing an operating model, not a system—and you should decompose it into smaller subsystems.

Step 5: Extract artifacts and enforcement¶

Artifacts:

What is produced every time the system runs?

Enforcement:

What happens if the artifact is missing or the decision is avoided?

If enforcement is unclear, the system likely survives only by goodwill.

Step 6: Identify the causality model embedded in the system¶

Look at how it expects truth to be discovered:

by planning?
by experimentation?
by managing bottlenecks?
by selecting winners?
by negotiating power and boundaries?

Mismatch is the most common root cause of “it worked somewhere else.”

Step 7: List the boundary rules¶

Every serious system has a “no.”

Examples of boundary rules:

“No work starts without definition-of-done” (scope/quality boundary)
“No initiative without an owner” (ownership boundary)
“No decision without a written artifact” (inspectability boundary)

If a system has no boundary rules, it is a vocabulary.

Step 8: Model misuse explicitly¶

Write at least three ways the system predictably fails.

Examples:

becomes reporting theater
becomes an identity (“we do X”) rather than a tool
becomes punitive measurement
becomes central control disguised as alignment

A system with no misuse model is unsafe to roll out.

Step 9: Define adoption path and minimum viable use¶

Specify:

who can run it first
what the minimum artifact and cadence is
what result should be visible quickly if it works

If it requires org-wide buy-in before any value appears, treat it as high-risk.

The Primary Artifact: The Decomposition Table¶

Create a table with the 10 dimensions as rows and fill them in.

This artifact has two jobs:

enable rational comparison across systems
expose hidden assumptions and incompatibilities

It also makes debate productive:

Instead of arguing “is this framework good?”, you argue:

“Does it optimize the decision we’re failing at?”
“Can we enforce its constraints at our unit of analysis?”
“Does its causality model match our environment?”

How to Compare Two Systems Using Decomposition¶

You can compare systems by:

decision type optimized (do they solve the same decision?)
object of control (do they control the same lever?)
constraint/enforcement (do they have teeth?)
unit of analysis (are they scale-compatible?)
causality model (do they assume the same world?)

Two systems can coexist only if their:

objects of control don’t collide, or
precedence rules are explicit.

Otherwise, you will get silent conflict and drift.

Misuse Model: How Decomposition Gets Misapplied¶

Misuse 1: Treating it as academic analysis¶

People decompose frameworks for intellectual satisfaction.

Correction: decomposition should end in an adoption decision: adopt, adapt, replace, or reject.

Misuse 2: Weaponizing decomposition¶

People use decomposition to discredit opponents.

Correction: decompose your current system first. If you can’t, you’re not qualified to critique replacements.

Misuse 3: False precision¶

Teams fill in the table with confident guesses.

Correction: mark uncertain fields explicitly and gather evidence. A “known unknown” is better than a wrong claim.

The Non-Negotiable Rule Introduced Here¶

No system may be adopted, mandated, or criticized until it has a decomposition table.

If someone can’t tolerate decomposition, they’re selling identity, not operating logic.

Exit Condition for This Chapter¶

Decompose one real system you are using or considering.

Your decomposition is complete when you can state:

the observable failure it targets
the primary decision it optimizes
the object(s) of control it manipulates
the artifact it produces
the constraint that enforces it
three predictable misuse modes
what unit of analysis it is valid for