DACI decision‑making framework

1. What Is DACI decision‑making framework?

The DACI framework is a simple, high‑clarity way to assign roles for making a specific decision. The acronym stands for Driver, Approver, Contributors, and Informed. It defines who orchestrates the process (Driver), who makes the final call (Approver), who provides input (Contributors), and who needs to know the outcome (Informed). By separating process ownership from decision rights, DACI reduces churn, accelerates decisions, and clarifies accountability.

Within Team Effectiveness & Collaboration frameworks, DACI is a lightweight decision governance tool. It’s used by cross‑functional teams—product, engineering, marketing, finance, operations, legal—to agree upfront how a decision will be made and by whom. It pairs naturally with operating cadences (e.g., portfolio reviews, release planning) and complements models that set goals (OKRs) or prioritize scope (MoSCoW).

In plain terms: for any material decision, name one Driver to run the process, one Approver to decide, a defined set of Contributors to provide input, and a list of Informed stakeholders to receive the decision and rationale. Then run a structured, time‑boxed process to a clear outcome.

2. Origin and Background

Origin: Unclear; in use since at least the 1990s, especially in product management and cross‑functional technology organizations. DACI emerged as a pragmatic alternative to ambiguous decision processes in matrixed environments, where unclear authority and slow consensus often create delays and rework.

It became widely known through practitioner literature, product management communities, and internal playbooks at tech firms. Many organizations adopted DACI alongside or as a more decision‑specific complement to role frameworks like RACI and to decision rights models like RAPID.

3. How DACI Works

DACI establishes four roles for a single decision (not for ongoing job descriptions). The key is unambiguous assignment and time‑boxed execution.

The Four Roles

• Driver: Owns the decision process. Responsibilities include framing the decision and scope, aligning on criteria, assembling the Contributors, gathering inputs and options, running the cadence (meetings, async reviews), synthesizing perspectives, and surfacing a recommendation. The Driver ensures the decision happens on time—without necessarily having the final say.
• Approver: The decider. There should be exactly one Approver for speed and accountability (or a clearly defined, small decision board that acts as one entity). The Approver confirms criteria, considers the Driver’s synthesis and Contributor input, makes the final call, and owns the outcome.
• Contributors: Subject‑matter experts and stakeholders who provide data, analysis, risks, and options. They do not decide. Their input is time‑boxed and tied to defined questions or artifacts (e.g., security assessment, customer impact analysis, cost model).
• Informed: Stakeholders who must be informed of the decision and rationale because they execute, depend on, or are affected by it. They are not part of the decision process unless explicitly added as Contributors.

What Good Looks Like

• Scope clarity: The decision statement specifies what is in scope, what is out of scope, time horizon, constraints, and definition of success.
• One Approver: Single‑threaded accountability; if governance requires a committee, define how it acts as one (e.g., quorum + majority rule) and who signs.
• Time‑boxed cadence: A short schedule with milestones: criteria alignment, input window, option review, decision date, communication plan.
• Decision criteria: 3–7 criteria, weighted if necessary (e.g., customer impact, revenue/ROI, risk/compliance, time to value, cost/effort), published at the outset.
• Artifacts: A decision brief (1–2 pages) and a decision log entry capturing statement, roles, criteria, options and analysis, final decision, rationale, and follow‑ups.

How It Differs from RACI and RAPID

• RACI (Responsible, Accountable, Consulted, Informed) assigns work responsibility generally and can be applied to processes. DACI is explicitly decision‑centric and separates process leadership (Driver) from decision rights (Approver). In practice, RACI’s “Accountable” can be ambiguous for decisions; DACI removes ambiguity by naming the Approver.
• RAPID (Recommend, Agree, Perform, Input, Decide) is a comprehensive decision rights model. DACI is simpler: Driver ≈ Recommend/coordinate, Approver ≈ Decide, Contributors ≈ Input (and sometimes Agree), Informed ≈ Perform/Informed for execution and awareness. Use RAPID for complex, multi‑tier governance; use DACI for faster day‑to‑day cross‑functional decisions.

4. When to Use DACI

Most helpful when:

• Decisions involve multiple functions (e.g., product, engineering, finance, legal, security) and ambiguous authority.
• Timeline matters (e.g., release gating, vendor selection, pricing changes, incident response follow‑ups), and prolonged consensus would delay value or increase risk.
• Past decisions have suffered from “decision drift,” re‑litigation, or “meetings after the meeting.”
• You need a repeatable pattern to scale decision hygiene across teams and geographies.

Especially powerful: For medium‑stakes decisions that recur frequently in a portfolio (e.g., roadmap trade‑offs, go/no‑go for experiments, exception thresholds) where a consistent template increases speed and quality.

Less suitable or potentially misleading: For trivial, low‑impact choices where overhead outweighs benefit; for once‑in‑a‑decade decisions requiring bespoke governance (mergers, Board‑level issues); or if used as a fig leaf when real authority doesn’t exist (e.g., Approver lacks mandate).

Practice today: Many organizations embed DACI into decision briefs and logs, tie it to OKR reviews and portfolio forums, and store artifacts in shared workspaces so Informed stakeholders can self‑serve the rationale.

5. How to Apply DACI: Step‑by‑Step

1. Define the decision and boundaries.

   Write a crisp decision statement: what we are deciding, by when, over what time horizon, with which constraints (budget, compliance, brand), and how we will judge success. Example: “Select a cloud cost‑management vendor for a 12‑month enterprise contract by May 31; constraints: SOC 2 Type II, data residency, ROI ≥ 2x within 12 months.”

2. Assign DACI roles explicitly.

   Identify one Driver and one Approver. List Contributors needed for analysis (e.g., Security, Finance, Procurement, Customer Success) and who must be Informed (e.g., Engineering managers, Support). Publish the list in the decision brief. Confirm availability and expectations with each person.

3. Align on decision criteria and process.

   Driver proposes 3–7 criteria (weighted if helpful) and a short cadence:

   • Day 0–2: Criteria alignment with Approver and key Contributors.
   • Day 3–10: Input window (data gathering, vendor demos, risk assessment).
   • Day 11–14: Synthesis and recommendation.
   • Day 15: Decision meeting (or async approval).
   • Day 16–18: Communicate decision and rationale to Informed; log and proceed.

   The Approver confirms criteria and timeline.

4. Gather inputs and options (Driver + Contributors).

   Specify the questions and artifacts needed from each Contributor (e.g., Finance: 3‑year TCO vs. baseline; Security: control gaps; Legal: contract risks; CS: customer impact). Keep input time‑boxed and standardized to ease comparison. Driver socializes interim findings to prevent surprises.

5. Synthesize and recommend (Driver).

   Driver evaluates options against criteria (use a simple matrix), highlights trade‑offs, risk mitigations, and an explicit recommendation. Circulate a draft for quick Contributor review to catch errors—not to reopen criteria.

6. Decide and document (Approver).

   Approver reviews synthesis, asks clarifying questions, and makes the call. The decision brief captures final choice, rationale (tied to criteria), and any conditions (e.g., “pilot first; exit clause X”). Both Driver and Approver ensure the decision is entered into a shared decision log.

7. Communicate and execute (Driver).

   Notify Informed stakeholders with a concise summary: what, why, when, who owns next steps. Provide links to the brief and log. If the decision affects plans (e.g., roadmap), ensure downstream artifacts are updated.

8. Review outcomes and learn.

   Set a check‑in (e.g., 30/90 days) to assess if assumptions held and to capture learnings. Update any decision playbooks (e.g., refine criteria templates for next vendor decision).

6. Example: DACI in Action

Context: A $900M global SaaS company must decide whether to introduce usage‑based pricing for a new AI add‑on. The choice affects revenue, product adoption, billing complexity, and support. Past pricing decisions have stalled due to conflicting stakeholder views.

Applying DACI:

• Decision statement: “Set pricing model for AI Assist by July 15 for Q4 launch; choose among usage‑based, seat‑based, or hybrid; constraints: AR aging stability, billing system limits, competitive positioning, margin ≥ 70%.”
• Roles: Driver—Senior Product Manager; Approver—VP Product. Contributors—Finance (rev modeling), Sales Ops (quoting/billing), Engineering (metering feasibility), Support (case forecast), Legal (terms), Marketing (positioning), Data Science (usage patterns). Informed—Regional Sales Directors, Customer Success leaders, Billing, Executive Staff.
• Criteria (weighted): Customer adoption impact (30%), revenue growth and predictability (25%), operational feasibility (20%), margin (15%), competitive differentiation (10%).
• Process: 3‑week timebox: week 1 inputs/modeling; week 2 synthesis; week 3 decision.
• Outcome: Hybrid pricing approved: base seat fee + metered overage with guardrails (discount tiers, free band for trials). Conditions: pilot with 50 customers, automated metering MVP, updated billing terms. Decision logged and communicated with rationale and next steps; Marketing and Sales Ops updated enablement.

Results (three months): Pilot conversion rate 18% higher than seat‑only control; AR stable; support cases as forecast; minimal billing friction due to early constraints. Decision speed improved (three weeks end‑to‑end) vs. previous cycles that took two months.

7. Strengths and Limitations

Strengths

• Clarity and speed: Single Driver and single Approver remove ambiguity, reduce decision drift, and increase throughput.
• Accountability: Approver owns the outcome; Driver owns the process. Contributors know how and when to help.
• Scalable and lightweight: Works for many recurring decision types; easy to embed in briefs and logs.
• Cross‑functional alignment: Forces early agreement on criteria and scope; avoids “meetings after the meeting.”

Limitations

• Not a substitute for authority: If the Approver lacks real mandate, DACI cannot compensate; politics will override.
• Overhead risk: For trivial decisions, formal roles add friction; use judgment on when to apply.
• False consensus risk: If criteria are vague or rubber‑stamped, the process looks clean but yields poor choices.
• Complex governance: Regulated or high‑stakes decisions may need a richer model (e.g., RAPID) and formal committees.

8. Common Pitfalls (and How to Avoid Them)

• Multiple Approvers.
  What goes wrong: Slow decisions, vetoes, and diffusion of accountability.
  Avoid by: Naming one Approver. If a committee is required, define quorum and one signatory responsible for the final call.
• Driver ≠ Approver confusion.
  What goes wrong: Driver behaves like the decider; Approver disengages until late, then overturns work.
  Avoid by: Explicitly defining roles, aligning on criteria early, and holding regular checkpoints.
• Vague decision scope.
  What goes wrong: Endless expansion; re‑litigation of adjacent topics.
  Avoid by: Writing a crisp decision statement with boundaries and constraints. Park out‑of‑scope items in a backlog.
• Undefined or shifting criteria.
  What goes wrong: Stakeholders argue opinions; decisions feel political.
  Avoid by: Agreeing 3–7 criteria up front; freezing them unless new facts emerge (document changes in the log).
• Too many Contributors.
  What goes wrong: Analysis paralysis; scheduling overhead.
  Avoid by: Limiting to essential SMEs; time‑boxing inputs; using async templates for contributions.
• Hidden veto players.
  What goes wrong: Late objections from functions with de facto power (e.g., Security, Legal) derail timelines.
  Avoid by: Including necessary veto‑holders as Contributors from the start; securing their SLAs for input.
• No documentation.
  What goes wrong: Decisions get revisited; institutional memory fades.
  Avoid by: Maintaining a decision log with rationale and links to artifacts; make it searchable and open by default.
• Applying DACI to everything.
  What goes wrong: Bureaucracy, slower small decisions.
  Avoid by: Calibrating: reserve DACI for medium/high‑impact cross‑functional decisions; allow lightweight calls for the rest.

9. How DACI Relates to Other Frameworks

• RACI: RACI clarifies ongoing responsibilities. DACI is decision‑specific. Use RACI for process ownership; use DACI to run discrete decisions within those processes.
• RAPID: RAPID provides a fuller decision rights taxonomy (Recommend, Agree, Perform, Input, Decide). DACI is simpler and faster for common cross‑functional decisions. Choose RAPID when formal agreement rights or complex governance are needed.
• Vroom–Yetton–Jago and Tannenbaum–Schmidt: These help you choose the participation level (autocratic vs. consultative vs. group). Combine with DACI: pick participation mode, then assign Driver/Approver/Contributors and run the process.
• GRPI and Hackman: GRPI (Goals, Roles, Processes, Interpersonal) and Hackman’s conditions set team design. DACI operationalizes “Roles/Processes” for decisions, improving speed and clarity.
• OKRs: OKRs define outcomes. DACI governs decisions (e.g., roadmap trade‑offs) that affect how you meet those outcomes.
• MoSCoW, RICE, WSJF: These prioritize scope across items. DACI clarifies who decides which items make the cut and documents the call and rationale.
• Decision logs and playbooks: DACI integrates into your decision log template; over time, you build a knowledge base of criteria and patterns that raise decision quality.

10. Key Takeaways

• DACI clarifies decision roles: one Driver to run the process, one Approver to decide, defined Contributors to provide input, and Informed stakeholders to receive the outcome.
• Use it for medium/high‑impact cross‑functional decisions where ambiguity slows progress or causes re‑litigation.
• Make it work: write a tight decision statement, agree criteria, time‑box inputs, synthesize options, decide on schedule, and log and communicate the rationale.
• Keep one Approver for accountability; don’t confuse Driver and Approver; limit Contributors to essential SMEs.
• Pair DACI with prioritization (MoSCoW/RICE), participation models (Vroom–Yetton–Jago), and operating cadences and decision logs for durable impact.

11. FAQs About DACI

Is DACI the same as RACI?
No. RACI assigns responsibility for work in processes or projects (Responsible, Accountable, Consulted, Informed). DACI is decision‑specific and distinguishes the process owner (Driver) from the decider (Approver). Many teams use both—RACI for execution, DACI for key decisions within execution.

How many Approvers should we have?
One. A single Approver maximizes speed and accountability. If governance requires a board, define how it acts as one Approver (quorum, decision rule) and who signs.

Can the Driver and Approver be the same person?
It’s possible but not ideal for cross‑functional decisions. Separating roles reduces bias, increases engagement from Contributors, and preserves challenge. For small, simple decisions, one person may pragmatically play both roles—use judgment.

How does DACI fit in Agile?
Well. Use DACI for decisions that cut across squads or functions—e.g., release gating, architecture choices, vendor selection, pricing, exception thresholds. Keep it lightweight: a one‑page brief, clear roles, a two‑week timebox, and a decision log entry.

When should we use DACI vs. RAPID?
Use DACI when you need speed and clarity for common cross‑functional decisions with clear deciders. Use RAPID when you need formal Agree rights, multiple layers of Input/Recommend, or complex governance (e.g., risk committees, regulated changes).

What artifacts should we keep?
A decision brief (statement, roles, criteria, options, recommendation), a decision log entry (final decision, rationale, date, owner, links), and any supporting analyses from Contributors. Store them in a shared, searchable workspace.

How long does a DACI process take?
For a typical cross‑functional decision, 1–3 weeks is common with a disciplined timebox. High‑stakes decisions may take longer; trivial ones should be faster or not use DACI at all.

How do we prevent re‑litigation?
Agree and freeze criteria early; time‑box input; log the decision and rationale; and define what new evidence would reopen it. Leaders must model “disagree and commit” and back the Approver’s call.

What if stakeholders keep adding Contributors?
Keep the bar high: Contributors must bring specific, needed input tied to agreed criteria. Others can be Informed. The Driver enforces the timebox and scope.