Bridging the gap between engineers and non-technical stakeholders

A product manager once came to me with a feature request that seemed simple: “add a filter to the dashboard.” The engineer who picked it up explained it would take three weeks. The PM said that was impossible, it’s just a dropdown. Two weeks of tension followed, then a rushed implementation that broke two other filters and needed a hotfix the week after launch.

Nobody was wrong, exactly. The engineer knew the data model made this genuinely complex. The PM knew the business needed it and that “it’s complicated” can sometimes mean “I don’t feel like doing it.” Neither of them had the shared context to trust the other’s perspective.

That’s the gap. It’s less about communication style and more about mutual context, and engineering managers are in the best position to close it.

Why both sides talk past each other

Engineers and non-technical stakeholders are optimizing for different things, and they often don’t realize the other side’s constraints are real.

Engineers think in systems. They see the downstream consequences of a shortcut taken today: the database schema that’ll need a painful migration in six months, the API design that’ll break three client apps when it changes. When they say something is risky, they usually mean it.

Stakeholders think in outcomes. They see the customer who needs this feature, the sales deal that’s contingent on it, the quarter-end deadline that’s non-negotiable. When they push back on a timeline, they usually have a real reason.

The problem is that each side tends to think the other is being difficult rather than operating from legitimate constraints. Engineers hear “just make it work” and feel dismissed. Stakeholders hear “this is technically complex” and hear a polite no.

I’ve been on both sides of this. I resisted building a feature once because it seemed like a bad product idea. It turned out to be a key selling point for a major client. I didn’t have the business context to know that, and nobody gave it to me.

What actually helps engineers communicate upward

The core shift is moving from describing the problem to describing the consequences.

“This requires refactoring our authentication layer” lands very differently depending on how you frame it. Compare:

• “We need to refactor the auth layer before we can add SSO support.”
• “SSO support would normally take two weeks, but our current auth layer makes it a six-week project. If we spend two weeks of cleanup first, the SSO work itself drops to two weeks. Total: four weeks, but we end up with cleaner infrastructure that makes the next five things easier.”

The second framing gives the stakeholder something to work with. They can weigh the trade-off. They might even have context that changes the calculus. Maybe the SSO deal is three months away and four weeks is fine.

The technical debt analogy is one I use constantly with non-technical stakeholders because it maps to something they already understand. Taking on debt isn’t inherently bad. It’s a tool. But the interest compounds, and at some point you’re spending more on interest than on anything new. That lands faster than any technical explanation.

Transparency about risks matters more than most engineers think. Stakeholders hate surprises. If there’s a chance a feature ships late, or that a dependency isn’t ready, or that the approach has a known weakness, say so early. It’s almost always better to surface the risk at sprint planning than at the sprint review.

What engineering managers need to do on both sides

The EM role in this gap is genuinely bilateral: it’s not just translating for engineers.

On the engineering side: make sure the team understands why the business wants what it’s asking for. I’ve seen engineers become much more creative about solutions once they understood what the feature was actually trying to accomplish. If they know the “why,” they can sometimes propose a faster path to the same outcome.

On the stakeholder side: give enough technical context for decisions to be informed without drowning people in implementation details. “This requires a database migration with downtime risk” is enough context for a PM to help schedule it carefully. They don’t need to understand what the migration does.

The move I’ve found most useful: bring engineers into planning conversations earlier, not as implementers who receive specs but as contributors who can flag complexity before it becomes a crisis. An engineer in a planning session who says “this touches the payment flow, we should budget extra time for testing” is worth far more than discovering that mid-sprint.

The gap doesn’t close because both sides decide to be nicer to each other. It closes when both sides have enough shared context to trust each other’s judgment, and someone has to build that context deliberately. Usually that’s the EM.