Toolkit — Case Studies¶

These case studies are illustrative composites: they’re built from common patterns seen across engineering/product organizations, but they are not reports of a single identifiable company. Their purpose is to show how the lens “bites” in practice: turning vague discomfort into decisions, artifacts, constraints, and defaults.

Use them as reference moves, not as prescriptions.

Case Study 1 — “We Need Alignment” That Was Actually an Ownership Failure¶

Context¶

Unit of analysis: multi-team (3 product teams + 1 platform team)
Domain: shared API used by multiple products

Observable failure statement¶

Dependency work routinely stalled 1–2 weeks because teams disputed who owned API changes and backward compatibility decisions. Escalations became the default. Releases slipped and platform engineers became a bottleneck for decisions, not implementation.

Lens diagnosis¶

Frame: cooperation
Decision type failing: ownership
Object of control: interfaces
Causality model: socio-technical dynamics (authority and boundaries)
Landscape note: sprint planning existed, but it optimized sequencing within teams, not ownership between teams

Minimal viable system change¶

Artifact: Interface Ownership Contract (one page per API)
Owning team
Change approval rule
Compatibility policy
Escalation path
SLA for review
Constraint + default:
Constraint: “No API change merges without owner approval within 24h.”
Default: “If no response in 24h, change proceeds under ‘backward compatible only’ rule.”

Misuse model + mitigation¶

Misuse: owner becomes gatekeeper
Mitigation: timeboxed SLA + compatibility default limits power capture
Misuse: contract becomes stale
Mitigation: quarterly review + sunset clause (“expires unless renewed”)

What changed after 2 cycles (expected)¶

Fewer escalations, faster API decisions, and disputes moved from “who owns?” to “does this violate compatibility?” (a healthier argument).

Case Study 2 — “We’re Slow” That Was Actually Uncontrolled WIP¶

Context¶

Unit of analysis: team
Domain: feature delivery with frequent interrupts

Observable failure statement¶

“Small” tasks routinely took 10–20 days. Engineers had 5–10 in-progress items each. Work piled up in review/QA queues. Releases slipped and quality incidents increased.

Lens diagnosis¶

Frame: delivery
Decision type failing: sequencing (and repair secondary)
Object of control: constraints (WIP) + work items (size/definition)
Causality model: constraints & flow

Minimal viable system change¶

Artifact: Single visible queue with columns and explicit WIP counts
Constraint + default:
Constraint: “Max 3 items in progress for the team.”
Default: “New urgent work displaces the lowest-priority in-progress item (paused, not parallelized).”

Misuse model + mitigation¶

Misuse: teams hide work “off-board”
Mitigation: definition of work includes “anything consuming >30 min/day”
Misuse: WIP becomes a performance weapon
Mitigation: treat metrics as learning-only; tie changes to decision logs, not evaluation

What changed after 2 cycles (expected)¶

Cycle time dropped; bottlenecks became visible; fewer “busy but not finishing” weeks.

Case Study 3 — OKRs Became Reporting, Not Investment Decisions¶

Context¶

Unit of analysis: organization (portfolio)
Domain: product + platform investments

Observable failure statement¶

Quarterly OKRs were written and reviewed, but priorities didn’t change. Teams committed to too many initiatives. Leadership used OKR reviews for status reporting; kill decisions were rare. Work accumulated and strategy felt performative.

Lens diagnosis¶

Frame: strategy + evolution
Decision type failing: investment (and scope secondary)
Object of control: goals + allocation constraints
Causality model: feedback loops (learning) + evolution (selection)
Landscape note: roadmaps and OKRs both claimed priority authority (collision)

Minimal viable system change¶

Artifact: Allocation Table (portfolio capacity by category)
Feature / Reliability / Platform / Discovery (percentages)
Named owners per allocation slice
“Kill / continue / increase” decision field
Constraint + default:
Constraint: “Allocation is fixed for the quarter; initiatives must fit.”
Default: “If a new initiative enters mid-quarter, it must displace an existing one (named).”

Misuse model + mitigation¶

Misuse: OKRs stay as slogans
Mitigation: goals must link to allocation and a kill/continue decision
Misuse: leadership adds more goals rather than choices
Mitigation: initiative cap + forced displacement rule

What changed after 2 cycles (expected)¶

Fewer initiatives, clearer tradeoffs, and “kill decisions” became normal rather than taboo.

Case Study 4 — Incident Reviews That Didn’t Produce Repair¶

Context¶

Unit of analysis: team / multi-team (service ownership)
Domain: reliability and on-call

Observable failure statement¶

Incidents repeated with similar causes. Postmortems existed, but action items were vague and often not completed. Reliability work lost to feature delivery, and on-call fatigue increased.

Lens diagnosis¶

Frame: delivery (operations) + cooperation (handoffs)
Decision type failing: repair
Object of control: constraints (capacity protection) + information flow (decision log)
Causality model: constraints & flow

Minimal viable system change¶

Artifact: Repair Decision Record (one per incident)
“What will change?” (single repair decision)
Owner
Due date
Verification method
Constraint + default:
Constraint: “Protect 20% capacity for repair until repair backlog < threshold.”
Default: “If repair capacity is consumed by features, release scope is reduced automatically (predefined cut list).”

Misuse model + mitigation¶

Misuse: postmortems become blame narratives
Mitigation: focus artifact on “next change decision,” not storytelling
Misuse: repair capacity is silently borrowed
Mitigation: allocation table visible + displacement rule enforced

What changed after 2 cycles (expected)¶

Fewer repeated incidents, and repairs stopped competing invisibly with features.

Case Study 5 — Architecture Review Board as a Bottleneck¶

Context¶

Unit of analysis: multi-team / org
Domain: design approvals and standards

Observable failure statement¶

Architecture reviews introduced multi-week delays. Teams prepared large docs for approval, then reworked them after late feedback. The board became a gate without clear criteria, and teams routed around it.

Lens diagnosis¶

Frame: cooperation + evolution (standards)
Decision type failing: sequencing (and ownership of standards)
Object of control: interfaces + authority constraints
Causality model: socio-technical dynamics

Minimal viable system change¶

Artifact: Decision Gate Checklist + Interface Contract
Only decisions that affect shared interfaces require review
Standard criteria listed explicitly
Constraint + default:
Constraint: “Review SLA is 72h for interface-affecting changes.”
Default: “If SLA expires, change proceeds if checklist is satisfied; dissent is logged for later audit.”

Misuse model + mitigation¶

Misuse: board expands scope to everything
Mitigation: boundary rule: “No interface impact, no board”
Misuse: default becomes reckless
Mitigation: checklist includes blast radius and rollback plan minimums

What changed after 2 cycles (expected)¶

Reviews became narrower, faster, and focused on shared interface risk rather than general design style.

Case Study 6 — “Innovation Program” Without Selection Pressure¶

Context¶

Unit of analysis: organization
Domain: internal innovation bets

Observable failure statement¶

Many “pilots” ran indefinitely, consuming capacity with unclear outcomes. Nothing died. Teams accumulated tools and prototypes, creating fragmentation and maintenance burden.

Lens diagnosis¶

Frame: evolution / scaling
Decision type failing: investment (selection/kill)
Object of control: constraints (kill criteria) + information flow (bet tracker)
Causality model: evolution / selection

Minimal viable system change¶

Artifact: Bet Tracker
Hypothesis
Success criteria
Budget/timebox
Owner
Review date
Kill/continue decision field
Constraint + default:
Constraint: “Every bet has a 6–8 week timebox and kill criteria.”
Default: “If success criteria aren’t met at review, the bet is killed and artifacts are archived.”

Misuse model + mitigation¶

Misuse: criteria become vague to avoid killing
Mitigation: criteria must be measurable or observable; otherwise bet cannot start
Misuse: killing becomes politically unsafe
Mitigation: normalize killing as success (“saved capacity” tracked and celebrated)

What changed after 2 cycles (expected)¶

Fewer pilots, clearer learning, and reduced tool sprawl because selection started happening.

How to Use These Case Studies¶

When you face a real situation, don’t copy the solution. Copy the move:

Write the observable failure statement
Choose the dominant frame
Name the decision type being optimized
Choose 1–2 objects of control
Produce one artifact that makes the decision inspectable
Add one enforceable constraint + default
Predict misuse and mitigate
Run one cycle, then review: keep/modify/subordinate/remove