00 The Decision Loop
Good decision-making is a loop, not a single moment. The OODA cycle (Observe, Orient, Decide, Act) describes how high-performing individuals and teams navigate decisions continuously, adapting as new information arrives.
↓ Click any node to explore
01 Decision Foundations
Before applying any framework, you need shared language, a lens for reversibility, and a way to treat decisions as learnable rather than final.
↓ Click any subsection to explore
What actually counts as a decision? What does decision debt cost you? The vocabulary you need before applying any framework.
Decision vs. Assumption vs. Task
A decision is a choice between options where the outcome is uncertain and the choice has consequences. An assumption is a belief held without verification that underlies a decision. A task is an action required to execute a decision already made.
Decision Velocity
The rate at which a team makes and acts on decisions. Slow decision velocity is often a symptom of unclear ownership, over-consultation, or fear of being wrong. Fast velocity without quality produces chaos. The goal is appropriate velocity: fast where it can be, deliberate where it must be.
The Cost of Deferring
Decision debt accrues when decisions are left implicit, deferred indefinitely, or made without acknowledgment. Like technical debt, it compounds. Every team member building on an undecided foundation makes assumptions, and those assumptions diverge over time.
Reversibility, not importance, not risk, not size, determines how much deliberation a decision deserves.
- Difficult or impossible to undo once made
- High stakes: wrong choices have lasting consequences
- Requires deliberation, consultation, documentation
- Examples: platform migrations, org restructures, vendor lock-in
- Default: slow down, involve the right people, write it down
- Can be undone, iterated, or reversed relatively cheaply
- Lower stakes: wrong choices can be corrected
- Requires a decision owner and a bias toward action
- Examples: feature flags, sprint priorities, team processes
- Default: move fast, learn, adjust; don't over-engineer the process
The best decisions are designed to be learnable: structured as hypotheses, testable, and revisitable. That's epistemic discipline, not indecisiveness.
Decisions as Hypotheses
Reframe decisions as: "We believe that doing X will lead to Y because Z." This forces you to name the reasoning, identify the observable outcome, and commit to checking whether you were right. It makes revisiting the decision a learning activity, not an admission of failure.
Design for Testability
Where possible, design implementation so impact can be measured. Feature flags, pilot groups, phased rollouts, time-limited experiments: these tools turn Type 1-feeling decisions into Type 2 ones. Not every decision can be tested, but more can than you think.
Revisiting vs. Reopening vs. Reversing
Revisit: look at a decision again in light of new information, without immediately reopening debate. Reopen: formally reconsider, involving the original DACI. Reverse: make a new decision that supersedes the old one, with full documentation.
Learning from Outcomes, Not Intentions
Good decisions that led to bad outcomes are worth analysing. Bad decisions that led to good outcomes are especially worth analysing, luck is not a repeatable process. Run post-decision reviews to understand the gap between your model of the world and what actually happened.
02 Decision Roles & Authority
Unclear ownership is the single most common root cause of slow, bad, or unactioned decisions. DACI gives every decision a clear driver and a single approver: the minimum viable structure for decisions to actually happen.
| Letter | Role | Accountability | Communication | Typical examples |
|---|---|---|---|---|
| D | Driver | Pushes the decision forward. Owns the process: gathers input, sets the timeline, ensures a decision gets made. Does not necessarily make the final call. | 2-way: coordinates input from all parties | PM, Tech Lead, EM for initiatives within their scope |
| A | Approver | Makes the final call. One person, not a group. Lives with the outcome. Has the authority and accountability for the decision's consequences. | Final say: the only role that can block or reverse | EM for team-scope, VP for org-scope, CTO for company-scope |
| C | Consulted | Provides input before the decision is made. Their expertise matters. Must be consulted, not just notified, before the decision is finalised. | 2-way: must be heard, not just asked | Security for architecture decisions, Finance for budget decisions |
| I | Informed | Needs to know the outcome and why. Not part of the decision process. Over-populating this role creates noise; under-populating it creates misalignment. | 1-way: told after the decision is made | Adjacent teams, stakeholders, those affected downstream |
Use when...
- →The decision is Type 1 and benefits from live discussion
- →Ambiguity needs real-time resolution
- →Escalation has been unresolved asynchronously
Use when...
- →Decision is well-scoped and input can be structured in writing
- →Participants are distributed across time zones
- →The record matters as much as the outcome
03 Decision-Making Principles
Principles are the guardrails that operate when no explicit process exists. They shape behaviour in the moment, reduce cognitive load in novel situations, and create consistency without bureaucracy.
↓ Click any principle to explore
Once a decision is made by the rightful Approver, commit to it, even if you disagreed. Voice your objection clearly during the decision process. Once the call is made, advocate for it as if it were your own. Teams that relitigate every decision after the fact lose velocity and trust.
Not all information is equally relevant. For each piece of information: would this change our decision if it turned out to be wrong? If no, it's noise. Remove it from the evaluation. Decisions improve when you actively discard noise rather than passively accumulate information.
The right level means the decision is made as close to the information as possible. Leaders escalating decisions they could own, or individuals escalating decisions they should own, both damage velocity and signal poor trust. If someone below you can make this call with available information, let them.
HiPPO = Highest Paid Person's Opinion. In low-safety environments, decisions default to whoever speaks most confidently or has the most seniority, regardless of who has the best information. Senior people model intellectual humility. Dissent is welcomed, not merely tolerated.
Make decisions with about 70% of the information you wish you had. Waiting for 90% is usually fear disguised as diligence, and the delay itself has a cost that rarely gets counted. Wait for certainty and you'll make the decision late, and by default.
If you can't name three ways a plan could fail, or three genuine alternatives to your first idea, you haven't thought about it enough. The first option that comes to mind is rarely examined, only accepted. A forced third option surfaces assumptions the first two shared.
Commit to a clear, specific position so it can be usefully argued with, not a vague one nobody can push against. Hold it loosely enough to abandon the moment better evidence arrives. The goal is a position worth attacking, not one worth defending.
Before trusting your specific reasoning for this decision, ask how decisions like it usually turn out elsewhere. Inside-view thinking, believing your situation is different, is where most bad forecasts and blown timelines start. Base rates are a humbling, reliable check on optimism.
When the outcome is genuinely uncertain, prefer the path that keeps future choices open over the one that locks you in early. Optionality has a cost, so don't default to it when a decision is actually reversible or the information is already clear. Under real uncertainty, it's the cheapest insurance you can buy.
04 Techniques & Models
No single technique works for all decisions. Match the model to the decision type, the stakes, and the time available. The goal is a toolkit, not a single method applied everywhere.
A structured framework for choosing how collaborative a decision should be, based on two factors: quality requirements (does the right answer depend on expertise?) and acceptance requirements (does success depend on buy-in?). Ranges from purely autocratic through consultative to fully group-based. If the team won't accept a unilateral decision and their buy-in matters for execution, choose consultative or group mode. If you have the information and execution doesn't require their commitment, decide alone and inform clearly.
Imagine the decision has been made and it's failed, badly. Write the story of why. Pre-mortems surface risks and failure modes that optimistic planning misses. They also improve psychological safety: it's much easier to say "here's how this could fail" than "I think this is a bad idea."
"It's 12 months from now. This decision led to significant problems. What went wrong, and why?" Run individually before group discussion to avoid groupthink.
Specific risks and failure modes, not generic concerns. Use them to stress-test the decision and add mitigations, or change the decision if risks are severe enough.
Map the forces pushing towards the desired outcome (driving forces) against those pushing away (restraining forces). Score each by strength. If driving forces significantly outweigh restraining forces, the decision has a reasonable chance of succeeding. If not, either strengthen the drivers, reduce the restraints, or reconsider. Particularly useful for organisational changes where the technical decision may be clear but the human resistance is underestimated.
Define the criteria that matter (cost, speed, risk, reversibility, team capability). Assign a weight to each based on importance. Score each option against each criterion (1–5). Multiply score by weight, sum the totals. Use the result as a prompt for discussion, not a mechanical answer.
The OODA Loop is most valuable as an accelerant in fast-moving situations: incidents, competitive pressures, rapidly changing requirements. The key is shortening the loop: faster observation, faster orientation through prepared mental models, rapid low-stakes decisions, and immediate action that generates new observable data. Teams that have pre-built their Orient stage (clear principles, agreed frameworks) move through the loop faster than those building context from scratch under pressure.
Project yourself to age 80 looking back. Which decision would you regret more: acting or not acting? Jeff Bezos used this to evaluate leaving a comfortable career to start Amazon. It works equally well for career decisions, build-vs-buy calls, and architectural pivots. It cuts through short-term anxiety to surface long-term values. Pair with a time-limited commitment: "We will try this for 90 days and revisit." This turns a scary irreversible-feeling decision into a Type 2 one.
05 Documenting Decisions
Undocumented decisions are liabilities. They create onboarding debt, repeat arguments, and a fog of "I thought we decided this?" Documentation doesn't slow decision-making. Poor documentation reverses it, repeatedly.
Request for Comments
When: Before a significant decision is made. You're proposing something and seeking structured input.
Purpose: To gather the right perspectives, surface concerns, and build alignment, not to get permission.
Good RFC structure: Problem statement. Proposed solution. Alternatives considered. Questions seeking input. Decision timeline and owner.
Common mistakes: RFCs that are really announcements. RFCs with no deadline. RFCs sent to everyone.
Architecture Decision Record
When: After a significant architectural or structural decision is made.
Purpose: To create a durable record of the reasoning so that future engineers understand context, especially when they want to challenge it.
Good ADR structure: Status (proposed / accepted / superseded). Context. Decision. Consequences (positive and negative).
Common mistakes: ADRs without rejected alternatives. ADRs never updated when superseded. ADRs stored where nobody finds them.
RFC vs. ADR: the practical difference
An RFC is a conversation starter. An ADR is a conversation record. Most significant decisions warrant both: an RFC to gather input and converge, followed by an ADR to record the outcome. For smaller decisions, an ADR alone is sufficient.
06 Risks & Biases
Decisions fail in patterned ways: individual judgement gets distorted by cognitive bias, ownership gets ambiguous the moment a decision crosses a team boundary, and the same failure modes recur across teams who've never talked to each other. Naming these risks is the first step to interrupting them.
↓ Click any subsection to explore
Confirmation bias, sunk cost fallacy, and groupthink: the patterns that distort judgement, and how to counter each one.
Seeking what confirms
We favour information that confirms our existing beliefs and discount information that challenges them. In decisions, this means seeking out people who agree, and misinterpreting data that contradicts our hypothesis.
Throwing good after bad
Continuing to invest in a decision because of what has already been spent, regardless of whether continuing makes sense going forward. Common in long-running projects, platform decisions, and hiring decisions.
Harmony over accuracy
Groups suppress dissent and converge on consensus prematurely, prioritising social cohesion over quality of reasoning. It feels like alignment, but is actually pressure to conform.
When a decision's consequences extend beyond a single team's boundary, ownership becomes ambiguous and friction follows.
When a decision's consequences extend beyond a single team's boundary, the process changes. Ownership becomes ambiguous, timelines clash, and competing priorities create friction. This is where most organisational decision debt accumulates.
When a Decision Escapes a Team
A decision has escaped its team's boundary when another team's work depends on its outcome, it affects a shared resource or platform, it has compliance or security implications, or its timescale extends beyond one team's sprint.
At the boundary, the first task is re-establishing DACI across teams. Without this, cross-team decisions drift indefinitely.
Stakeholder Mapping
Map stakeholders by two dimensions: influence (can they block or enable?) and interest (how much do they care?). Prioritise high-influence, high-interest stakeholders for Consulted roles. A stakeholder not mapped is one who discovers your decision after it's made, and whose objection arrives too late to be useful but too early to be ignored.
Managing Conflicting Interests
When teams have legitimately competing priorities, the resolution is almost never "compromise." Compromises on cross-team decisions produce solutions that satisfy nobody and optimise for nothing. Surface the underlying objective each team is serving. When a shared solution isn't possible, escalate to the level where both teams share an Approver.
The same failure modes recur across teams. Naming them is the first step to interrupting them.
| Failure Mode | What it looks like | Principle that addresses it | Technique that addresses it |
|---|---|---|---|
| Analysis Paralysis | The team keeps gathering more data and deferring the decision, indefinitely. | Bias toward action. Type 2 decisions don't deserve Type 1 processes. | Timebox the decision. Use weighted scoring to converge options. |
| Premature Closure | The team lands on the first reasonable option and stops exploring alternatives. | Separate signal from noise. Challenge the first option before closing. | Pre-mortem analysis. Weighted scoring. Devil's advocate role. |
| Decision by Committee | Too many Approvers. Requires unanimous agreement, producing watered-down outcomes or no decision at all. | DACI: exactly one Approver. Disagree and commit once decided. | Vroom-Yetton for involvement level. DACI to clarify ownership before the meeting. |
| HiPPO Override | The most senior person states their view and the team implicitly converges, regardless of correctness. | Psychological safety. Leaders model intellectual humility. Independent views first. | Anonymous scoring before discussion. Pre-assigned devil's advocate. Written inputs before meetings. |
| Implicit Decisions | Decisions are made by default, through inaction, assumed consensus, or unchallenged assumptions. | Decision debt is real. Name what you're deciding before you decide it. | Decision log. ADRs. RFC process. Regular decision archaeology. |
07 Escalation Pathways
Escalation is a routing decision, not a failure. The failure is escalating too early (wasting senior attention) or too late (letting a stuck decision block delivery indefinitely).
Timebox first, escalate second
Before escalating, set a deadline: "We will decide by [date] or escalate." Most stuck decisions resolve when a timebox is added. Indefinite deferral is itself a decision, usually a bad one.
Escalate with a recommendation, not just a problem
Arrive with: the decision you need made, your recommended option, alternatives considered, the risks of delay, and the ask: "we need a decision by [date]." Escalating without a proposed solution dumps cognitive load upward and slows resolution.
Route to the right level, not the highest available
Escalation should go to the lowest level of authority that has the mandate to resolve it. Going straight to the CTO for a team-level decision an EM could resolve signals poor calibration. Identify who shares Approver authority over the conflict and start there.
Set a resolution timebox at the escalation level
Escalation without a deadline creates a new deferral point at a higher level. Name the deadline explicitly: "We need a decision within 48 hours or we will proceed with option A as the default." This forces the system to engage, or to consciously accept the default.
If escalation fails, decide anyway
If the deadline passes, make the most reversible available decision. Document the decision, the escalation attempt, and the outcome. A decision made and recorded, even a suboptimal one, is usually better than indefinite paralysis. The record protects everyone.
08 Decision Health Self-Assessment
How does your team's decision-making actually function? Rate each dimension honestly. The composite score reflects overall decision discipline. Track it quarterly, and a rising trend compounds directly into delivery speed and quality.
Decision Health Check
09 The Decision-Making Runbook
Eight repeatable steps for any significant decision. Not every decision needs all eight, but every decision benefits from knowing which steps to apply and in what order.
Classify
Name the Decision Clearly
Can you write the decision in one sentence? If not, you don't have a decision. You have a problem to explore. Naming it precisely separates it from assumptions and tasks, and sets the scope for what comes next.
- Write the decision as: "We are deciding whether to [option A] or [option B...]"
- Classify as Type 1 (irreversible) or Type 2 (reversible)
- Identify the decision's boundary: within one team's authority or cross-boundary?
- List the key assumptions underlying each option: surface them before evaluating
- Output: a one-sentence decision statement with a Type classification
DACI
Establish Ownership Before Anything Else
Before discussing options, agree who plays each DACI role. This single step prevents the most common failure mode: wrong people in the room, right people not in the room, no clear Approver.
- Name the Driver: who is responsible for moving this forward?
- Name the Approver: one person, not a group
- Name the Consulted: who must be heard before the decision is made?
- Name the Informed: who needs to know the outcome?
- If cross-boundary, re-run DACI at the cross-team level before proceeding
- Output: completed DACI with named individuals for each role
Mode
Choose Sync or Async
The default should be async. Synchronous decisions are the exception, reserved for high-stakes, high-ambiguity situations where live dialogue changes the quality of the output.
- Is this well-enough scoped to resolve asynchronously? If yes, write an RFC and set a comment deadline
- Does it require live dialogue? If yes, schedule a focused meeting with pre-reading
- For async: "No response by [date] = agreement with the proposed option"
- For sync: send a pre-read. No surprises in the room, only discussion of unresolved issues
- Output: chosen mode with a decision deadline set
Technique
Apply the Right Tool
Match the technique to the decision type. Not all decisions need a formal model, but knowing which tool to reach for speeds up the process significantly.
- Multiple structured options? Weighted scoring matrix: agree criteria before scoring
- High-stakes Type 1? Pre-mortem: imagine failure and work backward
- Unsure how much to involve others? Vroom-Yetton
- Evaluating a change? Force field analysis
- Fast-moving situation? OODA loop: shorten the observe-to-act cycle
- Output: chosen technique applied, key outputs documented
Signal
Separate Signal from Noise
Before evaluating options, explicitly filter the inputs. For each piece of information: would this change our decision if it turned out to be wrong? If no, it's noise.
- List the information inputs you're working with
- Flag each as: High-signal (decisive), Context (useful but not decisive), Noise (irrelevant)
- Check for confirmation bias: are you weighting information that confirms your preferred option?
- Assign a devil's advocate to challenge the leading option with high-signal counter-evidence
- Output: a filtered input set with explicit noise removed
Decide
Make the Call and Document It
The Approver decides. The decision is recorded, immediately, not later. The record includes what was decided, why, what was considered and rejected, and who made the call.
- The Approver makes the call, even if not the most vocal voice
- Write an ADR (architectural decisions) or a decision log entry (operational decisions)
- Record the rejected alternatives and why they were rejected
- Note the confidence level and conditions under which you'd revisit
- Output: recorded decision with rationale and context
Commit
Communicate, Align, and Execute
A decision not communicated is a decision not made. Inform all I stakeholders. Close the loop with Consulted parties. Disagree and commit is the expectation of everyone on the team.
- Inform all I stakeholders, with the what, why, and what it means for them
- Close the loop with Consulted parties: "Your concern about X was noted. We decided Y because Z."
- Address vocal disagreement directly: acknowledge, explain, invite commitment
- Update dependent plans, roadmaps, or backlogs the decision affects
- Output: all stakeholders informed, decision actively implemented
Review
Learn from the Outcome
Schedule a decision review at the point when you can actually measure the outcome, not immediately after implementation. The goal is improving the team's decision-making model, not judging the decision-maker.
- Return to the decision record at the pre-agreed review date
- Did the outcome match the prediction? If not, was the decision wrong or the execution wrong?
- If new information would have changed the decision: update the ADR and note what you learned
- Celebrate good process even when outcomes are bad. Penalise good outcomes from bad process.
- Output: decision record updated, lessons fed back into team norms
10 Quick Wins to Start This Sprint
Each of these takes under an hour and starts building the habits the framework depends on. Pick two and do them this week before touching the full runbook.
Classify your next three pending decisions as Type 1 or Type 2
Just this one question changes how much process each one deserves. Most decisions that feel like Type 1 are actually Type 2. Act accordingly.
Run DACI on one decision you're currently involved in
Who is the Driver? Who is the single Approver? If you can't answer both, that's why the decision is stuck.
Find one decision in analysis paralysis and timebox it
Name the decision, name the deadline, name the Approver. "We will decide by Friday." This alone resolves more stuck decisions than any framework.
Write your first ADR, even a rough one
Pick the most significant architectural decision not documented in the last 6 months. Four fields: status, context, decision, consequences. 20 minutes now saves hours next year.
Run a pre-mortem on a decision you're about to make
"It's six months from now. This decision caused significant problems. What went wrong?" Do it individually, in writing, before the group discussion. You'll surface concerns that would otherwise stay silent.
Convert one scheduled meeting into an async decision
Write the proposal, share with the relevant Consulted, set a 48-hour comment deadline. If no material objection arrives, the Driver proceeds. The meeting was never needed.
Ask your team: "What decision are we avoiding right now?"
Not as a challenge, as a genuine question in a retro or standup. The answer will likely be something everyone already knows. Naming it is the first step to making it.
Schedule a review for one significant decision you made last quarter
What did you predict? What actually happened? Why was there a gap? Even a 15-minute async review builds the learning muscle. Good decisions get better. Bad ones get diagnosed.
∞ The Golden Rule
The best decision-makers aren't the ones who get it right every time. They're the ones who make decisions at the right level, with the right people, at the right speed, and who systematically learn from the outcomes. A culture of good decision-making compounds. Faster decisions, less debt, stronger alignment, more autonomy. The loop keeps turning.