This is a question that most engineering managers who come from a core software engineering background struggle with. I certainly did. Having spent years as a software engineer before moving into management, I carried a strong attachment to being close to the code. It was familiar, it was comfortable, and it was how I had learned to measure my own effectiveness.

As I grew into engineering management, I spent a lot of time thinking about this question, both consciously and subconsciously.

So rather than being vague or hedging, I want to answer it directly.

The short answer is no.

In most cases, engineering managers should not be writing production code.

That answer is opinionated, and it is grounded entirely in experience.

---

Why I Kept Coding Early On

Early in my management journey, I stayed hands-on with coding. I had been close to the codebase for a long time, and at that stage, it still felt natural to keep contributing. This approach can work when the team is very small and the problem space is well understood. In those situations, the surface area of responsibility is limited, and the cost of context switching is relatively low.

But that phase does not last long.

As teams grow and responsibilities expand, the nature of the engineering manager role changes significantly. The way you add value changes. The problems you are expected to solve change. And most importantly, the opportunity cost of where you spend your time becomes much more visible.

That is when the tension really begins.

---

The Real Advantages of Coding as a Manager

To be fair, coding does come with real advantages, and it is important to acknowledge them honestly.

One advantage is technical credibility. When you are in the code, you understand the system at a deeper level. Your suggestions carry more weight because they are grounded in firsthand knowledge. When you speak in design discussions or team forums, people trust that you know what you are talking about.

Another advantage is empathy. Writing code helps you understand what your engineers are actually dealing with day to day. Something that looks like a small feature on the surface can hide significant complexity underneath. Poor testing practices, brittle release pipelines, or accumulated technical debt can dramatically increase the effort required to deliver even modest changes. Being in the code makes those realities impossible to ignore.

These benefits are real. And for many managers, they are exactly what pulls them back toward coding.

---

Why the Tradeoff Rarely Works Long Term

Despite those advantages, the tradeoff usually is not worth it.

Every hour I spend coding is an hour I am not spending on the responsibilities that only I can fulfill as an engineering manager. That is where the real cost shows up.

When you step back and look at the role through a return-on-investment lens, the problem becomes clearer. A company is not paying an engineering manager because they want one more engineer on the team. They are paying for a different kind of leverage. They expect value in areas that other engineers are not scoped or positioned to provide.

From that perspective, coding naturally falls to the very bottom of the value stack for an engineering manager.

There are many responsibilities that come before it, and those responsibilities are the reason the role exists in the first place. When I prioritize coding over them, what I am really doing is trading high-leverage work for low-leverage comfort. Coding becomes an escape into something familiar rather than a deliberate choice based on impact.

---

What the Engineering Manager Role Is Actually Optimized For

At a senior level, engineering management is about multiplying impact through others.

That includes growing people, setting clear expectations, giving feedback, and helping engineers navigate their careers over time. It includes owning delivery in a way that is sustainable rather than reactive. It includes working across functions, translating ambiguity into clarity, and making tradeoffs that balance speed, quality, and long-term maintainability.

It also includes providing strategic technical leadership without being the person implementing everything yourself. That means guiding architecture discussions, assessing risk, and ensuring the team is solving the right problems, not just executing efficiently.

I explore this shift in depth in my post From IC to EM: A Practical Transition Guide, where I break down how expectations change as you move into management and why the mindset shift is often harder than the skills shift.

With that baseline established, the real clash becomes easier to see.

---

Where Coding Starts to Clash with the Role

The moment coding begins to compete with these responsibilities, it becomes a liability rather than an asset.

The cost shows up subtly at first. Strategic guidance becomes shallower. Career conversations become shorter or more reactive. Clarity around priorities erodes. Over time, the core of what engineering management is supposed to deliver starts to weaken.

In the short run, this tradeoff can look deceptively fine. Velocity might increase. Features might ship faster. The team might even feel productive. But in the long run, the cracks appear. Lack of clarity turns into confusion. Reduced trust turns into disengagement. Absence of strategic direction turns into reactive execution.

Eventually, culture suffers. And when culture suffers, output follows.

At that point, even if short-term delivery looks good on paper, the team itself is paying the price.

---

This Is Not an Argument Against Being Technical

None of this means that engineering managers should stop being technical.

Staying technical still matters. It just looks very different at this stage of the role.

For me, staying technical has meant staying close to system design, understanding architectural tradeoffs, asking better technical questions, and maintaining enough depth to evaluate risk and long-term implications. When I want to explore new technologies or sharpen my skills, I do it intentionally and in ways that do not put me on the critical path for my team.

There are healthy ways to stay technically engaged without undermining your leverage as a manager, and there are unhealthy ways to cling to coding that quietly hurt the team over time.

I go much deeper into those distinctions in my post Staying Technical as an Engineering Manager, where I outline concrete ways to maintain technical credibility without defaulting to writing production code.

---

Final Thoughts

The question is not whether engineering managers can code. Most can. The question is whether they should, given the responsibilities they carry and the leverage they are expected to provide.

In my experience, coding often feels right in the short term and wrong in the long term. It delivers immediate gratification but quietly pulls focus away from the work that only an engineering manager can do.

The role exists for a reason. And when you fully embrace that reason, the decision becomes much clearer.

---

Your Turn

If you are an engineering manager who has wrestled with this question, I would love to hear your perspective.

Have you found a healthy balance between coding and leadership?
Have you seen the long-term effects of prioritizing one over the other?
Or do you disagree entirely with this view?

Share your experience and your thinking. This is a conversation worth having.