Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

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

How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.
Developer Experience Principle 3: Easy to Build (Oct 5)
A product makes it Easy to Build by focusing on productivity for developers building real-world applications.
How to understand your product and your market (Sep 30)
A customer development question you can ask to find out who your product is best for and why they'll love it.
Developer Experience Principle 2: Easy to Use (Sep 28)
Making it Easy to Use means letting the developer do everything without involving you.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.