DACI Framework

Most decisions in organisations don't fail because people chose the wrong option. They fail because nobody was clear on who was making the decision in the first place. The DACI Framework fixes that. It gives every decision four clearly defined roles, so everyone knows who's driving, who's deciding, who's contributing, and who just needs to know.

What is the DACI Framework?

The DACI Framework is a decision-making tool that assigns four roles to every decision:

• Driver - the person responsible for moving the decision forward
• Approver - the person with the authority to say yes or no
• Contributors - the people who provide input and expertise
• Informed - the people who need to know the outcome

The framework emerged from product management culture - Intuit is often credited with developing it - and has since spread across industries as a way to cut through the ambiguity that slows decisions down. It's particularly useful when decisions involve multiple teams, when authority lines aren't obvious, or when too many people think they have a vote.

The core idea is simple: not everyone involved in a decision has the same role. Some people need to shape the thinking. Some people need to make the call. Some people just need to know what was decided. When those roles aren't clear, you get slow decisions, revisited decisions, and decisions that unravel because someone who should have been involved wasn't - or someone who shouldn't have final say keeps overriding the outcome.

DACI is closely related to RASCI, which covers broader task and process accountability. The difference is focus: DACI is built specifically for decisions, while RASCI maps responsibility across ongoing work. Many teams use both - DACI for the decisions that need making, RASCI for the work that follows.

The four DACI roles

Each role has a distinct purpose. Getting them right - and keeping them distinct - is what makes the framework work.

Driver

The Driver owns the process, not the outcome. They're responsible for framing the decision, gathering the right input, keeping things moving, and making sure a recommendation reaches the Approver. Think of the Driver as the person who makes sure the decision actually gets made, rather than drifting or stalling.

A good Driver defines the question clearly, sets a timeline, pulls in the right Contributors, synthesises what they hear, and presents options. They don't need to be the most senior person - they need to be close enough to the issue to frame it well and organised enough to drive the process.

One decision, one Driver. If two people are sharing the Driver role, nobody's driving.

Approver

The Approver makes the final call. They review the Driver's recommendation, weigh it against the organisation's priorities and constraints, and either approve, reject, or send it back for more work. There should be one Approver per decision - not a committee.

This is the role that causes most confusion when it's poorly defined. If the Approver isn't named upfront, teams often discover halfway through that they've been building a case for the wrong person, or that someone with more authority swoops in at the last moment and overturns weeks of work.

The Approver doesn't need to have done the analysis. They need to have the authority and context to make a good call based on what the Driver brings them.

Contributors

Contributors are the people whose input shapes the decision. They bring expertise, data, perspectives, or experience that the Driver needs. They have genuine influence - their input should meaningfully inform the recommendation - but they don't have a vote.

This distinction matters. Contributors are consulted, not consensus-makers. The Driver listens carefully to what Contributors bring, but the final recommendation doesn't need unanimous agreement from every Contributor. If it did, you'd have a committee, not a decision-making process.

Be deliberate about who's a Contributor. Too few, and you miss important perspectives. Too many, and the process bogs down. A useful question: does this person have knowledge or context that would change the quality of the decision? If yes, they're a Contributor. If they just need to know the outcome, they're Informed.

Informed

Informed people need to know what was decided and why, but they're not part of the decision-making process itself. They might be affected by the outcome, need to act on it, or simply need to stay in the loop.

Getting the Informed list right matters more than it sounds. Miss someone who should have been told, and you create confusion or resentment when the decision lands. Include someone who should have been a Contributor, and you've cut out a perspective that might have changed the outcome.

The Informed role is also where good communication discipline lives. It's not enough to make a decision - the people who need to know about it need to hear about it promptly, clearly, and with enough context to understand the reasoning.

How to use the DACI Framework

DACI works best when you apply it before the decision-making starts, not after things get complicated.

1. Name the decision. Write it down as a clear question. "Should we restructure the customer service team?" is a decision. "Customer service improvements" is not. The clearer the question, the easier everything that follows.

2. Assign the four roles. For this specific decision, who is the Driver? Who is the Approver? Who are the Contributors? Who needs to be Informed? Write it down and share it. If there's disagreement about who the Approver is, that's a conversation worth having now rather than later.

3. Set the timeline. When does this decision need to be made? The Driver owns the timeline and keeps things moving. Without a deadline, decisions expand to fill whatever time is available.

4. Gather input. The Driver consults Contributors, gathers data, and does the thinking. This might be a single conversation or a series of meetings depending on the decision's complexity. The key is that the Driver synthesises what they hear into a clear recommendation - Contributors aren't asked to reach consensus among themselves.

5. Decide. The Driver presents their recommendation to the Approver with the reasoning behind it. The Approver reviews, asks questions, and makes the call. If the Approver sends it back for more work, the Driver picks it up and runs the process again.

6. Communicate. Once the decision is made, the Informed group hears about it - what was decided, why, and what happens next. This step gets skipped more often than any other, and it's usually the one that causes problems downstream.

Tips for making DACI stick

Use it for decisions, not everything. DACI is built for specific decisions - not for running projects, managing tasks, or tracking ongoing work. If you need broader accountability mapping, that's where RASCI comes in.

Start with the decision, not the roles. Teams sometimes jump to assigning roles before they've agreed on what the decision actually is. Get the question sharp first.

Keep the Approver singular. The moment you have two Approvers, you have a political problem disguised as a governance structure. One person makes the call. If the decision is too big for one person, break it into smaller decisions.

Revisit the roles if the decision changes shape. A decision that started as operational might become strategic. That might mean a different Approver. The roles should match the decision as it evolves, not as it was first framed.

Example

A professional services firm is deciding whether to move from a regional office structure to a hub model. The CEO assigns the DACI roles:

Driver: The Head of Operations. She's closest to the data on office utilisation, travel patterns, and team distribution. She'll frame the options, consult the right people, and bring a recommendation.

Approver: The CEO. This is a structural decision with significant cost and people implications - it needs the most senior call.

Contributors: The Finance Director (cost modelling), the Head of People (workforce impact and employee experience), two Regional Directors (ground-level reality), and the Head of Technology (infrastructure requirements). Each brings a perspective the Driver needs to build a complete picture.

Informed: All staff (once the decision is made), the board (who need to know but aren't approving this operational decision), and key clients who would be affected by office changes.

The Driver runs the process over four weeks. She holds separate conversations with each Contributor, synthesises the input into three options with trade-offs clearly laid out, and presents her recommendation to the CEO. The CEO asks two follow-up questions, requests one additional data point from Finance, and approves the hub model with a phased transition. The Informed group hears about the decision the following week, with the reasoning and timeline included.

The whole process takes five weeks. Without DACI, the same decision could easily have drifted for months - bouncing between meetings, revisited by different groups, with nobody clear on who had the final say.

Limitations of the DACI Framework

DACI does one thing well - clarifying decision-making roles. It doesn't try to do everything.

It doesn't improve the quality of the decision itself. DACI tells you who decides, not how to decide well. For that, you need tools that help teams think through options from different angles - something like Six Thinking Hats is useful alongside DACI when the decision itself is complex.

It assumes decisions can be clearly bounded. Some decisions aren't discrete - they're ongoing, evolving, or entangled with other decisions. DACI works best when you can frame a clear question with a clear endpoint. For messier, more emergent situations, it's less natural.

It can feel heavy for small decisions. Not every decision needs four formally assigned roles. DACI earns its keep on decisions that cross team boundaries, involve ambiguous authority, or have meaningful consequences. For everyday operational choices, it's overhead.

The Approver role can become a bottleneck. If the same person is Approver on too many decisions, everything queues behind them. Watch for this - it usually signals that decision-making authority needs to be distributed more deliberately across the organisation.

Getting started

Pick one decision your team is currently trying to make - ideally one that's been lingering or where it's not clear who has the final say. Write the decision as a question, assign the four DACI roles, set a deadline, and run the process.

You don't need to roll out DACI across every decision in the organisation. Start with one that matters, see how the clarity changes the speed and quality of the outcome, and go from there. The framework is lightweight enough to try in a single meeting, and the results usually speak for themselves.

For organisations looking to strengthen how decisions flow across teams, DACI sits naturally within broader work on operational effectiveness and how strategy gets embedded into everyday work.