The DRI

Every initiative carries one name: its DRI, the Directly Responsible Individual. The DRI is the single person accountable for whether that initiative lands, on time and at quality. One initiative, one DRI. If everyone is accountable, no one is.

The DRI owns the outcome, not the keyboard. Their job is to make the thing happen and keep the status honest, not to build it themselves. That distinction is the whole point of the role.

Discomfort is the signal you’re doing it right#

If you are a DRI and you feel comfortable, something is wrong. Being handed accountability for an outcome, especially on a product you do not know well, should feel like weight. That discomfort is not a problem to manage away; it is the thing keeping you honest. A DRI who feels relaxed about an initiative they cannot yet see the whole of has stopped owning it and started hoping.

The role is not a set of fields to keep updated. It is one commitment: make sure it lands, completely. Everything else, the updates, the sequencing, the guardrails below, is downstream of whether you actually feel on the hook for the outcome.

This changes which questions you ask. The common one is mechanical: “it’s in block 3, do I start the block-1 item now or plan first?” That is the wrong question, because it is about arranging the work, not about whether the work will succeed. The question that matters is: am I sure this will land? If the honest answer is no, the next move is not a better schedule. It is to raise it, now.

Two things that discomfort should make you do early, not late:

• Not sure you’ll succeed? Ask for help immediately. The cost of asking is smallest at the start and grows every week you sit on it. A DRI who waits until the deadline to admit they were never going to make it has failed at the one job the role has: keeping the status true. Early is cheap, late is a surprise, and surprises are the failure.
• Under-resourced for the scope? Shout. Handed a genuinely complex initiative with only an intern to execute it, the wrong response is to quietly try and hope. Say plainly that the scope and the resourcing do not match, and say it before the block starts, not after it slips. If you are accountable for the outcome, you are expected to fight for what the outcome needs.

None of this is working harder in the abstract. It is a specific instinct: feel the weight, trust the discomfort, and act on it while acting still changes the result.

The accountability-partner principle#

A DRI is an accountability partner, not the executor. The builders do the work; the DRI holds it accountable and is accountable for it.

Keep the two separate. The moment the DRI is also the one building the initiative, the accountability partner disappears: the person vouching for the work is the person who did it. You lose the outside read on “is this actually on track”, the second set of eyes, the one person whose only job is the outcome rather than the task. An initiative where the same person builds it and reports on it has no real check at all.

So the default is two roles, two people:

On a team too small to split them, the DRI may also contribute, but the accountability check still has to come from someone else: their lead or manager becomes the partner in the weekly sync. The principle holds even when headcount is thin. Never let one person be the only voice on both the work and whether it is on track.

What a DRI does#

• Owns the initiative fields. Problem, solution, release plan, person-sprints, flag: filled and current before stories are placed. See User Story Map.
• Clears the path. Sequences the work, unblocks the executors, escalates when stuck. Accountability includes removing what is in the way.
• Posts updates regularly. On every active initiative: what moved, what is blocked, and a confidence call, on track, at risk, or off track. An initiative with no update in 2 days is stale, and stale is visible.
• Calls risk early. At-risk is named the week it becomes at-risk, not at the deadline. No surprises, up or down. See Communication.
• Owns it through Learn. It is not done when it ships. The DRI stays accountable until the outcome is measured and known. See Launch and Learn.

Guardrails#

• One DRI per initiative. Not two, not a squad. A single name, or accountability blurs.
• The DRI is not the executor of the same initiative. Keep the accountability partner off the keyboard for that work, so someone independent is always reading whether it is really on track. On a small team, borrow that check from a lead or manager.
• Accountability is not rescue. The DRI does not quietly build it themselves when the executor stalls. If they end up having to, the executor or the scope is wrong: surface that, do not paper over it.
• Accountable, not a bottleneck. The DRI removes blockers; they are not a gate every decision must route through. Empower the executors to move.
• Authority matches accountability. A DRI is trusted to make the calls their outcome needs. If they cannot, that is a management gap to fix, not a DRI who should stay quiet.
• The update is non-negotiable. It is the artifact of the role. Miss it and the initiative is presumed adrift.

Who is the DRI#

The DRI is whoever is best placed to own the outcome: usually a Mid or Senior for a real initiative, or a Lead who assigns the execution and holds the accountability. It is assigned during Half Strategy planning and written on the initiative in Define, before any story is placed.

Being a DRI is how engineers grow into owning outcomes rather than tasks, the trunk climb in Product Engineer. It is a real rep in ownership and delivery, taken one rung before it feels comfortable, with the manager as the accountability partner while the muscle builds.

Related: User Story Map, Half Strategy, Define, Communication, Product Engineer