A senior engineer posted on Reddit recently about their struggle with a DRI assignment. Six teams. Multiple backend codebases. iOS, Android, web clients, all needing to sync with two separate backend systems. They were expected to break down work for client teams they didn’t manage, estimate a feature they weren’t building, track progress across people who didn’t report to them.
Their team lead had already stepped in. They wrote: “I’m also not entirely sure that this is what I imagined a senior engineer role to be like. I expected to stay in my lane — backend engineering — but just do more of it.”
The top comment got 77 upvotes. It named the thing clearly:
“The DRI concept for engineers is gaining more and more traction in the industry… For work that is small to large, you assign a mature engineer — ideally someone who has shown a track record of successfully coordinating and delivering on smaller things — as a DRI to take the role of a mini-TPM.”
Mini-TPM. There it is. That’s what the DRI role actually is, and most orgs never say that out loud when they hand you the title.
A TPM’s job is coordination: driving cross-team decisions to closure, tracking dependencies, managing escalation paths, holding alignment across teams that report to different people and have competing incentives. When an engineer is assigned as DRI on a cross-functional feature, they’re being asked to do that job with borrowed authority and no dedicated role.
The engineer in that Reddit post said explicitly that they had been doing the technical work successfully. What was hard was the coordination surface: estimates across teams they didn’t manage, progress tracking for work they weren’t doing, alignment across codebases moving at different speeds on different teams’ schedules.
That is the DRI job. The technical contribution is real, but it’s not the primary accountability.
The commenter was honest about why the role exists at all:
“Because you can’t assign a TPM, PM or EM on every single initiative that’s going on. You’ll run into a bottleneck.”
The engineering DRI is a resource constraint dressed up as a role definition. Most large engineering orgs have more cross-functional initiatives running than they have coordination capacity to staff with dedicated program managers. So they push coordination accountability down to engineers on the initiatives that don’t justify a full-time PM, give those engineers some borrowed authority from whoever put the initiative on the priority list, and trust that a “mature engineer” can figure out the rest.
The commenter, who was skeptical: “I think it’s also a clear indicator that you’re doing too many projects in parallel as an org.”
The DRI absorbs the coordination tax that would otherwise be visible on a TPM’s calendar.
What does coordination actually require in a role like this? The commenter put it in a specific order: “You coordinate, delegate, and contribute. In that order.”
The sequencing is the thing. Contribution — the actual technical work — comes last. Coordination comes first. For an engineer who expected more senior technical work, this inversion is what creates the identity dissonance. You were told you’d be doing harder engineering. You’re doing a different job.
In practice, coordination means making sure decisions actually close in the meetings where they’re discussed. Not just discussed. Closed. An explicit statement of what was decided, a named owner from each affected team, the rationale captured well enough that someone who wasn’t in the room can understand it without a fifteen-minute briefing.
Most DRI failures I see aren’t caused by the DRI being incompetent. They’re caused by the meetings failing before the work even starts. The kickoff. The first alignment sessions. The early cross-team syncs. These are where scope interpretations diverge, where concerns get acknowledged but not resolved, where alignment looks achieved but isn’t structurally complete.
A decision gets discussed. The group appears to converge. No one explicitly states what was decided. No one names who owns the next step on the iOS side versus the backend side. The dissent — “I think this approach will cause problems with the migration timeline” — gets noted, the meeting moves on, and two weeks later the iOS team builds in a direction that conflicts with what the backend team assumed was agreed.
The DRI is now debugging a scope conflict that was baked into the kickoff before they ever wrote a line of code.
The coordination mechanics that prevent this are specific and learnable:
An explicit decision statement before the meeting ends — not just what was discussed, what was decided. Named owners for every action across every team, including ones the DRI doesn’t manage. Surfaced dissent inside the meeting rather than through back channels afterward, because a concern raised after the meeting dissolves becomes a relitigated decision rather than a resolved one. Captured rationale, documented well enough that someone who missed the meeting can understand why the decision went the way it did.
When these are present, a DRI can hand off context, track dependencies with confidence, escalate blockers with a paper trail. When they’re absent, the DRI spends most of their coordination time reconstructing what was previously agreed. Decision churn — the same scope questions relitigated in meeting after meeting — isn’t a team dynamic problem. It’s a structural one. The decisions that should have closed in the early meetings didn’t close, and everything downstream inherits that instability.
The engineer who posted asked whether what they were experiencing was normal.
The answer is yes. And the normality is the problem.
Being assigned coordination accountability for a six-team feature without explicit preparation for the coordination work is a common pattern. Discovering mid-delivery that the role is fundamentally different from what was implied is common. The commenter who explained the role best was also honest about its limits: “It’s a lot harder than it looks to be a good DRI. People should be able to volunteer as DRIs, but it’s not a viable process in my experience.”
What the DRI role reveals, when you look at how it actually operates, is where the organization’s coordination capacity runs out. When a DRI succeeds, the initiative was scoped right, the DRI had relevant coordination experience, and the early meetings produced structurally complete decisions. When a DRI fails, at least one of those three things was missing.
The first two are visible on a spreadsheet. The third one — whether the decisions that came out of the kickoff actually closed, or just looked like they did — is almost never instrumented. Which is why DRI failures tend to get categorized as people problems rather than structural ones.
They’re not.