Directly Responsible Individual (DRI)

The DRI is the single person accountable for a project's outcome — not just for doing work, but for ensuring the project is going well and that everyone involved can operate autonomously.

Being DRI is distinct from being an IC on the project. The DRI:

Owns the working doc (master reference for goals, staffing, roadmap, open questions)
Runs the weekly meeting (backstop for coordination; creates common knowledge)
Maintains a plan/roadmap with intermediate milestones — primarily as an early-warning system
Maintains a stack-ranked list of who's working on what
Sends weekly broadcast updates (vibe, what changed, what's next — signal/noise optimized)
Runs retrospectives when the project has enough data

The minimum viable overhead: <1 hour setup, 30 min/week meetings, 15–30 min/week to write an update. The overhead savings are not the point — the point is enabling everyone else to autonomously prioritize without round-tripping through the DRI for every decision.

What the DRI is not

The strongest IC on the project. The most important DRI traits are being highly organized and laser-focused on end goals, "perhaps to the point of being annoying about it."
A facilitator who doesn't make decisions. The DRI needs enough technical context and organizational trust to make most prioritization decisions autonomously.
The person who does the most work. Being DRI trades IC productivity for project throughput. This is expected and usually worth it.

Keep goals simple

The best thing a DRI can do to enable delegation is keep goals crip enough to fit in a Slack message while still describing a concrete path to the end state. If the goal can't be stated simply, people will optimize for the wrong subgoal.

"Keep goals simple" doesn't mean "do less." It means finding the latent structure that enables clean recursive decomposition into subgoals — which often requires substantial cognitive and hands-on work to identify.

Sources

how-ive-run-major-projects-ben-kuhn