The DRI Role in Engineering Is a Coordination Job. Nobody Warns You.

A recently promoted senior engineer posted on Reddit about struggling as a DRI. The feature had multiple backend codebases in sync, iOS, Android, and web clients all needing to align with two backend systems, and complex business logic that cut across all of them. They were also expected to break down work for client teams, estimate the full feature (not just the backend), and keep everyone's progress tracked.

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, handle more complicated backend problems, mentor more junior backend devs... but I never expected to have to sit down with a client dev and break their work into chunks and estimate it."

The top comment had 77 upvotes. It described a structural reality that most organizations implement without ever articulating it.

The role nobody explained

Mini-TPM. That phrase is doing a lot of work. A TPM's job is coordination: driving cross-team decisions to closure, tracking dependencies, managing escalation paths, maintaining alignment across parties who report to different people and have competing priorities. When an engineer is assigned as DRI on a cross-functional feature, they are being asked to do that job — with borrowed authority rather than a dedicated role.

The engineer in the Reddit post wasn't failing at the technical work. They said so explicitly: "I HAVE been doing all of that relatively successfully." What they were struggling with was the coordination surface area: estimations across teams they didn't directly manage, progress tracking for work they weren't doing, alignment between codebases moving at different speeds with different teams' priorities. That is the DRI job. The technical contribution is part of it; the coordination work is the primary accountability.

Why organizations create the role

The commenter was direct about the underlying logic: "Because you can't assign a TPM, PM or EM on every single initiative that's going on. You'll run into a bottleneck." This is not an engineering design philosophy. It is a resource constraint dressed up as a role definition.

Organizations that have adopted matrix structures — which by the mid-2020s is most large engineering organizations — have more cross-functional initiatives running simultaneously than they have coordination capacity to staff with dedicated program managers. The engineering DRI is the structural response: push coordination accountability down to engineers on initiatives that don't justify a full-time PM or TPM, give those engineers some borrowed authority from whoever put the initiative on the priority list, and trust that a "mature engineer" can fill the gaps.

The commenter, who was skeptical of the model, put it plainly: "I think it's also a clear indicator that you're doing too many projects in parallel as an org." The engineering DRI role often exists not because it's the optimal structure but because the organization has stretched its coordination capacity past the point where every initiative can have dedicated coordination support. The DRI absorbs the coordination tax that would otherwise be more visible if it were landing on a TPM's calendar.

What the role actually requires

The commenter described the DRI's core responsibility in a specific order: "You coordinate, delegate, and contribute. In that order." The sequencing matters. Contribution — the actual technical work — comes last. Coordination and delegation come first. For an engineer who expected to do more senior technical work, this inversion is the thing that creates the identity dissonance the Reddit poster described.

What does coordination actually look like in practice for a DRI on a complex feature? It means driving every significant cross-team decision to a structurally closed state before the meeting ends: an explicit statement of what was decided, a named owner from each affected team, and the rationale captured well enough that it won't need to be reconstructed when someone who wasn't in the room asks why the decision was made that way. It means knowing when a blocker has exceeded the DRI's authority to resolve and escalating it to whoever does have that authority — fast, with specific context, rather than absorbing it until it becomes a timeline crisis.

The commenter described this escalation mechanism explicitly: "As a DRI you are generally not responsible for implementing the majority of work. You are responsible for making it happen and are generally entrusted some level of borrowed authority through the sponsor of the project... It also means you escalate when there is an issue you can't resolve yourself." Borrowed authority has a ceiling. Knowing where that ceiling is, and escalating before you hit it rather than after, is one of the things that separates a DRI who can do the job from one who can't.

Where DRIs run into structural failure

Most engineering DRI failures aren't caused by the DRI being incompetent. They're caused by the coordination mechanics failing in the meetings that shape the work — usually the kickoff, the early alignment sessions, the first cross-team syncs. These are the meetings where scope interpretations diverge, where concerns get acknowledged but not resolved, where alignment looks achieved but isn't structurally complete.

The problem is specific. A decision gets discussed in a cross-team meeting. The group appears to converge. But 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 and then the meeting moves on without resolution. 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.

This is what the original poster was experiencing. Multiple backend codebases in sync, multiple clients all needing to align — that's not an unusual feature structure. What made it unmanageable was almost certainly not the technical complexity alone. It was the coordination surface area: decisions being discussed across six or more teams with no consistent mechanism for confirming that the discussion produced a real agreement rather than a polite approximation of one.

The coordination mechanics a DRI needs to enforce

Four things. An explicit decision statement: the group confirms in words, before the meeting ends, what was decided — not just what was discussed. Named owners: every action that needs to happen has a specific name attached to it, including on teams the DRI doesn't manage. Surfaced dissent: concerns get raised in the meeting rather than through back channels afterward, because a concern raised after the meeting has already dissolved becomes a relitigated decision rather than a resolved one. Captured rationale: why the decision was made, documented well enough that someone who wasn't in the room can understand it without a fifteen-minute briefing.

These mechanics allow decisions to hold under pressure. When they're present, a DRI can hand off context to a new stakeholder, track dependencies across teams with confidence, and escalate blockers with a clear paper trail. When they're absent, the DRI spends most of their coordination time reconstructing what was previously agreed rather than moving the work forward.

The Reddit commenter who explained the role best was also honest about the model's limits: "I personally don't think so. 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." They're describing the gap between what the role looks like on an org chart and what it requires in practice. The structural mechanics of coordination are learnable, but they have to be made explicit. Most organizations assign engineers as DRI, give them a brief on authority and scope, and then leave them to figure out the coordination mechanics on their own.

What the DRI role reveals about the organization

The Reddit poster asked whether what they were experiencing was normal. The answer is yes — and the normality is the problem. An engineer being assigned coordination accountability for a six-team feature without explicit preparation for the coordination work is a common pattern, not an unusual one. The experience of discovering mid-delivery that the role is fundamentally different from what was implied is also common.

What the DRI role in engineering actually measures, when you look at how it operates in practice, is the organization's coordination capacity relative to its initiative load. When DRIs succeed, it usually means the initiative was appropriately scoped for the role, the DRI had prior coordination experience, and the meetings that shaped the work produced structurally complete decisions. When DRIs fail, at least one of those three things was missing — and the one that's hardest to see from the outside is the last one.

You can check an initiative's scope. You can assess an engineer's experience. What's much harder to assess is whether the decisions that came out of the kickoff and the first three syncs actually closed — or whether they produced the appearance of alignment that will dissolve the first time a timeline slips or a dependency doesn't land on schedule. Most organizations have no instrumentation for that layer, which is why DRI failures tend to look like people problems rather than structural ones.