Chapter 14 — Common Failure Patterns¶

This chapter is a catalog of system failure patterns—not as trivia, but as a diagnostic tool.

Each pattern describes:

the observable symptoms
the underlying mechanism
why it’s attractive
what it breaks
a corrective design move

Use this chapter when you suspect your “system” is turning into ritual, theater, or politics.

Pattern 1: Vocabulary-First Systems¶

Symptoms¶

lots of new terms
debates about definitions
“we need alignment” becomes frequent
artifacts are mostly glossaries and decks
decisions don’t get faster or safer

Mechanism¶

Vocabulary creates shared labels without enforcing shared commitments.

People mistake naming for control.

Why it’s attractive¶

low conflict
feels sophisticated
easy to teach and spread

What it breaks¶

decision accountability
learning loops
speed under stress

Corrective move¶

Add:

one explicit decision output
one artifact that records the decision
one constraint that triggers a default if the decision isn’t made

If you can’t enforce those, admit it’s a vocabulary, not a system.

Pattern 2: Ritual Without Artifact¶

Symptoms¶

recurring meetings that “feel important”
endless revisiting of the same topics
outcomes are verbal and evaporate
decisions are postponed by default

Mechanism¶

The system is actually a cadence. Cadence is mistaken for governance.

Why it’s attractive¶

creates social rhythm
provides a sense of control
distributes responsibility through attendance

What it breaks¶

inspectability
commitment
continuity across time and people

Corrective move¶

Define the meeting’s purpose as:

produce a specific artifact
that contains a specific decision
that triggers specific next actions

No artifact, no meeting.

Pattern 3: Artifact Without Decision¶

Symptoms¶

many documents and dashboards
“status” is always available
nobody can name the decision that changed because of the artifact
planning produces slides, not commitments

Mechanism¶

Artifacts are optimized for reporting, not for decision-making.

Why it’s attractive¶

legibility is rewarded
leadership feels informed
avoids conflict (information can be shared without choosing)

What it breaks¶

prioritization
accountability
speed to commitment

Corrective move¶

Require each artifact to include:

a decision field (“What changed?”)
an owner
a default if no decision is made
a link to the next action

If the artifact can’t change action, delete it.

Pattern 4: Constraintless Systems¶

Symptoms¶

“it’s a guideline”
exceptions are constant
under stress, people ignore the system
enforcement relies on reminders and shame

Mechanism¶

Without constraints, the system cannot force tradeoffs or defaults.

Why it’s attractive¶

reduces resistance
avoids authority conflict
feels “empowering”

What it breaks¶

reliability under pressure
learning (no stable process)
credibility (“process doesn’t matter here”)

Corrective move¶

Add one enforceable constraint with a default:

scope cap, WIP limit, timebox, gate, authority boundary

If enforcement is impossible, redesign the unit of analysis or adoption path.

Pattern 5: “Best Practice” Systems¶

Symptoms¶

justification is “industry standard”
system is adopted with minimal local diagnosis
dissent is framed as immaturity (“you’ll get it later”)

Mechanism¶

External legitimacy replaces local problem fit.

Why it’s attractive¶

reduces uncertainty
provides political cover
accelerates rollout

What it breaks¶

fit to context
trust (people feel coerced)
learning (feedback is dismissed)

Corrective move¶

Force a local contract:

name the local failure
name the decision optimized
define the artifact and constraint
define misuse risks in your environment

If you can’t do this, you’re buying identity, not design.

Pattern 6: Framework Stacking¶

Symptoms¶

multiple overlapping systems
conflicting artifacts
teams spend time translating between methods
governance expands to reconcile contradictions

Mechanism¶

When one system fails, another is added rather than replacing or subordinating.

Why it’s attractive¶

avoids admitting failure
keeps everyone’s preferences alive
adds “coverage” without removal

What it breaks¶

coherence
throughput (coordination load rises)
accountability (no one knows which system wins)

Corrective move¶

Apply the landscape rule:

each recurring decision must have one “source” artifact
adding a system requires removing or subordinating another

Pattern 7: Scale Mismatch (Scale Collapse)¶

Symptoms¶

a team practice mandated org-wide
heavy governance to enforce simple routines
widespread superficial compliance
local adaptations are treated as failures

Mechanism¶

System assumptions don’t survive the unit-of-analysis change.

Why it’s attractive¶

leaders want comparability
copying seems cheaper than redesign
success stories are compelling

What it breaks¶

autonomy
adaptability
credibility of governance

Corrective move¶

Redesign for the new unit:

control interfaces rather than rituals
shift artifacts to match the scale (ownership maps, contracts, portfolio allocations)
explicitly define enforcement authority

Pattern 8: Metric Capture¶

Symptoms¶

metrics improve while reality worsens
teams optimize numbers over outcomes
people hide work to protect metrics
metrics become performance weapons

Mechanism¶

Measurement becomes an incentive system, not an information system.

Why it’s attractive¶

makes leadership feel in control
simplifies complexity
supports comparability and accountability narratives

What it breaks¶

truth
psychological safety
long-term performance

Corrective move¶

separate metrics used for learning from metrics used for evaluation
add “anti-gaming” signals
tie metrics to decision logs (“what did we change because of this?”)

Pattern 9: Legibility Over Truth¶

Symptoms¶

sanitized status updates
surprises emerge late
bad news travels slowly
artifacts look clean but don’t predict outcomes

Mechanism¶

Artifacts are optimized to be understood by power, not to reflect reality.

Why it’s attractive¶

reduces conflict
protects reputations
makes planning look stable

What it breaks¶

early detection
repair speed
trust

Corrective move¶

Design artifacts for truth first:

include uncertainty explicitly
record assumptions
require red/yellow flags with owners and next actions
protect candor from punishment

Pattern 10: Consensus Systems (Veto Everywhere)¶

Symptoms¶

decisions take a long time
“alignment” becomes endless
people avoid proposing bold moves
the loudest or most risk-averse actor controls outcomes

Mechanism¶

Consensus creates distributed veto power and rewards avoidance.

Why it’s attractive¶

feels fair
reduces overt conflict
spreads responsibility

What it breaks¶

speed
ownership
innovation under uncertainty

Corrective move¶

Introduce authority boundaries and defaults:

define who decides
define consult vs inform
define escalation rules
use timeboxed decision windows with default outcomes

Pattern 11: Systems That Can’t Die (Fossilization)¶

Symptoms¶

systems remain after context changes
nobody remembers why the system exists
the system is defended as “how we do things”
removing it feels dangerous

Mechanism¶

No retirement mechanism + identity attachment + fear of chaos.

Why it’s attractive¶

stability feels safe
removing systems creates political risk
“more process” seems responsible

What it breaks¶

adaptability
speed
morale (people feel trapped in rituals)

Corrective move¶

Add review and retirement rules:

sunset clauses
kill criteria
cost caps (time budget)
explicit “replace vs stack” governance

Pattern 12: Hero-Dependent Systems¶

Symptoms¶

works only when one person is present
unclear rules; “just ask Alex”
decisions stall when the hero is absent
knowledge is social, not inspectable

Mechanism¶

Enforcement and interpretation live in a person, not in artifacts and constraints.

Why it’s attractive¶

fast initially
avoids writing things down
hero becomes a coordination hub

What it breaks¶

scalability
resilience
onboarding and continuity

Corrective move¶

Move the system into artifacts:

decision logs
explicit rules and defaults
ownership maps
documented constraints

If you can’t make it inspectable, it’s not a system—it’s a person.

How to Use This Chapter¶

When evaluating a system, ask:

Which two patterns does this system most resemble?
Which pattern is it drifting toward under stress?
What single constraint or artifact change would reverse the drift?

This is not about perfection. It’s about preventing predictable failure.

Exit Condition for This Chapter¶

Pick one system you currently use and do two things:

Identify the top 2 failure patterns it exhibits today
Apply one corrective move that changes either:
a constraint, or
an artifact, or
an authority boundary

If nothing changes in decisions within a week, the correction was cosmetic.