Chapter 15 — Minimal Viable Systems¶

Most systems fail because they start too large.

They try to fix everything, satisfy everyone, and represent the full complexity of reality. That produces a familiar outcome:

heavy adoption cost
weak enforcement
artifact overload
inevitable drift into ritual

This chapter defines an alternative: Minimal Viable Systems (MVS).

An MVS is the smallest system that can reliably improve a decision under real constraints and survive misuse.

The Failure This Chapter Prevents¶

Observable failure: teams design systems that are too complex to adopt, too broad to enforce, and too expensive to maintain.

Symptoms:

long rollout plans and training programs
many artifacts created before any decision changes
stakeholders demand customization before first use
the system requires facilitation to function
the system becomes “optional” because it’s too heavy

Root cause:

the system is designed as a full operating model rather than a decision machine.

What “Minimal Viable” Means Here¶

Minimal viable does not mean simplistic.

It means:

the smallest scope that still has teeth
the smallest artifact that is still inspectable
the smallest constraint that still forces tradeoffs
the smallest adoption path that still produces visible value

An MVS must still include:

one observable failure target
one optimized decision type
one object of control (maybe two at most)
one inspectable artifact
one enforceable constraint with a default
one misuse warning
one adoption path

If you remove any of these, the system becomes either:

a suggestion, or
a template, or
a meeting.

The MVS Core Formula¶

You can build an MVS by committing to this formula:

One Decision + One Artifact + One Constraint + One Default

Everything else is optional until proven necessary.

One Decision¶

Pick one primary decision type:

priority
scope
ownership
sequencing
investment
diagnosis
repair

Avoid multi-decision systems at first. They become political immediately.

One Artifact¶

The artifact is the “shared object” that makes the decision inspectable.

Examples (by decision type):

Priority → ranked stack with capacity allocation
Scope → explicit in/out boundary list with change log
Ownership → ownership map for one domain/interface
Sequencing → dependency map + chosen order
Investment → allocation table + rationale + kill criteria
Diagnosis → causal map + “next change” decision
Repair → repair backlog with protected capacity rule

One Constraint¶

A constraint is how the system forces reality to be confronted.

Examples:

“Max 3 active items; new work displaces old.”
“No work starts without an owner and exit criteria.”
“If unresolved dependency > 48h, escalate.”
“If decision not made by Friday, default ships.”

One Default¶

Defaults are what prevent “we’ll revisit” from defeating the system.

Examples:

“If we can’t agree, we pick the option with lower blast radius.”
“If priority isn’t decided, we continue the current top item.”
“If ownership unclear, the team closest to the interface owns until reassigned.”

Defaults must be explicit and socially acceptable, or they will be ignored.

The MVS Build Procedure¶

Step 1: Choose a narrow target failure¶

Pick a failure you can observe weekly.

Good targets:

“Work items labeled small take > 10 days”
“Ownership disputes block releases”
“Priorities reverse after executive reviews”
“Incidents repeat without structural fixes”

Bad targets:

“Improve alignment”
“Increase innovation”
“Improve culture”

Step 2: Choose a decision you can change immediately¶

Ask:

“What decision do we keep avoiding or re-litigating?”

Choose one.

Step 3: Pick the smallest object of control that touches the failure¶

Prefer objects you can edit without permissions:

work item definitions
WIP limits
interface contracts
ownership maps
decision logs

Avoid incentives and org chart unless you own them.

Step 4: Design the artifact to be hard to fake¶

Artifacts should not be “nice to have.” They should be hard to produce dishonestly.

Techniques:

include a “decision changed” field
include an owner and timestamp
include assumptions and constraints
include the next action and deadline
make it visible to the people affected

Step 5: Add a constraint with an explicit default¶

Ask:

“How will we avoid this decision?”
“What rule blocks avoidance?”
“What happens automatically if we still avoid it?”

Step 6: Define minimal adoption¶

An MVS must be adoptable by a small group without institutional permission.

Define:

who runs it first
how often it runs
what it produces on the first run
what improvement should be visible within 1–2 cycles

If first value requires org-wide rollout, it’s not minimal.

Minimal Viable System Patterns (Reusable Shapes)¶

These are MVS “shapes” you can deploy quickly.

Pattern A: Decision Log MVS¶

Target failure:

repeated reversals
loss of rationale
blame cycles

Decision optimized:

diagnosis / investment / scope

Artifact:

one-page decision record: context, options, decision, rationale, owner, review date

Constraint + default:

“No major work starts without a decision record.”
Default: “If no record, work cannot claim priority.”

Pattern B: WIP Cap MVS¶

Target failure:

too much in progress
slow cycle time
constant context switching

Decision optimized:

sequencing / repair

Artifact:

visible queue with explicit WIP count

Constraint + default:

“Max N items in progress.”
Default: “New work displaces lowest priority in-progress item.”

Pattern C: Ownership Boundary MVS¶

Target failure:

cross-team blocks
interface disputes
“not my problem”

Decision optimized:

ownership

Artifact:

ownership map for one interface/domain + escalation path

Constraint + default:

“Every interface must have an owning team.”
Default: “Owning team is the one operating it in production until reassigned.”

Pattern D: Capacity Allocation MVS¶

Target failure:

repair work always sacrificed
strategy resets without behavior change

Decision optimized:

investment / priority

Artifact:

allocation table (e.g., feature/repair/platform) with explicit percentages

Constraint + default:

“Allocation is fixed for the cycle.”
Default: “If requests exceed allocation, they queue, not steal capacity.”

Misuse Model: How MVS Gets Misapplied¶

Misuse 1: Minimal becomes “optional”¶

Teams interpret minimal as “lightweight” and remove enforcement.

Correction:

minimal means few parts, not weak constraints.

Misuse 2: Minimal becomes “pilot forever”¶

People keep it small to avoid commitment or organizational exposure.

Correction:

define explicit scale criteria:
“If X improves for 3 cycles, expand scope.”

Misuse 3: Minimal becomes “local patch”¶

Teams fix local pain while the real failure is cross-boundary.

Correction:

if the failure is multi-team, your MVS must control interfaces or decision rights, not just team rituals.

The Non-Negotiable Rule Introduced Here¶

If you cannot produce a system that changes a real decision within two cycles, you are not designing a system—you are designing compliance.

Start minimal. Prove value. Then expand.

Exit Condition for This Chapter¶

Design one Minimal Viable System by writing:

Target observable failure (3–5 sentences)
One decision type to optimize
One artifact (name + fields it contains)
One constraint + explicit default
One misuse warning + mitigation
Who can adopt it first and what “first value” looks like