The DACI Framework: How Technical Program Managers Drive Cross-Team Decisions
DACI defines who actually gets to decide, not just who's responsible for the work. Here's how the four roles work, why DACI is different from RACI, and how to use it to answer a Technical Program Manager interview question.
By The Cala Voice Team ·The most common failure mode in a cross-team program isn't a lack of effort. It's a decision that never actually gets made, because five people believe they have a vote and nobody is sure who has the final call. The meeting ends with "let's think about it," the same debate resurfaces two weeks later, and the program slips while everyone agrees the topic is important.
DACI (Driver, Approver, Contributors, Informed) is the framework Technical Program Managers use to prevent exactly this. It doesn't decide the question for you. It decides who is allowed to decide, before the debate starts, so ambiguity about decision rights never becomes the reason a program stalls.
The Four Roles
Driver
The Driver owns moving the decision to closure. This is usually the Technical Program Manager. The Driver doesn't necessarily have the final call, their job is to gather the right input, frame the options clearly, and force the decision to actually happen by a specific date, rather than let it drift.
Approver
The Approver has the final call. There should be exactly one Approver, or a small, named group with a clear tiebreaker. The single most common DACI failure is having no named Approver, or having so many people who believe they're the Approver that the decision has no real owner.
Contributors
Contributors provide input, expertise, and constraints, but they don't have veto power. An engineer on a Contributors list can say "this approach will take three extra weeks," and that input should genuinely shape the decision, but the Contributor doesn't get to unilaterally block it.
Informed
The Informed group learns about the decision after it's made. They're not consulted beforehand, because consulting everyone who's merely affected by a decision is exactly the bottleneck DACI exists to avoid.
Why DACI Beats a Meeting Without Roles
Most cross-team decisions don't fail because nobody has an opinion. They fail because everyone in the room believes their opinion carries decision-making weight, so the conversation never converges. A senior engineer who believes they're an Approver behaves very differently in a meeting than a senior engineer who knows they're a Contributor: the first will hold out for their preferred option, the second will state their concern clearly and let the decision proceed.
Naming the roles before the meeting, not during it, changes the entire dynamic. It also creates accountability: when a decision turns out badly, DACI makes it clear whether the failure was a bad call by the Approver, or the Driver failing to surface a Contributor's warning that should have changed the outcome.
DACI vs RACI
DACI and Responsible, Accountable, Consulted, Informed (RACI) are often confused, and interviewers notice when a candidate uses them interchangeably.
RACI is a framework for execution responsibility: who does the work (Responsible), who is ultimately accountable for it being done (Accountable), who needs to be consulted during the work (Consulted), and who needs to be informed once it's done (Informed). RACI answers "who does what."
DACI is a framework for decision rights specifically: who drives a decision to closure, who has final approval authority, who contributes expertise, and who is informed of the outcome. DACI answers "who decides."
A program can, and often should, use both: RACI to clarify execution ownership across a workstream, and DACI to clarify who resolves a specific contested decision within that workstream. Naming this distinction explicitly in an interview answer is a strong signal that you've used both frameworks in practice, not just memorized their acronyms.
How to Apply DACI in a TPM Interview Answer
A strong answer to a cross-team decision question doesn't just say "I got everyone aligned." It names the specific DACI structure you set up.
Typical question: "Two engineering teams disagreed on which service should own a shared piece of infrastructure. How did you resolve it?"
A strong answer: names who the Driver was (often the candidate), who was named as the single Approver and why that person had the standing to make the call, which engineers were Contributors and what specific technical input changed the outcome, and how the decision and its rationale were communicated to the Informed group afterward so it didn't get relitigated.
A weak answer: describes a lot of meetings and stakeholder management activity without ever naming who actually had the authority to decide, which reads as a program that got resolved by attrition rather than by structure.
DACI in a Technical Program Manager Interview
DACI comes up most often in behavioral and deep behavioral questions about resolving cross-team disagreement, and it's one of the fastest ways to demonstrate structured decision-making rather than generalized "stakeholder management." Naming the Driver and Approver explicitly, and explaining why that Approver was the right choice, does more work in an interview answer than describing the disagreement itself.
For the full interview process this framework fits into, What Is a Technical Program Manager Interview? Complete Overview for First-Timers covers every stage of the loop and what each round tests.
Cala Voice runs you through behavioral and technical mix scenarios built around exactly this kind of cross-team decision-making, so you can practice naming a DACI structure out loud before it comes up in a real interview.