A directly responsible individual, or DRI, is one named person accountable for a decision, a project, or an area of work. The DRI model assigns a single owner to each thing that matters, so the answer to "who owns this" is always one name, never a shrug. It beats committee ownership because shared accountability is usually no accountability: when everyone owns a decision, no one does, and the work stalls in the gap between people who each assumed someone else had it.
The idea is simple, but the value depends on one thing teams forget. Naming a DRI only helps if people can find out who the DRI is. A name that lives in someone's memory, or in a kickoff doc nobody reopens, is not much better than no name at all. The DRI model works when "who is the DRI for the billing system" is a question you can ask a record and get answered.
What is a directly responsible individual?
A directly responsible individual is the single person on the hook for a given decision or area, the one who makes the call and answers for the outcome. It does not mean that person does all the work, and it does not mean they decide alone without input. It means that when the question is "who is accountable here," there is exactly one name, and that person cannot pass the buck to a group.
The DRI is accountable, not necessarily the expert and not necessarily the doer. On a migration, the DRI might coordinate five engineers and write none of the code, but they own whether the migration lands and they answer when it does not. That single point of accountability is the whole mechanism.
Why does committee ownership fail?
Committee ownership fails because accountability does not divide. When you assign a decision to a group, you have not given it three owners, you have given it zero. Each person reasonably assumes another is driving it, the decision sits, and when it finally goes wrong there is no one to answer the simple question of why nobody acted. Diffusion of responsibility is not a character flaw. It is the predictable result of naming a crowd instead of a person.
There is a speed cost too. A committee has to converge before anything moves, so the slowest, most cautious member sets the pace, and bold calls get sanded down to whatever everyone could tolerate. The group informs; the DRI owns.
Committees also blur the record. Six months later, "the platform team decided to use Kafka" tells you nothing about who to ask when the decision needs revisiting. "Priya is the DRI for the platform messaging choice" tells you exactly who holds the context. One of those is a queryable answer. The other is a dead end.
How does the DRI model compare to RACI?
The DRI model and RACI are both ways to assign responsibility, but they answer slightly different questions. RACI is a matrix that labels each person on a task as Responsible, Accountable, Consulted, or Informed. The DRI model collapses the most important of those, accountability, into a single named role and keeps it simple. RACI describes a web of involvement; the DRI names the one person who owns the outcome.
You can use both. RACI is useful when a task has many contributors and you want to spell out who does the work versus who must be consulted. The DRI is the answer to "but who is ultimately accountable," which RACI also captures in its single "A," sometimes too quietly to be useful in practice. Many teams find that naming a DRI loudly, in plain language, sticks better than maintaining a full matrix nobody reads.
DRI ownership vs. committee ownership
| What you need | Committee ownership | Directly responsible individual |
|---|---|---|
| Who is accountable | A group, so effectively no one | One named person |
| Speed of decisions | Gated by the slowest member | The DRI decides with input |
| Who to ask later | Unclear | The named DRI |
| When it goes wrong | Everyone points sideways | One owner answers |
| Findable in a record | "The team decided" | "Priya is the DRI for X" |
The right column is not about blame. It is about having one person who holds the context and can speak to the reasoning when the decision needs to be revisited.
How do you make "who is the DRI for X" answerable?
Naming a DRI is half the job. The other half is making that name findable, which is where most teams quietly fall down. A DRI assigned in a kickoff meeting and never recorded anywhere is a DRI in name only, because three months later nobody remembers who it was, and the question goes back to the void.
This is where StandIn helps. StandIn auto-indexes your work, so the projects, decisions, and areas you own are discoverable and pointable. That makes the material findable. But indexing alone does not establish who owns what, because indexed text does not carry accountability on its own. Declaring is the separate human step where the DRI vouches for the ownership: "yes, I am the directly responsible individual for the billing system, and you can quote me." A declared DRI turns "who owns this" into a question with a sourced answer and a named person behind it.
The result is that "who is the DRI for the payments integration" becomes a query, not a hallway hunt. Ask the record and you get the name, the area, and a link to the work it covers, sourced to the person who stood behind it. Ask about an area no one has claimed, and the record says "no record," which is the most useful answer you can get, because it tells you the ownership is genuinely missing and someone needs to claim it. That refusal is information. You can see how indexing and declaring fit together in how StandIn works.
What happens to a DRI's knowledge when they leave?
This is the hardest test of any ownership model, and it is where a recorded DRI earns its keep. When a DRI leaves and their accountability lived only in people's heads, the area becomes an orphan. Nobody is sure who owns it now, the context walks out the door, and the next person inherits a system with no clear history of why it is the way it is.
When the DRI relationship was declared into a record, the handoff is concrete. The successor reads who owned the area, the decisions that DRI stood behind, and the reasoning attached to each, so they pick up real continuity instead of a guess. The record outlives the person, which is the point. Pairing the DRI model with a queryable record keeps a team's accountability intact even as people rotate through.
Frequently Asked Questions
What does DRI stand for?
DRI stands for directly responsible individual, the single named person accountable for a decision, project, or area. It is the one person who answers for the outcome, even if others do the work.
How is a DRI different from a manager?
A manager runs people; a DRI owns a specific decision or area. A junior engineer can be the DRI for a service their manager has never touched. The role is about accountability for a thing, not authority over people.
Is the DRI model the same as RACI?
Not quite. RACI is a full matrix of Responsible, Accountable, Consulted, and Informed. The DRI model focuses on the single accountable owner and keeps it loud and simple, though you can use both together.
Does StandIn assign DRIs automatically?
No. It indexes your work so ownership is discoverable, but a DRI relationship only becomes an answer when the person declares it. It never assigns accountability on its own, and it says "no record" when no one has claimed an area.
How do I find out who the DRI for something is?
Ask the record. If the DRI was declared, you get the name, the area, and a source. If no one has claimed it, you get a clear "no record," which tells you the ownership needs to be assigned.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to retire your daily standup?
Distributed teams use StandIn to start every shift with full context, no standup required. Engineers publish a 60-second brief. The next shift wakes up knowing exactly what to work on.