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.

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:

Role	Optimizes for	Held accountable by
Executor	Building the thing well	The DRI
DRI	The thing landing, and the status being true	The team, in the weekly call

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 Communicate Up.
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 Quarterly Roadmap 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.