👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
Most Engineering Managers used to be software engineers at one stage in their career. In most cases, these are technical people who have a passion about people.
Coding used to be part of their day-to-day, but it’s not anymore.
Coding used to require proper focus time. It doesn’t anymore. I can spin up a claude agents to do some research while I am in meetings, review in between meetings what it came up with, give it a steer and have it go implement whatever I want.
I can do that to help with a feature my team is working on this sprint because an engineer is on holidays. Or I can look at why our deployments are taking 40 minutes and failing regularly.
I think one of these two options is a pretty bad use of time.
Many people ask me (or on the internet in general) if Engineering Managers should be writing code.
This is the wrong question though.
Should managers code?
This argument has been going on forever. There’s an article from Coursera from 2016 (lol): “Should engineering managers write code? Wrong question.”
“Coding” can mean so many different things and these days there’s certainly more pressure to do more of it than before.
LeadDev’s Engineering Leadership Report 2026 found 37% of engineering leaders are doing more hands-on technical work than before.
I really like the point that James Stanier makes here:
“All managers should be in the code, but not all managers should be writing code.”
The answer to the question is certainly not “managers shouldn’t code”.
But I think it’s important to be very intentional about why you’re in the code in the first place.
Coding to ship
This is one that many love to do but it’s not a good use of time.
There’s a certain type of satisfaction that you get when you ship a feature and it lands in the hands of customers. The thing is, that this shouldn’t be your priority anymore.
It’s not that you don’t have the ability to do that. It’s more that your other responsibilities will get in your way.
Charity Majors makes this point in The Engineer/Manager Pendulum: both engineering and people management require focused attention.
As a manager, your week will get interrupted. I literally can’t remember the last time I was able to plan out my week on Monday and everything go to plan that week.
You coding is also taking work away from engineers. The particular task that you’re picking up might have been an opportunity for someone on the team to learn something you already know.
Also, things can get quite messy if you get on the critical path.. because, you might create a PR that needs to ship, but you also have interviews, 1:1s, planning, a random urgent request from your manager or your CTO, an escalation and whatever else happened that week. Who’s going to address the comments on your PR and drive it through?
Another thing is.. technical decisions can naturally start moving towards you. Even if you don’t intend that to happen, your opinion isn’t quite the same as another engineer’s opinion anymore.
Many companies nowadays are seeking for the player-coach. The engineer/tech lead who’s also managing the people in their team. Doing both at the same time at a high level I think is incredibly hard.
Coding to understand
Now that’s an interesting area. Understanding is very powerful to have as a manager.
You want to know how things are built. Where are the parts that need improving, and why. What’s slowing the team down by feeling some of that pain.
Camille Fournier talks about the importance of being able to ask good technical questions in this YC interview. To be able to do that you need to understand well your systems.
You don’t necessarily need to be shipping features. You can pick up small things like looking at the deployment pipeline, debugging a flaky test, pairing with someone, reading code through a service you don’t properly understand.
I wrote before about the five engineering skills worth evolving, and a lot of it is basically this. Stay close enough to understand.
AI might have changed all this a bit
The problem so far has been that meaningful coding didn’t fit particularly well between meetings. That’s changing though.
Will Larson wrote about this last year. After years of barely coding as a manager, he started doing it again with agentic tools.
He still follows some rules that are worth keeping in mind.
Don’t take time-sensitive work
Don’t put yourself on the critical path
Work on things that your team struggles to prioritise but that are obviously useful
These feel much more like coding to understand than becoming another engineer in the team.
But AI creates another problem.
It makes it much easier to be useful... and much easier to feel useful when you’re actually getting in the way.
So I think Engineering Managers need a simple way of deciding whether they should work on something or leave it for one of the engineers.
I use three questions for this:
👇👇👇 (access with a paid subscription)