Should managers still code?

It has been interesting what both groups of 'yes' and 'no' chime in here. Personally I am on the side of 'no' but for a rather simple reason. I ask myself the following question:

Why spend time being good at something you don't care about being good at any more?

It is purely a personality thing however for me I would like to continue moving up the career ladder and you rarely see CTOs, VpEng rolling up their sleeves and sifting through CloudWatch logs. I want my focus to be on working the skills associated with those roles.

As a people manager that works with many incredibly capable engineers that are aspiring to be managers, I share with them this advice, 'excellent engineers compound their value by making other engineers excellent. It's far more difficult to do that when you are writing code.'

Depends, I always took a sprint task, certainly less than the team itself, but how do I design a career path if I'm blissfully unaware of the work that is being done? How do I plan long term if I don't understand the technical complexity of the problems being faced? Why would I waste time on conflict resolution when I can spend time enabling and building people? You want to argue about your colleague, or make do you want to advance and make more money?

Toyota calls it the gemba walk. Managers need to see how the factory is running with their own eyes. Not just live behind a desk and listen to what they hear in meetings.

A movie director can see the sets with their own eyes. But you can't see the state of a software codebase without reading and understanding the code, and the most surefire way to do that is to try to write something, even just documentation.

You don't assess the state of your software by walking around the office and looking at hands on keyboards. You look at the codebase.

They are not that different.

Conway's Law is real.

Great engineers are not just "pure programmers", they understand the scale and organization of their domain. Similar for managers.

In joking terms, the 8th OSI layer is "money/politics".

It can help but it's not essential. Most coders make lousy managers and most mangers make lousy coders. Sometimes you find people that can do both.

The meta question here is do you need a person to manage you or can you perform at your peak without being micro managed. If so, you might be management material ;-).

I've worked as a employee, freelancer, consultant and lately as a CTO. As a consultant you tell managers how to manage. When freelancing you don't lift a finger unless you are told by your client, who is not your manager (important to be able to tell the difference). If you start consulting them effectively, make sure you increase your rates.

If you are an employee, you might have a career path that may involve you evolving into a manager. And as a CTO of a small company it's my job to make sure shit gets done. And sometimes that means getting hands on and leading by example. And sometimes that means delegating work and optimizing my time use. And sometimes I like having some fun. I hate delegating fun things.

A CTO that isn't hands-on is not a CTO and cannot provide long term meaningful technical leadership. Any technical skills they have don't have a long shelf life. Companies with no CTO and a hands off VP of engineering are probably not technology companies. This is a problem if they are trying to be one. Or used to be one.

I've consulted a few of those. I've also advised startup founders to not hire a CTO and instead find themselves a good VP of engineering. Because they weren't creating a tech company and their technical staff was OK but clearly not management material. In a startup, CTO is a founding role. A tech lead reports to the VP of engineering, a CTO reports to the CEO. Or sometimes is the CEO as well. Big difference. The VP of engineering is not a C level executive typically. They aren't co-founders. They don't hold a lot of equity. Good CTOs that can double being a decent VP of engineering are rare. Very different skill sets. The opposite is more common.

In short, it all depends.