I was a consultant for a bunch of startups for 4-5 years, selling my services as a "CTO for hire" to them, and was full-time CTO in multiple startups to boot.
I had a general line/rule of thumb. At < 6 engineers, you had to write code regularly as the team was so small it couldn't carry the weight of a member of the tech team who didn't commit regularly.
At 12+ engineers, you didn't have time to in order to do the other work (management, prioritisation, reports, strategic thinking, etc.), well enough.
At 6-12 engineers (where I spent most of my time), I didn't have time to write code, but had to in order to keep the company moving. Cue 60-100 hour weeks for 10 years. Yeah.
I went to quite a few CTO events, and in all honesty, it was a surprise to many of them that I both knew how to code and that actually spent any time doing it. I thought it was insane that there are CTOs - many of them - that aren't interested in the practice of creating technology at a hands-on level, but I could also understand how that happened: in my location (London), it's quite normal for non-tech CTOs to pick up from founding CTOs after a few years.
It's a weird situation to be in, and eventually a couple of years ago I decided to evaluate what I wanted and wrote a list of what I liked and didn't like about my job as a CTO.
I realised all the things I enjoyed were actually the responsibilities of a senior engineer, and all the things I didn't like were the management and board duties of being a CTO. Slept on it for a week, resigned, applied for senior roles, and generally am much happier (2 years on).
It's worth really thinking about what you want from the role. If you're a co-founder, you can shape it, but you have responsibilities to your investors, wider board, exec team, managers and developers. Most importantly, your have responsibilities to yourself.
Choose your own adventure when it comes to being a CTO, but choose wisely and carefully.
Back in the early 2000s I worked for a telco. Telecom was having a pretty rough time following the dot com crash. They replaced the previous CTO with a CTO that had a financial background (would have been suitable for as a CFO). This blew my mind at the time. The explanation was simply he's going to be less persuaded by seniors managers arguing for projects on technical merit and more persuaded by the dollars and cents. Rightly or wrongly, it worked, they got out of trouble early and when the economy turned around he was swiftly replaced by a hacker CTO.
One previous CTO of mine frequently told us he hadn't written a line of code since the late 1970s, and even then he hadn't done much. He didn't know what an SSH key was, didn't know the difference between FTP and HTTP, and hadn't heard of MySQL (this was mid 2000s).
He had two excellent abilities: convincing the board to give more money to IT, and hiring good people to spend the money wisely.
My experience comports with the parent. Most "CTO"s or "CIO"s I've met have a weak or non-existent technical background. I worked closely with a CTO whose only direct technical experience was a couple of CAD classes he took at a community college.
Generally, a CTO's tech "qualifications" are more from having some general knowledge about the technology ecosystem (e.g., they've managed software people before, and they know what Microsoft SQL Server is) than from any hands-on experience.
They will often be the type that have always been interested in gadgetry and tech, but basically only enough to subscribe to WIRED (back when that was a thing people did) and observe the industry casually. Not enough to get involved in the process themselves.
CxO is a fundamentally non-technical job, so I don't know what people expect from "technical" occupants. Technical people do poorly because the role is almost entirely subsumed by "business" responsibilities; that is, closing sales, talking to media/making presentations at conferences, sitting in meetings with lawyers and investors, setting budgets, and so forth.
Let me ask you, what is a "technical" CTO supposed to do?
I had a general line/rule of thumb. At < 6 engineers, you had to write code regularly as the team was so small it couldn't carry the weight of a member of the tech team who didn't commit regularly.
At 12+ engineers, you didn't have time to in order to do the other work (management, prioritisation, reports, strategic thinking, etc.), well enough.
At 6-12 engineers (where I spent most of my time), I didn't have time to write code, but had to in order to keep the company moving. Cue 60-100 hour weeks for 10 years. Yeah.
I went to quite a few CTO events, and in all honesty, it was a surprise to many of them that I both knew how to code and that actually spent any time doing it. I thought it was insane that there are CTOs - many of them - that aren't interested in the practice of creating technology at a hands-on level, but I could also understand how that happened: in my location (London), it's quite normal for non-tech CTOs to pick up from founding CTOs after a few years.
It's a weird situation to be in, and eventually a couple of years ago I decided to evaluate what I wanted and wrote a list of what I liked and didn't like about my job as a CTO.
I realised all the things I enjoyed were actually the responsibilities of a senior engineer, and all the things I didn't like were the management and board duties of being a CTO. Slept on it for a week, resigned, applied for senior roles, and generally am much happier (2 years on).
It's worth really thinking about what you want from the role. If you're a co-founder, you can shape it, but you have responsibilities to your investors, wider board, exec team, managers and developers. Most importantly, your have responsibilities to yourself.
Choose your own adventure when it comes to being a CTO, but choose wisely and carefully.