Articles like these are kind of hard to parse because there's no well-defined meaning to the title of "CTO". Our "CTO" codes, probably more than anybody in the company, but that's because he's got a founder-inherited CTO title that mostly just means "he can do whatever he wants" --- we're happy with that, what he wants is practically always great.
That's one definition of a CTO. Another CTO type is the opposite: "the thing you call an engineering founder when they've done so much customer-facing work that you have to take their commit bit away from them". This is, I think, an even more common archetype than the other one.
Then you have the toxic CTO definitions --- CTO as "ultimate decision maker for engineering", or, God help you, CTO as "executive manager of all of engineering".
You'd have to be specific about what kind of CTO you are to really make the question of why you code interesting.
The only title that a founder can have that matters more than "founder" is a CEO.
He calls himself a CTO, and that's fine, but he's really just a technical cofounder, and that's what he's acting like (and it sounds like it's a very positive thing for the company).
The CTO title and the whole point of the article are not really relevant, this entire situation would not be possible if he weren't a co-founder.
I think it is a good lesson that founders shouldn't necessarily be pigeon holed into roles they don't want, but the CTO title really has nothing to do with it.
This comment seemed the most reasonable of all of the first line comments so far.
You could event extend it farther by highlighting that many firms have a VP of Engineering AND a CTO.
In that scenario, the CTO tends to do more "strategic" and "big picture" work and the VPE is who runs the day to day work of managing SWEs, setting standards etc.
But even then, there are many different flavors of that too.
I once worked for company with C-level guys working alongside the rank and file. Smartest guys I knew, EE degrees with honours from Cambridge. So smart that they knew their strength, and decided to let better people manage the company they created.
I found the article interesting, even given a large range of possible definitions of CTO.
I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.
For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?
Title inflation has been going on forever. For early stage companies, titles are mostly about perception and presentation, mostly for people outside the company.
> because there's no well-defined meaning to the title of "CTO". Our "CTO" codes,
Amen.
I am a CTO, but spend most of my day coding. I was brought onto a smallish/medium sized company to get their base tech into the modern age, build LOB apps to improve some workflows, and ultimate build a new EMR in that space to replace the one the company is using.
I don't have anybody that reports to me. I'm one of 2 tech people in a company of clinicians and doctors. There is no budgeting or reports I have to generate.
But, it was the only title that made sense given my role in that specific company.
Anytime someone asks me I always have to add "but I don't really do CTO things".
so you’re not a CTO according to your own definition of what a CTO does then.
my previous employment i was “lead engineer”. i got to pick that title. had a 1 day per week part timer reporting to me. similar company description. making technical decisions. strategy meetings with CEO and founder etc.
i was not a lead engineer and ive since changed my linkedin page/cv to just say “engineer”. who or what was i leading? a contractor in ukraine who did work for us one day a week? nah, need a team (ie more than 1) to be able to lead.
do the brave thing and call bullshit on yourself. this is something good leaders do.
People here want "CTOs" to be brave enough to call bullshit on their "CTO-hood" but nobody here is brave enough to call bullshit on the title itself, which is the truer and more important observation.
That's one definition of a CTO. Another CTO type is the opposite: "the thing you call an engineering founder when they've done so much customer-facing work that you have to take their commit bit away from them". This is, I think, an even more common archetype than the other one.
Then you have the toxic CTO definitions --- CTO as "ultimate decision maker for engineering", or, God help you, CTO as "executive manager of all of engineering".
You'd have to be specific about what kind of CTO you are to really make the question of why you code interesting.