Can you manage a dev team and still be hands on?

I think you can have a minor hands on role but not be part of any KPI for output. Hands on can mean getting the most out of your team through enabling thier best interests. For me that would be enough if I ever got to be in your shoes.

It depends on what you mean by "manage", and it depends on what size of "team" we're talking about. I'm on a project right now (and have been for ~2yrs) where our lead developer largely manages our tasks and ticketing system, attends meetings most days, and still puts out a significant amount of code.

Our team is not enormous, it's currently 7 developers (including him), 2 testers, and a system engineer. But he performs the majority of what I would consider "management" functions for the team, and still puts out a few hundred lines of code per week. And he's only working 40hr weeks, not working til midnight or anything.

That said, he's not a CTO, he's just the lead of a single project team. Being a CTO is typically (in my experience, feel free to disagree) much more complicated than simply directing a group of devs to work on stuff. There's usually some longer-term vision planning, working with system engineers to plan out the long-term architecture of the product, sometimes working with vendors, etc etc. That stuff will keep you busier.

I agree. The way I see a development team leader is that the person should be thinking about projects alignment with company direction, improving development processes, delegating tasks, stacks (current and future) and the most important to me is the growth of your team members; 1:1 discussions, mentoring, career mapping. I don't see how the leader would still have time to do anything else, especially coding.

I understand that the willingness to get hands-on is still there; if it could be done faster by you or if the project would finish sooner, why not, right? However, letting yourself involved is (in my opinion) hurting your team members more than helping them. They won't get the experience or knowledge that you have, and you might have overlooked some areas in your own role since you spent the time doing what they're supposed to do instead.

If the knowledge gap is the problem, I would say do a pair programming so that the knowledge is sort of transferred. The next time similar thing happen, you don't have to do anything, they'll do it instead. If a company relies on the leaders doing too much and it still didn't work out, that could be a sign of a 'management smell' in my opinion. Either there's a resource problem or they're not delegating that much.

"The 4 stages of a CTO: 1. I wrote the whole thing / 2. I still code 50% / 3. I wish I had time to code / 4. My team doesn't let me code anymore"

-- Simon Stemplinger

This has been pretty much my experience as my team grew from me + 1 to me + 16. I do some pairing and reviewing, mostly on the older parts of the codebase, but don't get to do much new stuff. I'm just too booked with other kinds of work. It's that whole maker vs manager schedule thing.

My company has both a CIO and a CTO, both manage teams of people, both still write code. Big caveat, my company is pretty small with not a ton of engineers. I imagine the more engineers, the more work there is to do with planning / organizing.

I guess what I’m saying is it’s definitely possible, but you’ll probably want to look at smaller companies / startups.

Yes, it's possible. Not ideal, but possible. I spent 10 years in consulting both managing and delivering code. There is no "one-size-fits-all" answer. For example, if I'm on a single project as technical lead it is possible to divide my time between managing, removing roadblocks, enabling other team members and contributing to the bottom line by building features and completing stories. On the other hand, if I'm on a dozen projects then I probably won't be very effective as a contributor and could end up negatively impacting things.

There is also the question of timeline. In many projects I led, I would start out in a very hands on role and help provide initial guidance and architecture. Then I'd transition to having less of a hands on role and shift responsibility more to the team.

My personal philosophy is that there is a nuanced line between a person responsible for the team (interviewing, feedback, support, etc.) and a person responsible for the project (staffing, delivering, removing roadblocks, clarifying expectations, etc.). Sometimes those roles overlap, but while team management doesn't require hands-on, managing the project does. It is tough to help resolve conflicts if you're not knowledgeable about the code base or in the trenches with the team to understand what they are facing.

It also depends on a certain extent what your personal desires are vs. the flexibility of the role. I never wanted to be ivory tower management, and always wanted to have some stake in the game just because I love both coding and managing and never felt they had to be mutually exclusive. If I wanted to stop coding I could have easily changed the makeup of the team to ensure there was no need for me to be part of the critical path for delivery.

There is a great metaphor for building a pyramid with massive blocks. Imagine them attached to ropes so that a team can pull them up a ramp to put them in place. I always focused on roles that let me grab the rope and lead by pulling it up the ramp with my team alongside me, and purposefully avoided roles that would have forced me to sit on the block, point up the ramp and expect my team to do all of the pulling.

As a CTO of not big company (YET!), i could confirm that it IS possible. Not in a 8 hour day tho :)
My developers team is of 7 + 2 qa + sysadmin.
5 of 7 are juniors, and it takes a good portion of day to guide, teach and review their work.
Techical discussions, decisions i am making daily, future plannings and establishing a path that we will go, takes a good part of the day too. Usually i am having daily standups with the team, private calls with all developers (to be sort of in touch), calls with CEO, chat with custoner support, and a lot of reading daily, just to stay in 'shape' and to know the trends, as well to learn other people experience.
Not on daily basis, but every now and then i am jumping in coding to get things done faster.
Daily, i do some kind of pair coding and education with our developers.
Planning tasks, sorting out responsibilities, delegating techincal tasks ... I love this job :)

As long as you have the wherewithal to dig in after seeing to your management responsibilities and you prioritize not being the bottleneck, it can be done. The size of the overall organization and/or internal unit and the politics of how it operates both make a big difference in how successfully.

By my personal experience, I have found that the more you have to manage up and across the less the amounts of PullRequests. Yes, you want to stay on top on the Code, the quality the architecture the decisions and direction, you will be able to influence but you will not be able to contribute as much as you will like. And to be honest, a Manager and more a CTO are roles to protect the developers, to guide them, inspire them and allow them to do the best job possible while you deal with the politics, budgets, timelines, keep expectations healthy, deal with the situations of perceived low quality, negotiate features and times makes sure the team is not developing something that makes no sense just because someone things is a good idea while keeping an eye to the trends in the industry and see how that can be beneficial in the long term and how to get time and budget to allow the team to experiment and learn from it.
To be honest, try to do all of that and do it well and in a way that helps the team and you will find your self with no much time for code. This doesn't mean that you should not be able to roll your sleeves and code on a crunch time or be able to fire up the IDE and look for that piece of code that introduced the bug and fixed when is an emergency, you have to do it and do it well or at least in a helpful way.
CTO's are exceptions and they can still be able to code, but they need to have a team of Directors and Managers that will do their job well so will free his hands and allow him to work on some experimental projects that will provide future directions, but again it depends how much they have to manage up and sideways and the support from the staff below him.

Hands on for a team lead is difficult. Usually something else will take a hit. Their primary responsibilities should be planning, design and ensuring developer tasks are being worked according to the first too. If they are hands on, it should be prototyping a design. Nothing that could put their primary role in jeopardy.

I'm a software dev manager for a software dev team of 7 (including myself) and the metric I've come across a few times is ~30% of your time should still be in dev and from my experience that's fair. There are days when I don't program at all but keeping my skills in constant use means more redundancy (I have a backup on the team (someone who can lead if I'm sick/on holiday/whatever) and I can provide backup for the senior devs and chip in when things get crazy. It also helps to keep me reminded of current dev concerns (the struggle of estimating, the frustration of sloppy requirements, etc). The company is under 20 employees but even if it were to double, I think I'd still like to keep my finger on the pulse of dev.

As with all things in life, balance is required. Balance will look different for every organization, but typically you cannot be hands on in the code, filling your brain with the intricate details of a complex system, while simultaneously planning bigger picture items for your organization and tech stack, interviewing new employees, handling business partnerships, mentoring your employees, and staying on top of the health of your team.

I would say the best way to be an engineering manager is to pair from time to time on the most critical things with your most senior engineers to keep passing on information, but spend the rest of your time actually managing. Care for your organization and the people it is comprised of. Help people flourish, remove obstacles for them, teach them, and help guide the ship to calmer seas.

Only if the team is mature. The more junior devs on the team, the more you will need to guide them.