COMMON PITFALL
DACI framework: write the call, not the roster
A filled roster of four names is where the work starts, not where it ends.
By Michael Tor · October 2026
DACI (Driver, Approver, Contributors, Informed) is a decision-making framework that assigns roles for a group decision. ProductPlan notes it was developed at Intuit as a variant of RACI. A DACI has done its job only when the Approver has written down which option was chosen and why, by the agreed date. A filled roster of four names is where the work starts, not where it ends.
Who is this for?
Product leads, PMs, and engineering managers who set up a DACI page at kickoff for a cross-team call. A platform migration, a pricing change, a scope cut. The tension is predictable. Once the roster is filled, everyone feels the decision is owned. The meeting drifts into consensus. Contributors act like voters. The date slides. Weeks later, nobody can point to the moment the Approver actually chose.
What is the roster-only failure mode?
The roster-only DACI. Four role boxes are filled, but there is no question in the title, no options laid out, and no decide-by date. The Approver either never states a call or signs whatever the loudest Contributor wanted. Atlassian's playbook contrasts a passive rubber stamp with an active decision maker. The inverse happens when the Driver keeps gathering input forever because nobody is waiting on a date. Both look like process. Neither produces a written call.
Consider a team moving notifications to a new service. In version A, the roster is filled, they hold three meetings, and Contributors mostly agree. The Approver says sounds good, keep going. A month later, two teams are building different things. In version B, the page is titled "Do we move notifications this quarter or after billing?" It lists two options with each Contributor's input and a date. The Approver writes "after billing; the on-call risk is not worth it this quarter." Informed teams get a one-paragraph note.
When has a DACI actually produced a call?
Check these six conditions.
-
The page is titled as a question to answer.
Atlassian suggests formatting it as "DACI: [question]?"
-
Exactly one Approver, by name.
Atlassian puts it as "the one person (yes: one)".
-
Real options are written side by side with what each Contributor said about them.
Contributors have a voice, not a vote.
-
A decide-by date the Driver holds.
The Driver gets a decision made by the agreed date.
-
The Approver's call is written with the chosen option and the main reason the others lost.
This is what feeds your product decision log.
-
The Informed group gets the outcome and what changes for them.
They are told once it is made, not just handed the roster.
When does DACI help?
It helps in cross-team calls where authority is fuzzy and a single named Approver ends the ping-pong.
When does it hurt?
It hurts on small reversible calls where filling a roster costs more than the decision. Bain notes not every decision needs the full level of rigor. It also hurts when the Approver is chosen for seniority rather than the context to choose. Bain describes a related model, RAPID (Recommend, Agree, Perform, Input, Decide), as a way to bring transparency to decision accountabilities.
Sources:
• DACI roles and the one-Approver rule (Atlassian Team Playbook) → https://www.atlassian.com/team-playbook/plays/daci
• DACI's Intuit origin as a RACI variant (ProductPlan) → https://www.productplan.com/glossary/daci/
• RAPID decision roles and single decider (Bain & Company) → https://www.bain.com/insights/rapid-decision-making/