Why I code as a CTO

In very small startups, CTOs need to code. You need as many people who can code checking in as possible, but you are trying to extend runway and so you don't have too many people on the team yet.

Critically, at this stage of the company your attention is not needed elsewhere as much as it will be one day: governance is light, the team size is small and everyone in the business is talking about product market fit all the time.

In more established businesses, CTOs can't code. I don't mean they don't have the ability, I mean they don't have time at first, and eventually they lose touch with the code base and tools to the point where getting involved slows everyone down, so please, on behalf of your staff, don't.

These CTOs are not "stuck in meetings" - the meetings are the work. Meetings are work. If a meeting isn't work for you, the questions is why are you there. Every meeting a CTO is asked to attend should (and probably does), need strategic technical/engineering input.

The CTO is going (or at least should be), because they have the experience, skills and ability to synthesise decisions and move everyone forward without having to drag all the rest of the senior engineering staff in. They are doing that work so that others don't have to.

They may also sit at the top of the org chart for a section of the company that means HR, Finance or other senior stakeholders want to engage them in order to drive strategic changes.

For a long time, I joked I was in the middle: I worked for startups that were small enough I had to code, but I didn't have the time because of everything else. So I coded, but I was exhausted.

And now you know why it's "former" CTO. This stage is painful. The temptation is to do both. Perhaps start working long days or weekends, but that sends a poor signal to your team.

Complaining or boasting about being very busy or working long days is not the badge of honour you might think it is: it's a signal to your team that you can't manage your time, and you don't value work/life balance. They will vote with their feet if that carries on for more than a month or two.

The better solution is, in my view, find the work/life balance, prioritise and say no to things that don't fit. It's often easier to say no to coding tasks, which you can hire other people to do, than it is to say no to the CEO about something they need doing, which you can't hire other people to do (at least, not without replacing you). Make clear - and signal to others - that you're going to choose how you spend your time carefully, but not because you are a precious resource but because that's the culture you want to instil and for them to do the same. Lead by example, always.

As an aside, even in small startups, when you are coding as a CTO, you should not choose the things that excite you the most, but the things that get in the way of your team the most.

Your engineering staff don't want you to take the meaty things that customers value - they want to do that, it's why they took a crap salary and the promise of untold options-based riches, because at least they get to work on meaningful things customers get excited by.

What they'll value is that horrid piece of refactoring that nobody wants to go near just going away, or that nasty new feature that needs integrating with that third party API everyone hates working with.

Your job as CTO is not to be "the best guy in engineering", it's to move all the obstacles out of the way of the engineering team to make them all the best they can possibly be.

Get rid of their reasons/excuses for failure, by doing whatever it is that needs to be done to help them succeed.

Sometimes, that means focusing on being in meetings to make sure that new policies or product directions aren't going to chop their feet out from underneath them. That means you need to realise that meetings are the work. Get over it.

And if you don't want to do that, and instead throw PRs over the wall that you & AI put together on a Saturday morning and expect a round of applause and hearty thanks... again, expect people to vote with their feet eventually.

At the CTO level of a growing company it is one of the lower leverage things they can do. Setting technical direction, hiring the right people, and putting the right people in positions of power will all have much more impact than writing some code on the weekend.