A team can have sharp people, good data and real urgency and still stall, because nobody is sure who actually gets to call it, and every decision gets treated as if the company's future hangs on it. The fix is rarely "go faster." It's two cheaper questions, asked before the debate: who owns this decision, and how reversible is it? Get those right and most of the friction disappears.

The quick version

  • Two questions, not one. "Who decides?" (decision rights) and "How careful must we be?" (reversibility) are different, answer them separately.
  • RAPID names the roles. Recommend, Agree, Perform, Input, Decide, one Decider, a scoped veto for Agree, and Input that doesn't get to block.
  • One-way vs two-way doors. Reversible calls get a light, fast process; irreversible ones get deliberation. Don't run the heavy process on the light decision.
  • Escalate the decision, not the conflict. Send it up with options and a recommendation attached, not a fight to referee.

The idea in depth: who decides (RAPID)

The cleanest answer to "who decides?" comes from Bain & Company. In their January 2006 Harvard Business Review article "Who Has the D?", Paul Rogers and Marcia Blenko argued that organisations stall not because people are slow but because decision roles are blurry. Their tool, RAPID, assigns five roles to a single decision (the letters are a loose mnemonic, not the order of play):

flowchart LR
  I(["Input, facts, no veto"]) --> R("Recommend, frames options")
  A(["Agree, scoped veto"]) --> R
  R --> D("Decide, one accountable owner")
  D --> P("Perform, executes")
RAPID puts one accountable owner at the centre: Input and Agree feed the Recommender, the Decider chooses, Perform delivers. Leaders Loop
  • R, Recommend: builds the proposal, gathers the facts, lays out real options and trade-offs.
  • A, Agree: holds a formal veto, but only on narrow, pre-agreed grounds (legal, safety, budget). Not a general "I'd have done it differently."
  • P, Perform: executes once the call is made.
  • I, Input: supplies facts and perspective to the Recommender, consulted, but cannot block.
  • D, Decide: the single person who chooses. One D. Not a committee.

The two moves that make RAPID more than a tidy acronym are the single Decider and the scoped Agree. Most decision paralysis is really an unbounded-veto problem: five people each behave as if they can block, so consensus becomes the floor and nothing ships. Naming one D, and confining the veto to specific grounds, separates "I want to be heard" (Input) from "I can stop this" (Agree). So the move is: before a contested decision, write the five roles on one line, "D: Priya. A: Legal (privacy only). R: the squad. I: Sales, Support. P: Eng.", and circulate it. The argument that follows is now about the decision, not about who's allowed to make it.

Bain's follow-up book Decide & Deliver (Blenko, Mankins & Rogers, 2010) adds a blunt rule of thumb: past about seven people in a decision group, each extra member tends to cut effectiveness by roughly 10%. Treat it as a practitioner heuristic from one firm's data, not a law, but as a reason to keep the Decide-and-Agree circle small, it holds up.

"Who decides?" and "How careful must we be?" are different questions. Most teams collapse them into one, and then argue about both at once.

The idea in depth: how reversible (one-way and two-way doors)

RAPID tells you who. It says nothing about how much process the call deserves, and matching process to stakes is the second half of the job. The most usable lens here is Jeff Bezos's, from Amazon's 2015 and 2016 letters to shareholders. He splits decisions into two types by their reversibility:

  • Type 1, one-way doors. Consequential and hard to reverse. Once you walk through, you can't easily walk back. These deserve deliberation, consultation and care.
  • Type 2, two-way doors. Changeable. If the call turns out wrong, you reopen the door and walk back. As Bezos put it, "Many decisions are reversible, two-way doors. Those decisions can use a light-weight process."

His warning is the part leaders miss: as organisations grow, they tend to apply the heavy one-way-door process to everything, including the two-way doors. The result, in his words, is "slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention." The cost of treating a reversible call as if it were irreversible is invisible, it shows up as a culture that can't move, which is exactly why it goes unfixed.

flowchart TD
  S(["A decision arrives"]) --> Q{"Cheap to reverse?"}
  Q -->|"Yes, two-way door"| F("Light process: one D decides fast, ~70% of the info")
  Q -->|"No, one-way door"| C("Heavy process: consult, name the Agrees, decide slowly")
  F --> M("Ship, watch, walk back if wrong")
  C --> M
Reversibility sets the process; RAPID sets the people. Run the two checks before, not during, the debate. Leaders Loop

Pair this with Bezos's companion rule: decide at roughly 70% of the information you wish you had; waiting for 90% usually just means you were slow. That figure is illustrative, a calibration, not a measurement you can take, but the discipline is real: for two-way doors, the cost of a late decision usually beats the cost of an occasionally wrong one. So the move is: when a decision lands, ask one question first, "if this turns out wrong, what does it cost us to walk it back?" Cheap to reverse → push it down to a single D and decide this week. Expensive to reverse → that's where the deliberation, the named Agrees and the slower clock belong.

An honest limitation: both tools assume you can read the door correctly, and people are reliably bad at it. Loss aversion makes us treat reversible calls as one-way doors ("what if it's my name on it?"), and a few genuine two-way doors are quietly one-way, a "reversible" pricing experiment can burn trust you don't get back. Annie Duke's Thinking in Bets (Portfolio, 2018) makes the related point: judge a decision by its process and odds, not by how it happened to turn out. RAPID and the door test are scaffolding for that judgement, not a substitute for it, and they bite hardest on risk vs uncertainty vs ambiguity, where under deep ambiguity even "reversible" is a guess.

The idea in depth: escalation done well

Escalation is where decision rights get tested, and where most cultures go wrong, either nobody escalates (and bad calls stand) or everything escalates (and the top becomes the bottleneck). Clear RAPID roles tell you exactly when escalation is legitimate: the decision crosses the Decider's authority; an Agree withholds a veto on valid grounds; or it's a one-way door whose blast radius is bigger than the current owner's accountability.

The failure mode is escalating the conflict instead of the decision, two people walk into a director's office wanting a referee. So the move is: escalate with a package, not a complaint, the decision, the options, the recommendation, and the specific disagreement. Borrow Amazon's disagree and commit: once the D decides, dissenters commit fully rather than relitigating. Argue hard before the line; row together after it. That single norm is what lets a team move fast without pretending it agrees on everything.

flowchart TD
  X(["Stuck on a decision?"]) --> Y{"Crosses the D's authority, or a one-way door beyond their accountability?"}
  Y -->|"No"| Z("Let the D decide; others disagree and commit")
  Y -->|"Yes"| E("Escalate the decision: options + recommendation + the disagreement")
Escalate the decision, not the conflict, and only when it genuinely outgrows the owner. Leaders Loop

A worked example

A product squad at a mid-size SaaS company wants to drop a rarely-used "export to CSV" feature to free up engineering time. The debate has dragged for three weeks across two Slack threads and a tense stand-up. (Names and figures below are illustrative.)

First, the door. Reversing this is cheap: they can hide the button behind a flag and restore it in an afternoon if churn spikes. Two-way door, so it gets a light process and a fast clock, not a steering-committee. Second, the roles, written on one line: D: Maya (PM). R: the squad. A: Security (only if export touches a compliance obligation). I: Customer Success, two enterprise account managers. P: Engineering.

Suddenly the three-week stall is legible. Customer Success had been behaving like an Agree, implicitly vetoing, when they were really an Input. Their data (roughly 40 accounts use export monthly, illustrative) is real and informs Maya's call; it doesn't block it. Security checks the one thing that could make this a one-way door, a contractual data-export commitment, finds none, and steps aside. Maya decides Thursday: flag it off for most accounts, keep it live for the 40, revisit in 30 days. The dissenting account manager disagrees and commits. What unblocked it wasn't new information; it was naming the door and naming the D.

Frequently asked questions

What is the difference between RAPID and RACI?

RACI maps tasks to people (Responsible, Accountable, Consulted, Informed). RAPID maps a single decision to roles. The pieces RAPID makes explicit that RACI tends to blur are the one named Decider and the scoped, real veto for Agree, the two things that actually unstick decisions.

How do I know if a decision is a one-way or two-way door?

Ask what undoing it would actually cost, the time, the money, and the hit to your credibility. Reversible within a sprint at low cost? Two-way door: decide fast and low. Slow, expensive or reputation-damaging to unwind? One-way door: slow down and consult. When unsure, ask whether you could run it as a small, reversible test first.

Who should be the single Decider?

The person closest to the trade-off who is also accountable for the result. The D is a role for one decision, not a rank, a senior leader can quite happily be the Input or the Agree on a call a frontline manager owns. Resist making the most senior person the default D; that's how you recreate the bottleneck.

When should a decision be escalated?

When it crosses the Decider's authority, when an Agree exercises a legitimate veto, or when a one-way door's consequences exceed the owner's accountability. Escalate the decision with options and a recommendation attached, not the argument for someone else to settle.

Doesn't assigning decision rights just add bureaucracy?

Only if you do it on every trivial call. Done once, up front, for the genuinely contested decisions, it removes the recurring tax of re-arguing who decides. The bureaucracy you can feel is usually the absence of clear rights, not their presence.

Related in the Toolkit

Where to go next