Why developers (usually) make lousy managers

Have you ever wondered why this particularly brilliant and talented coder crashed and burned when they got promoted into a leadership position? All the lights were green though. They’ve been in the company long enough to know how things get done around here. They are respected by other developers for their technical skills. They even got initial training when they got promoted. But it didn’t work. Their team’s productivity quickly started to plummet. Some team members began to complain. And the manager’s morale descended into the abyss. So what went wrong?

Obviously, it’s definitely not because the new manager lacked intelligence or turned into an asshole the minute they got promoted. It actually has to do with how developers work and many, many, misconceptions about what managers are and should do. Let’s explore some of them.

Why do we need software development managers, anyway?

One day in July 2001, Larry Page decided to fire all of Google’s managers. Since Google hired only the most talented engineers, he thought that extra layer of supervision was unnecessary and was slowing projects down. Instead of the managers, all of Google’s engineers would report to one person, a newly hired VP of engineering. But Page’s reorganisation didn’t last long. While some engineers thrived without supervision, problems arose. Projects that needed resources didn’t get them. Redundancy became an issue. Engineers craved feedback and wondered where their careers were headed.

Like all individual contributors, developers need and want to be managed (when it’s done the right way). In a team that is well managed, everyone is at the right place with the right information so that the team’s output is the most efficient. Team members know where they stand in terms of performance and personal development, while being protected from unnecessary changes and interruptions (hello sales teams 👋).

But is managing software developers different?

While developers have been compared to factory or construction workers for a long time (you know, because they « build » things), their work pattern is actually closer to a writer’s. As much as you’d like to have that new feature divided into known and predictable tasks, the reality is that a developer’s work implies a fair amount of creativity and problem-solving. Like writing a story or a scenario. If you’re a coder or you’ve done creative work, you know what I’m talking about. Making it work requires a high amount of concentration, limited human interactions and some productive procrastination times (aka staring at your screen doing nothing). Managing these creative types is very different from managing employees with predictable and repeatable tasks.

Developers are also different in terms of expectations. Because of the binary nature of their work (algorithms work or don’t work) and their highly analytical mindset, they have trouble understanding floating concepts like « gut feeling » or accepting irrational demands. They need to be convinced with rational arguments and, even soft concepts (like empathy or active listening), should be measured.

Manager is a different job, not a promotion

So if developers should be managed differently, why do former developers fail so often at managing their peers. After all, they know them so well. But transitioning from an individual contributor role (where your performance is measured by your technical skills) to a manager role (where your performance is measured by your team’s performance and appreciation) can be tricky. For example, if the manager was a superstar developer, it could be super hard for them to let a team member build a feature their own way while you know you would have done it completely differently. Managers have to learn how to delegate and coach, instead of arguing over implementation details or remaking features at the last minute.

Managers with a technical background should also abandon their problem-solving mentality. I’ve seen countless managers that feel that it’s their responsibility to solve all the problems that arise at team and individual level, and never empower their team to do it by themselves.

They also have to learn that becoming a manager doesn’t mean abandoning their analytical mindset. Teams are systems and can (should) be run with algorithms with inputs and outputs. Human interactions can be measured and analysed (it’s called people analytics).

I don’t like management, maybe we should hire a VP of Engineering

With so many developers becoming bad managers (or don’t even try), many tech leaders are tempted to hire seasoned managers from outside. But make no mistakes, if hiring a good developer is a pain, hiring a good engineering manager is even worse, because there’s so few of them. What should you do? Reconcile developers with (good management) by showing that management can be done the right way through systems design (so that your team run efficiently without constantly asking for directions), relationships building (so interactions with other teams are smooth) and coaching (so each individual contributor can grow within the company).