There's a persistent myth in engineering management that once you cross into leadership, you should step away from the code. Delegate everything. Trust the team. Stop reviewing PRs. Focus on "strategy."
I disagree.
Not because I don't trust my team, I do. But because the moment I lose context on what's actually happening in the codebase, I lose the ability to make good decisions about it.
The false dichotomy
The industry has set up a binary: you're either an IC or a manager. Technical or strategic. Hands-on or hands-off.
But the best engineering managers I've worked with, and the kind I try to be, operate in the uncomfortable middle. They're close enough to the work to smell when something is off, but far enough to see patterns the team can't see from inside a sprint.
This isn't about writing production code every day. It's about maintaining enough technical fluency to:
- Ask the right questions in architecture discussions, not performative ones
- Spot risks early that would otherwise surface three sprints later as "unexpected complexity"
- Unblock people effectively because you understand their problem, not just their ticket
- Earn trust from engineers who can tell when their manager actually understands the trade-offs
What "staying technical" actually looks like
For me, it's not about committing code to the main branch. It's about a set of habits:
-
Reading PRs regularly. Not to nitpick, but to stay oriented. I want to know what's changing, where complexity is growing, and how the team thinks about problems.
-
Joining architecture discussions as a participant, not an approver. I bring opinions, but I hold them loosely. The goal is to sharpen the team's thinking, not override it.
-
Prototyping when it helps. Sometimes the fastest way to evaluate a direction is to build a rough version. I do this when it genuinely unblocks a decision, not to prove I can still code.
-
Staying current with the ecosystem. Not every new framework, but the big shifts. AI tooling, infrastructure patterns, language evolution. Enough to know what's signal and what's noise.
The danger of the non-technical EM
I've seen what happens when engineering managers fully disconnect from the technical side:
They rely entirely on what their team tells them, which sounds fine in theory, but teams often don't surface problems until they're urgent. A technically literate manager catches the early signals: the growing unease in a refactoring conversation, the PR that's been open for two weeks, the architecture decision that everyone agreed to but nobody believes in.
They also lose credibility. Engineers are generous, they'll work with a less-technical manager who's honest about their gaps. But they won't trust one who pretends to understand and clearly doesn't. The gap shows. It shows in the questions you ask, the trade-offs you accept, and the decisions you escalate.
The balance is the job
Being a technical Engineering Manager doesn't mean doing the team's work. It means keeping yourself calibrated enough to lead well. It means knowing when to zoom in and when to zoom out. It means resisting the pressure to become a full-time meeting operator whose only tool is a calendar.
The teams I've led have consistently told me the same thing: they value having a manager who understands what they're dealing with. Not one who codes for them, one who gets it.
That's the bar I try to hold. And I think more Engineering Managers should.
This is something I think about often. If you're navigating the IC-to-manager transition or figuring out how to stay technical as a leader, I'd love to hear how you approach it.