Should a CTO keep on coding?

I’ve always been fascinated by systems, the way they work, the way you can put them apart and build them back up. Part of this fascination is my insatiable desire to always be learning but also a challenge I like I give myself: can we do better? This fascination is what drove me most of my career. But my focus has usually be on the technology side, not really the human side. As human beings, we are full of feelings and uncertainties, you can’t apply a binary vision to the people around you, which results in people being harder to manage than technology. I knew that becoming a founder and growing a team meant that I would have to face some very interesting challenges. One of them being how do I transition from one role to the other within my own company.

When you start as a technical founder, you are really a developer, quickly becoming a team lead. The team lead does leadership things but still codes and does very little management tasks. Then depending on how the company grows, usually you become a manager and now you have very little time to code. I tried to do both coding and management for a little while and I quickly realized I wasn’t doing the team or the company a favor. That’s why I opted to hire a great technical manager and focused on my CTO role.

“My role is to make sure we are making the right business decisions and we have a plan on how to implement them”. — Me, in this blog post

If my job is to identify technical opportunities, make and/or support business decisions, should I still code? If I do, is it because I like it or because I need to? Should all CTOs continue or stop to code? If I keep on coding, what should I be coding, how do I relate to the rest of the company?

The answers to those questions greatly depends on the business you are in and the kind of decisions that need to be made and the stage of the company. I’ll go even further and say that it probably also depends on the kind of CTO you are. But at the end of the day, you should look at this quote from Camille Fournier and decide if coding is helping you with that or not:

“No matter what, the CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them.” — Camille Fournier, The manager’s path

If you keep on coding, you should never stand on the critical path. Your code output shouldn’t be as important as your leadership role. Your coding should only be there to help you make the right business decisions. Hopefully you can delegate most of the coding, but in some cases, that’s not feasible or recommended. Let’s take a quick look at why you might still be coding as a CTO:

My team is too small

You are probably a technical cofounder or you were given a CTO title to make you feel good. Your job is to build the right foundation for your company and help make the right business decisions so you can grow the team. By the way, you probably should start looking for a good team lead and maybe a good manager for your team.

I am the expert

Time to share the knowledge or hire other experts. You are a single point of failure, that’s dangerous! (Note: that’s the situation I’m trying to get out of, I have a lot to say about this)

I do a better job and deliver faster than the rest of the team

Maybe you didn’t hire the right people and should correct that. Or maybe you don’t have the right process in place yet, or finally, maybe you aren’t doing the rest of your job well and should focus on that. (Other option: you need an ego check)

I feel guilty to let the team struggle, they have so much on their plate

If they have too much on their plate, maybe the workload isn’t adequate for the team size. It’s your job to help define the business objectives and have a plan in place to execute. If the team needs your help with code, the planning wasn’t done right. It might happen from time to time but it should be really exceptional.

I need to prove to the company (or myself) that I still “got it”

That’s an obvious one, but more common than you think. Especially when you have a very strong engineer becoming a CTO. As engineers we value ourselves based on their capacities at designing solutions and all a sudden their actual coding abilities aren’t needed. Jordan Hubbard once told me that key to be a happy great engineer manager when you’ve been a great developer is to focus on helping others getting as good and even better than you.

So if coding helps you figure out the biggest technical opportunities and risks for the business, keep doing it but don’t stay on the shipping critical path! Otherwise, you probably shouldn’t code much anymore.