So many things wrong with this sort of “CTO must not do what they enjoy but what is the list of responsibilities “ robotic thinking. So you think coding is not high leverage on a tech company. Do you even remember why your company exists anymore? Surely not to give people a living and let them be happy at work, according to you. Absolutely no, the only purpose of a company is to deliver value, but I bet you can’t even define value other than a hand wavy impact on ROI or whatever makes this quarter’s numbers look good.
In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that.
This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.
> So you think coding is not high leverage on a tech company.
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.
You’re wrong man. These things you mentioned happen rarely, it’s not what you do day to day. If you don’t do some high value coding you have no clue how to steer a tech company at a technical level.
I don't know about that. I was a "CTO" for a small (10-person) and a slightly larger (around 100-person) VC-backed startup. Hiring was always top of mind at both places. Not even "people management", just hiring alone. I'm not saying this universal, but when a company is expected to scale rapidly (as is often the case with venture-backed firms), managing people can easily consume your entire workday even at a relatively small size company.
Of course, I'm not saying that's everyone's experience. There are obviously lots of reasons that dynamic might be different: For example if you're not a VC-backed company, or a CTO who's a world-renowned technical expert in a particular field (nobody's bringing Ilya on board for his ability to hire).
But it's very, very easy for people management to be a day-to-day thing and I don't think it's a waste of time compared to direct contributions.
As a former "CTO" at a small company and an early stage employee at several others, hiring was a ton of work for everyone. It was honestly the hardest thing I had to do. However, it was by no means a constant, day-to-day thing.
More power to you - I easily spent weeks at a times sifting through resumes and interviewing, and even once someone was hired making sure they were onboarding well and feeling well-supported and etc.
By the time everything was humming along we were either raising a new round (and thus hiring more), or someone was leaving and we had to refill that role.
I think me mentioning a list of responsibilities sort of derailed the conversation a little bit.
It's not about them avoiding what they enjoy. It's about empowering and scaling a human organization to take on larger and larger scope over time. And at a technical company, the CTO is uniquely positioned to understand organizational scalability and technical scalability. So the risk I see with a CTO that focuses predominantly on coding is that they may be neglecting higher impact work that they could be doing that would set the organization up to empower more people to do the kind of work that they think is necessary.
The other risk I observed with a CTO that predominantly codes is that they become a bottleneck and are not actually able to ship the really experimental and product-altering features that they envision, and so they end up handing off essentially half-done ideas to teams who are then responsible for picking up the half-done mess and getting it to something that's suitable for production. I think this is probably avoidable in some way, but I do think it's an intrinsic risk of taking on large projects as a single coder while having other responsibilities to the company.
In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that.
This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.