You can be the chief officer of a 1 person organization, or a 100,000 organization. Or pick another dimension such as SLOC, number of projects/products, teams, DAU, etc.
CTO has a different meaning at different levels of scale.
With a headcount of around 250 employees, you can still work directly on implementation. But with a headcount of 100,000, it doesn't make sense.
I really appreciated this blog post, John, to know that you're doing what I've been doing without a guilty conscience.
I'm a VP eng/research at a startup and also feel like one of the few people apart from the founders who can push major technical initiatives by just doing it themselves, due to: business context, technical chops, architectural judgment, grit, and seniority to pull in cross-functional stakeholders to help out.
However, I have often questioned if it is correct that so few people in the org can do this and if I shouldn't be enabling others to do it themselves instead.
How have you been able to navigate not having any direct reports? Who does your engineering org report to and how are you able to manage conflict between org builders and your technical vision?
You have no direct reports. That’s the difference. You’re effectively the solo Fellow level engineer at the company, driving the largest tech decisions based on time spent in code; and you’re doing your job well by familiarizing yourself with all parts of the code, including areas that need bug fixes.
This is not the same as an SDM or Director or people with lots of reports. It’s mostly the “having reports” part that causes devs to reduce or stop coding, since managing and project leadership are whole jobs.
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.
Title inflation has been going on forever. For early stage companies, titles are mostly about perception and presentation, mostly for people outside the company.
I think this captures the technical track dual to CEO 'founder mode'. As cringeworthy as many found that term, it captures the plain truth that there are certain types of changes that only people at the top are (or at least feel) empowered to make in an organisation's structure or processes. A CTO can choose to ship substantial, opinionated pieces of software that wouldn't (at least quickly) emerge from lower level teams. Arguably the best way to communicate a radical design is working code. That said, I do think the degree to which a company can push down this sort of constitutional power is a good measure of long term organisational health.
> I currently manage no direct reports and ship a lot of code. Not in an “I dabble when I have free time in between meetings” way, but in an “I shipped multiple substantial features last quarter” way
Possibly unpopular, but this is an interesting topic, so I'll post my counterpoint.
The question is: what are you not doing that is in the list of CTO responsibilities because you're coding? One of the reasons stated why you do this is "because you enjoy it", and on the list of reasons you need to do it is there are only a handful of people in the org that can ship new product surface area. That's...concerning. That seems like the kind of thing the CTO would want to fix, but I don't think having the CTO be the one to ship that surface area is highest-leverage use of time. If I'm reading this right, it's essentially that "because of the virtue of my position and autonomy, I can work on experimental projects for months at a time, but I don't empower my teams to do the same."
I have direct experience with this sort of attitude at companies between 200-400 people, and the messaging from top brass was framed as "innovation cannot be democratized". After seeing it in action for several years, I think it's a poor model. CTOs are technical visionaries, but coding is not a high-leverage activity. Good startup CTOs need to change their role multiple times over the course of the life of a company, and failing to understand the profound impact you can have as a leader is a common pitfall, because it doesn't fit with what you enjoy, or often what you have experience with. In the case of Assembled, Crunchbase says between 100-250 employees. If you get more towards 500-1000, I would seriously recommend you re-evaluate your thinking on coding as CTO, at least to the degree you are today.
One technical question: do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? What happens when you don't have time to land the long-term experiment before you need to turn to the next concern? I ask these questions because they are the points where I've seen this system fail, and I'm curious if that has every been an issue for you.
> I currently manage no direct reports and ship a lot of code.
This is a wildly different status than almost all other people with this title.
I’m glad this person still likes coding, and they seem to be great at it, but this role doesn’t match up to the title. This doesn’t really matter until he wants to switch jobs and realizes near zero CTO positions outside of this one company will require few meetings and zero management. He’d have to change title to principal engineer or something but an article titled “Why I code as a Principal Engineer” doesn’t quite grab attention the same way.
My journey has been quite similar (just a few more years of "unhappy John") and this approach is now very close to what I practice. I do have a few reports and run the R&D leadership team, I delegate as much as I can to my directors. (Besides being hands on where the organization needs it, I still regard the other part of my job to keep our org accountable, engineers inspired, and keeping the big picture in.)
For people who doubt this, I recommend "How to Build a Car" by Adrian Newey (CTO of Redbull Racing).
But to be clear - if you do coding as CTO only because "only you can run certain projects," part of your job should be to fix that first. You will still have the easiest time doing it, but you should always have (many) others in position to run innovation projects, work with customers etc.
I have not read that book, but ordered it just now. Thanks for the recommendation.
I'm also a CTO, and the comment about 'delegation' is something I think is important. The decision of what and how to delegate is IMHO something that is easy to get wrong. It is hard to do right all the time.
It is easier the better your team is, so hiring people that are better/smarter than you is the first step. I like the concept that I can do the job of most of the people that work for me, but all of them can do it better. There are times where direct involvement is important - sometimes for big decisions but also sometimes for small ones that need something extra to make it across the line. I like what you said about "org accountable, engineers inspired, and keeping the big picture in". That is a good summary.
I worked with plenty of founders like this - they carry a C level title, but never stop being just an engineer or sales guy or designer.
That’s all fine when you have no employees - C titles are bullshit when it’s just two bros in a dorm - but it invariably hurts the company prospects as the team grows.
The common hack is hiring a “VP of Eng” to take care of the actual C-level work.
Mind you, there’s absolutely nothing wrong in wanting to be the guy who sits in a corner and codes. Just don’t call it “leadership” or “chief” anything, since you’re sitting in a role and not acting the part.
Question for people who have gone through the journey of being tech founders that have grown a company. At what size of org / engineering team would you expect the founder to not code at all anymore?
I have a hard time taking someone with the title of “CTO” seriously if they have no reports and have time to code instead of being concerned with strategy.
I’ve had a few “opportunities” to be a “CTO” that were really no more than a glorified, underpaid senior developer with the promise of “equity” that would probably be meaningless
Okay, I just have one main question and a follow up. Who is at the wheel of your tech and engineering strategy then? And is staying across everything to make good informed decisions in that space not enough to be a full time job by itself? I can understand some coding can be a good input for deciding strategy but not as described in the article.
At the time, our company had ~500 employees. The CTO would write code, and it would get merged almost immediately, he would brag about it in meetings. We would then quietly modify it to the point of it being unrecognizable.
Example: we talked about upgrading our scraper because it was getting blocked quite frequently. The CTO wrote a brand new one that was supposed to be much smarter than what we had in place. The only problem was, he wrote a python script. This was a php application. Yeah, it was merged, it never ran because, well it was python. We fixed some of the flaws in our scraper and reduced the block rate. The CTO saved the day...
I have a question to the CTOs here, honestly asking: How can you have your team work on cutting edge technology without understanding the technology by getting your hands dirty, open your terminal, tinker with the technology, look into it, play with it, try to get a grasp of it. How?
I don't think this is a really convincing argument: There are plenty of leaders who haven't "done the job" in decades, and we don't question that. It's incredibly common in professional sports, for example.
Mike McCarthy hasn't played a down of American football in 40 years, and never played at a very high level. But we don't question his ability to get others to perform complex motions.
As Brockman says, you need a very strong VP Eng to make this possible.
It’s an important milestone for the technical founder(s) to decide if they are going to hang up their spurs and become a manager/leader, or keep doing the technical work. (A common failure mode is trying to do both.)
98 comments
[ 4.2 ms ] story [ 71.2 ms ] threadCTO has a different meaning at different levels of scale.
With a headcount of around 250 employees, you can still work directly on implementation. But with a headcount of 100,000, it doesn't make sense.
I'm a VP eng/research at a startup and also feel like one of the few people apart from the founders who can push major technical initiatives by just doing it themselves, due to: business context, technical chops, architectural judgment, grit, and seniority to pull in cross-functional stakeholders to help out.
However, I have often questioned if it is correct that so few people in the org can do this and if I shouldn't be enabling others to do it themselves instead.
How have you been able to navigate not having any direct reports? Who does your engineering org report to and how are you able to manage conflict between org builders and your technical vision?
This is not the same as an SDM or Director or people with lots of reports. It’s mostly the “having reports” part that causes devs to reduce or stop coding, since managing and project leadership are whole jobs.
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.
Very loose definition of a CTO.
The question is: what are you not doing that is in the list of CTO responsibilities because you're coding? One of the reasons stated why you do this is "because you enjoy it", and on the list of reasons you need to do it is there are only a handful of people in the org that can ship new product surface area. That's...concerning. That seems like the kind of thing the CTO would want to fix, but I don't think having the CTO be the one to ship that surface area is highest-leverage use of time. If I'm reading this right, it's essentially that "because of the virtue of my position and autonomy, I can work on experimental projects for months at a time, but I don't empower my teams to do the same."
I have direct experience with this sort of attitude at companies between 200-400 people, and the messaging from top brass was framed as "innovation cannot be democratized". After seeing it in action for several years, I think it's a poor model. CTOs are technical visionaries, but coding is not a high-leverage activity. Good startup CTOs need to change their role multiple times over the course of the life of a company, and failing to understand the profound impact you can have as a leader is a common pitfall, because it doesn't fit with what you enjoy, or often what you have experience with. In the case of Assembled, Crunchbase says between 100-250 employees. If you get more towards 500-1000, I would seriously recommend you re-evaluate your thinking on coding as CTO, at least to the degree you are today.
One technical question: do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? What happens when you don't have time to land the long-term experiment before you need to turn to the next concern? I ask these questions because they are the points where I've seen this system fail, and I'm curious if that has every been an issue for you.
This is a wildly different status than almost all other people with this title.
I’m glad this person still likes coding, and they seem to be great at it, but this role doesn’t match up to the title. This doesn’t really matter until he wants to switch jobs and realizes near zero CTO positions outside of this one company will require few meetings and zero management. He’d have to change title to principal engineer or something but an article titled “Why I code as a Principal Engineer” doesn’t quite grab attention the same way.
For people who doubt this, I recommend "How to Build a Car" by Adrian Newey (CTO of Redbull Racing).
But to be clear - if you do coding as CTO only because "only you can run certain projects," part of your job should be to fix that first. You will still have the easiest time doing it, but you should always have (many) others in position to run innovation projects, work with customers etc.
I'm also a CTO, and the comment about 'delegation' is something I think is important. The decision of what and how to delegate is IMHO something that is easy to get wrong. It is hard to do right all the time.
It is easier the better your team is, so hiring people that are better/smarter than you is the first step. I like the concept that I can do the job of most of the people that work for me, but all of them can do it better. There are times where direct involvement is important - sometimes for big decisions but also sometimes for small ones that need something extra to make it across the line. I like what you said about "org accountable, engineers inspired, and keeping the big picture in". That is a good summary.
That’s all fine when you have no employees - C titles are bullshit when it’s just two bros in a dorm - but it invariably hurts the company prospects as the team grows.
The common hack is hiring a “VP of Eng” to take care of the actual C-level work.
Mind you, there’s absolutely nothing wrong in wanting to be the guy who sits in a corner and codes. Just don’t call it “leadership” or “chief” anything, since you’re sitting in a role and not acting the part.
Edit: relatedly - at what size do you need a cto?
I’ve had a few “opportunities” to be a “CTO” that were really no more than a glorified, underpaid senior developer with the promise of “equity” that would probably be meaningless
Example: we talked about upgrading our scraper because it was getting blocked quite frequently. The CTO wrote a brand new one that was supposed to be much smarter than what we had in place. The only problem was, he wrote a python script. This was a php application. Yeah, it was merged, it never ran because, well it was python. We fixed some of the flaws in our scraper and reduced the block rate. The CTO saved the day...
Mike McCarthy hasn't played a down of American football in 40 years, and never played at a very high level. But we don't question his ability to get others to perform complex motions.
As Brockman says, you need a very strong VP Eng to make this possible.
It’s an important milestone for the technical founder(s) to decide if they are going to hang up their spurs and become a manager/leader, or keep doing the technical work. (A common failure mode is trying to do both.)