Toolkit — Decision-Type Field Guide¶

This guide helps you identify which decision you are actually failing to make, and what kinds of systems tend to work for that decision. Each decision type includes:

failure signals (what you’ll observe)
best-fit objects of control
artifact options (inspectability)
constraint + default patterns (teeth)
common misuses (predictable breakage)

Use it to translate vague problems (“alignment”, “clarity”, “speed”) into a concrete decision machine.

Priority¶

When priority is failing (signals)¶

Everything is “top priority”
Work starts faster than it finishes
Priorities reverse after reviews
Teams optimize local queues, global goals drift

Best-fit objects of control¶

Work items
Constraints (initiative/WIP caps)
Information flow (single priority artifact)

Artifact options¶

Ranked stack with explicit capacity allocation
“Now / Next / Later” with explicit “Not doing”
Decision log of priority changes (why, when, who)

Constraint + default patterns¶

Initiative cap (e.g., max 3) + displacement default (“new displaces lowest”)
WIP cap + pause default (“pause, don’t parallelize”)
Deadline to decide + continue-current default (“if not decided, current top remains”)

Common misuses¶

Priority artifact becomes status report
Leadership injects “urgent” without displacement
Priority is declared per team, not per shared constraint (collision)

Scope¶

When scope is failing (signals)¶

Work expands mid-flight (“just one more thing”)
Commitments are missed due to scope creep
Requirements debates never end
“Done” is negotiable

Best-fit objects of control¶

Work items (definition, slicing, acceptance)
Constraints (timeboxes, gates)
Information flow (scope boundary visibility)

Artifact options¶

In/Out list (explicit boundary)
Acceptance criteria / Definition of Done
Shaped pitch document (bounded work)

Constraint + default patterns¶

Timebox (“appetite”) + ship-something default (reduce scope, keep deadline)
“No change without tradeoff” + remove-something default
Gate: “No start without exit criteria” + block-start default

Common misuses¶

Scope becomes contract rigidity (no learning allowed)
Scope is negotiated via politics, not artifacts
“Scope control” becomes bureaucracy (heavy approvals)

Ownership¶

When ownership is failing (signals)¶

“Not my problem” or “ask X” is common
Dependencies stall, escalations dominate
Interfaces change without coordination
Responsibility is assigned without authority

Best-fit objects of control¶

Interfaces
Domains
Authority boundaries (decision rights)

Artifact options¶

Ownership map (system/interface/domain → owning team)
Interface contract (change protocol, compatibility rules, SLAs)
Decision rights table (decide/consult/inform)

Constraint + default patterns¶

“Every interface has an owner” + ops-default (“team running it owns until reassigned”)
Review SLA + safe-default (“if no response, proceed under backward-compatible-only rule”)
Escalation timer + auto-escalate default

Common misuses¶

Ownership becomes gatekeeping power capture
“Shared ownership” becomes “nobody owns”
Ownership maps rot (no review cadence)

Sequencing¶

When sequencing is failing (signals)¶

Work is constantly blocked by dependencies
Too many parallel efforts, low completion rate
“Next” changes daily; throughput is volatile
Bottlenecks are known but ignored

Best-fit objects of control¶

Work items (ordering, dependency clarity)
Constraints (WIP/queue policies)
Interfaces (dependency boundaries at multi-team)

Artifact options¶

Dependency map + chosen order
Queue policy (classes of service)
Bottleneck map (where work waits)

Constraint + default patterns¶

WIP limit + displacement default
Dependency resolution timebox + escalate default
“Stop-the-line” rule + stabilize-first default

Common misuses¶

Sequencing becomes “plans” disconnected from capacity
People route around the sequence with side channels
Dependencies are tracked but not resolved (artifact without enforcement)

Investment¶

When investment is failing (signals)¶

Too many initiatives, few outcomes
Nothing dies; pilots run forever
Strategy resets don’t change allocation
Important but non-urgent work never gets funded

Best-fit objects of control¶

Goals (as selection criteria)
Constraints (allocation caps, kill criteria)
Information flow (portfolio visibility)

Artifact options¶

Allocation table (capacity by category)
Initiative/bet tracker with owners and budgets
Kill/continue/increase decision log

Constraint + default patterns¶

Fixed allocation per cycle + displacement default for mid-cycle adds
Initiative cap + must-kill default (new requires killing one)
Kill criteria + auto-kill default at review if criteria unmet

Common misuses¶

Investment artifacts become reporting decks
Kill decisions become politically unsafe (no selection pressure)
Teams sandbag to protect funding (metric gaming)

Diagnosis¶

When diagnosis is failing (signals)¶

Same failures repeat with different blame stories
Postmortems exist but don’t change behavior
“Root cause” is vague or moral (“communication”)
Data exists but doesn’t change decisions

Best-fit objects of control¶

Information flow (what evidence is captured)
Work items (problem definitions)
Constraints (required “next change” output)

Artifact options¶

Incident timeline + causal map
Decision log entry (“what we now believe and will change”)
Hypothesis + evidence table (what would change our mind)

Constraint + default patterns¶

“No postmortem without next-change decision” + block-close default
Evidence requirement + unknown-explicit default (“mark as unknown, assign investigation”)
Timeboxed diagnosis + smallest-safe-fix default

Common misuses¶

Diagnosis becomes storytelling, not decision-making
Blame capture (politics)
Endless analysis avoids repair commitments

Repair¶

When repair is failing (signals)¶

Reliability and tech debt always lose to features
Incidents recur; “we’ll fix later” repeats
Teams normalize toil and firefighting
Known constraints remain for months

Best-fit objects of control¶

Constraints (protected capacity, gates)
Work items (repair backlog definition)
Interfaces (where failures originate across boundaries)

Artifact options¶

Repair backlog with owners and deadlines
Reliability budget / error budget policy (if applicable)
Repair decision record per incident (single “next change”)

Constraint + default patterns¶

Protected repair allocation + scope-cut default (feature scope reduces if repair violated)
Stop-the-line threshold + stabilize-default (no new releases until fixed)
SLA for repair items + escalate-default

Common misuses¶

Repair becomes “nice to have” with no enforcement
Repair capacity silently borrowed
Repair backlog becomes a graveyard (no selection/pruning)

Fast Translation Table¶

Use this to convert vague requests into decision types:

“We need alignment” → usually priority, scope, ownership, or investment
“We need to move faster” → often sequencing (flow) or repair (constraints)
“We keep redoing work” → often diagnosis (learning loop) or ownership (boundaries)
“Too many initiatives” → investment + scope constraints
“Cross-team friction” → ownership (interfaces/domains)

Choosing a Decision Type Under Ambiguity¶

If multiple seem true, ask:

“Which decision, if made well, would dissolve the others?”
“Which decision are we most consistently avoiding?”
“Which decision is currently being made by accident (defaults, politics, urgency)?”

Pick one primary decision type and treat others as secondary effects.

Exit Condition for This Guide¶

You can treat this guide as “installed” when you can:

take a vague complaint in a meeting,
name the likely decision type within 60 seconds,
propose a candidate artifact and a constraint+default that would force the decision to become inspectable.