Decision Architecture: Stop Leaving "Who Decides, and How" to Luck
Topic: Decision Architecture·4 tools
"Disagree and commit." — Jeff Bezos, 2016 shareholder letter
This week's premise: the bottleneck for a rising tech leader is rarely "can't make a technical call." It's that the organization's decision machinery is broken — nobody knows who decides, reversible trivia gets a heavyweight process, while big irreversible bets get rubber-stamped with "let's just ship and see," and after the call people keep grinding against it. This issue gives you four tools answering four questions: how heavy a process does this decision deserve (decision types), who decides (RAPID), how to make everyday decisions fast (DACI), and how to get everyone to truly execute once it's decided (Disagree and Commit).
TOOL 01
Sort by Decision Type: First Ask Whether the Door Swings Back
Type 1 vs Type 2 — Match Process to Reversibility
ReversibilityMechanismProcess weight
The Principle in One Line
Triage before you decide: a two-way door (reversible) gets delegation, speed, tolerance for trial and error; a one-way door (irreversible) is what deserves slowness, consensus, and your personal attention. Process weight should match the cost of the decision — not the size of your anxiety.
In Their Words
"Some decisions are consequential and irreversible or nearly irreversible — one-way doors — and these decisions must be made methodically, carefully, slowly. But most decisions aren't like that — they are changeable, reversible — they're two-way doors."— Jeff Bezos, Amazon shareholder letter 2015
Scene
Situation: two decisions land at once — (1) whether to migrate the core order service from MySQL to a new distributed database; (2) which logging library to use this sprint.
✗ The common move
You give both the same process: review meeting, full-team vote, long RFC. The logging library debate drags on for two weeks; the database migration, by contrast, gets rubber-stamped with "let's ship and see" because everyone's tired — you ran your most dangerous one-way door through the lightest process.
✓ The fix (classify first, then pick the process)
Logging library (two-way door): "We can swap it back in a day. I'm delegating this to X — decide it today, no meeting."
Database migration (one-way door): "Once the data is moved, there's basically no going back. This earns a two-week RFC, the DBA and SRE in the room, and my personal sign-off." Spend "slow" only on the one place that deserves it.
The 30-Second Triage Checklist
Is this reversible? Is the rollback cost hours, weeks, or impossible?
Does it touch one team, or span many teams / commit us externally?
Can we survive the worst case? (A two-way door survives even if it's wrong.)
Am I forcing a heavyweight process onto a reversible call? (The #1 source of decision paralysis.)
Am I running an irreversible call through too light a process? (This one is more dangerous.)
Common Mistakes
One-size-fits-all process. Demanding consensus for everything treats every two-way door as a one-way door — the team grinds to a halt.
Using heavy process to dodge accountability. Adding approvals to small calls looks "rigorous" but really dilutes "I decided" into "we all decided together."
Mistaking "hard to build" for "irreversible." A big engineering lift isn't necessarily a point of no return; many big projects are gradually rollable, reversible two-way doors.
Key References
Jeff Bezos, Amazon shareholder letters (2015 / 2016) — the origin of "one-way / two-way door," now industry vernacular.
TOOL 02
RAPID: Give "Who Decides" a Definite Answer
RAPID — Who Has the D?
Decision rightsCross-teamRole assignment
The Principle in One Line
When a cross-team decision is stuck, the problem is almost never "not enough information" — it's that nobody knows who decides. RAPID splits a decision into five roles: Recommend, Agree (holds a veto), Perform, Input, Decide. The one rule that matters most: the D must be a single person.
In Their Words
"Decisions are the coin of the realm in business. Every success, every mishap, every opportunity seized or missed is the result of a decision someone made or failed to make."— Rogers & Blenko, "Who Has the D?" HBR, 2006
The letters are a mnemonic, not a sequence; the real order is usually I→R→A→D→P.
Scene
Situation: three teams need to split a monolith into microservices. Five meetings in, still no conclusion.
✗ The common move
Every meeting is "so, what does everyone think?" The loudest voice wins the room, nobody owns the outcome, and next week starts from zero. Democratic in appearance, accountable to no one in practice.
✓ The fix (send a RAPID before the meeting)
"The split-boundary proposal is Recommended by the Platform Lead; SRE has Agree (veto) on availability impact; DBA and each product team give Input; Decide = me (BigCat); once set, the three teams Perform."
Open the meeting with the frame: "This meeting has one purpose — hear the Recommend, collect Input, then I give the D in the room."
Self-Check Before Using RAPID
Does this decision have exactly one D? (Two Ds = no D.)
Does each Agree (veto) have a legitimate reason to veto? Over-issuing A's causes paralysis.
Does the Recommender have real voice, or are they just "drafting for the boss to rewrite"?
Do the Input people know they aren't voting? Say so up front, or they'll feel ignored afterward.
Common Mistakes + A Note for Women
Handing out too many A's (vetoes). Each extra A is another chokepoint; the decision dies in sign-offs.
The D landing on the highest-ranking person rather than the most accountable one. RAPID's whole value is decoupling the decision from the org chart.
Letting Input think they're voting. Afterward that group feels "my view was ignored."
Female Leader's Note
Research repeatedly shows women are more often assigned Recommend / Perform (drafting, executing) while the D lands on a male colleague — and that a woman's proposal in a meeting is more likely to be "restated" and credited to someone else. A proven counter is amplification (used by women on Obama's White House staff): when a woman makes a key point, another person immediately repeats it and names her — "that's X's proposal." Writing down "who is Recommend, who is D" in a RAPID is itself a mechanism that stops contribution from quietly migrating.
Key References
Paul Rogers & Marcia Blenko (Bain & Company), "Who Has the D? How Clear Decision Roles Enhance Organizational Performance," HBR, 2006 — the original RAPID paper.
TOOL 03
DACI: Lightweight Decision Rights for Engineering Teams
DACI — Lightweight Decision Rights
LightweightSingle DriverEveryday calls
The Principle in One Line
RAPID fits big, cross-org decisions that need a formal record; everyday in-team decisions need something lighter — DACI: Driver (drives it forward, doesn't necessarily decide), Approver (the single decider, usually 1 person), Contributors, Informed. One page, one doc, ten minutes.
In Their Words
"The whole decision-making process can be summed up in three phrases: free discussion, a clear decision, and full support."— Andy Grove, High Output Management, Ch.5
Scene
Situation: every small call (axios vs fetch, whether to add a pre-commit hook, API naming style) gets dragged into a full-team vote. Engineers are irritated, and decisions keep getting slower.
✗ The common move
Afraid of being "undemocratic," you discuss everything with the whole team. A lint rule eats 40 minutes; a senior engineer privately complains "everything needs a meeting." Consensus culture has become an efficiency black hole.
✓ The fix (establish a DACI norm)
"For in-team calls like these, the proposer is the Driver and writes a half-page doc: context, options, recommendation. The Approver defaults to me or a tech lead I name — one person. Contributors comment in the doc async for 48 hours. At the deadline the Approver decides, writes down the reasoning, and broadcasts one line to the Informed."
How to choose the tool: 3+ teams / irreversible / needs a formal record → RAPID; in-team / reversible / needs speed → DACI.
Self-Check Before Starting a DACI
Does this really need a meeting, or is a DACI doc + async comments enough?
Is the Approver exactly one person? (Not "a few of us will figure it out.")
Do Contributors have a deadline for input? Input without a deadline drags forever.
Is the decision recorded? In three months, when someone asks "why did we choose this," can they find the answer?
Common Mistakes
Using DACI on a big irreversible decision. A lightweight tool can't carry high risk — that should escalate to RAPID + RFC.
Driver and Approver being the same person without noticing. You lose the separation between "drive" and "gatekeep," and slide back to one-person rule.
Not recording the decision. The team re-decides the same question over and over, arguing from scratch each time.
Key References
DACI originated at Intuit and was popularized by the Atlassian Team Playbook ("DACI: a decision-making framework"). Andy Grove, High Output Management, Ch.5 — the "free discussion → clear decision → full support" model.
TOOL 04
Disagree and Commit: The Discipline After the Decision
Disagree and Commit — The Discipline After the Decision
DissentExecutionTeam commitment
The Principle in One Line
Dissent belongs before the decision; execution belongs after it. Once the D is made, even if you disagree, you execute fully — not pay lip service, undermine it behind the scenes, or hold back waiting to say "I told you so." This is the dividing line between high-output teams and self-grinding ones.
In Their Words
"If you have conviction on a particular direction even though there's no consensus, it's helpful to say, 'Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?'"— Jeff Bezos, Amazon shareholder letter 2016
Scene
Situation: in an architecture review you argue for SQS for the message queue (simple, sufficient); most of the team and your boss lean toward Kafka. The D (your boss) lands on Kafka.
✗ The common move
You say "fine" out loud, then snipe in the team channel — "not my call anyway." The moment Kafka has trouble, your first line is "I said SQS was better." The team learns that dissenters hold grudges and wait for things to fail — so next time nobody dares to decide.
✓ The fix (dissent clearly before, commit clearly after)
Before the decision: "Let me put my objection on record: SQS has lower ops cost, and our throughput won't reach Kafka's sweet spot within two years."
After the decision: "Okay, it's Kafka. I disagree, but this is a reversible technology choice, not a one-way door. I'm fully behind it — I'll write the migration plan and genuinely help it succeed; I won't be secretly rooting for it to fail."
Self-Check Before You Commit
Did I voice my dissent fully and clearly before the decision? (Speaking up only afterward doesn't count.)
Once it's set, are my words and actions consistently behind it?
Am I harvesting "I told you so" behind the scenes? (Team poison.)
If this is irreversible and I judge it genuinely harmful — did I escalate, or am I using "commit" to avoid conflict?
The Boundary (Stated Honestly)
Disagree and commit does not apply to "irreversible + high-risk + you judge it will cause real harm" decisions — those require a formal escalation, not silent commitment. Using "agree to disagree" as a universal shield is abdicating your responsibility as a professional.
Common Mistakes + A Note for Women
Treating silence as agreement. No objection ≠ genuine buy-in; bottling it up until after the decision does the most damage.
Using "disagree and commit" to suppress dissent that hasn't been fully voiced. That's an abuse — it becomes "shut up and execute."
The decider treating commit as "no more discussion." Forbidding a revisit even when new evidence appears is just stubbornness.
Female Leader's Note
Women voicing dissent are more readily labeled "not a team player" or "difficult," while the same objection from a man reads as "having conviction." One counter: anchor the dissent explicitly in data and shared goals ("for the SLA, what worries me is X"), and then, immediately and visibly, signal support once it's decided. This combination — object clearly, then commit clearly — actually builds reputational capital as "reliable, plays the issue not the person."
Key References
Jeff Bezos, Amazon shareholder letter 2016 — the origin of "disagree and commit." Patrick Lencioni, The Five Dysfunctions of a Team — "Commitment is a function of clarity and buy-in": commitment isn't consensus, it just needs clarity + being heard.
This Week's Exercise · Your Day 15 Action
This week, do one concrete thing — not reflection, not reading:
Pick one decision that's stuck in front of you this week. Step 1: run Card 1's 30-second triage — one-way door or two-way? Step 2: pick the tool by scale — cross-team, draw a RAPID (write down in black and white who the single D is); in-team, start a half-page DACI doc (one Driver, one Approver, a 48-hour async input window). Get this decision to "actually owned and landed" this week.
Afterward, log one line: how long did it take from kickoff to the call? Faster or slower than the last decision of this kind?
Go Deeper
When does a "single Decider" actually do harm?
Both RAPID and DACI stress a single decider, but for highly specialized decisions where information is widely dispersed (security architecture, compliance boundaries), one person deciding can systematically miss critical input. What such decisions really need isn't "more voting rights" but a structured way to funnel scattered knowledge to the D (pre-mortems, red-team reviews). Ask yourself: am I chasing decision speed, or using "single D" to avoid the hassle of letting different expert views collide on the table?
How does RAPID/DACI land differently in steep-hierarchy vs flat cultures?
In rigidly hierarchical organizations, whether "D = a non-most-senior person" written in a doc actually holds depends on whether the top leader publicly backs the mechanism — otherwise the paper D gets overridden by "one word from the boss." Flat cultures have the opposite risk: everyone feels they have input rights, so no one is willing to be the single D. The framework is neutral; whether it lands depends on who's backing it.
Where's the line between "disagree and commit" and "playing it safe, following the crowd"?
The outward behavior looks similar (both end up supporting a call they don't fully endorse); the difference is before the decision: a true committer voices clear, on-the-record dissent first, then executes fully; the crowd-follower never speaks up, to avoid accountability. The test: did this person put their objection on the table before the call? If someone always "knew it all along" only afterward, that's not commitment — it's evasion.
Speed vs quality — which way should your team tune?
Over the past year, did "deciding too slow" or "deciding too carelessly" cause more harm? The answer tells you whether to add process or strip it. A common misjudgment: the problem is clearly "too slow" (heavyweight process even on two-way doors), but after one careless decision blows up, you add approvals to everything — dragging the whole team into paralysis. Diagnose the dominant cause first, then prescribe.
Should every decision carry a two-line "why" record?
The long-term value of a decision log (ADR) is routinely underrated: it spares the team from re-litigating the same question from scratch, and lets newcomers quickly grasp "why we chose this back then." The cost is each Approver writing two extra lines of reasoning. The question: in your team, has the waste from "re-deciding" without records grown big enough to justify that friction? For most growing engineering teams, the answer is yes.