Decision Frameworks for Managers: DACI, RAPID and When to Just Decide

A team of eight spends three weeks "aligning" on which analytics vendor to use. There are two Slack threads with 60 messages each, a comparison spreadsheet nobody finished, two meetings that ended with "let's take this offline," and a growing sense that the decision is cursed. The actual difference between the two vendors? Marginal. The cost of the three weeks? A blown integration deadline and eight people learning that decisions here are painful.

Nothing about the vendor choice was hard. What was missing was structure: nobody knew who was deciding, who was merely consulted, when input closed, or where the outcome would be recorded. Decision frameworks exist to answer exactly those questions — and used correctly, they make decisions faster, not more bureaucratic. Used incorrectly, they become the bureaucracy. This guide covers DACI and RAPID in working detail, the reversibility test that tells you how much process a decision deserves, decision logs, and the underrated option of just deciding.

Why decisions stall (it's almost never the difficulty)

Watch stalled decisions closely and the same five causes appear:

1. No named decider. Everyone assumes consensus is required, so one skeptic can hold the group hostage indefinitely. Consensus is a lovely outcome and a terrible requirement.
2. Unbounded input. With no deadline for comments, there's always one more stakeholder to hear from. Input windows that never close are how three-day decisions take three weeks.
3. Stakes inflation. A reversible choice gets treated like a company-defining commitment because nobody asked "what does it cost to be wrong?"
4. Relitigating. The decision was made — but not written down, so it gets remade every time a new person joins the project or an old skeptic finds a fresh forum.
5. Decision-shaped avoidance. Requesting another analysis, another options doc, another stakeholder review — activities that feel like progress while deferring the moment of commitment.

Frameworks fix the first two. Reversibility thinking fixes the third. Decision logs fix the fourth. Only leadership fixes the fifth, but the other four remove its hiding places.

The reversibility test comes first

Before choosing a framework, size the decision. The most useful sizing question is Jeff Bezos's one-way/two-way door distinction, from his Amazon shareholder letters: is this decision reversible?

Two-way doors — you can walk back through if it's wrong. Trying a new sprint length. Adopting a code formatting standard. Picking the analytics vendor on a monthly contract. The cost of a wrong call is small and mostly refundable, which means the biggest risk is deciding slowly, not deciding wrong. Two-way doors deserve minimal process: an owner decides, informs, and moves.

One-way doors — reversal is impossible or brutally expensive. Choosing your core database. Signing a three-year enterprise contract. A public pricing change. Hiring for a leadership role. These deserve real process: structured input, explicit tradeoff analysis, a written recommendation, deliberate pace.

Two failure modes, and every team has a lean toward one:

• Treating one-way doors as two-way — the startup that "moves fast" into an architecture that takes two years to escape.
• Treating two-way doors as one-way — the enterprise that convenes a committee to choose a standup time.

The second failure is more common and more corrosive, because it's invisible: nobody writes a postmortem for six weeks lost across forty over-processed small decisions. A practical calibration: estimate the cost of a wrong call (money, time to unwind). If unwinding costs less than a week of one person's time, it's a two-way door — decide within 48 hours and skip the rest of this article's machinery.

A useful refinement for the middle ground: doors that are technically two-way but socially one-way. Rolling back a tool the whole team just migrated to is "possible" the way un-throwing a party is possible. Weigh the human cost of reversal, not just the technical one.

DACI, in working detail

DACI — Driver, Approver, Contributors, Informed — comes out of Intuit and was popularized by Atlassian. It's the lighter of the two frameworks and the right default for most team-level decisions.

• Driver — runs the decision process: frames the question, gathers input, writes the recommendation, chases the approver, communicates the outcome. One person. The driver is a project manager for the decision, not necessarily its decider.
• Approver — makes the call. One person. Not a committee, not "leadership." The single most valuable word in DACI is the singular in "Approver."
• Contributors — people whose input is actively solicited because they have relevant expertise or are affected. They're consulted; they don't hold vetoes.
• Informed — people told of the outcome. They get the decision, not a vote.

Worked example: choosing a support platform

The support team (6 people) is outgrowing shared inboxes. The team lead sets up DACI in a one-page doc:

• Driver: Maya (senior support engineer — closest to the pain, not the most senior person; drivers should be chosen for proximity, not rank)
• Approver: Support team lead
• Contributors: two support engineers, one sales engineer (integration touchpoints), finance (contract terms)
• Informed: the wider go-to-market team

Maya writes the decision doc Monday: context, three options with pricing and tradeoffs, her recommendation. Contributors get a hard comment deadline of Thursday noon. Friday, the approver reads the doc and comments, decides in a 20-minute call with Maya, and Maya posts the outcome and rationale to the informed list. Elapsed time: five days. Meeting time consumed: 20 minutes. The same decision run as "let's discuss as a team" is the three-week horror story from the introduction.

Where DACI breaks

DACI wobbles when the approver won't approve (kick it up: an approver who can't decide in a week forfeits the role), when contributors expect their input to be binding (state explicitly in the doc: "input shapes the recommendation; the approver decides"), and when the driver and approver are the same person on contentious calls — workable for small decisions, but for anything political, separating "runs the process" from "makes the call" keeps the process honest.

RAPID, in working detail

RAPID — Recommend, Agree, Perform, Input, Decide — comes from Bain & Company and adds a role DACI lacks. The letters aren't sequential; the actual order of operations is Input → Recommend → Agree → Decide → Perform.

• Recommend — owns the analysis and proposal. Equivalent to DACI's driver.
• Input — consulted parties. Equivalent to contributors.
• Agree — the important addition: people who must formally sign off, typically legal, security, compliance, finance. An Agree is a veto with a badge. Their concerns must be resolved or explicitly escalated — the recommendation cannot proceed around them.
• Decide — the single decision-maker.
• Perform — who executes the decision. Naming this role forces the question "can we actually do this?" before the call is made, and prevents the classic gap where a decision is made but implementation is assumed and unowned.

Worked example: launching in the EU

A 200-person SaaS company considers opening EU sales:

• Recommend: Head of Sales (builds the case: market, pricing, staffing)
• Input: CS lead, product (localization scope), two large EU prospects
• Agree: Legal (GDPR posture, data residency) and Finance (entity setup, VAT)
• Decide: CEO
• Perform: Sales ops + a product squad for compliance features

Legal's sign-off here isn't advisory — launching without resolving data residency is how companies acquire regulatory fines. RAPID makes that veto explicit and bounded: legal can block on compliance, but legal is not the decider, so their veto can't silently expand into blocking the strategy for taste reasons. That containment — vetoes that are real but scoped — is RAPID's core contribution.

Where RAPID breaks

The Agree role is a loaded weapon. Grant it only for genuine hard constraints (legal, security, regulatory). The moment "Agree" gets handed to every stakeholder with strong opinions, you've rebuilt consensus decision-making with extra paperwork — the exact disease frameworks exist to cure. A RAPID with five Agrees is a committee wearing a lanyard.

Choosing between them (and their cousins)

	DACI	RAPID	RACI	No framework
Best for	Team/department decisions	Cross-functional, high-stakes decisions	Ongoing work responsibilities — not decisions	Two-way doors
Decision-maker	Approver (1)	Decide (1)	— (undefined!)	The owner
Veto role	None	Agree	None	None
Overhead	~1 page, days	Multiple roles, 1–3 weeks	N/A	Minutes
Failure mode	Approver stalls	Agree sprawl	Confusing accountability with decision rights	Wrong call on a one-way door

Notes worth internalizing:

• RACI is not a decision framework. It maps responsibilities for ongoing work (Responsible, Accountable, Consulted, Informed). Teams that grab RACI for decisions discover it never names a decider — "Accountable" is about owning outcomes, not making calls. Use RACI for org design, DACI/RAPID for decisions.
• Default to DACI; escalate to RAPID when a decision crosses org boundaries or has hard-constraint stakeholders who genuinely hold vetoes.
• The frameworks share one load-bearing idea: a single named decider plus explicitly non-binding input. If you remember nothing else, writing "Decider: Priya. Input closes Thursday." at the top of a doc captures 80% of the value of either acronym.

The decision log: the highest-value artifact in this article

Frameworks help you make the decision. The log keeps it made.

A decision log is a running record — one entry per significant decision — kept somewhere the whole team can read. The minimum viable entry has six fields:

## 2026-01-14 — Move billing to usage-based pricing tiers
Status: Decided
Decider: CPO (DACI approver)
Context: Flat pricing is blocking mid-market deals; 3 of last 5 losses cited it.
Options considered: keep flat / usage tiers / hybrid seat+usage
Decision & rationale: Usage tiers. Hybrid rejected as too complex to message; 
  flat rejected on deal data. Accepted risk: existing customer migration friction.
Revisit when: 2 quarters of data, or if churn in migrated accounts exceeds baseline.

What the log buys you:

• Relitigation ends. When the question resurfaces — and every real question resurfaces — the answer is a link, not a meeting. "We decided this in January; here's the entry, including why your alternative was rejected. Has anything in the 'revisit when' clause changed?" If yes, reopen honestly. If no, done in one message.
• Onboarding accelerates. New hires read six months of decisions and absorb not just what was decided but how this team weighs tradeoffs — institutional judgment, downloadable.
• Rationale survives departures. "Why is the architecture like this?" has an answer after the architect leaves.
• Your judgment gets auditable. Rereading your own log yearly is a humbling, genuinely useful calibration exercise: which calls aged well, and what did the bad ones have in common?

Keep the log where work happens — a dedicated wiki section or a docs page per team, not a spreadsheet nobody opens. Teams running on Openbook typically keep it as a Wiki room page (markdown, easy to link from anywhere) or a Docs page per department, so a decision entry is one ⌘K search away when a thread starts relitigating. Public-by-default decision logs also do quiet cultural work: they make decisions legible to adjacent teams, which kills a surprising amount of cross-team friction — more on that dynamic in Default to Open: The Case for Transparent Internal Communication.

Running decisions async (most of them should be)

Neither DACI nor RAPID requires a meeting, and most decisions run better without one. The async pattern:

1. Driver posts a proposal doc — context, options, recommendation, named roles, and a comment deadline ("input closes Thursday 5pm CET").
2. Contributors comment in the doc, not in chat, so the input is attached to the decision permanently.
3. Driver revises and flags the approver.
4. Approver decides in writing in the doc.
5. Outcome goes to the informed list and into the decision log.

A meeting enters only when written rounds reveal genuine conflict — two contributors with incompatible positions the driver can't reconcile on paper. Then a 25-minute call with exactly those people, decision at the end, back to writing. The full pattern — proposal templates, deadline etiquette, disagree-and-commit in async form — is covered in How to Make Decisions Asynchronously, and the note-taking discipline that feeds the log is in Meeting Notes That Compound.

Two async-specific rules earn emphasis. Silence past the deadline is consent — say so in the doc, enforce it kindly, and people learn to comment on time. And the driver must actually close: a proposal doc with 30 comments and no decision line is the async version of the meeting that ends with "let's take this offline."

When to just decide

Here's the part frameworks vendors won't tell you: a large fraction of managerial decisions deserve no framework at all. You're the manager; deciding is the job. Just decide when:

• It's a two-way door with wrong-call costs under roughly a week of one person's time.
• You have 80% of the information and the remaining 20% costs more to gather than a wrong call costs to fix. Colin Powell's version: act somewhere between 40% and 70% information — past 70%, you're paying for certainty with time.
• The team is split on a matter of taste, not fact. Someone has to pick the standup time. Pick it.
• A delay is itself a decision — and usually the worst available one. Deferring a staffing call by a month is choosing understaffing for a month.

The craft is in how you just decide. Announce it as a decision, not a discussion: "I'm deciding this one — we'll do X starting Monday. If it's clearly worse in a month, I'll happily reverse it." That sentence does three jobs: it claims the decision honestly (no fake consultation, which people detect and resent far more than honest authority), it names the reversibility, and it pre-commits you to reviewing the outcome.

The disagree-and-commit corollary: when you decide against someone's expressed input, acknowledge it directly — "I heard your case for Y and I'm going the other way, because Z. I need you fully in on X regardless." People commit to decisions they lost far more readily when their input was visibly heard and explicitly overruled than when it vanished into a void.

And a quota worth adopting: if you're a manager and you can't remember the last time you just decided something, you're over-processing. Conversely, if every decision on your team is a "just decide," you're probably running through one-way doors at speed. A healthy log shows a mix — mostly fast small calls, a few well-run structured ones.

Escalation: what to do when the process deadlocks

Even well-run frameworks hit walls. Three deadlocks recur, each with a standard exit:

The approver won't approve. The doc is complete, input is closed, and the decision sits for two weeks because the approver keeps asking for "a bit more analysis." Give approvers an explicit SLA when roles are assigned — "decision within five working days of the final doc" — and give the driver standing permission to escalate one level when it lapses. This isn't insubordination; it's the deal. An approver who wants the role keeps the clock.

Two Agrees (or two strong contributors) are in genuine conflict. Security says the integration is unacceptable as designed; sales says the quarter dies without it. Don't let the driver shuttle-diplomat this for weeks. Put both parties and the decider in one 30-minute meeting with a single agenda item: each side states their constraint and the cost of honoring it, and the decider picks which cost the company eats. Deadlocks between functions are precisely what deciders are for — the failure is letting the conflict simmer at the driver's level, where nobody has the authority to resolve it.

New information arrives mid-process. A pricing change from the vendor, a reorg, a competitor launch. The driver's call: if it materially changes the options, restart the input window (shortened — 48 hours, flagged as a re-review); if it doesn't, note it in the doc and proceed. What you must not do is let "something changed" silently reset the process without a stated new deadline, because that's how five-day decisions become five-week ones with no single decision anyone can point to.

The meta-rule for all three: every deadlock gets a named next step with a date, visible in the decision doc. Deadlocks fester in ambiguity and resolve on contact with a deadline.

Anti-patterns: how frameworks go wrong

• The ceremonial DACI. Roles assigned after the decision was made in a hallway, to give it a paper trail. Everyone can tell. Corrosive.
• Approver inflation. "Approvers: Sam, Lee, and the steering group." Three approvers is zero approvers.
• Framework as delay. Spinning up RAPID for a two-way door is decision-shaped avoidance with better stationery. Match process weight to reversibility, always.
• Input theater. Soliciting comments after the recommendation is immovable. If input can't change the outcome, don't request it — inform instead. People forgive not being consulted; they don't forgive fake consultation.
• The undead decision. Decided, logged… and quietly not executed, because nobody held the Perform role. Every decision entry needs an owner for the follow-through, with the work tracked on a real board like any other work.
• Log rot. A decision log updated for two months and abandoned reads as an archaeology site. Make logging part of the decision ritual itself — the driver's final step, every time — not a separate documentation chore.

Practical next steps

1. Sort your current stuck decisions. List everything "in discussion" right now. Mark each one-way or two-way. Decide every two-way door on the list this week — most have been waiting for permission, not information.
2. Run your next real decision through lightweight DACI. One page: driver, approver, contributors, deadline, recommendation. Time-box the whole thing to five working days.
3. Start the decision log today. Create the page, backfill your last five significant decisions from memory (imperfect entries beat none), and add "log it" as the final step of every decision going forward.
4. Reserve RAPID for the next genuinely cross-functional, hard-constraint decision — and cap the Agree list at the people who hold true vetoes.
5. Audit in a month: did decisions get faster? Is anything being relitigated that the log should have killed? Adjust.

Speed in decision-making doesn't come from deciding recklessly. It comes from matching process to stakes, naming one decider, closing input on a date, and writing the outcome down so it stays decided.

If you want proposal docs, a decision log, and the boards that track follow-through in one searchable workspace, that's what Openbook's Docs, Wiki, and board rooms are for — one ⌘K search across all of it.