Playbook From the archive
The DRI Principle
Every important outcome needs one person who is ultimately responsible
From the archive. This preserves an earlier position; its claims and assumptions may differ from my current thinking.
On this page 9 sections
Every important outcome needs one person who is ultimately responsible for it. That person is the Directly Responsible Individual (DRI).
What DRI Means
The DRI is accountable for the outcome.
They have:
- Power — authority to make decisions in their domain
- Accountability — ownership of results, good or bad
- Responsibility — the outcome succeeds or fails with them
The DRI is the person who cares most, knows most, and is best positioned to drive the overall effort to success.
What DRI Doesn't Mean
The DRI is not the person who does all the work.
This is the most common misconception. People hear "directly responsible" and think "must do everything myself."
Wrong.
The DRI is an owner, not necessarily the implementer:
- They don't have to write all the code
- They don't have to create all the designs
- They don't have to do all the analysis
- They don't have to manage all the tasks
The DRI orchestrates, decides, and ensures the outcome happens. They're responsible for the "what" and "whether"—not necessarily the "how" of every detail.
Owner vs. Executor
Think of the DRI like a homeowner:
- The homeowner is responsible for the house being maintained
- They decide what needs fixing and when
- They might hire plumbers, electricians, contractors
- They might do some work themselves
- But they're accountable for the house's condition
The DRI for a project works the same way:
- Responsible for the outcome
- Decides what needs doing and prioritizes
- Coordinates with engineers, designers, analysts, stakeholders
- Might do some implementation work themselves
- But accountable for the project's success
At Different Scales
Small efforts: DRI often is both owner and implementer
- "I'm the DRI for this feature" → you design it, code it, ship it
- You wear all hats because the scope is manageable
Larger efforts: DRI orchestrates but doesn't do everything
- "I'm the DRI for the mobile app rewrite" → you don't write every line of code
- You set direction, make trade-offs, unblock the team, drive to completion
- Engineers implement, designers create, PMs coordinate, but you own the outcome
Domains: DRI owns an area over time
- "I'm the DRI for authentication" → you're the go-to person, decision maker, and accountable for auth working well
- You don't personally fix every auth bug, but you ensure they get fixed
The principle scales. The scope changes, but the accountability doesn't.
What the DRI Actually Does
The DRI's core job:
- Set direction — what are we trying to achieve?
- Make decisions — when there's ambiguity or trade-offs
- Unblock progress — remove obstacles, clarify questions, resolve conflicts
- Coordinate resources — who does what, when
- Drive to completion — ensure the outcome actually happens
- Own the result — take responsibility when things go well or poorly
- Be the point of contact — the person others go to with questions
The DRI knows the status, understands the trade-offs, and can speak authoritatively about the domain. They don't know every detail of every task, but they know the overall picture.
Power and Accountability Go Together
You cannot have accountability without power. You cannot have power without accountability.
If you're the DRI:
- You have authority to make decisions in your domain
- Others should defer to your judgment
- You can be overridden only in rare, critical cases
- When things fail, it's your responsibility
If someone else is the DRI:
- You can give input and challenge their thinking
- But they make the final call
- You commit once the decision is made
- They own the outcome
This clarity prevents:
- Decisions by committee
- Diffusion of responsibility
- "Not my problem" culture
- Endless debates without resolution
Listen → Challenge → Commit
When you're not the DRI:
- Listen — understand their thinking
- Challenge — offer better ideas, raise concerns, ask hard questions
- Commit — once they decide, support the decision fully
You can disagree during the discussion. But once the DRI decides, you commit. You don't undermine, revisit, or continue arguing.
If you can't commit, escalate explicitly—don't silently resist.
Common Mistakes
Mistake 1: Diffused responsibility "We're all responsible for this project" → Result: No one is truly accountable. Decisions stall. Things fall through cracks.
Fix: Name one DRI. Others contribute, but one person owns it.
Mistake 2: DRI does everything "I'm the DRI so I have to write all this code myself" → Result: Burnout, bottleneck, slow progress.
Fix: Delegate execution. Own the outcome, not every task.
Mistake 3: DRI without power "You're responsible but you need approval from three people for every decision" → Result: Accountability without authority. Frustration and failure.
Fix: Give DRIs real decision-making power in their domain.
Mistake 4: Too many DRIs "We have 5 DRIs for this project" → Result: Confusion about who decides what. Overlapping accountability.
Fix: One DRI per outcome. If there are multiple outcomes, split them clearly.
Mistake 5: DRI as title without culture "We assign DRIs but everyone still needs consensus" → Result: DRI principle exists on paper, not in practice.
Fix: Actually let DRIs make decisions. Challenge them, but commit to their calls.
The Questions to Always Ask
"Who is the DRI for this?" "Do they have the power to make decisions?" "Do they have the right support and resources?" "Am I clear on my role if I'm not the DRI?"
If there's no clear DRI, stop and assign one. If the DRI doesn't have real power, fix that. If people keep undermining the DRI, address the culture.
Your goal isn't consensus on every decision. It's clear accountability with appropriate input—and the velocity that comes from knowing who decides what.
Once you have clear DRIs, decisions become faster and cleaner. Ownership becomes real. And outcomes improve because someone actually cares.
Christian Blank
San Francisco · Updated May 2026
christian@blank.dev | www.blank.dev
Co-written and formatted with AI