Man, if I'm trying to decide which company to work for, and I see a blog post from its CTO crowing about regularly checking in code on Saturdays and Sundays, I'd start backing slowly away. And when I got to the bit that said "AI has made me three times as productive," I'd turn and run.
Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not working through the weekend. If you're doing it, your reports and their reports will feel the need to do it, too. Don't. And if you do anyway, certainly don't brag about it!
And then listen to this insanity:
> Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.
That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute, but, being above that process, you personally choose to circumvent it, foregoing required legal or engineering reviews, and shipping it immediately to your critically important customer? If one of the engineers who worked under you did that, you'd probably have fired him.
> That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well
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 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?
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.
Again, implies there is such a thing as a "list of CTO responsibilities". Companies can decide to give their CTO x or y portfolio, but by the time a company reaches the point where titles matter, it's hard to think of an intrinsically "CTO" responsibility that isn't covered by a VP/E or VP/PM. The one thing I can think of is "organization-wide architecture oversight", which is a pretty toxic role to assign.
In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM).
There's definitely an interesting article to write about the VP/E who still codes!
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
The role of CTO is more about accountability, responsibility and autonomy.
I try to minimize meetings to the minimum necessary to get everyone on the same page with what our next goal is. From there, I'm right there in the trenches with my team working to get these sprints done. sure, it sounds like a senior lead developer and if you're in a small startup, it kind of is. The CTO part comes in twofold, if the project is falling behind, its on me to figure out whats keeping us from hitting the dealing and resolving it. I've let people go who underperformed. Its also my job to see who's getting burned out and making sure they get some time off so that they can come back refreshed and ready to push again.
Ss far as promise of "equity," Im currnetly pretty happy that I maxed out equity at the beginning.
And if when you sat for a behavioral interview at a company of any size and they leveled you based on “scope” and “impact”, you would be leveled as a senior engineer or a team lead.
And the “two parts” of your responsibility were those of senior/lead devs at the last 60 person company I worked for in 2020.
Equity in private companies is statistically meaningless and will be worthless. I’m at a point in my career where I only care about cash and RSUs in public companies that I can easily sell when they vest
But yes, I've been a CTO with a zero reports and doing everything while working in a company with > 200 employs. And while revenue was fine %he payment was shit.
It’s mostly because tech titles have no meaning without context (not specifically a tech thing either but we seem to do it more than most).
One place I was a senior dev running two teams of 8-9 devs (as both a line manager and a day to day manager plus mentoring), another I was a “Head of Software Engineering”, there where only 9 devs in the business, did get a nice pay bump with the ridiculous title though so that was nice.
The senior managing two teams thing came about because there was one senior per team and when the pandemic hit the manufacturing dev teams senior just upped and quit, I took over temporarily and then the pandemic lasted longer than anyone expected, it was a lead role even with one team and frankly at least a couple on each team should have been seniors on ability and experience but it was a weird org that way.
People find it strange when I interview candidates, I don’t even look at resumes. I don’t need to. I ask questions to measure among other things the size and complexity of projects they were responsible for, the level of complexity, and what they actually accomplished.
If he came in and call himself a “CTO” and then he described his day to day work, that would be a red flag for me.
The article could also have been called something like “my job is to write code and I call myself CTO”. I don’t see a problem with that if it works for the org e.g. the business cofounder is CEO and the technical one is CTO and that’s the company.
It feels it bit disingenuous though to act like he’s breaking the mold and continuing to code when his day to day is higher level management stuff. It’s not quite the same as like Tobias Lutke still working on Ruby or something.
In their defence, I can see "no direct reports" perhaps referring more to the line managerial side than code responsibility.
However a few things stood out in this to me.
> So pushing new ideas is quite important because they require intentional, sustained effort. Between org structure, roadmap incentives, and limited risk budget, few engineers can take months to pursue ambiguous bets.
That's exactly the kind of thing a CTO should be fixing.
> A recent example: we kept talking about building an AI chat product for our customers. It was clearly valuable, but it felt like a daunting task, and no one on the team had the time and headspace to take it on given their existing commitments.
Why? It's one of the hottest tech trends. If you've got nobody who would jump on this given you're an AI company, did they have valid technical reservations?
If nobody had the space, why? You're a C-suite exec, saying something is clearly valuable, why can't you get someone to work on it for a few days?
This post is a job ad, but it screams of a disfunctional company to me. Why can't your other devs do this? Why do they not have the time or headspace? Why do they not have the safety of taking on ambiguous bets that the company itself thinks are sensible?
> Last month, we had a million dollar per year customer that came to us with a burning need: they needed full data redaction on one of our integrations for compliance reasons. Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day
There are two possible explanations (outside of "it's a lie"):
1. Your team has valid reasons that data redaction for compliance reasons isn't the sort of thing you should slap together in a day
2. You have massive customer need for features that take a day to ship and your company is so fucked it'll turn them into multi-departmental nightmare meetings for absolutely no reason
> We’re building AI-powered tools to transform customer support, and we need technical folks who aren’t afraid to get their hands dirty. If this sounds like your kind of environment, check out our open roles.
No thanks. Sounds like being CTO could be fun, coding-wise, and being a grunt elsewhere without the headspace or time to take on valuable tasks sounds pretty awful.
Broadly it sounds like someone else is the CTO and John gets the title because he's a cofounder and coding. But he's a software engineer. That's cool, enjoy that, you don't need to want to do larger scale strategy or anything else. But someone should do that job.
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.)
> 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.
It seems possible that most CTOs are in tiny startups, don't have reports and we don't know about them because, having no reports, they don't get a lot of visibility compared to someone at the top of a 10,000 person org chart.
But the article framing is still odd. If the CTO has no reports who is going to do the coding other than the CTO? The reason the CTO is coding is because, being CTO, they want technical things to happen. He can't farm it off to his reports because they don't exist. Case closed. The real question is why doesn't he feel hiring some people to code is a good idea. 1 highly capable report could probably +30%, 40% his productivity.
With no directs, even “principal” would be a stretch in any company of note. If he spends that much time “coding”, that barely qualifies as a “senior” at large tech companies.
Let me clarify. I know there are principals with no directs. I’m more calling out that the “scope” of a principal is a high bar at Big Tech and if he is spending all of his time coding at a startup, I doubt that he is working at the level of a principal at BigTech.
My own anecdote is that the level of work I was doing as an “architect” at a 60 person startup where I was the second technical hire when the new CTO was hired to bring tech leadership in house from a third party consulting company mapped to a mid level L5 consultant at AWS ProServe (to be fair I only had two and a half years of AWS experience at the time I was hired by AWS) and now while I’m a “Staff consultant” at a third party AWS consulting firm with around 1000 people, looking at the leveling guidelines and expectations at my current company, AWS and GCP, it maps to a “senior”
It's definitely not super uncommon where I'm at. CTOs, especially those that founded companies and are more technical doers than managers, that end up having responsibility for architecture and technical matters (tech lead deluxe), but no people (due to lack of people management and leadership skills/or desire for that kind of job - sometimes also product management skills at larger organizations).
CTO is usually the exec responsible for the entire tech org. The CTO reports to the CEO, and the top managers and maybe a few ICs in the tech org report to the CTO.
You're saying "usually" about something that has definitely not been a norm in my career. It seems like there's really only two ways to interpret that arrangement: either the CTO is in fact the EVP/E (fair enough! lots of CTOs are other exec roles with a funny hat), or the CTO has a single top-level manager report, in which case what really happened is that the org hired a pro to run engineering and put the "CTO" out to pasture.
Dotted line reporting is very different. In these instances the VP/E is usually directly interfacing with other executives as the CTO's peer. This is even more true when the budget is managed by the VP/E and the CTO is more customer/sales facing.
I've been at several companies that have a CTO and a Director of Engineering. The CTO sets the strategy, and the Director of Engineering handles the execution. In theory the Director "reports" to the CTO (I.e. is under in the org chart), but not necessarily. Sometimes the Director reports to the CEO, and/or takes a more collaborative role with the CTO.
This does not apply at my current company, where the CTO has their title as an artifact of how the founding team was structured, but if I was founder/early at a company, progressed to a senior role, and then was told that I should take a role where I "set engineering strategy", I would immediately conclude that I was being managed out. "Strategy", in particular, is the kiss of death.
Both in my own personal direct experience and in 15 years of consulting, primarily for tech startups, the modal CTO I encountered had in reality a product manager role with a special title that was helpful in important pre-sales meetings --- and they did not tend to be the de facto VP/PM.
I think CTO as "other, better-defined kind of exec, but with a funny hat" is a perfectly cromulent model. I think CTO as "PM that customers feel flattered to talk to" is another perfectly cromulent model. To me, "CTO" is almost an honorific, or like a title of nobility.
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 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?
“ how are you able to manage conflict between org builders and your technical vision?”
That for me, is the core of the issue. I have been in a few places where senior management (up to c level) still code and are critical parts of the project team.
The problem is who keeps them to schedules and co-ordination with the other people on the project. Hard to complain about team level issues if the failing person is also the boss of the technical staff.
Build a demo perhaps to illustrate the idea/vision but don’t code, focus on the high level management and direct the ICs to build out the production version.
Both roles (management and coding) are difficult, demanding positions to do well, deserving of respect and commitment.
>People assume CTOs who code are either working on pet projects that never ship or doing ceremonial code reviews.
people don't think that. people think CTOs who code may not be doing the leadership, managerial, or biz dev aspects of their job, or something like, why is he called CTO and not "engineer" or "architect" or "lead"?
I always have wondered a bit, do people in other fields have this, too? Like do people expect the CMO at a pharmaceutical company to still be running clinical trials or whatever to, I dunno, maintain their street cred? Or is it just tech companies where people seem to have existential angst about managers doing manager instead of "technical" work?
This is a series B company not an international pharmaceutical conglomerate. Perfectly reasonable for a CTO to participate in engineering work at this stage. I've experienced a few early companies where CTO just did meetings or that didn't have someone within the leadership team who dug into engineering at all and it wasn't pretty...
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
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.
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...
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?
Yes, usually they'd hire someone with a title of "vp of eng" or similar and have them do hr-mandated "people management". CTO is then freed up to do strategy and whatever else and he/she typically has the power to organize work outside of official reporting chain anyway. Not saying I'm a fan of this arrangement but it's pretty common and not the worst way to handle things.
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.
The amount of commentators that downright oppose and ridicule a CTO coding is why enshittification is so pervasive. If a CTO understands the codebase to the point where they can contribute to it, I presume that's a good thing. I sense so much fear of actual engineering and technology in the comments and it really highlights why startups are failing to innovate and create compelling products.
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.
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?
Man, if I'm trying to decide which company to work for, and I see a blog post from its CTO crowing about regularly checking in code on Saturdays and Sundays, I'd start backing slowly away. And when I got to the bit that said "AI has made me three times as productive," I'd turn and run.
Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not working through the weekend. If you're doing it, your reports and their reports will feel the need to do it, too. Don't. And if you do anyway, certainly don't brag about it!
And then listen to this insanity:
> Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.
That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute, but, being above that process, you personally choose to circumvent it, foregoing required legal or engineering reviews, and shipping it immediately to your critically important customer? If one of the engineers who worked under you did that, you'd probably have fired him.
Flabbergasted to say the least. Dude do your job. Fix the process. Don't set a bad example.
> That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well
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 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?
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.
Again, implies there is such a thing as a "list of CTO responsibilities". Companies can decide to give their CTO x or y portfolio, but by the time a company reaches the point where titles matter, it's hard to think of an intrinsically "CTO" responsibility that isn't covered by a VP/E or VP/PM. The one thing I can think of is "organization-wide architecture oversight", which is a pretty toxic role to assign.
In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM).
There's definitely an interesting article to write about the VP/E who still codes!
Exactly. Role and title are amorphous and depends on the industry, stage of the company, etc.
Look at this CEO who codes: https://github.com/lattner :-) (He was fund raising in July, August)
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
The role of CTO is more about accountability, responsibility and autonomy.
I try to minimize meetings to the minimum necessary to get everyone on the same page with what our next goal is. From there, I'm right there in the trenches with my team working to get these sprints done. sure, it sounds like a senior lead developer and if you're in a small startup, it kind of is. The CTO part comes in twofold, if the project is falling behind, its on me to figure out whats keeping us from hitting the dealing and resolving it. I've let people go who underperformed. Its also my job to see who's getting burned out and making sure they get some time off so that they can come back refreshed and ready to push again.
Ss far as promise of "equity," Im currnetly pretty happy that I maxed out equity at the beginning.
CTOs come in all shapes and forms
And if when you sat for a behavioral interview at a company of any size and they leveled you based on “scope” and “impact”, you would be leveled as a senior engineer or a team lead.
And the “two parts” of your responsibility were those of senior/lead devs at the last 60 person company I worked for in 2020.
Equity in private companies is statistically meaningless and will be worthless. I’m at a point in my career where I only care about cash and RSUs in public companies that I can easily sell when they vest
I'm a CTO that codes. I have zero reports.
We also have zero employees and relatively little revenue :-)
I think my role would indeed have to shift if we were to employ people and I don't like it, but I think you're not wrong.
The self burn is the best burn.
But yes, I've been a CTO with a zero reports and doing everything while working in a company with > 200 employs. And while revenue was fine %he payment was shit.
It’s mostly because tech titles have no meaning without context (not specifically a tech thing either but we seem to do it more than most).
One place I was a senior dev running two teams of 8-9 devs (as both a line manager and a day to day manager plus mentoring), another I was a “Head of Software Engineering”, there where only 9 devs in the business, did get a nice pay bump with the ridiculous title though so that was nice.
The senior managing two teams thing came about because there was one senior per team and when the pandemic hit the manufacturing dev teams senior just upped and quit, I took over temporarily and then the pandemic lasted longer than anyone expected, it was a lead role even with one team and frankly at least a couple on each team should have been seniors on ability and experience but it was a weird org that way.
People find it strange when I interview candidates, I don’t even look at resumes. I don’t need to. I ask questions to measure among other things the size and complexity of projects they were responsible for, the level of complexity, and what they actually accomplished.
If he came in and call himself a “CTO” and then he described his day to day work, that would be a red flag for me.
The article could also have been called something like “my job is to write code and I call myself CTO”. I don’t see a problem with that if it works for the org e.g. the business cofounder is CEO and the technical one is CTO and that’s the company.
It feels it bit disingenuous though to act like he’s breaking the mold and continuing to code when his day to day is higher level management stuff. It’s not quite the same as like Tobias Lutke still working on Ruby or something.
In their defence, I can see "no direct reports" perhaps referring more to the line managerial side than code responsibility.
However a few things stood out in this to me.
> So pushing new ideas is quite important because they require intentional, sustained effort. Between org structure, roadmap incentives, and limited risk budget, few engineers can take months to pursue ambiguous bets.
That's exactly the kind of thing a CTO should be fixing.
> A recent example: we kept talking about building an AI chat product for our customers. It was clearly valuable, but it felt like a daunting task, and no one on the team had the time and headspace to take it on given their existing commitments.
Why? It's one of the hottest tech trends. If you've got nobody who would jump on this given you're an AI company, did they have valid technical reservations?
If nobody had the space, why? You're a C-suite exec, saying something is clearly valuable, why can't you get someone to work on it for a few days?
This post is a job ad, but it screams of a disfunctional company to me. Why can't your other devs do this? Why do they not have the time or headspace? Why do they not have the safety of taking on ambiguous bets that the company itself thinks are sensible?
> Last month, we had a million dollar per year customer that came to us with a burning need: they needed full data redaction on one of our integrations for compliance reasons. Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day
There are two possible explanations (outside of "it's a lie"):
1. Your team has valid reasons that data redaction for compliance reasons isn't the sort of thing you should slap together in a day
2. You have massive customer need for features that take a day to ship and your company is so fucked it'll turn them into multi-departmental nightmare meetings for absolutely no reason
> We’re building AI-powered tools to transform customer support, and we need technical folks who aren’t afraid to get their hands dirty. If this sounds like your kind of environment, check out our open roles.
No thanks. Sounds like being CTO could be fun, coding-wise, and being a grunt elsewhere without the headspace or time to take on valuable tasks sounds pretty awful.
Broadly it sounds like someone else is the CTO and John gets the title because he's a cofounder and coding. But he's a software engineer. That's cool, enjoy that, you don't need to want to do larger scale strategy or anything else. But someone should do that job.
I think the linked https://blog.gregbrockman.com/figuring-out-the-cto-role-at-s... is much more interesting, it gives more actionable detail and advice.
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.)
> 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.
It seems possible that most CTOs are in tiny startups, don't have reports and we don't know about them because, having no reports, they don't get a lot of visibility compared to someone at the top of a 10,000 person org chart.
But the article framing is still odd. If the CTO has no reports who is going to do the coding other than the CTO? The reason the CTO is coding is because, being CTO, they want technical things to happen. He can't farm it off to his reports because they don't exist. Case closed. The real question is why doesn't he feel hiring some people to code is a good idea. 1 highly capable report could probably +30%, 40% his productivity.
With no directs, even “principal” would be a stretch in any company of note. If he spends that much time “coding”, that barely qualifies as a “senior” at large tech companies.
There are plenty of Principal Engineers (L8) at Google who have no reports. In fact, I think the majority have no reports.
Let me clarify. I know there are principals with no directs. I’m more calling out that the “scope” of a principal is a high bar at Big Tech and if he is spending all of his time coding at a startup, I doubt that he is working at the level of a principal at BigTech.
My own anecdote is that the level of work I was doing as an “architect” at a 60 person startup where I was the second technical hire when the new CTO was hired to bring tech leadership in house from a third party consulting company mapped to a mid level L5 consultant at AWS ProServe (to be fair I only had two and a half years of AWS experience at the time I was hired by AWS) and now while I’m a “Staff consultant” at a third party AWS consulting firm with around 1000 people, looking at the leveling guidelines and expectations at my current company, AWS and GCP, it maps to a “senior”
Yeah 60% coding 40% managing juniors is basically what senior dev has looked like me for the past few jobs, even at smaller (~15-30 employees) outfits
It's definitely not super uncommon where I'm at. CTOs, especially those that founded companies and are more technical doers than managers, that end up having responsibility for architecture and technical matters (tech lead deluxe), but no people (due to lack of people management and leadership skills/or desire for that kind of job - sometimes also product management skills at larger organizations).
Sounds more like a "distinguished engineer" ?
No it isn't. Lots of CTOs don't have reports.
I have a terribly hard time understanding the effectiveness of a CTO who has no reports, especially in a technology company.
What is it that you think a CTO does? There isn't a standard answer to this question.
CTO is usually the exec responsible for the entire tech org. The CTO reports to the CEO, and the top managers and maybe a few ICs in the tech org report to the CTO.
You're saying "usually" about something that has definitely not been a norm in my career. It seems like there's really only two ways to interpret that arrangement: either the CTO is in fact the EVP/E (fair enough! lots of CTOs are other exec roles with a funny hat), or the CTO has a single top-level manager report, in which case what really happened is that the org hired a pro to run engineering and put the "CTO" out to pasture.
It's very common to see a VP of Engineering managing the day-to-day operations while the CTO acts in a capacity like this.
I’ve seen that too, but then the VP of Engineering tends to report to the CTO, and not to- say, the CEO directly.
Dotted line reporting is very different. In these instances the VP/E is usually directly interfacing with other executives as the CTO's peer. This is even more true when the budget is managed by the VP/E and the CTO is more customer/sales facing.
really? like who?
I've been at several companies that have a CTO and a Director of Engineering. The CTO sets the strategy, and the Director of Engineering handles the execution. In theory the Director "reports" to the CTO (I.e. is under in the org chart), but not necessarily. Sometimes the Director reports to the CEO, and/or takes a more collaborative role with the CTO.
This does not apply at my current company, where the CTO has their title as an artifact of how the founding team was structured, but if I was founder/early at a company, progressed to a senior role, and then was told that I should take a role where I "set engineering strategy", I would immediately conclude that I was being managed out. "Strategy", in particular, is the kiss of death.
Both in my own personal direct experience and in 15 years of consulting, primarily for tech startups, the modal CTO I encountered had in reality a product manager role with a special title that was helpful in important pre-sales meetings --- and they did not tend to be the de facto VP/PM.
what's the most effective model you've seen?
I think CTO as "other, better-defined kind of exec, but with a funny hat" is a perfectly cromulent model. I think CTO as "PM that customers feel flattered to talk to" is another perfectly cromulent model. To me, "CTO" is almost an honorific, or like a title of nobility.
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 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?
“ how are you able to manage conflict between org builders and your technical vision?”
That for me, is the core of the issue. I have been in a few places where senior management (up to c level) still code and are critical parts of the project team.
The problem is who keeps them to schedules and co-ordination with the other people on the project. Hard to complain about team level issues if the failing person is also the boss of the technical staff.
Build a demo perhaps to illustrate the idea/vision but don’t code, focus on the high level management and direct the ICs to build out the production version.
Both roles (management and coding) are difficult, demanding positions to do well, deserving of respect and commitment.
Just my opinion after bad experiences.
If your job functions leave you time to code you probably shouldn't have the title of CTO.
A CTO with atrophied skills (or no hands-on technical skills in the first place) can be just as dangerous.
I like to code as a cat. Coding as a dog is ruffer though.
>People assume CTOs who code are either working on pet projects that never ship or doing ceremonial code reviews.
people don't think that. people think CTOs who code may not be doing the leadership, managerial, or biz dev aspects of their job, or something like, why is he called CTO and not "engineer" or "architect" or "lead"?
I always have wondered a bit, do people in other fields have this, too? Like do people expect the CMO at a pharmaceutical company to still be running clinical trials or whatever to, I dunno, maintain their street cred? Or is it just tech companies where people seem to have existential angst about managers doing manager instead of "technical" work?
This is a series B company not an international pharmaceutical conglomerate. Perfectly reasonable for a CTO to participate in engineering work at this stage. I've experienced a few early companies where CTO just did meetings or that didn't have someone within the leadership team who dug into engineering at all and it wasn't pretty...
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've always wondered: Why did we switch to "code" instead of "program"?
> 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
Very loose definition of a CTO.
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.
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...
If you don’t have direct reports, why are you “CTO” and not founding or principal engineer?
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?
Edit: relatedly - at what size do you need a cto?
It depends on what that founder wanted to do! Lots of founders code for the whole ride.
Is it common for a CTO to not have any direct reports?
Yes, usually they'd hire someone with a title of "vp of eng" or similar and have them do hr-mandated "people management". CTO is then freed up to do strategy and whatever else and he/she typically has the power to organize work outside of official reporting chain anyway. Not saying I'm a fan of this arrangement but it's pretty common and not the worst way to handle things.
Stopped reading at “CTO with no direct reports”. Chief of who?
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.
The amount of commentators that downright oppose and ridicule a CTO coding is why enshittification is so pervasive. If a CTO understands the codebase to the point where they can contribute to it, I presume that's a good thing. I sense so much fear of actual engineering and technology in the comments and it really highlights why startups are failing to innovate and create compelling products.
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.
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?
The backlash is really telling of how bad things have gotten when a Chief Technology Officer coding in a software startup is disqualifying.
I am the CTO of zero employees and I code all day.
It's amazing that this guy can deliver so much despite only typing with one hand.
This is just title inflation. If this is what you're doing, you're not a CTO or you're not doing your job properly.