Here's How Often a CTO Should Code

The Chief Technology Officer. The maker of things. The knower of stuff. The solver of problems. The guy who probably has to fix their parents computer each Thanksgiving. But how often should they be coding?

As often as they feel they need to

Being hands on and understanding the technology at a level where you can make critical decisions about execution is important, particularly when your company is still evolving its strategy and product. Being ahead of the next big thing, and knowing how new solutions could be applied within your team (and what knowledge is required to take full advantage of their benefits) is an imperative for CTOs in most organizations. And for most CTOs, it's just something they are going to do anything because it's the stuff they love doing.

In larger organizations, the CTO may have many delegates in the forms of engineering managers, directors, and vice presidents who may preside over different specializations (databases, devops, backend, frontend, etc.). These "super-CTOs" may have larger public relations, sales, marketing, financial, and compliance responsibilities that absorb too much of their time to be "in the weeds." This effectively makes their deputies "Associate CTOs" who will likely be doing more of the hands on work. Even still, it's valuable for technology executives to remain conversant in the latest technologies as to not risk alienating their leadership position with a lack of knowledge.

But not if they have to

Caveat: If you are a startup CTO and the only other person in the company can't code, then this doesn't apply to you. Early stage startups that are trying to get off the ground should hire engineering staff judiciously as the product gains market fit (>$250K in annual revenue is a good financial benchmark). Until then, the CTO is likely the DBA, DevOps lead, front-end developer, engineer in test, and even designer (I've been there!). But once you start hiring, or if you have an established team - your hands on role should be greatly diminished and eventually, non-existent.


  1. If you're hiring people, it shouldn't be because there's more code than you can write in a day - it should be because coding is getting in the way of the other things you may have to do. Client meetings? More important than coding. Customer research? More important than coding. Hiring. More important than coding.
  2. You are there to build the business, not be an engineer. And that means you have a team to build. If your product or service is generating revenue and you can start building a team, start building a team. That means you are becoming a mentor and coach, and while you may be a player/coach at first - the longer that you are the guardian of the code base, the less agency your team will feel to take ownership.
  3. If upon self reflection you look at the above points and say "well, those don't apply to me" - then my guess is that you are doing it to avoid other things you don't want to do, or that you need to hire more people. If you love coding so much that you are using it to avoid budgeting meetings - that's a problem. If you are doing it because there is still more work than people to get it done, that's a problem too. If you don't like running a business and want to code - cool. But you're not the CTO. If you are committing to getting an amount of work done that your team could never deliver and you need to be superman - stop overcommitting to the business.

The Zuckerberg Conundrum

There's an old story that at Facebook - the "status update" feature was so sacrosanct that changes to it could only go to production if the CEO Mark Zuckerberg approved the changes himself. This is insane if true, but does highlight that there are certain components of every product that may be particularly complex, or still rooted in something that a founding CTO feels so paternal of that they have a problem letting go of their accountabilities to it. Every product has one thing that if it were to break would be a problem for the business.

But this highlights the problem of one person ever having such a critical role in the ongoing development of a software product. If anyone, nevermind a founding CTO builds some new feature that will be so critical that the business will die if the builder were to disappear - that's just not an acceptable situation. Instead, it is the duty of such a knowledgeable person to document what they've done, educate their team, and ensure that the team has the knowledge, agency, and mandate to eliminate their role as a single-point-of-failure.

You can take the CTO our of software engineering, but you can never take the software engineer out of the CTO. CTO's growing companies need to develop the self-awareness, trust, and downright laziness to know that they are now responsible for something larger than code. There are customers, shareholders, and employees that depend on their expertise and leadership - there's not a lot of time left in the day for those things if the CTO is also the reason why the engineering team functions well.

For early stage startups, the CTO may have to be the lead engineer. But once they can afford to hire - the CTO has to begin to step away from that engineering role and trust that their hires will carry the torch of their work to continue to refine and improve the product. Great CTOs become the best coaches, not the most valuable player.

Ryan Norris Ryan Norris

Ryan is the former Chief Product Officer at Medullan, CTO at Be the Partner, and CTO and General Manager at Vitals. He currently works as a fractional CTO offering strategy as a service to growth-stage companies in health care and education.

Recommended Posts