Assign Decision Ownership with DACI

Hello. In the previous lesson, you translated project-lead experience into résumé evidence: accurate leadership verbs, meaningful scope, and measurable outcomes. That work made your past leadership visible. This lesson focuses on a behavior you will need to demonstrate on the job and in interviews: creating clarity about who gets input, who coordinates, and who makes the call.

Technical managers routinely face decisions that span engineering, product, security, operations, and business constraints. If ownership is vague, teams can mistake consultation for consensus, wait for approval from the wrong person, or reopen a decision after work has started. By the end of this lesson, you will be able to assign decision ownership using DACI and document it in a lightweight, usable form.

---

Decision ownership is not task ownership

A project can have many tasks, each with an implementer and reviewer. A decision, by contrast, is a bounded choice with consequences: for example, whether to delay a launch for a reliability fix, which migration sequence to adopt, or whether to accept a security-risk exception.

A common failure in technical teams is treating every affected person as a co-owner of the decision. That sounds inclusive, but it creates delay and ambiguity. People need different kinds of involvement:

• Some must coordinate the work needed to reach a decision.
• One person must be able to make the final call.
• Some have expertise that should materially shape the choice.
• Others need timely notice because their work changes after the choice is made.

DACI is designed to make those distinctions explicit for a significant, discrete decision. It is particularly useful when the decision crosses team boundaries or when authority is otherwise easy to confuse.

---

The four DACI roles

DACI stands for Driver, Approver, Contributors, and Informed. The roles apply to a decision, not permanently to a person’s job title. An engineering manager may Approve one decision, Drive another, and be Informed about a third.

Driver: owns the decision process

The Driver makes sure the decision gets made well and on time. They clarify the decision statement, identify stakeholders, gather relevant evidence, arrange discussions, track open questions, and record the outcome.

The Driver is not automatically the most senior person, the project manager, or the person who implements the result. A senior backend engineer or project lead can be an effective Driver for a decision that their engineering manager Approves.

A Driver should be able to answer:

• What exactly are we deciding?
• By when must a decision be made?
• What evidence, options, and criteria are needed?
• Whose expertise is essential?
• What remains unresolved, and who owns the next action?

Important: Driving is active leadership, but it is not unilateral authority. A Driver who makes the final call without being the Approver has bypassed the framework.

Approver: owns the decision

The Approver is the single person who makes the final decision after hearing appropriate input. They own the trade-off and accept accountability for its consequences.

The word single matters. Two “final approvers” usually means no final approver: the decision can stall whenever they disagree. If two leaders genuinely have authority, resolve that governance conflict before beginning the DACI. For the decision itself, name one person who will decide by the agreed date.

The Approver should have both:

1. Authority: organizational permission to make the call.
2. Accountability: responsibility for the delivery, operational, financial, or customer consequences.

For a team-level engineering decision, the Approver may be the engineering manager. For an architectural choice that affects multiple departments, it may be an engineering director or a designated architecture owner. The correct choice depends on your organization’s delegated authority, not merely seniority.

Contributors: provide decision-relevant expertise

Contributors give input before the decision is made. They may supply data, identify risks, recommend an option, challenge assumptions, or explain constraints.

Contributors have a voice, but they do not have a veto merely because they contributed. The Driver should be selective: include people whose expertise can change the quality of the decision. A long contributor list can turn a timely decision into endless consultation.

For a backend and AWS decision, useful contributors might include:

• a platform or SRE engineer who understands operational implications;
• a security specialist who can identify control requirements;
• a product manager who clarifies customer and timing constraints;
• an application owner who knows migration risk and service behavior;
• a finance or FinOps partner when cost is a meaningful criterion.

Being affected by a decision does not automatically make someone a Contributor. Ask: What unique knowledge can this person provide before the choice is made?

Informed: receives the outcome

Informed stakeholders are affected by the decision but do not need to shape it directly. They receive the outcome, its rationale, and any actions or changes relevant to them.

This is not a lesser or dismissive role. An engineer whose on-call procedures change, Support staff who need to understand a customer-visible behavior, or a dependent team whose timeline changes may all need clear communication. The distinction is about decision efficiency: their need is for a usable outcome, not participation in every discussion.

A good message to Informed stakeholders states:

• the decision made;
• the effective date or implementation plan;
• the brief rationale;
• what changes for them;
• where to find the full record or raise an implementation issue.

---

Assign DACI in the right order

Naming four categories is easy. Assigning them well requires starting with the decision, rather than with the people in the room.

Use this sequence when you establish a DACI.

1. Write a decision statement that can be answered

A decision statement should identify a specific choice, scope, and date. Avoid vague statements such as:

Improve our deployment process.

That is an initiative, not a decision. It contains many possible decisions.

Instead, write:

By 15 July, decide whether the payments team will adopt the shared deployment pipeline for its three Node.js services in Q3.

This statement gives the Driver a clear endpoint. It also makes it possible to identify the actual decision-maker and the expertise needed.

If a statement contains several choices, split it. For example, “select a platform, decide a migration sequence, and set the rollout date” is probably three separate decisions. One DACI per meaningful decision prevents the roles from becoming muddy.

2. Name the Approver first

Ask: Who has the authority and accountability to accept this trade-off?

Starting here prevents a frequent mistake: appointing the most organized person as Driver, then assuming they can decide. A project lead may run the process excellently, but the engineering manager may need to own the delivery and operational risk.

Confirm the commitment explicitly:

You are the Approver for the adoption decision. We will collect input by 12 July, and you will make the call by 15 July.

This prevents an Approver from behaving as a passive reviewer after the process is already underway.

3. Choose a Driver who can move the work

The Driver needs enough context, credibility, and time to coordinate the decision. They do not need to be the technical expert in every area. Their responsibility is to make sure the right evidence gets in front of the Approver.

For a transition into technical management, this is a role you can often demonstrate immediately. Your prior project-lead experience likely contains examples of coordinating dependencies, surfacing risks, and keeping a decision moving. In an interview, describing that work as “I drove the decision process; my manager made the final call” is both strong and accurate.

4. Add only necessary Contributors

For each potential Contributor, ask:

What question can this person answer that would materially affect the decision?

If the answer is specific, include them and state the input you need. For example:

Contributor	Decision-relevant input
Platform engineer	Pipeline compatibility, operational support model, rollback capability
Security engineer	Required controls and exceptions, if any
Product manager	Delivery-date constraint and customer impact of delay
Payments service owner	Migration effort, service-specific risks, testing needs

This makes consultation focused. It also helps the Driver request input asynchronously when a meeting is unnecessary.

5. Identify who must be Informed

Finally, list people whose work, commitments, or customers will be affected. Define the communication they need rather than simply adding names to a distribution list.

For example:

Informed group	What they need to know
Payments engineers	Adoption decision, rollout sequence, required preparation
Support lead	Any release-window or customer-impact implications
Dependent checkout team	Timeline implications and any interface changes
Engineering leadership	Decision, rationale, major risk, and expected delivery effect

---

Worked example: a deployment-standardization decision

Imagine that your organization has several Node.js services, each using a different deployment workflow. Release rollbacks are inconsistent, and a Q3 reliability goal depends on adopting a shared pipeline for the payments domain.

The decision is:

By 15 July, decide whether the payments domain will adopt the shared deployment pipeline for its three Node.js services in Q3.

A defensible DACI could look like this:

DACI role	Assignment	Why this assignment fits
Driver	Backend project lead	Coordinates evidence, schedules reviews, tracks open questions, and maintains the decision record.
Approver	Engineering manager for Payments	Owns Q3 delivery commitments, team capacity, and the operational trade-off.
Contributors	Platform engineer, security engineer, product manager, service owners	Each supplies evidence on feasibility, controls, customer timing, and migration risk.
Informed	Payments engineers, Support lead, checkout-team lead, engineering director	Their work, release planning, or stakeholder communications may change after the decision.

Notice what this DACI does not say:

• It does not make the platform engineer Approver simply because they own the pipeline.
• It does not make every payments engineer a Contributor by default.
• It does not imply that the Driver will build every migration.
• It does not ask the group to reach unanimous agreement.

The Driver’s job is to assemble a decision brief. It might contain the current rollout problem, three service assessments, expected adoption effort, rollback constraints, security requirements, delivery impact, and a recommendation. Contributors review the material and raise concerns. The Approver decides whether to adopt, defer, or choose a limited pilot.

Once the decision is made, the Driver records it. That record stops the team from relitigating the same question two weeks later and gives Informed stakeholders an explanation they can act on.

---

A lightweight DACI record

A decision framework only helps if people can use it during normal delivery work. Use this template in a project document, ticket, or decision log.

Decision: [A single, answerable choice]
Decision date: [Date]
Driver: [Name]
Approver: [One name]
Contributors: [Name — specific input needed]
Informed: [Person or group — communication needed]

Context: [Why this decision is needed now]
Options and criteria: [Alternatives, evidence, and evaluation criteria]
Decision: [Final choice]
Rationale: [Why this option was chosen, including key trade-offs]
Follow-up actions: [Action, owner, due date]

The first six lines establish decision rights. The rest makes the decision usable after the meeting. Keep the record concise, but preserve enough context that a new team member can understand why the choice was reasonable at the time.

---

Check for common DACI failures

Before you publish a DACI, run this short review.

Failure signal	Why it causes trouble	Correction
Two or more Approvers	The final decision can deadlock or become political.	Escalate the authority question and name one Approver.
No named Approver	Consultation may continue indefinitely.	Identify the person accountable for the consequences.
Driver assumes decision authority	Coordination and authority become confused.	State the decision date and the Approver’s responsibility explicitly.
Every affected person is a Contributor	Input becomes slow, repetitive, and difficult to synthesize.	Keep Contributors to people with unique, decision-relevant knowledge.
Informed stakeholders hear late	Teams discover changes after plans or commitments are made.	Plan the outcome message while setting up the DACI.
The “decision” is actually an initiative	Roles become broad and unclear because several decisions are hidden inside it.	Rewrite it as one bounded choice, or split it into several DACIs.
The outcome is undocumented	The decision gets reopened and rationale disappears.	Record the choice, rationale, owner, and follow-up actions.

The purpose is not bureaucracy. If a choice is small, reversible, and entirely within one engineer’s authority, a DACI would be overhead. Use it when the cost of unclear ownership, delayed input, or a surprising outcome is high enough to justify a few minutes of explicit structure.

---

DACI and RACI: choose the tool that fits

DACI is often confused with RACI, but they answer different questions.

• DACI clarifies how a group reaches a particular decision.
• RACI maps who performs, owns, is consulted on, and is informed about ongoing tasks or deliverables.

The roles overlap in spirit, particularly the importance of a single final accountable person. But do not treat DACI’s Driver as RACI’s Responsible role. A Driver coordinates a decision process; a RACI Responsible person performs the work.

For example, you might use:

• a DACI to decide whether to adopt the shared deployment pipeline;
• a RACI afterward to clarify who builds migration tooling, migrates each service, reviews controls, and communicates release status.

That distinction prevents a decision-rights document from turning into a sprawling project plan. In later modules, you will use related tools for delivery planning, architectural decisions, incident roles, and stakeholder communication.

---

Key takeaways

DACI gives a technical manager a practical way to make decision rights visible before ambiguity becomes delay or conflict.

• Define one specific decision with a scope and decision date.
• Assign one Approver who has authority and accountability for the trade-off.
• Choose a Driver who coordinates evidence, stakeholders, open questions, and documentation.
• Use Contributors for focused, decision-relevant expertise—not as a substitute for consensus.
• Keep affected people Informed with a clear outcome, rationale, and implication for their work.
• Record the decision and its follow-up actions so the team can execute without reopening the question.

Next, you will build on this idea of calibrated leadership by deciding when a technical manager should step in directly, coach, delegate, or simply monitor a team situation.