Fordel StudiosThe engineering manager has not written production code in three years. They can facilitate a sprint planning meeting. They are good at one-on-ones. They write clear performance reviews. They manage up effectively. They cannot tell you whether the estimate for the feature their team is working on is reasonable, whether the proposed architectural change is sound, or whether the engineer who is struggling is struggling with a hard problem or an easy one being done wrong.
They are managing people who build software without understanding what building software requires. This is a meaningful limitation, and it compounds over time.
What Technical Context Enables
An engineering manager with current technical understanding can evaluate estimates because they understand what the work actually entails. They can have a substantive conversation about architectural risk because they understand what architectural debt looks like in practice. They can mentor engineers on technical judgment because they have formed technical judgment recently, not in a codebase from five years ago that bears no resemblance to what their team works with today.
They can also detect when their team is under-scoping work that will become a problem later, or over-scoping work to protect themselves from criticism. This pattern-matching requires being close enough to the technical reality to read the signals. A manager who is fluent in the process but not the substance sees the outputs — PRs merged, tickets closed, demos presented — without the ability to evaluate whether the quality of those outputs is appropriate.
“An engineering manager who cannot evaluate technical work is a project manager who went to a coding bootcamp. They manage the calendar, not the craft.”
How the Drift Happens
Most engineering managers were strong individual contributors who transitioned to management. At the moment of transition, their technical understanding is current and deep. Over time, as management absorbs more of their attention, the coding lapses. The architecture decisions move faster than they can follow. The new tools the team adopts are not ones they have used. The technical intuition that was current three years ago is now applied to a system that has changed significantly.
The drift is gradual and invisible. The manager is still making confident technical judgments. Those judgments are increasingly based on pattern matching from a previous context rather than current understanding. Engineers who are close to the code know this. They adjust their communication accordingly — simplifying technical context, avoiding the conversations that would reveal the gap. The manager is now managing a team that is actively managing them.
What Good Engineering Management Requires
Good engineering management requires enough technical credibility to earn the trust of engineers who are doing the work. That credibility cannot be faked with process fluency and good communication skills — engineers know the difference between a manager who understands what they are dealing with and one who is managing around the technical reality.
The best engineering managers I have worked with spend time every week staying close to the code. Not necessarily writing it. Reading PRs, participating in architecture discussions with prepared questions, asking engineers to walk them through technical decisions and following the explanation. The time investment is modest. The credibility it maintains is significant, and it is the foundation that makes everything else in the management role more effective.