Why I still code as an engineering manager

One of the questions engineering managers get asked repeatedly is whether they still code.

The debate is usually framed too simply. Either a manager should remain deeply hands-on to stay credible, or they should step away from code entirely to focus on leadership. In practice, most good answers live somewhere in between.

I still code as an engineering manager, and I do it on purpose.

Not because I think management is incomplete without code. Not because I need to prove that I can still ship. And definitely not because I want to be the hidden bottleneck behind every important technical decision.

I do it because staying close to the work helps me make better decisions about architecture, delivery, prioritization, and coaching. It keeps my understanding of engineering reality grounded in actual systems rather than abstract summaries of them.

Coding is not the same as refusing to delegate

The most important distinction here is intent.

Some managers code because they do not trust their teams enough. Some code because they cannot let go of the identity of being the most productive individual contributor in the room. Some code in ways that create invisible dependency and confuse ownership.

That is not what I mean.

If a manager’s coding habit makes the team slower, more hesitant, or less likely to own problems end to end, it is not helping. It is management debt.

The goal is not to remain central. The goal is to remain close enough to the texture of the work that your judgment stays sharp and your leadership stays real.

Why I think hands-on managers can be better decision-makers

Management at scale creates a dangerous abstraction layer. The more senior you get, the easier it becomes to learn about engineering only through documents, updates, or filtered interpretations.

That distance has costs.

It can make architecture seem cleaner than it is. It can make delivery problems look like prioritization problems when they are really systems problems. It can make developer productivity conversations feel conceptual when they are actually rooted in very concrete sources of friction.

Staying hands-on helps me:

• see where systems are genuinely awkward
• feel the cost of poor abstractions directly
• spot where execution friction is structural rather than individual
• understand how architecture decisions affect the lived developer experience
• coach with greater specificity because I have recent contact with the work itself

This is particularly important in the kind of environments I work in, where integrations, platform systems, product systems, and operational concerns all intersect. The tradeoffs are rarely obvious from the outside.

Technical credibility matters, but not for ego reasons

Teams do not need their manager to be the strongest coder in the room. They do need to believe that the manager understands engineering deeply enough to make good calls, challenge weak reasoning, and recognize strong work.

That is what technical credibility buys.

It helps when discussing architecture. It helps when shaping delivery approaches. It helps when deciding whether something should be generalized or shipped more narrowly. It helps when reviewing whether a plan is sound or merely polished.

In my own work, staying hands-on has helped me remain useful across frontend, backend, services, and operational engineering. That breadth matters because many management decisions are only as good as the manager’s ability to see the real interaction between product goals, platform constraints, and developer workflow.

Coding helps me mentor better

I care a lot about helping engineers grow into larger problem spaces.

That kind of mentoring is stronger when it is tied to real work rather than generic leadership advice. If I am close enough to the systems, I can coach more concretely:

• where an abstraction is too narrow
• where a spec is underdeveloped
• where an engineer is solving the local problem but missing the reusable one
• where the design is clever but fragile
• where the team is choosing speed in a way that will create future drag

This does not mean hovering over implementation. It means having enough context to push people toward stronger judgment.

That is especially important if your management style, like mine, is stretch-oriented. I want engineers to think harder, take ownership, and learn from decisions. That works best when I can intervene selectively and precisely, not just at the level of general encouragement.

The real risk: becoming a hidden dependency

There is still a genuine danger here.

Managers who stay hands-on can unintentionally become load-bearing in the wrong way. The team starts routing the hard parts through them. Reviews become asymmetric. Engineers defer rather than decide. Architectural authority becomes concentrated.

That is the failure mode I try hardest to avoid.

Staying technical only works if paired with disciplined delegation and clear ownership boundaries. Engineers should not have to wait for my code to move their work forward. My hands-on involvement should create context and leverage, not dependency.

That means asking hard questions of myself:

• Am I doing work that someone else should own?
• Am I solving because it is high leverage, or because it is familiar?
• Would the team be stronger if I stepped back from this slice?
• Am I using coding as a way to stay connected, or as a way to avoid harder management work?

Those questions matter because coding can be useful, but only if it is in service of the team.

Different seasons require different ratios

I do not think there is a universal amount that managers should code.

The right ratio depends on context:

• team maturity
• org size
• reliability needs
• hiring gaps
• whether the team is in a foundational build phase or a scaling phase
• whether you are leading one team or several

There are seasons when hands-on work should increase. For example, when architecture is still forming, when a new initiative needs a strong technical foundation, or when the team is navigating unfamiliar systems complexity.

There are other seasons when management leverage matters more than code output. Hiring, org redesign, performance work, roadmap shaping, and cross-functional alignment can all rightfully consume the bulk of attention.

The important thing is to stay intentional. The ratio should reflect what the team needs, not just the part of the job you like most.

What staying hands-on means to me now

For me, coding as an engineering manager is not nostalgia for an IC role. It is part of how I stay honest.

It keeps my architectural instincts grounded. It helps me preserve technical taste. It sharpens my coaching. And it reduces the risk that my leadership becomes disconnected from the real system my team is trying to ship inside.

The bar is not “does the manager still code?”

The better bar is:

Does the manager stay close enough to the work to make better decisions, while building a team that does not depend on them to move?

That is the version of hands-on management I believe in.