Why developer experience matters in engineering management

There’s a senior developer whose code reviews I noticed had become thin. Short comments, less engagement, approvals coming faster than the PRs warranted. I recognized it as a signal, not about the code but about the person. I knew what I was looking at because I’d been that developer.

That’s the kind of thing coding experience lets you see. Not by reading metrics or running a weekly pulse check, but by pattern recognition built from having done the work.

What you actually gain from having coded

Coding experience gives an engineering manager a specific kind of understanding that’s hard to build any other way: you know what deep work feels like, which means you know what interrupts it. You know how far an estimate can slip when the problem turns out to be different than it looked. You know the particular frustration of reviewing a PR for the fourth time because the comments weren’t clear. You’ve felt the satisfaction of getting a thing actually shipped.

That experience doesn’t make you a better coder as a manager. It makes you a better reader of what’s happening on your team. When a developer says “this is going to take two weeks,” you have enough context to ask useful questions rather than just accepting the number or pushing back on it reflexively.

It also changes how you advocate for the team upward. An EM who’s never written production code can make the case for technical debt investment, but it’s a harder argument when it’s built from reports rather than experience. When you’ve lived the cost of bad architecture, you explain it differently.

Hands-on doesn’t mean writing production code

Being technically involved as an EM doesn’t mean staying in the codebase. For most teams at any reasonable scale, an EM who’s writing production code alongside their reports is often solving the wrong problem with their time.

What it does mean: reading code, participating in architecture discussions, attending technical spikes, understanding what the team is actually building and why it’s hard. Enough involvement that when the tech lead says “this approach has a correctness problem,” you understand what that means for the timeline and the decision.

The credibility that comes from technical understanding isn’t about proving you can still code. It’s about the quality of your questions. Engineers will work with managers who ask good questions. They tolerate managers who ask bad ones.

When the EM doesn’t have coding background

This isn’t an argument that non-technical EMs can’t lead engineering teams. Some do it well. The ones who do tend to invest heavily in building a close working relationship with a strong tech lead, stay genuinely curious about the technical work, and are explicit about what they’re relying on their technical partners to provide.

The pattern that fails is the EM who doesn’t have a coding background and doesn’t compensate for it, relying entirely on process, velocity metrics, and status updates rather than understanding. That disconnect surfaces in bad estimates, missed risk signals, and teams that feel like their work is invisible to leadership.

What this means practically

If you’re an EM with a coding background: keep it alive enough to stay credible, even if that just means reading PRs, running a small personal project, or occasionally pairing on something low-stakes. The goal isn’t to be a developer. It’s to maintain the vocabulary and pattern recognition that makes you a better leader for developers.

If you’re an EM without that background: the gap is real but closeable. Work closely with a senior technical partner and be explicit that they’re filling it. Take the time to understand basic coding principles even if you never write a line in production. Developers respect managers who are trying to understand their work far more than managers who’ve decided they don’t need to.