There's a quiet anxiety that follows almost every engineer into management: the fear of becoming irrelevant. You used to be the person with answers. Now your IDE gathers dust, the codebase moves on without you, and a junior engineer just used a framework you've never heard of. The instinct is to claw your way back into the code to prove you've still got it.
That instinct is wrong — but the worry underneath it is right. Technical credibility matters enormously for an engineering manager. A leader who can't reason about technical trade-offs can't make good prioritisation calls, can't push back on bad architecture, and won't be trusted by the engineers they lead. The mistake is believing credibility comes from writing the most code. It doesn't. It comes from exercising the best judgment.
What technical credibility actually is
Engineers don't need their manager to be the strongest coder on the team. In fact, a manager who insists on being the best coder usually becomes the bottleneck. What engineers need is a manager who:
- understands the system well enough to ask the right questions,
- can tell a real risk from a hypothetical one,
- knows when "good enough" is genuinely good enough, and
- will make a call when the team is stuck between two reasonable options.
That's judgment, not throughput. And judgment is what lets you stay credible even as your hands-on skills inevitably narrow.
How technical skill decays — and what to protect
When you stop coding daily, two things happen. Your breadth (awareness of tools, patterns, and what's changing in the ecosystem) fades slowly. Your depth (the muscle memory of building a specific thing) fades fast. You can't stop this, and fighting it consumes time you owe your team.
But there's a third thing — systems understanding — that doesn't decay if you maintain it, and it's the one that actually matters for leadership. Knowing how your services fit together, where the load concentrates, which parts are fragile, and what the real constraints are: that's the knowledge that makes you useful in an architecture review or an incident. Protect it deliberately.
Practices that keep you credible without making you the bottleneck
Read code; don't own it
Reading pull requests — not to gate them, but to stay close to how the system is evolving — is one of the highest-return habits available to a manager. You absorb the architecture, you notice patterns, and you spot the engineer who's quietly struggling, all without becoming a required approver.
Stay in the room for the hard decisions
You don't need to design the system, but you should be present when it's being designed. Ask why, surface the trade-offs the team is glossing over, and make sure someone is accountable for the decision. Your value is in the quality of the questions, not the answers.
Go deep occasionally, narrow on purpose
Pick one area each quarter to genuinely understand — a new part of the stack, an incident's root cause, a thorny migration. You can't be deep everywhere, so be deliberately deep somewhere. It keeps your instincts calibrated and signals to the team that you still do the work of understanding.
Let the team be smarter than you
The most credible managers are comfortable being the least knowledgeable person in the room about a given technology — and they say so. "You know this better than I do; walk me through the trade-off" builds far more trust than pretending. Credibility comes from sound judgment about which engineer to trust on which question, not from having every answer yourself.
Knowing when to intervene — and when not to
The hardest part of technical judgment as a manager is restraint. You will often see a team heading toward a decision you'd make differently. Sometimes you should step in; usually you shouldn't. Intervene when the cost of being wrong is high and hard to reverse. Stay out when the team will learn more by owning the outcome than by following your call. Knowing the difference is the essence of technical leadership.
Judgment over throughput
Technical credibility isn't a measure of how much you code — it's a measure of how well you reason about technical reality and how wisely you apply that reasoning to leadership decisions. That's why Technical Judgment is one of the five domains in the EMA Competency Framework: it assesses the manager's ability to exercise sound technical judgment without doing the engineering.
If you want an honest read on where your technical judgment stands — through realistic scenarios rather than trivia — that's exactly what EMA-I is built to measure.