Managers and technical ability

There’s a belief in the software development world that you can’t manage developers unless you’ve been one yourself. This often gets reduced to the shorthand that some manager "isn’t technical."

We say someone is "technical" or "not technical" as if this is a binary choice. In reality, it’s a giant scale. I spent much of my career as a developer before shifting to product management. Twenty years ago I wrote a web server and a database engine. I was CTO at two of my companies. I barely understand the basic concepts behind Kubernetes.

Am I technical?

It’s clear that I was technical. But am I still? Is "being technical" something you lose over time? If "technical" is a scale, am I technical enough? I could learn Kubernetes if I had the need, so does that play into the "technical" scale?

Lisa used to be a network administrator and now is a development manager. She can still design and troubleshoot a network, so she’s clearly "technical." She told me that she’s struggling as a development manager and thinks it’s because she wasn’t ever a developer.

There was a study that found hospitals run by doctors perform better than hospitals run by people without medical training. It’s unlikely that doctors turned senior administrators would be able to lead a complex surgical procedure or would be up on the latest treatments for specific illnesses. Their medical skills and knowledge would be too rusty to be effective. Being a manager of doctors is a completely different career than being a doctor was and managing is now their primary skillset. Then what makes doctor-run hospitals better?

Being familiar with what it’s like to be a doctor is what leads doctor-managers to do a better job running hospitals. They know what it’s like to do the work, they understand the challenges, the tradeoffs, and the decisions that face doctors daily. This is why they are better at leading other doctors.

The best development managers are former developers themselves because they understand what goes into developing software. It’s not because you need to be the technical expert to lead developers. But because you need to understand what it is like to be a developer.

This is why Lisa is struggling. She has a technical mind and understands technical concepts, but she has no frame of reference when her team is deciding the tradeoffs between two design options.

I suspect this translates beyond "developer" or "not developer" as well. Someone that has spent their entire career developing web applications won’t understand the things that make writing embedded firmware unique. Putting a web developer turned manager in charge of a firmware team would have the same problems that a network admin managing the team has.

A surgeon likely wouldn’t make a good manager of virologists.

The further up the management ladder you go, the less you get involved in domain-specific things, so the less your specific domain will matter. The surgeon that can’t manage a virologist team could lead a cross-functional group of teams, even when that includes virologists.

I don’t need to know Kubernetes commands to lead an ops team, I just need to understand basic ops concepts. I don’t need to know ops to lead an organization that includes an ops team. It’s enough that I can grasp any high-level technical concepts if someone in my organization needs to explain them to me.

Managing developers requires you to be a specialist. Managing development managers requires you to be a generalist. The closer you are to the people doing the work, the closer your skills need to resemble those of the people doing the work. It’s not a matter of "being technical."