RAPID vs DACI: Fixing the 'Who Actually Decides' Problem

Most decisions that stall aren't intellectually hard — they're organizationally undefined, with nobody clearly told they own the call. RAPID and DACI are both decision-rights frameworks that name one accountable owner and separate that person from everyone who merely has input, giving debate an endpoint. Use RAPID for complex, cross-functional bets; use DACI for lighter, team-level decisions.

Quick Answer: RAPID (Recommend, Agree, Perform, Input, Decide) fits high-stakes, multi-team decisions where a formal Agree step matters before one person commits. DACI (Driver, Approver, Contributors, Informed) fits faster, single-team decisions with one Driver and one Approver. Both collapse the moment "Agree" or "Approver" quietly grows past two or three names.

Why Decisions Stall: Diffuse Accountability, Not Difficulty

Decisions stall for a structural reason, not an intellectual one: too many people can weigh in, and no one is clearly on the hook for what happens next. When accountability is diffuse, every stakeholder is behaving rationally — adding a caveat, requesting more data, waiting for someone else to move first — because committing carries a risk that no single person is assigned to own.

Bain's Paul Rogers and Marcia Blenko, who popularized RAPID in a widely cited Harvard Business Review piece, found this pattern showing up as a repeatable set of behaviors rather than as genuine analytical deadlock:

• Everyone consults, no one decides. A dozen people are "involved," but the decision doc has no name in the final-call box.
• The loudest voice wins by default. Without a designated decider, the person with the most tenure or political capital fills the vacuum — whether or not they have the best judgment.
• Re-litigation after the fact. A choice gets made in one meeting and quietly reopened in the next, because no one was empowered to close it.
• Escalation as a habit. Middle managers route routine calls upward because ownership was never actually pushed down to them.

Patrick Lencioni's work on organizational health makes a related point: teams that can't commit to a decision usually have a prior problem with unresolved conflict, not a downstream problem with execution. A leader's own default style compounds this. The affiliative or consensus-seeking styles Daniel Goleman catalogs are excellent for morale, but applied to every decision, they quietly guarantee that nothing gets a single owner — our guide to Goleman's six leadership styles covers when to deliberately switch out of consensus mode.

McKinsey's research on organizational decision-making has repeatedly found that only a minority of executives believe their companies make good decisions quickly, and that a large share of decision-making time goes toward decisions that recur without ever being resolved cleanly. That's the diffuse-accountability disease showing up in survey data: not a shortage of analysis, a shortage of ownership.

Bain's own follow-up research, published in the book Decide & Deliver, found decision effectiveness correlating with financial performance more closely than almost any other organizational trait the firm studied. Fix who decides, and a surprising amount of downstream execution friction — the re-work, the re-litigated meetings, the silent slippage — tends to disappear on its own.

Decision-rights design belongs inside a broader leadership operating system, not as a one-off workshop exercise — see the complete guide to PM leadership for how it connects to hiring, 1:1s, and org design more broadly.

RAPID and DACI at a Glance

RAPID and DACI are both decision-rights frameworks, but they split accountability into a different number of named roles: RAPID uses five (Recommend, Agree, Perform, Input, Decide); DACI uses four (Driver, Approver, Contributors, Informed). The practical difference is that RAPID separates "who builds the recommendation" from "who must formally agree" from "who executes," while DACI compresses several of those into one Driver.

The takeaway: RAPID is built for decisions where the recommendation-writer, the people who must formally agree, and the final decider are genuinely different people or functions — useful when a decision crosses departments with real veto stakes. DACI assumes a simpler chain, one Driver running the process toward one Approver's call, which is faster for a decision that lives inside a single team.

If you've used RACI (Responsible, Accountable, Consulted, Informed) before, both newer frameworks fix its most common failure mode: nothing in RACI stops multiple names from sharing the "Accountable" box, so accountability quietly diffuses right back into committee. RAPID and DACI both insist on exactly one Decide/Approver name — that single constraint is doing most of the work.

When RAPID Fits a Decision

RAPID earns its extra structure when a decision crosses three or more functions, carries a real chance someone will formally object, and is expensive or slow to reverse enough to justify a documented Agree step. It's overkill for anything a single team could resolve in a day.

Four signals suggest RAPID is the right amount of process:

1. Cross-functional scope — pricing, packaging, platform architecture, market entry, anything that changes what other teams must build or sell.
2. Genuine veto stakes — legal, finance, or a general manager whose numbers move as a direct result of the call.
3. High irreversibility — Amazon founder Jeff Bezos's well-known "one-way door" framing is a useful filter here: decisions that are hard to reverse deserve the extra ritual; easily reversible "two-way door" calls don't.
4. A history of re-litigation — if a certain type of decision keeps resurfacing in meetings, that's a direct signal the organization needs a documented Decide seat for it, not another round of discussion.

If none of those four apply, RAPID's ceremony — a written recommendation, a formal agree cycle, a distinct perform hand-off — will slow a decision down without adding real rigor. That's a cost, not a safety margin.

A platform-architecture choice that will constrain three product lines for the next two years is a clean example: multiple functions carry real stakes, reversing it later is expensive, and the recommendation genuinely benefits from a formal technical review before anyone commits. That combination is exactly what RAPID's extra ceremony is for.

When DACI Fits a Decision

DACI earns its keep on decisions that live inside one team or a small cluster of close collaborators, where speed matters more than a formal veto right — feature scope, sprint sequencing, a UX pattern choice, an experiment design. It weakens the moment a decision genuinely needs an outside function's formal sign-off, which DACI doesn't cleanly separate out the way RAPID does.

Atlassian popularized DACI inside its own Team Playbook precisely for this lighter-weight, single-team case, and the framework shows its strength there:

• A product trio deciding which of three onboarding flows to ship next sprint.
• A platform team choosing a caching strategy where the only real stakeholders are inside the team.
• A design system decision where "informed" parties (other pods) just need the outcome, not a vote.

Where DACI gets stretched thin is a decision that looks single-team on day one but turns out to need finance or legal sign-off later — a paid-feature gate, a data-sharing choice, anything touching a contract. If that risk is plausible, start with RAPID's extra Agree seat rather than retrofitting one mid-decision.

A useful gut check: if you can name every stakeholder who could plausibly object in under ten seconds, and none of them sit outside the team, DACI is almost certainly enough. The moment that list requires you to think, or crosses a department boundary, treat it as a RAPID decision instead.

Worked Example: Assigning Roles for a Pricing Decision

A pricing change is a textbook RAPID decision: it touches sales, finance, legal, and product, and a wrong call is both expensive and slow to unwind. Below is one way the five roles might be staffed for a mid-market SaaS price increase, followed by the single most common way this exact setup breaks.

Notice that Perform is its own seat, separate from Decide — the CRO who makes the call almost never personally rewrites a hundred contracts. RAPID makes execution ownership explicit; DACI usually leaves it implicit inside the Driver's job, which is fine at team scale but can quietly drop the ball on a decision this size.

The Input seat is where the decision earns its evidence rather than its politics. Grounding that input in what customers are actually paying to get done — see the complete guide to Jobs to Be Done — beats a survey of internal opinions about what "feels fair." Mapping where price friction actually surfaces along the customer journey, such as a renewal call or a stalled trial, turns Input into a data source instead of a gut-check.

The Too-Many-Approvers Failure Mode

The single most common way this setup fails is scope creep in the Agree seat. What starts as "Finance and Legal must agree" quietly grows to include a Sales VP, a Customer Success VP, and a regional GM — each with an informal veto nobody wrote down anywhere.

Once four or five people can each say no, the decision doesn't have a decider anymore. It has a committee wearing a decider's nameplate.

Three things usually drive this creep:

• Political insurance. The Decide-holder invites extra Agree signers to spread blame if the call goes badly.
• Old grudges. A function burned by a past pricing change insists on veto rights going forward, regardless of relevance to this decision.
• No audit cadence. Nobody revisits the chart after its first use, so an ad hoc "let me weigh in" quietly hardens into a permanent Agree seat.

The fix is mechanical, not diplomatic:

1. Cap Agree at two or three named roles, each tied to a real formal constraint (legal, financial, regulatory) — never a courtesy invite.
2. Convert extra "must agree" requests to Input. They still get heard; they just can't block.
3. Put a review trigger on the chart itself, not just on the decision's substance, so scope creep gets caught before the next high-stakes call.

Sometimes the creep isn't structural, it's personal — one stakeholder consistently treats an Input seat as an informal veto no matter what the chart says. If that continues after a direct conversation about role boundaries, it can become a performance conversation rather than a process fix; the guide on managing someone out with dignity covers that harder, less comfortable case.

Keeping the Decision-Rights Map Alive

A RAPID or DACI chart is only as good as its last update, and most get built once in a workshop, dropped into a slide, and forgotten as roles and stakes shift. Treating decision rights as a living record, tied to who each stakeholder actually is and what they currently care about, keeps the map usable months later, not just on the day it was drawn.

Pair the map with a habit of reviewing decisions after the fact. A decision journal that records what was decided, by whom, and what actually happened next is how you calibrate whether the right person held the Decide or Agree seat, so the chart gets adjusted before the next high-stakes call fails the same way.

A living decision-rights map really only needs to answer three questions on demand, which is a stakeholder record's job far more than a slide's:

• Who currently sits in each seat — updated as people change roles or leave, not frozen at workshop day.
• What stake or interest they hold in this specific decision area, not just their job title.
• What they were involved in before, so a repeat decision isn't staffed from a blank slate.

Key Takeaways

• Diffuse accountability, not analytical difficulty, is what actually stalls most decisions — name one owner, not a committee.
• RAPID's five roles separate the analysis (Recommend), the veto (Agree), and the call itself (Decide) — reach for it when a decision is cross-functional and hard to reverse.
• DACI's four roles compress the chain into a Driver and an Approver — reach for it on faster, single-team decisions.
• The most common failure isn't choosing the wrong framework; it's letting Agree/Approver quietly expand until everyone effectively has a veto.
• Assign names, not job titles, and put a review date on the chart itself so it doesn't silently go stale.
• Ground the Input/Contributors role in real evidence — Jobs-to-Be-Done interviews, customer-journey friction points — not an internal opinion poll.
• A decision-rights map is a living document, best paired with a stakeholder record and a decision journal, not a one-time workshop artifact.