DACI vs RACI: which to use, and when

If you have ever sat in a 90-minute meeting that ended with "let's circle back next week," you have lived the cost of bad decision governance. Roles are vague, owners are plural, and "alignment" becomes a synonym for delay. Two frameworks promise to fix this: RACI and DACI. They look similar on a slide. They are not.

This article is for product managers, engineering managers, and operators who keep getting handed decisions and want a cleaner way to run them. We will look at what each framework actually is, where RACI breaks for non-trivial calls, when it is still the right tool, and how a DACI workflow runs in practice.

A quick refresher: what is RACI?

RACI is a responsibility-assignment matrix that comes out of process management in the 1970s. The acronym stands for:

• Responsible – the people who do the work.
• Accountable – the single person who owns the outcome and signs off.
• Consulted – the people whose input is sought before the work happens.
• Informed – the people who are notified once the work is done.

RACI was designed to map who does what across an ongoing process. Think of a payroll cycle, a quarterly close, an onboarding workflow. It answers the question "for this recurring activity, who does which part?". It is at its best when the work itself is well-defined and the open question is execution, not direction.

A quick refresher: what is DACI?

DACI was developed at Intuit in the early 2000s and has since become the default decision framework at companies like Atlassian. The acronym stands for:

• Driver – the single person who runs the decision process. They schedule the work, gather the inputs, and bring the decision to a close. They do not necessarily decide.
• Approver – the single person who makes the final call. Often, but not always, more senior than the Driver.
• Contributors – the people whose input shapes the decision. They have a voice, not a vote.
• Informed – the people who need to know the outcome but were not part of making it.

Notice the shift in centre of gravity. DACI is not asking "who does the work?" It is asking "who is moving this decision to closure, and who is on the hook for whether the answer was right?"

The difference that actually matters

Both frameworks split a single role into two. RACI splits doing from owning (Responsible vs Accountable). DACI splits running from deciding (Driver vs Approver). That second split is the one that matters for decisions, and it is the one RACI fudges.

In RACI, the "Accountable" person is supposed to be the decision-maker. But that role is loaded: they own the outcome, sign off the artefact, and are the escalation point. In practice, that means most teams quietly assign "Accountable" to the most senior person available, even if they are not close enough to the work to make a good call. The decision then either happens in absentia, gets delayed for their availability, or gets re-litigated three times because no one was actually empowered to close it.

DACI's Driver/Approver split solves this. The Driver does the running: convenes the right people, surfaces the trade-offs, drafts the recommendation, and brings it back to the Approver with a clear ask. The Approver does one thing: decide. They do not have to be the most senior person in the room, only the right person for this specific call.

Where RACI quietly fails for decisions

Three failure modes show up almost every time a team tries to run a real decision through a RACI matrix.

1. The "Accountable plural" problem

RACI is supposed to allow exactly one Accountable per row. In practice, teams routinely list two or three. "Engineering and Product are jointly accountable." "The VP of Sales and the Head of Customer Success share accountability." This is not a small bug. It is the root cause of most stalled decisions, because plural accountability is no accountability. There is no one whose calendar you can put a deadline on.

DACI is structurally clearer here: there is one Approver, full stop. If you cannot name a single Approver, the decision is not yet ready to be made. That alone forces a conversation that RACI lets you skip.

2. The "Consulted" veto trap

RACI's "Consulted" role is supposed to mean "we will get their input." In practice it slides into "we will get their agreement." Once five stakeholders have been Consulted, none of them want to be the one whose objection got overruled, so the Accountable person ends up needing implicit consensus to move. The decision becomes a negotiation over the lowest common denominator instead of the best available answer.

DACI's Contributor role is more honest about the contract: you contribute, you do not decide. Veto rights, where they exist, are explicit and time-bound, not smuggled in through ambiguity.

3. The missing Driver

RACI has no concept of a Driver. The closest analogue is a "Responsible" person, but Responsible means "does the work," not "moves the decision." For execution, this is fine: the work itself drives the schedule. For decisions, it is fatal. Decisions do not move on their own. Without an explicit Driver, the default outcome is delay.

Naming a Driver is one of the highest-leverage things a team can do. It is a small structural change that turns "this should get decided eventually" into "this will be decided by Friday because Anna owns getting it across the line."

When RACI is still the right call

None of this means RACI is bad. It means RACI is built for a different problem. RACI is the right tool when:

• The activity is recurring and process-shaped (payroll, deployments, incident response, audit prep).
• The open question is "who does which step?" rather than "what should we do?"
• You need a clear handoff map for a cross-functional workflow.
• Compliance or regulatory documentation requires the formal Responsible/Accountable distinction.

For these cases, DACI is overkill and adds friction. You do not need to "decide" how payroll runs every cycle. You need to know who is doing which step. RACI is a clean fit.

The mistake is using RACI when the actual question is "what should we do?" Pricing changes, hiring trade-offs, architecture choices, GTM strategy, vendor selection, prioritisation calls: these are decisions, and decisions deserve a decision framework.

A DACI workflow in practice

Here is what a clean DACI run looks like, using a concrete example: a B2B SaaS team is deciding whether to introduce a free tier.

1. Frame the decision. The Driver (a senior PM) writes a one-page brief: what we are deciding, why now, what the constraints are, what success looks like, and what the deadline is. No options yet, no recommendations. Just the question.
2. Name the roles. One Approver (the Head of Product). Three to five Contributors (Sales lead, Customer Success lead, an Eng lead, the Finance partner). Informed list (the broader exec team, the rest of Product).
3. Generate options with Contributors. The Driver runs an async round (a shared doc, a structured tool, a 60-minute working session) where Contributors propose and pressure-test 2 to 4 options. Trade-offs get surfaced explicitly.
4. Draft a recommendation. The Driver writes a recommendation, with the trade-offs and the dissent on the record. They share it with the Approver and Contributors with at least 48 hours of read time.
5. Decide. The Approver makes the call. They can accept the recommendation, pick a different option, or kick it back with specific questions. They do not get to delay indefinitely; if they cannot decide, the decision goes to their Approver.
6. Inform and record. The decision, the rationale, and the dissent get logged. The Informed list gets a short note. Future-you, looking at this in nine months, can reconstruct why.

Total elapsed time for a non-trivial decision like this: typically one to two weeks, with maybe four hours of meeting time across all participants. Compare that to the version where the same call gets re-litigated in three exec meetings over six weeks because no one was the Driver.

Migrating from RACI to DACI

If your team already lives in RACI, the migration is mostly a relabelling exercise plus one structural change. Map the roles roughly like this:

• RACI Responsible → DACI Driver, often.
• RACI Accountable → DACI Approver. Force the conversation about whether it is really one person.
• RACI Consulted → DACI Contributor. Be explicit that they do not have a vote.
• RACI Informed → DACI Informed. Same role, often the same list.

The structural change is the one that pays for itself: you stop using the framework for execution and start using it only for decisions. Operational handoffs go back into RACI (or a process document). Decisions get the DACI treatment.

Common DACI anti-patterns to avoid

Switching to DACI does not automatically solve the underlying problems. The same teams that struggled with RACI tend to drag the same habits into DACI. The four most common:

• Co-Approvers. "Let's have both the Head of Product and the CTO approve." No. Pick one. If the call genuinely sits at the intersection, the Approver is the person who would own the consequences if it goes wrong, and the other becomes a Contributor with a known veto right.
• The Driver who silently decides. A Driver who writes a recommendation and then nudges the Approver to rubber-stamp it is acting as the Approver. Either rename them and give them the authority, or restore the actual Approver to the role.
• Contributors as veto-holders. If "Contributors must agree" is the unspoken rule, you have rebuilt the RACI consensus trap inside a DACI shell. Be explicit: their job is to make the recommendation better, not to gate it.
• No deadline. A DACI with no decision date is just a long meeting. The Driver owns the deadline. If the Approver is missing the window, that is itself a decision worth escalating.

The short version

Use RACI when the question is "who does which part of this recurring process." Use DACI when the question is "what should we do, and who is going to close this out." Most decisions that drag on inside teams are RACI being misapplied to a DACI-shaped problem.

The single most useful thing you can do this week is to look at the three biggest open decisions in your team and ask: who is the Driver, and who is the Approver? If you cannot name one of each, you have just found why those decisions are stuck.