Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Managers and technical ability

Freshness Warning
This blog post is over 4 years old. It's possible that the information you read below isn't current and the links no longer work.

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."

Recently Written

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2024 Adam Kalsey.