Should engineering managers be writing code at work?

Every time the “should EMs still write code?” debate pops up, it comes with the same intensity you’d expect from a room full of people arguing about tabs vs. spaces. Everyone has a strong opinion. Everyone is very sure they’re right.

And yet… the conversation never actually resolves. It just resurfaces months later like nothing happened.

I think that’s because we’re asking the wrong question.

I’ve been an EM, I’ve managed EMs, and I’ve coached a lot of people through this transition. And I’ve learned that “Should EMs code?” is really a proxy for something deeper: identity, control, fear, ego, trust, and what we think we need to feel effective.

The short answer is messy: sometimes yes, sometimes no, often “it depends,” and always “not at the expense of your team.” But the longer answer is more interesting.

_{A thank you from this week’s sponsor:}

Now through the end of the year is prime streaming time on Roku, with viewers spending 3.5 hours each day streaming content and shopping online. Roku Ads Manager simplifies campaign setup, lets you segment audiences, and provides real-time reporting. And, you can test creative variants and run shoppable ads to drive purchases directly on-screen.

Bonus: we’re gifting you $5K in ad credits when you spend your first $5K on Roku Ads Manager. Just sign up and use code GET5K. Terms apply.

Use code GET5K now

When coding becomes avoidance

I once worked with an EM who absolutely loved writing code. Loved it so much that it slowly overtook everything else the job required. They volunteered for the most interesting tickets, hovered in every PR queue, and always had “just one more fix” to squeeze in.

Nothing exploded immediately, but the team started routing around them. Ownership eroded because the manager kept stepping in. The team felt like their manager was their peer, and they weren't getting the management guidance they were seeking. Decisions slowed because the manager inserted themselves into every critical path. Over time, it became clear that coding had turned into a way to avoid the harder, less tangible parts of management.

Eventually, they parted ways with the company. It wasn’t a failure of talent but a mismatch of role and identity. And it’s the example people point to when they argue EMs shouldn’t code at all.

When coding stays part of the job without taking over

On the opposite end was an engineer I coached who wanted to move into management but was convinced it meant giving up coding entirely. Coding wasn’t just work to them; it was confidence, creativity, and the part of the day that felt the most like “flow.”

But here’s the twist: they didn’t actually have to give it up.

Their company supported their continued coding, with one condition — they needed to stay out of the critical path. So they started taking on small, steady tickets: the glue work that unblocked teammates, the internal improvements that never made it to the top of the backlog, the kind of contributions that help the team without overshadowing it.

They stayed connected to the codebase without becoming the dependency. Their team took on the bigger, more complex work. And they learned something that many EMs eventually do: if you’re measuring your effectiveness by how "fun" the coding is, you’re probably using the wrong metric. Coding wasn’t the point anymore; supporting the team was.

This version of coding strengthened the team instead of pulling energy away from it.

When coding simply stops being the point

I’ve also seen people step into engineering management and realize almost instantly that they have no real desire to keep writing code. Not because they can’t, but because they’ve found a different way to be technical — one rooted in coaching, architecture conversations, system tradeoffs, and building the kind of clarity that makes everyone else better. As I've progressed in my own career, I've found myself in this camp. Especially now that I'm managing EMs, coding has taken a very far backseat.

Some of the most technically-minded leaders I know rarely touch a PR. Their depth shows up in how they think, not how many lines of code they write.

This is the part of the conversation that often gets overlooked: coding is only one way to stay technical, and frankly, one of the least leveraged ways as you grow into broader leadership.

Why the debate never dies

“Should EMs code?” keeps resurfacing because the role itself isn’t standardized. A small startup EM might legitimately need to ship code to keep the product alive. A mid-size or large org EM might actively harm the system by coding too much, because they become an unexpected dependency.

Job shape determines the answer. Team maturity determines the answer. Your own strengths, values, and identity determine the answer.

A universal rule will never work. But there are deeper forces underneath this debate that we rarely name.

The deeper forces we don’t talk about

Organizations quietly benefit from EMs who code. It’s invisible extra capacity. A way to plug staffing gaps without changing headcount. Cheap senior labor. And as long as the EM keeps saying yes to “just one more ticket,” the system has no reason to correct itself.

But organizations also suffer when EMs code too much. Ownership blurs. Engineers defer instead of lead. Prioritization shifts from team-driven to manager-driven. And the EM quietly becomes a single point of failure no one planned for — stuck in the constant tug-of-war of “Do I need to lead right now, or do I need to code right now?”

Different orgs incentivize different behaviors. PM-led orgs pressure EMs to stay deeply technical to maintain parity with ICs. Eng-led orgs sometimes over-index on coding as proof of competence because they lack other ways to evaluate managers. None of these incentives are neutral.

Both sides of the argument claim clarity, but each extreme has predictable failure modes.

When EMs don’t code at all, they risk losing context. They set unrealistic timelines. They rely too heavily on summaries and make architectural calls without enough ground truth.

When EMs code too much, they become the hero, the dependency, the person the team subconsciously waits for. Velocity becomes unpredictable. Team ownership collapses into manager ownership. And worse, the EM starts to feel more valuable as an IC than as a leader — a self-fulfilling loop.

Here's the quiet part we aren't saying out loud: many EMs keep coding because it’s the only part of the job where success is unambiguous. Management is fuzzy. Decisions play out over months. Impact is shared. Wins are collective. But code? Code compiles. It merges. It passes tests. You can point to it and say, “I did that.”

Coding becomes seductive not just because it’s fun, but because it’s clear, and clarity is addictive when the rest of the job is ambiguous, political, nonlinear, and often invisible.

This doesn’t make coding bad. It just means the motivation behind the coding matters.

A universal principle can exist — but only once we acknowledge the incentives and psychological hooks that pull managers toward the keyboard.

How AI complicates the question

AI doesn’t eliminate this debate; it intensifies it. If coding becomes faster, easier, and more automated, EMs may feel even more tempted to "just write the fix themselves." The dopamine gap widens. The ambiguity gap between IC work and management grows. And the risk of an EM slipping back into hero mode becomes even higher.

At the same time, AI shifts what it means to "stay technical." If AI can generate scaffolding, explore solutions, or refactor code, then the value of an EM isn’t in typing — it’s in judgment. It’s in asking better questions, guiding design, validating direction, and knowing when the output is good enough or dangerously wrong.

So does an EM need to write code to stay technical in an AI-driven world? Or do they need to understand how code is produced, reviewed, reasoned about, and challenged? AI doesn’t answer the debate; it exposes its fault lines.

The principle that does scale

I’ve never believed EMs universally should or shouldn’t code. Both stances are too blunt. But there’s one principle that holds across contexts:

If you’re going to code, stay out of the critical path.

Pick up work that unblocks your team instead of work that places you in front of them. Contribute in ways that strengthen ownership rather than collapse it. Prototype. Pair. Improve tooling. Guide — don’t dominate.

The coding you do should create space for your team, not take space from them.

Instead of asking whether EMs should code, perhaps we should ask:

What does my team need from me right now, and does coding support that or get in the way?

In some seasons, coding will ground you. In other seasons, it’ll quietly undermine your impact. The answer isn’t static because your team isn’t static, and neither are you.

This debate keeps coming back because the answer keeps evolving. And honestly, that’s exactly how it should be.