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.

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.