The DACI Decision Framework for Engineering Teams

Contributor
Apr 9
5 min read

DACI is a decision-making framework: Driver, Approver, Contributors, Informed. Used well, it prevents the common pattern where decisions get made, then relitigated, then made again, then relitigated. The artifact is simple; the discipline is naming the roles before decisions happen.

The Four Roles

Driver: the person who runs the decision-making process. Makes sure it happens. Owns the outcome of the process, not necessarily the decision itself.

Approver: the single person with final say. Often the team lead, product owner, or executive sponsor.

Contributors: people whose input shapes the decision. They get heard; their input is considered. They don't approve.

Informed: people who learn about the decision after it's made. They don't shape it but should know.

The single most important rule: one Approver per decision. Two means no decision authority.

Why DACI Helps

Common decision dysfunctions:

Decisions made in meetings; nobody knows by whom
Decisions re-opened weeks later because someone wasn't heard
Implementation blocked by lingering disagreement
Approval claimed by multiple people, contradicting each other

DACI forces clarity:

Driver moves the decision forward
Approver decides; not a committee
Contributors are heard but don't approve
Informed are notified but don't engage

DACI vs. RACI

The two acronyms overlap but address different things.

RACI: Responsible, Accountable, Consulted, Informed. For execution. Who does the work?

DACI: Driver, Approver, Contributors, Informed. For decisions. Who decides?

For execution work, use RACI. For decisions, use DACI. Sometimes you need both.

A Working DACI Document

A simple format:

Decision: [What needs to be decided]
Background: [Why this decision is needed now]
Options: [The choices being considered]

Driver: [Name]
Approver: [Name]
Contributors: [Names]
Informed: [Names or groups]

Timeline: [When the decision is needed]
Process: [How the decision will be made]

The whole thing fits on a page.

When to Use DACI

Worth the effort for:

Cross-team decisions
Significant technical decisions (architecture, vendor choice)
Decisions with multiple stakeholders
Decisions that keep getting relitigated
High-stakes choices

Skip for:

Routine decisions within a single team
Decisions where one person clearly owns
Choices that don't merit the overhead

The Driver's Job

The Driver isn't the decision-maker. They run the process.

Specifically:

Drafts the decision document
Identifies the right Approver and Contributors
Gathers input from Contributors
Surfaces the options and trade-offs
Brings the decision to the Approver
Communicates the decision to the Informed

A good Driver is neutral about the outcome. They want the right decision made, not a specific decision.

The Approver's Job

The Approver makes the call.

Their job:

Engage with the process the Driver runs
Read the inputs from Contributors
Make a decision (yes, no, alternative, defer)
Communicate the reasoning

What the Approver shouldn't do:

Disengage and rubber-stamp
Override the process by deciding without the inputs
Delegate to someone who can't really decide

Single Approver. Always.

The Contributors' Job

Contributors provide input. Their job:

Share their perspective
Surface concerns
Suggest alternatives
Engage in the discussion

What Contributors shouldn't do:

Expect their input to be the decision
Block decisions because they disagree
Wait until after the decision to raise issues

Contributors get heard. They don't necessarily get their way.

When Contributors Disagree

The Approver decides despite Contributor disagreement. Some Contributors will be unhappy with the decision.

Healthy patterns:

Disagreements are documented but the decision proceeds
Disagreeing Contributors commit to executing the decision they didn't fully support
The "disagree and commit" norm holds

Unhealthy patterns:

Decisions endlessly relitigated
Disagreeing Contributors quietly block execution
Decisions are made but not actually implemented

The Approver's job includes addressing unhealthy patterns.

The Informed

People who need to know but don't need to engage.

Common Informed:

Adjacent teams whose work might be affected
Leadership who wants visibility
Support teams who'll need to know the result
Future-affected stakeholders

The Driver communicates to Informed after the decision. They don't engage them during.

A Worked Example

Decision: which database to use for the new payments service?

Driver: Sam (Eng Lead, Payments)
Approver: Pat (Director, Engineering)
Contributors:
  - Riley (Sr Engineer, Database expertise)
  - Jordan (Sr Engineer, Payments expertise)
  - Casey (SRE, Operations expertise)
Informed:
  - Platform team
  - Security team
  - Compliance officer

Options:
1. PostgreSQL (matches our existing primary DB; team expertise)
2. CockroachDB (better multi-region; new to team)
3. Spanner (best consistency guarantees; vendor lock-in)

Timeline: Decision needed by 2026-08-15 to support Q4 launch.

Process:
  - Sam drafts options analysis (week 1)
  - Contributors provide written input (week 2)
  - 1-hour discussion (week 3)
  - Pat decides (week 3)
  - Sam communicates to Informed (week 3)

The document makes everything visible. The Driver runs the process; the Approver decides; Contributors shape; Informed know.

What Goes Wrong

Approver-by-committee. "Pat and the leadership team will decide." Means no one decides. Pick one.

Driver-as-decider. Driver tries to push their preferred outcome. Process becomes biased. Different Driver, or different approach.

Contributor-as-veto. Contributor insists their input must be the decision. Approver overrides; Contributor disengages.

Informed-as-Contributor. Person who should just be told instead engages and tries to shape. Re-classify or restate.

No DACI for big decisions. Decision happens in a meeting; nobody knows by whom; relitigation begins.

Decisions Without DACI

You don't need DACI for every decision. Most day-to-day decisions are made by individuals or small teams without ceremony.

Reach for DACI when:

Multiple stakeholders are involved
The decision will be expensive to reverse
The decision affects multiple teams
Past similar decisions have caused friction

For everything else, the lightweight version (one person decides, communicates) is enough.

DACI in Action

A working pattern for an engineering team:

Each significant decision has a DACI doc
The doc is brief (1 page max)
It's shared in a known place (wiki, drive, channel)
After the decision, it captures the decision and reasoning
Becomes a record for future reference

The doc is small. The discipline is using it.

Anti-Patterns

DACI-by-form. Filling in the template without engaging with the substance.

DACI for everything. Overhead exceeds value. Use for significant decisions only.

Approver-shopping. Bringing the same decision to different Approvers until one agrees. Defeats the framework.

DACI without follow-through. Decision made, not communicated, not implemented.

Connection to ADRs

DACI describes the decision process. ADR describes the decision itself.

For significant technical decisions, use both:

DACI to run the process
ADR to document the outcome

The DACI's "Approver" is the decision-maker named in the ADR. The discussion captured in DACI becomes context in the ADR.

Key Takeaway

DACI clarifies decision roles: Driver runs the process, Approver decides (single), Contributors provide input, Informed are notified. Use for significant decisions where multiple stakeholders are involved and relitigation is a risk. Skip for routine decisions. Keep the document brief; use the discipline. After the decision, the DACI document is a record of why; pair with ADR for technical decisions. The framework prevents the "decision made, then relitigated, then made again" pattern that wastes weeks.

ShiftQuality