Should managers still code?
theengineeringmanager.substack.com
Should managers still code?
1–10 of 319 posts
Re: Should managers still code?
#2Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad.
A hobby project to keep current isn’t a bad idea, though.
Re: Should managers still code?
#3This is a good article, and I find myself agreeing with it almost entirely. My current manager is one of the most effective development managers I've ever had in my career, and I think a good part of that is because he is involved in the codebase, but not directly responsible for new features in whole.
I have had managers with no concept of what's going on the codebase, and those were dysfunctional development teams that produced poor results, despite great communication and productive meetings.
I have had managers that were effectively another engineer on the team, and those were dysfunctional development teams that produced decent results, but had poor interaction with stakeholders and no unified direction.
As in many things, the ideal seems to be a happy medium. Someone who can read the code, who can write the code, and is interested in both, but whose duties are not primarily to do so.
Re: Should managers still code?
#4Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad. A hobby project to keep current isn’t a bad idea, though.
[dead]
Re: Should managers still code?
#5Absolutely not. Nothing like an out of touch manager slowing down their engineers with random PR comments and questions. They should not go deeper than the design document/architecture level. They are not adding any value trying to put their washed skills on display.
Re: Should managers still code?
#6Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad. A hobby project to keep current isn’t a bad idea, though.
As an engineering manager, I actually pick up the stuff other people don’t like to do or stuff I notice that is hanging out there. My goal is to move the team forward.
I’ve also done POCs of work that has been met with resistance that I didn’t feel was justified in order to actually give it a fair shake. That is my coding fun.
Re: Should managers still code?
#7Generally, no. There’s a risk of unfair competition for work (they can delegate the stuff they don’t want because they have political power) and their code often becomes “untouchable” because few will call it out if the code is bad. A hobby project to keep current isn’t a bad idea, though.
> unfair competition for work
That's a very good indicator of a bloated institution. People have to compete for work instead of pushing it away or avoiding it because they already have their hands full.
But I don't believe there is a general rule that applies here.
Most great managers I had were deeply technical and involved in the nitty gritty of the projects, including coding the very spiky aspects of a project.
Most mediocre managers I had were very focused on relationship building. The kind of manager that would need a hobby project to keep current, instead of being the most knowledgeable person in the room.
Re: Should managers still code?
#8Tldr: managers should be in the code, but should not code themselves.
The article suggests managers should focus several tasks that depend on the ability to code, but not produce code themselves. I think that's not sustainable. When a manager stops producing code, their skills in that area begin to deteriorate. I've seen it happen several times. When you stop coding, you'll eventually start missing crucial things in code review, make very poor estimations of labour involved, and assign the wrong team members to tasks. It won't happen immediately, but it will happen within 5 years.
I think a better way is to keep producing code, but at a lower rate. If the project you're working down doesn't permit low-commitment development, start developing tooling or pick up a side project. A coach doesn't need to be a top-player in the coding field, but they do need to remain fit.
Re: Should managers still code?
#9Middle management for software engineering has gone through a paradigm shift. The trend for businesses is flatter structures, manager roles with more responsibilities and this reality largely includes being as deep in the code as direct reports.
Since 2023, most roles I reviewed or interviewed for were player/coach roles, often close to 50/50 split. In my last EM role, I was hired for exactly this.
I found very few EM roles that are primarily managing with only "being in the code"; I can count on my hands out of hundreds of Engineering Manager roles. Probably closer to 95% or more EM roles require hands-on technical work similar to Tech Lead roles.
Re: Should managers still code?
#10From the article:
> It depends on the manager, the team, and the organization. As a senior leader, I would rather my managers be in the code as per the above list, but not necessarily putting themselves in the critical path by writing code, given that they are likely to be interrupted more often, have more meetings, and be pulled in more directions than their reports.