Most engineers who move into management feel it within a year. The codebase moves on without you, a pull request uses a library you've never touched, and in a design review you notice you're following the discussion instead of leading it. The tempting fix is to pick up a ticket or two and prove you've still got it.
We think that fix is wrong and the worry behind it is right. A manager who can't reason about technical trade-offs makes poor prioritisation calls, can't push back on a risky design, and loses the trust of the engineers they lead. Writing more code won't solve that. A manager who insists on staying the strongest coder on the team usually becomes its bottleneck instead. What keeps you credible is the quality of your technical judgment.
What engineers need from you
Engineers rarely need their manager to write the best code on the team. They need someone who:
- understands the system well enough to ask the questions that matter,
- can tell a real risk from a hypothetical one,
- knows when "good enough" is good enough, and
- will make the call when the team is stuck between two reasonable options.
None of that depends on how many commits you made last month.
What fades, and what doesn't have to
When you stop coding every day, depth goes first: the muscle memory of building a particular thing, the flags you used to know without looking. Breadth, your sense of the tools and patterns and what's changing, fades more slowly. You can't hold either back without doing the job you left, and trying eats time your team needs.
A third kind of knowledge lasts if you maintain it. Systems understanding is knowing how the services fit together, where the load concentrates, which parts are fragile and who understands each one. It's what makes you useful in an architecture review, or at two in the morning during an incident, and it's the one to protect on purpose.
Andrew Grove's High Output Management has an idea that helps here, though he meant it for the people you manage. Task-relevant maturity is how experienced someone is at the specific task in front of them. Apply it to yourself. A manager whose picture of the system is three years old has low maturity and high confidence, and that combination produces the worst interventions.
Habits that keep you close
Read code without owning it. Read pull requests and design documents to see how the system is changing, and stay off the list of required approvers. You pick up the architecture, notice patterns, and sometimes spot the engineer who is quietly stuck, and nobody waits on you.
Be in the room for hard decisions. You don't need to design the system. Be there when it's designed, ask why, and bring up the trade-off the team is skating past. Your contribution is the quality of your questions.
Go deep in one place at a time. Each quarter, pick one area and learn it properly: the billing pipeline, last month's outage, the migration everyone avoids. You can't be deep everywhere. Deep somewhere, rotating, keeps your map honest where it matters most.
Say when they know more. "You know this better than I do; walk me through the trade-off" earns more trust than pretending. Knowing which engineer to trust on which question is a technical skill too.
When to step in
The hardest part is restraint. You'll often watch a team head toward a decision you'd make differently, and most of the time you should let them.
The rule we use in the Body of Knowledge is to step in when the cost of being wrong is high and hard to reverse, and to stay out when the decision is reversible and the team will learn more from owning it. It's a practical form of the one-way and two-way doors Jeff Bezos described in Amazon's 2015 letter to shareholders. Changing the schema of a table three other teams read from is a one-way door. Choosing a test framework for a new service usually isn't.
When you do step in, raise what was missed instead of overruling. "What happens to in-flight orders during the cutover?" adds a consideration and leaves the decision with the team. If the question doesn't change their minds, the decision stays theirs, and so does the outcome.
Both failures are quiet. Override on preference often enough and the team stops deciding anything. Stay silent on a dangerous call to avoid friction and sooner or later they'll make one that hurts.
Where this sits in the standard
Technical credibility and intervention is competency TJ-4 in the EMA Competency Framework, in the Technical Judgment domain. The TJ-4 unit of the Body of Knowledge also covers how this changes once you manage managers, and why an executive keeps a short list of technical decisions they never delegate.
In EMA-I it comes up as a situation: a team is about to make a call you doubt, and you decide what to do. See what EMA-I covers, or compare the three levels.