Toolkit — Framework Decompositions¶

These decompositions are reference specifications, not endorsements. Real implementations vary, but the purpose here is stable: make the operating logic inspectable so you can decide adopt / adapt / subordinate / reject.

For each framework, you get:

one-sentence system spec
the 10 canonical dimensions (compressed)
common misuse modes (because they dominate real life)

OKRs¶

One-sentence system spec OKRs reduce strategy drift by optimizing investment/priority decisions via control of goals and information flow, producing OKR sets and check-ins, enforced by cadence and (sometimes) scope constraints, at the org/multi-team unit.

Canonical dimensions¶

Problem frame: strategy (sometimes discovery)
Object of control: goals; information flow (visibility)
Unit of analysis: org or multi-team (often misapplied to team-only)
Causality model: feedback loops (learn/adjust)
Decision type optimized: investment / priority (primary)
Artifacts: objective list; key results; check-in notes; (optional) decision log links
Vocabulary & boundary rules: “objective,” “key result,” “committed vs aspirational” (if used); disallow vague “impact” without measure
Operating mode: continuous cadence (quarterly + weekly/biweekly check-ins)
Misuse model: becomes reporting theater; key results become tasks; sandbagging; local optimization
Adoption path: leadership + 1–2 groups first; value appears when priorities/investments actually change

Common high-leverage adaptation: pair OKRs with an allocation constraint (capacity table + forced displacement rule).

Scrum¶

One-sentence system spec Scrum reduces delivery unpredictability by optimizing sequencing/scope decisions via control of work items, producing sprint goals and increments, enforced by timeboxed sprints and role/accountability rules, at the team unit.

Canonical dimensions¶

Problem frame: delivery
Object of control: work items (backlog, sprint backlog)
Unit of analysis: team
Causality model: feedback loops (inspect/adapt) with mild linear planning inside a sprint
Decision type optimized: sequencing (primary), scope (secondary)
Artifacts: sprint goal; backlog; increment; (optional) Definition of Done
Vocabulary & boundary rules: sprint, backlog, DoD; disallow “done-ish”
Operating mode: cadence-driven (sprints, reviews, retros)
Misuse model: sprint becomes a contract; velocity weaponization; ceremonies without decisions; backlog as junk drawer
Adoption path: single team can start; value appears when commitments stabilize and learning loops work

Common high-leverage adaptation: make Definition of Done and WIP/queue visibility explicit to prevent “in progress forever.”

Kanban¶

One-sentence system spec Kanban reduces flow delay by optimizing sequencing/repair decisions via control of constraints (WIP) and work item policies, producing workflow visualization and flow metrics, enforced by WIP limits and explicit policies, at the team or service unit.

Canonical dimensions¶

Problem frame: delivery (operations/service)
Object of control: constraints; work items
Unit of analysis: team/service (can extend to multi-team with interface focus)
Causality model: constraints & flow
Decision type optimized: sequencing (primary), repair (secondary)
Artifacts: board/queue; WIP limits; policies; cycle-time metrics
Vocabulary & boundary rules: WIP, classes of service; disallow hidden work
Operating mode: continuous pull; event-driven replenishment
Misuse model: board becomes status wallpaper; WIP limits ignored; metrics used for punishment; work moved off-board
Adoption path: one team can adopt quickly; value appears when cycle time drops and bottlenecks are visible

Common high-leverage adaptation: add a default displacement rule for urgent work (what gets paused).

Domain-Driven Design (DDD)¶

One-sentence system spec DDD reduces socio-technical coupling and semantic drift by optimizing ownership decisions via control of domains and interfaces, producing bounded context maps and ubiquitous language, enforced by boundary rules and architectural constraints, at the multi-team/org unit.

Canonical dimensions¶

Problem frame: cooperation + evolution/scaling
Object of control: domains; interfaces; vocabulary (as boundary enforcement)
Unit of analysis: multi-team / org
Causality model: socio-technical dynamics + evolution (boundaries evolve)
Decision type optimized: ownership (primary), repair (secondary via decoupling)
Artifacts: context map; domain glossary; aggregates boundaries; integration contracts
Vocabulary & boundary rules: “bounded context,” “ubiquitous language,” “aggregate”; disallow ambiguous shared meanings
Operating mode: continuous; design-time and change-time
Misuse model: becomes jargon; over-modeling; “domain” as political territory; ignores operational reality
Adoption path: start on one painful boundary; value appears when integration friction and rework drop

Common high-leverage adaptation: require interface contracts + ownership for each bounded context integration point.

Team Topologies¶

One-sentence system spec Team Topologies reduces coordination drag at scale by optimizing ownership/sequencing decisions via control of team boundaries and interaction modes, producing team maps and interaction contracts, enforced by boundary rules and platform constraints, at the multi-team/org unit.

Canonical dimensions¶

Problem frame: cooperation + evolution/scaling
Object of control: interfaces; ownership boundaries; information flow
Unit of analysis: multi-team/org
Causality model: socio-technical + evolution
Decision type optimized: ownership (primary)
Artifacts: team API/interaction map; responsibility boundaries; service ownership catalog
Vocabulary & boundary rules: stream-aligned/platform/enabling; disallow “everyone owns everything”
Operating mode: continuous; org design and change governance
Misuse model: reorg theater; labels without interface enforcement; platform becomes gatekeeper
Adoption path: start with one value stream + platform slice; value appears when dependency friction decreases

Common high-leverage adaptation: define interaction SLAs/defaults (e.g., response times, escalation).

ITIL Change Enablement (Change Management)¶

One-sentence system spec Change enablement reduces production risk by optimizing sequencing/risk decisions via control of constraints and approvals, producing change records and risk classifications, enforced by gates and authority rules, at the org/service unit.

Canonical dimensions¶

Problem frame: delivery (operations/risk)
Object of control: constraints; information flow
Unit of analysis: org/service
Causality model: linear planning + socio-technical (governance)
Decision type optimized: sequencing (primary), repair (secondary)
Artifacts: change request/record; risk category; approval trail; implementation plan
Vocabulary & boundary rules: standard/normal/emergency change; disallow unclassified change
Operating mode: event-driven; gate-based
Misuse model: bureaucracy; slows safe changes; people route around; approvals become blame shields
Adoption path: start with high-risk services; value appears when incident rate drops without killing throughput

Common high-leverage adaptation: make standard changes truly low-friction and use defaults to prevent dead queues.

SRE Incident Management¶

One-sentence system spec Incident management reduces outage impact by optimizing diagnosis/repair decisions via control of information flow and constraints (roles, timelines), producing incident timelines and action items, enforced by roles, severity policies, and post-incident requirements, at the team/multi-team unit.

Canonical dimensions¶

Problem frame: delivery (operations) + cooperation
Object of control: information flow; constraints
Unit of analysis: team/multi-team (depending on incident scope)
Causality model: constraints & flow + feedback loops
Decision type optimized: diagnosis (during), repair (after)
Artifacts: incident channel/log; timeline; severity classification; postmortem; repair decision record
Vocabulary & boundary rules: sev levels, incident commander; disallow “no owner” incidents
Operating mode: event-triggered; high-tempo operational
Misuse model: blame; postmortems without repair capacity; action items rot; over-classifying as “emergency”
Adoption path: one service/team can begin; value appears when repeated incidents fall and MTTR improves

Common high-leverage adaptation: protect repair capacity allocation with a displacement default.

Shape Up¶

One-sentence system spec Shape Up reduces delivery thrash by optimizing scope/sequencing decisions via control of work shaping and timeboxes, producing pitch documents and shaped bets, enforced by fixed cycles and appetite constraints, at the team/multi-team unit.

Canonical dimensions¶

Problem frame: delivery (and strategy-lite via bet selection)
Object of control: work items; constraints (time/appetite)
Unit of analysis: team/multi-team
Causality model: constraints & flow + mild evolution/selection (bets)
Decision type optimized: scope (primary), sequencing (secondary)
Artifacts: pitches; shaped work boundaries; cycle plan; cool-down notes
Vocabulary & boundary rules: appetite, shaping, bet; disallow open-ended scope
Operating mode: cycle-based (bets + cool-down)
Misuse model: shaping becomes central gate; “appetite” used to underfund; teams skip discovery and learn late
Adoption path: start with one product group; value appears when scope stays bounded and shipping cadence stabilizes

Common high-leverage adaptation: add explicit kill/reshape triggers mid-cycle when assumptions break.

How to Use This Page¶

Pick the framework someone is proposing.
Compare its decision type, object of control, unit of analysis, and causality model to your observable failure.
If there’s mismatch, adapt (change artifact/constraint/authority) or reject.
If it collides with an existing system, define a precedence rule or subordinate one.