What is a DRI?
A DRI, or directly responsible individual, is the one person accountable for a specific project, decision or outcome. They make the final call, they consult whoever they need to, and when the thing succeeds or fails, theirs is the name attached to it. One outcome, one name.
The value of the practice is in what it removes. Most stalled projects aren't stalled because the work is hard. They're stalled because four people each believe someone else is deciding, and every meeting ends with "let's sync offline." Putting a single name next to the outcome turns that diffuse responsibility into a question with an answer: who decides? Ask that person.
I use the term constantly with engineering teams, and the most useful version of it is blunt. If you can't name the DRI in under five seconds, there isn't one.
Where did the DRI concept come from?
The term is associated with Apple under Steve Jobs. Fortune's Adam Lashinsky described it in a 2011 feature on how Apple worked internally ("How Apple works: Inside the world's biggest startup"), writing that Apple's internal vocabulary had a name for the person responsible for a task, the DRI, and that the DRI's name often appeared on meeting agendas so everyone knew who owned each item. Lashinsky expanded on the practice in his 2012 book Inside Apple.
The practice spread well beyond Apple through GitLab's public handbook, which credits Apple with coining the term and turns it into explicit operating rules. Two of them are worth copying verbatim into your own team norms. The DRI has the final decision but should consult relevant stakeholders first. And DRIs don't owe a justification for every decision, which GitLab frames as a guard against analysis paralysis: people stop proposing things when every proposal triggers an endless round of explanations.
DRI vs RACI: what's the difference?
RACI maps everyone's participation in a piece of work; a DRI fixes who owns and decides it. RACI assigns four roles (Responsible, Accountable, Consulted, Informed) and requires exactly one Accountable person per task. The DRI is, in effect, that single A, without the rest of the matrix.
| DRI | RACI | |
|---|---|---|
| Answers | Who owns this and decides? | Who does what, who decides, who gives input, who gets told? |
| Number of roles | One | Four |
| Consultation | At the DRI's judgment | Listed explicitly (C) |
| Setup cost | One name in the ticket or agenda | A matrix per project, kept current |
| Best for | Fast decisions, small to mid-size work, incidents, ongoing ownership | Cross-functional programs with many handoffs, regulated work that needs a paper trail |
| Failure mode | A DRI without real authority becomes a scapegoat | The matrix goes stale, or several people end up marked A |
They aren't rivals. On a large program I'll use RACI to map the handoffs between product, engineering, security and legal, and still put a single DRI name at the top of the document. On everyday work the RACI is overhead and the DRI is enough.
How do you assign a DRI?
Pick the person closest to the work who has the authority to make its trade-offs, make sure they accept it, and write their name where the work is tracked. The steps:
- State the outcome in one sentence. "Migrate billing to the new payment provider by Q1 with no double charges" can have a DRI. "Improve billing" can't.
- Choose by authority and proximity, not seniority. The best DRI is usually the most senior person who is still close enough to the detail to decide quickly. A VP who will never read the design doc is the wrong pick.
- Get an explicit yes. Accountability someone didn't accept is blame waiting to happen.
- Hand over the decision rights. Write down what the DRI can decide alone, and the short list of things that still need sign-off (budget above a threshold, security exceptions). GitLab calls these the rare cases requiring approval.
- Record the name in the system of record. The ticket, the decision doc, the agenda,
CODEOWNERS, the on-call schedule. Wherever people go to ask "who owns this?" - Reassign explicitly. When the DRI changes roles, the ownership moves in writing. Silent drift is how orphaned systems happen.
If you're a CTO deciding what to keep for yourself versus hand out, this is the same exercise as the CTO delegation framework: a delegated decision without a named DRI usually floats back up to you.
Who is the DRI when AI agents write the code?
The human who directed the agent and merged its work. In most teams that's the PR author. An agent is a tool with a lot of initiative, and using a tool doesn't move accountability any more than using a compiler or a code generator did. If an agent-written change breaks production, the postmortem doesn't list the model as the owner.
This sounds like a technicality, and it's turning into one of the more important org-design questions of the AI era. When an agent can open twenty PRs a day, the ratio of code produced to humans who understand it changes fast. Without a named owner per change, you end up with code that every reviewer assumed someone else had read. The fix is the same as it always was: put a name on it.
Why can't an AI agent be the DRI?
Accountability needs three things an agent doesn't have. It needs consequences: a DRI's judgment is shaped by the fact that they will answer for the outcome. It needs context: the DRI weighs the customer escalation from last week, the board deadline, the team's morale, most of which never reaches the agent's context window. And it needs continuity: three months later someone has to be able to ask "why did we do it this way?" and get an answer from someone who remembers the trade-off. An agent can produce an explanation. It can't own one.
A DRI map for AI-era decisions
| Decision or artifact | Who is the DRI |
|---|---|
| An agent-written pull request | The human who prompted or assigned the agent and merges the PR |
| An autonomous agent that opens PRs on its own | A named engineer for that agent's scope, with authority to pause it |
| The AI code review bar | One engineering leader who owns the AI code review policy |
| An AI feature's outputs in production | The product or engineering lead for that feature, not the model vendor |
| Model and vendor selection | The platform or AI lead, with security and procurement consulted |
| An AI-assisted decision (pricing, hiring screen, credit) | The business owner of that decision; the AI is an input |
| Agent permissions and access scope | The engineering owner of the system the agent can touch |
Two practices make this real. First, write the DRI into the artifact: a CODEOWNERS entry, an owner field in the agent's config, a name in the PR template. Second, make the DRI the person with the stop button. If the named owner of an autonomous agent can't pause it without asking someone else, the DRI is decorative. For the broader governance side, the AI governance roles guide covers who sits where in the org, and the AI team org chart covers the reporting lines.
Common DRI mistakes
- Naming a team. "Platform owns it" means nobody does.
- Responsibility without authority. If the DRI needs three approvals to change anything, you've built a scapegoat, not an owner.
- The default-to-manager reflex. Assigning every DRI to the most senior person concentrates decisions in one inbox and slows everything down.
- Never reassigning. DRIs leave, change teams, go on parental leave. Ownership has to move with them in writing.
- Treating the AI tool as the owner. "Copilot wrote it" and "the model decided" are descriptions of how, not answers to who.
Sources
- Adam Lashinsky, "How Apple works: Inside the world's biggest startup," Fortune, 2011.
- Adam Lashinsky, Inside Apple, Business Plus / Hachette, 2012.
- GitLab Handbook: Directly Responsible Individuals
- Tech Manager Weekly #504 (19 October 2026), discussion of DRIs and ownership in the AI era.
Frequently asked questions
What does DRI stand for?
DRI stands for directly responsible individual. It is the one person who owns a project, decision or outcome and has the final say on it. The term is associated with Apple, where Fortune reported in 2011 that a DRI's name often appeared next to agenda items so everyone knew who was responsible.
Is a DRI the same as a project manager?
No. A project manager coordinates work and tracks progress; a DRI owns the outcome and makes the final decisions. On a small project the same person can be both. On larger work, the DRI is often a product or engineering leader while the project manager keeps the plan running, and the two roles should not be confused.
Can a team be a DRI?
No. The whole point of the practice is that accountability rests with one individual. A team can own a service or a codebase, but each decision, project or incident within it should have one person's name next to it. When the answer to "who is the DRI?" is a team name, nobody is.
What is the difference between a DRI and the Accountable role in RACI?
They map closely. RACI requires exactly one Accountable person per task, and GitLab's handbook notes the DRI usually sits in that A role. The difference is scope: RACI also spells out who is Responsible, Consulted and Informed, while the DRI practice only fixes who owns and decides, and leaves consultation to that person's judgment.
Who is the DRI for code written by an AI agent?
The human who directed the agent and merged the change, which in most workflows is the PR author. Using an agent does not transfer accountability any more than using a compiler does. For agent fleets that open PRs on their own, name a human DRI for each agent's scope of work, and make sure that person has the authority to pause it.
How do you assign a DRI?
Write down the outcome in one sentence, pick the person closest to the work who has the authority to make the trade-offs, confirm they accept it, and record the name where the work is tracked. Then give them the decision rights that go with it. A DRI who has to get every choice approved is a coordinator, not a DRI.
what is a dri
A DRI, or Directly Responsible Individual, is the one named person accountable for a specific project, decision, or outcome. They make the final call, consult whoever they need to, and their name is attached to the result whether it succeeds or fails. The rule is one outcome, one name. Never a team, alias, or tool. If you can't name the DRI in under five seconds, there isn't one.