I don't care if my manager writes code

I write a lot about how the post-2010s economic squeeze has made it harder to be a software engineer at a large tech company. But I haven’t said much about how it’s also harder now to be a software engineering manager.

In fact, I’m pretty sure that engineering managers have been hit hardest by the vibe shift: not only are they affected by the same problems, but their job is to be the face and instrument of the company that’s now cracking the whip and laying people off. And of course they’re vulnerable to getting laid off themselves, as tech companies now try to run leaner and cut out middle layers between executives and engineers.

This desire for efficiency has given rise to an interesting dynamic between tech companies and their managers. Managers are now expected to be part-time engineers: not just technical, but actively committing code alongside the team. It’s easy to find engineers on the internet who are celebrating this trend. But I really don’t like it. I prefer my manager not to be doing active engineering work.

Managing is hard

The first reason is that managing is a full-time job. Different companies have different expectations for software engineering managers, but every manager I’ve seen has had a lot of work to do. Shepherding their engineers’ promotions, smoothing out disagreements, being a basic sanity check on planned work, actively communicating up about projects, and so on. Much of the work is invisible to engineers, because it’s pre-planning or groundwork-laying for events that haven’t been announced yet (like new projects) or that will never be announced (like engineers having personal problems).

I don’t want my manager to neglect their actual management work so they can ship some more PRs. Even when the rubber really hits the road on a project, I have never once wished that my manager was picking up tickets and shipping code alongside me. The tighter a project gets, the more important it is for a manager to be keeping executives informed and relaxed, or to be providing air cover for decisions that have to be made, or to be fending off last-minute panics from external stakeholders. I would like them to be doing an excellent job at that so I can do an excellent job shipping the project.

Software engineering is hard

The other reason I don’t want my manager writing code is that writing code at large tech companies is very difficult. I’ve written a lot about why that’s true, but in short: it’s a combination of a constant giant coordination problem and a technical setup that’s deliberately absorbed all the profitable complexity that it can take. Doing good work in this environment requires staying on top of a lot of technical details. It requires having your head “in the problem”. It requires not being in ten meetings a day and juggling a hundred non-technical problems.

If I had to do the job of a software engineering manager alongside my actual job of writing code, I think I would be very bad at writing code¹. I don’t just mean that I would be slow, I mean that I would be sloppy: I would miss key points, cause bugs and weird interactions, and just in general drop all kinds of balls that it is my normal job to catch. I’d expect any manager I had who was also writing code to do the same (or alternatively, to do okay at the engineering work and completely neglect the management jobs).

Tech company power dynamics are hard

You might be thinking that engineering teams often have juniors or less-experienced engineers who sometimes do sloppy work, and the team absorbs that fine (by supervision, code review, and so on). That’s true! But there’s a big difference between a junior engineer doing sloppy work and a manager doing sloppy work. Unlike a junior engineer, a manager wields real institutional power in the organization.

Some managers may disagree with that. But it’s nonetheless true. Even if managers don’t get to fire or discipline engineers at will², they still have many levers available to them. First, they have the ear of their manager, who usually does get to fire engineers if they want to. A manager can completely ruin an engineer’s reputation by saying (or not saying) certain things in manager meetings. Second, managers are involved in normal promotion and bonus processes, and can do real career damage to an engineer simply by slow-rolling or doing a deliberately bad job. I know multiple engineers who had their deserved promotion delayed by twelve months or more due to their manager simply not submitting the right forms.

It is difficult to deal with a sloppy worker who has power over you in the organization. If they’re kind-hearted and easy to work with, there’s no problem. But people with institutional power can find it understandably hard to take criticism. And the instant the situation gets charged, it becomes impossible to manage. Can you leave a “blocking, do not merge” review on your manager’s PR, if your manager is already kind of annoyed at you? I mean, you can, but it’s likely to be career-limiting. What if your manager is suggesting a technically unsound approach in a team meeting?

This is the whole point of having explicit junior-mid-senior-staff roles at a tech company: to provide a structure for technical disagreements where it’s very easy for less experienced people to get feedback from more experienced people. When a junior engineer catches out a staff engineer in a mistake, the staff engineer can (hopefully) accept it with grace, because it doesn’t happen that often. That last clause is key: in a company where the promotion structure is dysfunctional, and technical ability has come unmoored from job titles, technical disagreements become a minefield. Junior engineers are frustrated at having to fix the shoddy work of more highly-paid and titled engineers, and senior engineers are frustrated at having to receive frequent criticism from their juniors. Requiring managers to do engineering work on the team wrecks this structure in the same way.

Final thoughts

I can see why some people like the idea of managers actively writing production code. It’d make it much easier for them to evaluate their engineers, give them real credibility, and so on. But I think it’s a pipe dream in a large tech company where there’s so much real manager work to do. Of course, it’s nice when a manager is technical enough to understand what their team is doing (even then, I wouldn’t say it’s essential). But that’s still a long way away from being able to actually contribute to what their team is doing.

Some companies want managers to write incidental code (copy tweaks or minor style change PRs, non-production code, that sort of thing). I don’t necessarily think that’s a bad idea, as long as they’re not getting involved in complex production changes. But I also don’t really care whether they do or don’t, as long as they’re still doing a good job as a manager.

Overall, I’ve worked with a lot of very good managers and some weak ones. They were good (or weak) because of their skill at managing, not because of their ability to do engineering work.

If you liked this post, consider subscribing to email updates about my new posts.