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.
> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie.
This bit got me. It's a direct quote from the linked post for those who haven't read it
(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.
My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.
I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.
In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).
I'm glad you are comfortable coming forward and for sharing your thoughts. Not to pile on with the others here but you may go fast alone but you go far together when you build the right team. Being an individual contributor CTO is not being a CTO for a business that succeeds at scale. Don't stop doing what you love if you feel that's more important but it's probably best to step back from being a CTO and hire someone to manage that role so you can code if you don't want to do the job.
This can work, imho, IFF the organization has both a CTO and CIO (or someone else tasked with managing the org). I've seen lots of places where the CTO is purely the technical visionary/advisor/final decision maker, and doesn't directly manage the technical organization.
This scenario is far more common outside of the tech industry, where you usually have a CIO running the IT cost center, and a CTO making decisions about technology adoption strategy.
The technical capacity of a CTO matters less then the CTOs ability to stay in their lane (for a lack of a better term).
I once worked for a company with a self taught CTO (and not the good kind). They had a number of star players, and this CTO would frequently lash out at them. All because he was getting in the way of them doing their jobs, doing work he wasn't qualified to do, trying forcing them to clean up after him, and then yelling at them for it. It was insanely toxic. I only lasted a few months. It was so bad I back channelled patches and project briefs to people he liked to get them approved.
Had this CTO remained people, project and product focused everything would have been fine.
Self taught in the programming sense, or the people management sense? Because I feel like the letter is much more common than not in software. Just curious in case there's an expected background you're thinking of when you say that. I have no point of reference for CTO backgrounds beyond generic MBAs or senior devs that either gave themselves the titles as founders or failed upwards.
> this CTO would frequently lash out at them [...] doing work he wasn't qualified to do, trying forcing them to clean up after him [...] and then yelling at them for it
Was that a Fintech in Germany, by any chance? :)
I once witnessed a meeting between a CTO and a Tech Lead. The CTO was attending from his laptop in an open office, and he was yelling in Russian for one hour straight at another Tech Lead because he wanted the tech lead to finish his work. It was a pathetic display, with the whole company watching and wondering what was going on.
Eventually he was "phased out" by having a few people promoted to VP of engineering who would deal directly with the CEO instead of him.
Last I heard he tried to rewrite the financial core in Golang by himself, but he failed since nobody wanted to work together with him and he doesn't really knew the language.
CTO, CIO, and the head of engineering (the latter of which can often be split among different groups) are often very distinct things, especially at larger companies. And, yes, while the CTO probably has a seat at the table for technology direction is often primarily a public technology face of the company as opposed to someone involved in a lot of hands-on day to day technology implementation.
“Probably has a seat at the table for technology direction” is a wild take to me. So much so that I can’t even formulate a response other than “what…?!”
I'm not sure what you find confusing. Someone can have an advisory and essentially technology evangelist role without necessarily being the ultimate decision maker. (And, at a larger company, a variety of folks--including the board--will ultimately make final consequential decisions.)
In most companies I've been a part off, including multiple >$1B tech companies, the CTO's focus is not on the engineering. That's the job of a VP Engineering or some similar position.
CTO (which will sometimes have a "CTO office") is to work besides the engineering on investigating new technologies and ideas that are beyond what the engineering organization would have otherwise done on the day to day. They are also an authority on all technology in the company but are not in the engineering "chain of command".
That said this is not universal, there are organizations where the CTO does lead the engineering organization. I think that's sub-optimal because there is always going to be tension between the day to day and the broader scope and those should be different roles.
In a startup, it is more common for a CTO to lead engineering because there is not yet enough to justify having both a VP Eng and a CTO and perhaps most of the work is around figuring out technologies. But as the company grows it makes sense to separate those functions.
This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.
When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.
As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.
I've seen both. A CTO office that also leads engineering--typically via a direct report to the CTO--and an organization where the CTO is largely an external evangelist (typically with a small staff) while engineering is a separate organization--though hopefully aligned. The view here where CTO is also the head of day-to-day engineering operations and technical vision is more of a small company/startup thing. The two are often separated to at least some degree at larger operations.
There is a big leap between them not being the sole person responsible for technical decisions and them not even necessarily having a seat at the table for technology direction. The former is understandable. Later - quite surprising.
I'm not sure what I wrote that's contrary to any of that? Maybe I shouldn't have used the word "probably"? There are a lot of people responsible for the technical direction of a large company of which the CTO is important but hardly the only one.
He mentions he has nobody reporting to him. That sounds like he’s really a staff engineer with a vanity CTO title, plus a lot of sway in strategic decision making.
It’s not a guaranteed recipe for disaster, but it depends critically on his relationship with whoever actually manages the engineering org. If they don’t pull in the same direction, things go south very quickly and you end up with a little civil war.
Either way it’s a red flag and I wouldn’t work there. Another red flag is that he wrote this blog post at all. Given how clearly negative the reaction to it was going to be, it’s a strong signal he doesn’t really think things through and has a ego wrapped up in his “coding” prowess and ability to circumvent process. People mention Woz as an example of a technical co-founder in a non-management role, but he is a humble guy and wouldn’t brag like this.
LinkedIn suggests "50-200". 54 work in San Francisco, and 154 people are associated with it. So probably closer to 150, but that includes a lot of Sales and Marketing related roles. Maybe the "engineering" org is ~100 or just under that.
FWIW Carmack did this as CTO of Oculus [0]. Another configuration I've seen is for the CTO to have like 1 direct (VP Eng) who does actual eng managing. You could argue it's a staff engineer role but I've never seen staff engineers actually get much say over org direction/structure or be empowered to break gridlock like this.
It's not that uncommon to keep the "CTO" title and not be the primary manager of the engineering organization. There are all kinds of things you can do with the org chart. If I recall correctly, Clickhouse works this way.
The company's cofounders comprise three people [1]:
* Aaron, a sales-oriented CEO from Elastic and Salesforce
* Alexey, the original Clickhouse developer, as CTO
* Yury, an experienced engineering executive from Google/Netflix as "President"
An excerpt from the launch announcement [2]:
> While negotiations were still ongoing, Katz decided they needed a third co-founder. “I kept thinking, if I could get a third co-founder to run product and engineering, and if I could find someone with the same level of experience building distributed systems on open-source that I have on go-to-market, it could be a really compelling combination,” Katz says.
I'm not that familiar with his employment history; you could be right. Either way, he'd still be an example. If you have longer term ones, I'm sure it would add to the discussion
I recall James Goodnight of SAS coding while being a CEO. As per https://www.forbes.com/sites/peterhigh/2014/05/12/an-intervi..., he still programs from time to time but doesn't have a specific part in development. In looking at the articles to refresh my memory, it is clear he is one of the good CEO's
> 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
You need to exercise your god given right to mog goons below you.
Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.
God forbid you'd actually have to do any real work when there's so many design, retro, and daily sync meetings to attend and so many jira issues to groom.
Only indirectly (through management) and still having control is exactly my point. Obviously if you need to do that over and over there’re some other actions need to be taken
Ive worked on both ends of the spectrum and id prefer too much process to too little
With too little process, people release bugs that I then have to scramble to fix. The CEO who pushed to skip QA and unit testing and everything in the name of release never has to deal with the consequences of their impatience
That same CEO would likely also push to have all of the things including no bugs, then complain people aren't productive enough when arbitrary and unrealistic deadlines aren't met.
Source: my personal experience. Very few of the managers who can code that I've worked with were better than any of the ones who couldn't, and those who did actively code while managing were universally worse.
Trouble is, I don't think they'll just get it and then set about to changing the processes. Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.
Unless you're at a very small company, CTOs set technical vision, choose high level tooling strategy and outline engineering culture in broad strokes, but the nitty gritty of process will be from an engineering director or other role below the CTO. The CTO will probably provide feedback if needed, but they're not in the weeds and won't be able to see problems unless they're raised.
You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so.
I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.
Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.
> If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok.
If the CTO has rank then why not work to solve the unresponsiveness or undesirable things?
If someone--even a founder--can act as a loose cannon then there is a risk that they'll introduce problems like instability, security vulnerabilities, or unnecessary conflict or resentment. Compliance programs like SOC and PCI don't look fondly on staff bypassing SDLC processes because of those risks.
That’s not a role that I’d normally associate with “Chief” anything (which, by definition, means direct reports). More like Principal Engineer, or Architect.
In smaller companies, this is probably fairly normal, but you can’t maintain this, as the company grows.
I had a similar path, in my career. I originally started as a regular engineer, in a two-person team, and eventually ended up managing a small team of up to ten engineers.
Towards the end, I couldn’t write any code (for the company), at all. I still needed to code, but did so, for volunteer/open-source stuff. I think it made me a better technical leader (I had an employment contract without a clause that interfered with outside coding).
I remember wanting to take an iOS training course, but the company wouldn’t support it, so I took vacation, and went on my own dime. I never regretted it, but it was discouraging.
The happy medium that the CTO did at the company where I worked where I was the architect guiding the technical direction, he would do non production level experimental coding as research - integrations with third party APIs, see if an AWS service was suitable - to take some of the load off of me hand the code over to me and I cleaned it up and made it production ready and championed it to the rest of the teams.
He still helped accelerate efforts, got his coding fix when he had time, wasn’t in the critical path of any work, and he made the entire org better.
(Author here): I hear what you’re saying, though I’ve never “crowed about regularly checking code in on Saturdays and Sundays” and I think that’s a false characterization of my article.
Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.
And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.
he's also casually trashing their engineering team... "I built it in a day" is suggesting no one else could have.
I personally don't think there's anything wrong with doing it (i.e. shipping a feature quickly that a customer needs), but writing a blog post about it is questionable.
No, he clearly points that anyone else would have to be taken off their existing work and would have to context-switch to the context he already has. That's not trashing his engineering team.
I code as a founder/CTO on weekends, I don't expect weekend work done by anyone else and most people rarely check in if ever on weekends.
The job profile of founder-CTO has not a lot of overlap with that of an individual contributor to be leading by example, the overlap is quite narrow even for senior engineering leadership.
Until recently[3] leaders with prior coding skills were always discouraged from code contributions and focus on management exclusively, for all the reasons some of them you describe.
--
I usually say that I am a part-time coder, not a professional one, and caution not to look at what I do as a benchmark or signal.
Vast majority of the code I write are DevEx or QoL for internal teams[4], or refactor tech debt that no one has time to deal with. Even mid-stage startups may not be large enough to invest in dedicated teams for this type of work.
Occasionally I have written such integrations like OP[1]. It is typically a PoC for a demo, never a production one to actual customers. It would be unfair (and failure prone) to expect anyone else to start supporting a production integration without the full tooling or documentation.
--
I agree it is a fine-line and you can err on the wrong side of it. It is easy and tempting to start focusing on production code and lose focus of the core job, but so many decisions as a founder are like that. I am hardly the best or optimal founder-CTO. However the value of being close to the metal is important and worth some risk in early to mid stage startups.
Perhaps there is also value in a CTO who understands what individual contributors are doing and is able to be more realistic about outcomes instead of being purely few layers above and not clued in.
--
[1] Not skipping legal that seems ridiculous, even if I wanted to, I can't imagine any partner would agree to it.
[3] Now I do encourage to try the new tools, it is not they contribute to production or be an IC, it is to get a sense of what is possible and what is not today. A lot of pipe-dreams are being sold in the industry, without hands on experience using the new tools ( which are rapidly evolving) managers can tend to overestimate or misunderstand what is doable.
[4]This is the core of the CTO job, writing code is rarely the bottleneck for productivity that was true even before generative coding tools, it is everything around that which creates friction. If you can reduce it, even writing some code to do so, it shouldn't be a problem or a flag.
If you want to work on the weekend - and occasionally I find myself doing so as a staff level IC consultant who does need to spend an inordinate amount of time mentoring, project management, suppprting sales, interviewing candidates, babysitting clients, etc… - don’t send messages on Slack or email outside of business hours. I schedule messages to go out Monday morning and I never mention I worked on the weekend.
I don’t want to set the expectation that people should work outside of business hours or that I’m willing to.
That’s the point — I and others would have the opposite reaction, it’s self selecting, so it’s doing its job. I didn’t even read the article because I thought “boring, nothing special about a CTO who codes, we all do.”
In that story, we don’t know why legal would need to be involved. Maybe it’s for a good and essential reason or maybe it’s for a sand-in-the-gears reason.
Maybe the CTO’s company uses GPLv3 or AGPL software and the customer’s legal department vomits all over AGPL and demands extensive review for GPLv3 for their developers. Or maybe they’re worried about later finger-pointing and support issues. Or ensuring the company is running on unmodified, mainline sources.
Those would all be reasons why the CTO’s company could ship without involving customer legal teams without it being a red flag to me.
Calling this guy a CTO is a stretch. He's a senior developer at a company with no CTO.
If you wanted to work yourself into a CTO position, his shop might not be a terrible choice, although I would imagine it would be a bit rough at first.
It seems like you're confusing technical founder CTO at a startup with professional CTO at a large org.
For the later, what you said makes some sense, and it definitely seems like you're more familiar with this archetype.
For the former, the article appears correct. If you've not worked at an early stage startup before, the culture is _very_ different.
As a side note: This article is doing it's job. People that are a good fit for the company will agree, and want to work with them. People that are not a good fit for the company will not agree, and naturally run the other way. Makes filtering out candidates easier.
At an early stage startup, shipping a feature should not require "many meetings across product, legal, and engineering". Especially not one that can be mostly built in a day.
> An engineer unfamiliar with that part of the codebase would spend quite a lot of time figuring out those details.
Your job is to delegate, yes, the first delegation is hard, but the engineer either grows, or doesn't (then you need to move or yeet).
Yes I understand that you want to code all the time, then you're not a CTO. A CTO leads from the front, leads with process, and context. Your job is to provide context so that your team can execute.
Agree. Let me say much the same through a parallel line of observation: maybe you dont need a this cto or any cto? Maybe you need to move this guy to sales.
Goodness gracious corporate america. Can we PLEASE stop with hustle and bs?
You ever heard buffet or munger say everyday they do some bill keeping in a double entry accounting system and AI makes them better? Never. Why? Because when you and your org are competent you're not constantly on the hussle. My guess if they need to, they do and as they have things on their mind they don't have time to blog about.
People know what management at Berkshire Hathaway stands for. Case closed.
Competent upper management can be a boon for orgs esp on cross functional management which builds the org and keeps ia from infighting and running in 10x different directions. This guy isn't that. Moreover that means other people on the board don't know that either.
Thank you for sharing this. The part about Warren Buffett and the contrast with hustle culture is particularly delightful. It highlights the importance of competence and meaningful leadership over performative busyness.
What’s your gripe with the part about the AI productivity boost? For anyone working in fairly standard web dev tech, I’d say it’s more of a red flag if a boss denies the productivity boost of these tools (at least when used by senior devs)
> Your job at the top is, more than anything else, pushing down a healthy culture.
The CTOs role leading the tech folk to support business goals, which culture a part of. The healthy part is a subjective thing.
I took that a step farther and got written into our SOX compliance processes explicit “deviate from normal processes as much as required when this short list of people declare an emergency”, shamelessly cribbed from aviation law.
I fondly remember times when at one company CTO was doing round the dev section at 4:50pm and saying everyone close their machines. Go home or to pub, it's an order.
Once I sent an email at 5:45pm as I forgot to say something earlier about the project. I didn't get a response and in the morning got told off that I should never send an email outside of working hours, unless it is a personal matter that cannot wait.
Couple of years later the owners exited and new management replaced everyone with workers from consultancy of theirs. Company no longer exists.
Frankly if you’re a CTO you aren’t incentivized by a salary. It makes sense in this case no different than you’d code on the weekends for your side hustle.
It only doesn’t make sense when this jackass thinks the salaried engineer needs this “grit”.
C-levels aren’t supposed to be “model employees”. The incentive structure is wildly weighted in their favor. Instead you should ask them to understand the difference, which is asking a lot of these sociopaths, but I digress.
Complete nonsense. The free market will tell him if he can do this or not. If he can get valid candidates pushing this culture and it’s legal, why shouldn’t he? You, anyone interviewing there or anyone working at their company presumably doesn’t have to work there. Most countries don’t have slavery for tech jobs!
No doubt he will lose many candidates with this culture (you and I included) but maybe that’s a strategy? Maybe he still gets plenty of candidates that are good and the culture he wants.
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.
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!
> The one thing I can think of is “organization-wide architecture oversight”, which is a pretty toxic role to assign.
I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches.
Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
Think about what it says, in a larger team staffed with competent technical talent, to have a single person across all of it reconciling decisions with their own personal mental model. I think it's an attractive idea for a lot of aspirants! Who wouldn't want to be President of Code? But ambiguity is resolved by practitioners at the sharp end of the system.
I see, and I agree completely. I don’t see the CTO as having that role, but you’re right I guess some people do. That’s one reason it makes sense to at least try to put some definition to the role, isn’t it? To help people realize it’s not a technical role, but a people/organizational role that generally only large organizations need…
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.
> 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"?
I liked your take and curious to know what you think a CTO should be doing here
Generally, I don't advocate for code getting thrown over the fence, regardless of the dynamics associated with the particular exchange. So the ideal approach here would be for the CTO to partner with a trusted engineer with some leadership capacity (tech lead, staff, etc.) and work through the architecture design and technical specifications for the project and get it off the ground and then hand that off to the tech lead that they partnered with so that they could carry it over the line, possibly with a team. Understanding the vision behind the project and why the CTO thought it was valuable is a critical aspect here. It turns what would otherwise be a low leverage project, mostly involving architecture and coding, into a much higher leverage project that's focused on educating and empowering other leaders in the organization. It also allows the CTO to stay close to the technical foundations and code so they don't lose touch with the organization that they're leading.
He's probably right that no-one else can do what he can, because competent Devs aren't going to work for a company that operates like this.
If you have to build something because "Devs are too busy working on other things", then you're just bad at prioritising tasks.
If your team "can't do what I can" then you're bad at hiring.
I don't mind if a CTO works on a bug ticket, but make it part of the usual process, not hero driven development. Otherwise, what's even the point of having a process in the first place?!
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
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.
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
> How do you concern about strategy all day? Just sit down and think about it?
I'm not OP, but whenever your product is implemented by more than one team you will also have the need to coordinate and set strategic goals as well as accompany and steer each team towards where it's infrastructure/tech stack/systems architecture need to be.
If you do not offer guidance and determine technical directions, each engineer working in each team will happily fill the void and do their best to scratch their itch at the expense of the whole company becoming an unmaintainable big ball of mud.
Let's put things differently: what do you expect will be the output of a company if no one is responsible for things like directing the company's R&D effort, coordinate and specify the company's tech roadmap, even oversee product development.
This is an interesting question - I am a CTO at >1B tech company and there is no doubt that part of my role is exactly this - Technology Strategy.
How do I do it?
(1) It is my job to be familiar with a wide range of technologies, which might include tech stacks, but us mostly tech offerings. The tech offerings means lots of meetings with companies that build tech that we might use. Some of those are useful, most are painful.
(2) Actually using technology - IMHO - This is one of the most important aspects of the CTO job. I code all the time, but not for any of our products or operations. I code to learn so I can help make better decisions. We use Kafka for instance, and when we first started using it I built a cluster in my homelab so I had a better idea how it worked. The same with Hadoop, Cassendra, and a few different flavors of Kubernetes. The T in CTO is for 'technology', but it really should be for 'technical'.
(3) Perhaps the single most important thing - I try to hire people that are much smarter than I am, always. The amount I learn from people that are smarter/faster/better is many orders or magnitude greater and more valuable than the reverse.
(4) All the rest of the CTO job needs to support this - so budgeting, head count plans, spending strategy, patents and IP, roadmaps, decisions, etc. All of these details have to roll up and hopefully support a strategy.
you read gartner's publication and blindly ask AI to copy paste that info in a memo or powerpoint to pass it on to the middle management without trying to figure out if it makes sense.
At least that is how it looks from the engineers perspective.
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.
> 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?
As a leader, especially a CxO, the most important job they have is the allocation of resources. It was clearly NOT valuable if they couldn't apply any developer time towards it.
Exactly. The best reading is that they wasted their own time on it. The worst case is that a simple clearly valuable thing is something the company is incapable of doing. Both are dysfunctional.
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.
> Between org structure, roadmap incentives, and limited risk budget, few engineers can take months to pursue ambiguous bets.
> I can.
It's weird to hear a company executive say essentially "this work is important, but our company has too much bureaucracy and risk aversion for a regular IC to spend time working on this, so I just do it myself." Like, maybe that means you should actually be spending your time removing those roadblocks, instead?
It's no wonder why small companies innovate more than large companies. What is a wonder is, why many small companies intentionally make themselves more like large companies and lose their innovative spark as a result.
> PR reviews for your commits may not be honest [...]
True. That's already something I struggle being the most senior in my team. It is hard to find reviewer for my commits who dare to actually reject my code.
This is such an interesting comment thread because people have such wildly different opinions and from my perspective the entire disagreement just comes from company size.
I am a "CTO" and I always put that in air quotes because I have one direct report and I spend the lion's share of my time doing IC work. I know what I do is not what people picture when they hear the title and I feel weird saying it. I use it because I do have to make the strategic technical decisions, there is no one else. When people are marketing technical B2B SaaS I am the one they are looking for.
From my perspective there just isn't nearly enough for me to do as a CTO to justify me not coding. If I were to hire someone just to manage them that would be an unjustifiable expense at this point. But I also get that as soon as we get to a reasonable size this would be totally unsustainable.
This sounds like myself as well. We are a small dev team of 6 (in a company of 30), however I also have a partial ownership stake in the company. Even though I spend a significant part of my time on "CTO" style work (client meetings, market assessments, product overviews, roadmap planning, third party collaboration, etc.) there also isn't near enough of that to fill my time or justify my salary. I code and review like my team does, but I also oversee technical direction for our whole portfolio and the responsibility for that technical success or failure rests on me. As we grow the coding will decrease I'm sure, but I see a lot of people here criticizing from a perspective of larger companies where a CTO would be a full time responsibility. In our situation the title (as much as I often dislike it) represents my level of responsibility, if not directly the full scope of my role.
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.
From your point of view, what's the approach taken by someone who rose to the rank? Is it mostly people and process management and less to do with tech?
Please, do not. Nobody will do a real code review for such a person. Nobody will start a discussion if this or that change makes sense. If you have managerial position stick to it and do not make other people's lives miserable
Depends a lot on the culture. I used to work for a small team of about 10-15 engineers and the CTO was a good person. He would write code about as much as the rest of us. He was just the leader, engi 0. So we treated his code reviews similarly. It was actually nice giving him review because asking questions would be met with more business context and would be a good way to learn about the development process.
Any good engineer will be grateful you find issues in their work, especially if you help track down solutions.
Of course, the CTO depending on AI to solve things may be less like that, IDK. Or even before AI I knew the type. I once gave a new CTO a whitepaper to read in private to understand some of the direction I was taking a project, and he basically flipped out. So YMMV.
> 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.
Most of those engineers, outside of ones who have extremely specialized knowledge or skills, are essentially managing others still just without a direct reporting chain.
The commit log for most of these high-level engineers is extremely sparse. They're spending most of their time writing documents or influencing orgs, not writing code.
Yes. I was responding to the sentence "With no directs, even “principal” would be a stretch in any company of note." which talked about direct 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”
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).
Not much is worse than working somewhere that a higher up is squatting a job title that they don't want to do. It just causes a dysfunctional lord of the flies situation where lower people fight for the reigns to get what they want.
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.
I was CTO of a <20 person startup. I recruited the entire tech team, collaborated with the CEO to build the product backlog and spec things out, presented to investors, but also had at least 50% time to code. Not all “CTO” roles are the same. At a small company they better be hands on.
I think a founder/early gets away with "CTO" on their resume, esp. if they're the only person in the org with the role (ie: it's a PM-style CTO, and there isn't a VP/PM; or: it's a VP/E-style CTO, and there isn't a VP/E). But outside that circumstance, given the choice, I'd rather have the VP/PM or VP/E role than "CTO".
(As we get deeper into these threads I am further out on a limb.)
Yes, I was one of the first hires. My role was closer to VP/E and "CTO" was mostly vanity, a reward for being early and getting a new company through the first couple years.
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.
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.
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.
Exactly. Most CTO's have tens if not hundreds of direct reports that rely on them regularly. Which is why their time must be used to support them leaving absolutely 0 time to do PR code contributions on the side (unless you work weekends).
Most comments here are assuming that there’s only “one, true CTO” role when in fact the role is essentially “everything that’s left over after you’ve delegated to others”.
> When I was figuring out my role as CTO, I read Greg Brockman’s blog post about defining the CTO role at Stripe. He talked to a bunch of other CTOs and realized there’s enormous variance in what the role looks like. Some CTOs are technical visionaries, some are org builders, some are infrastructure-focused. The commonality is that great CTOs figure out where they can create the most value given their particular skills, interests, and company context.
> For me, that’s meant writing a lot of code. It works because of my particular context: I enjoy building software more than org design, I have deep customer and codebase knowledge that makes me particularly effective, and we’ve hired strong engineering managers.
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 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.
I appreciated the sentiment but I do wonder how on earth a CTO has enough time to write one line of code, let along several thousands. Even before reaching the C-suite roles, higher ups tend to be in meetings all day, back to back. In the short amount of non-meeting time they find, they typically have to do other admin related things or information sharing.
I guess that CTO uses weekends or works super long hours which I is fine if they don't push that expectation onto others.
I'd only really expect a CTO in an early stage startup to be pushing code like this (and eventually stepping back when they grow).
While I think CTOs should take steps back from pushing to production systems because there's a lot of I dotting and T crossing that needs to happen with production systems that CTOs don't reasonably have time for, if a CTO wasn't writing experiments and building test systems to determine technical direction, or at least getting their hands dirty with said systems produced by their top principles, I wouldn't trust their judgment to set direction.
The last time I worked for a product company was 2020. I was the second technical hire by a then new CTO of a growing company started by a two non technical brothers who hired an outside consulting company to do all of the work.
When the company found product market fit, they hired the CTO to bring the technology leadership in house. Early on he would do experimental POC work that he passed on to me to make it a working system as I was swamped doing my own architectural herding cats work as the company was growing.
But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team.
I’ve been working full time for consulting departments/companies since mid 2020. My goal on any project I’m on with more junior people is to development them. I purposefully give them ambiguous technical requirements with broad guardrails so they have the autonomy to learn and grow and then help them when needed and I put them in front of the customer early on to I present their “workstream”.
From a hands on keyboard side, I let them pick what they want to work on first and I take the left overs.
"But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team."
That is a good summary of the progression of a successful CTO. The capabilities of the team is a summation operations, not a selection operation.
This might be best said as you want your CTO to be ABLE to build and operate your products, but not actually do it.
I like to say that my job as a CTO is to be able to do the job of most the people that work for me, but most of the people that work for me are much much better at it.
It was hard to tell if he means he doesn’t do meetings at all, though it’s kind of implied. There are lots of high leverage activities around advocating for engineering’s perspectives among the other executives and bringing the business context to engineering, both of which don’t involve directly managing reports.
But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones.
It seems like this sentiment relates closely to the ideas around dual track career progression, and having technical leadership tied to hiring and managing people. Hiring engineering talent is certainly important to the company, but is quite orthogonal to technical decision making and it seems like a natural place to split the role.
"But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones."
The distinction might be something more subtle - I think s good CTO should maintain a deep technical skill, but should do so without putting the technology of the company in jeopardy. I write code, and am a CTO, but I don't write code for our products. I write code in order to continue to develop and maintain deep technical skill. I also manage our technical operations, so I make an effort to a good understanding of the technical areas that are needed to operate - networking, device configuration, IP, etc. In a pinch I am fully capable of making a configuration change to a Cisco switch or a Palo Alto firewall, but in practice I have a team of people that are much better at those tasks. That allows delegation and understanding.
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.
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...
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.
Lots of naysaying this, and I don't necessarily disagree with the general skepticism, but there's something I learned in Military Science class in college that I found interesting: in the U.S. marines, every marine from generals to janitors is rated and trained as a capable combat marksman with a rifle regardless of their specialization.
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.
This is not really a good analogy. Tech is different.
I am not saying you should sit down and write code. But in IT you know the difference between a tech lead who knows technology, who knows what works, for what reason. And the one that just demands results but knows nothing about the details of the technology. Has never gotten his hands on it.
> This is not really a good analogy. Tech is different.
Why? Seriously: Give me a convincing reason why tech is different from every other field, where this happens regularly.
> I am not saying you should sit down and write code.
But that's the whole premise of this conversation. It's entirely possible to understand something deeply without doing the thing yourself.
It's entirely possible for a CTO to deeply understand technology without writing any code themselves, opening up a terminal, tinkering with anything, or even what individual contributors are doing day-to-day. I would actually say that's the hallmark of a good CTO.
Because one is an intellectual activity, the other is not. You cannot expect the 60+ year old coach to run and train with the team members. But you can as a CTO try out technology, open the terminal, run a docker container to see the technology. Otherwise you are too far away from the things you try to orchestrate. Here the analogy of a master chef comes to mind. She doesn't have to work with her sous-chefs, but it helps to be able to still master the knife, make sushi or make a Crème brûlée, or even an omelette. All while mostly focusing on the big picture.
The struggle I found in coding as a CTO was that executive team priorities would come along that would take precedence over my ability to maintain my coding contributions, and in my experience no developer team wants to inherit and maintain code from their CTO. I found myself ultimately more drawn to coding tasks that improved developer experience or validated proof-of-concept work.
I agree with the author that CTO positions are incredibly varied, so I appreciate them sharing what works for them personally and in their organization, even if it doesn't match what has worked for me.
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.
Man, we have got to bring the “chief engineer” title back into more companies.
CTO-titled people who self admittedly aren’t interested in leading groups of people set a terrible example for smaller outfits, and a confusing and tempting example for eng leadership at larger ones.
The new SEO fad is CEOs and CTOs writing articles trying to look like a regular guy.
Also the "C" in CTO means Chief, as in main manager (of managers); if you have no direct report you are not a manager, let alone a "chief" one; call yourself Founder/Distinguished Engineer
I respectfully agree with many of the comments here, but I can also recognize the value and effort of someone sharing their experience. It shows character, boldness and opens up dialogue. People are central to any effort in accomplishing a certain goal, even if it is a single individual. Organization is meant to facilitate the joint effort in accomplishing the common goals in a structured and systematic way. Having had the experience of taking technical leadership without the title or stake on the company, I still value people who actually care. And that is precisely what I can extract from reading this post. Keep the genuine love for the craft going, don't let yourself down by people who don't get it.
>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've experienced small companies that "scaled" their org and added unnecessary layers of management "because we're going to need it sooner than later." They never needed it. The leaders were out of touch with what was actually happening. Complete dysfunction ensued...
I'm a former startup CTO, and I have... err, views.
In very small startups, CTOs need to code. You need as many people who can code checking in as possible, but you are trying to extend runway and so you don't have too many people on the team yet.
Critically, at this stage of the company your attention is not needed elsewhere as much as it will be one day: governance is light, the team size is small and everyone in the business is talking about product market fit all the time.
In more established businesses, CTOs can't code. I don't mean they don't have the ability, I mean they don't have time at first, and eventually they lose touch with the code base and tools to the point where getting involved slows everyone down, so please, on behalf of your staff, don't.
These CTOs are not "stuck in meetings" - the meetings are the work. Meetings are work. If a meeting isn't work for you, the questions is why are you there. Every meeting a CTO is asked to attend should (and probably does), need strategic technical/engineering input.
The CTO is going (or at least should be), because they have the experience, skills and ability to synthesise decisions and move everyone forward without having to drag all the rest of the senior engineering staff in. They are doing that work so that others don't have to.
They may also sit at the top of the org chart for a section of the company that means HR, Finance or other senior stakeholders want to engage them in order to drive strategic changes.
For a long time, I joked I was in the middle: I worked for startups that were small enough I had to code, but I didn't have the time because of everything else. So I coded, but I was exhausted.
And now you know why it's "former" CTO. This stage is painful. The temptation is to do both. Perhaps start working long days or weekends, but that sends a poor signal to your team.
Complaining or boasting about being very busy or working long days is not the badge of honour you might think it is: it's a signal to your team that you can't manage your time, and you don't value work/life balance. They will vote with their feet if that carries on for more than a month or two.
The better solution is, in my view, find the work/life balance, prioritise and say no to things that don't fit. It's often easier to say no to coding tasks, which you can hire other people to do, than it is to say no to the CEO about something they need doing, which you can't hire other people to do (at least, not without replacing you). Make clear - and signal to others - that you're going to choose how you spend your time carefully, but not because you are a precious resource but because that's the culture you want to instil and for them to do the same. Lead by example, always.
As an aside, even in small startups, when you are coding as a CTO, you should not choose the things that excite you the most, but the things that get in the way of your team the most.
Your engineering staff don't want you to take the meaty things that customers value - they want to do that, it's why they took a crap salary and the promise of untold options-based riches, because at least they get to work on meaningful things customers get excited by.
What they'll value is that horrid piece of refactoring that nobody wants to go near just going away, or that nasty new feature that needs integrating with that third party API everyone hates working with.
Your job as CTO is not to be "the best guy in engineering", it's to move all the obstacles out of the way of the engineering team to make them all the best they can possibly be.
Get rid of their reasons/excuses for failure, by doing whatever it is that needs to be done to help them succeed.
Sometimes, that means focusing on being in meetings to make sure that new policies or product directions aren't going to chop their feet out from underneath them. That means you need to realise that meetings are the work. Get over it.
And if you don't want to do that, and instead throw PRs over the wall that you & AI put together on a Saturday morning and expect a round of applause and hearty thanks... again, expect people to vote with their feet eventually.
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 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
I stopped reading when he said "I have no direct reports" in the first paragraph. If you are the CTO and have no direct reports, you are pretending to be a CTO because that is not what a CTO does.
(Actually, I did read more, but with contempt stuck in my eyes...)
AI coding tools are great, and the biggest problem they create is that inexperienced people think they can now make technical contributions AND management. Totally untrue. Coding is a tiny part of the technical contribution, and AI tools right now mostly do ONLY that. Troubleshooting and debugging, and communication, and gathering customer requirements are much harder to delegate to AI tools. And, maintenance of code is the real cost center, and AI tools have yet to be proven on that front, and my experiences so far make me think this will be marginal improvements, not 10x improvements.
I'm going to paraphrase his comment about "shipping a vital customer feature by myself because I'm a big boy coder" (maybe I added something there, not sure) because I don't want to deal with the pain of reading it again. I see this all the time where CTOs brag about vibe coding something, and it is always to prove to the team how fast they can go as if that's the main problem. Focusing on that work means you are not writing down coding standards, managing team dynamics, and dealing with the hard problems. Those problems don't go away on their own, they are the real problems, and the downstream effects are what experienced CTOs and technical managers know all too well.
I’m not totally against CTOs who code (I like having management that I respect technically) but it sounds like this CTO is pretty clearly doing too much coding and not enough CTO-ing.
Posts like these show why the founding engineer is the most underpaid person in Silicon Valley. This CTO probably has 30% of the company. There’s probably a founding engineer doing 90% of the same work for years (and likely doing the technical bits better) for 1-1.5% of the company max.
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.
Because it's not his job. He should elevate someone else into that IC role instead of holding it for himself. The way he describes it, there is no one else in the company who can do the IC work he is doing, which is long-term bad.
Coding IC work takes a lot of focus and context that someone who is operating at the company-level should not really be in sole possession of.
To me, the whole point of these positions is to take the hit on random bullshit, planning, people management, etc and give your ICs space to do the kind of work he is taking on.
That doesn't mean you have no technical context or involvement in the development process, but it does mean you should probably be at least one step removed from it.
Hell yeah. I was honestly pretty surprised by this reaction here. On one hand, I can agree with the argument about focusing on strategy rather than coding — it makes sense. But on the other hand, I’m personally so tired of all this management bullshit out there, where the higher-ups have no idea about even the high-level technical abstractions of what’s going on under the hood in the projects they’re leading. Just imagine the level of incompetence when a Staff Engineer can mislead a Project Owner about the complexity of implementing simple pagination — and the POs and PMs are totally fine with it, like, “let’s just postpone it.” Hell yeah.
Yes, usually company hires 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.
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.
Been there done that. As a cto you don't spend time with details. Impossible to go deep and wide at the same time. Super humans don't exist. Fine to coach or teach people by coding. But shipping weekend products and bypassing team processes isn't really motivating. Apply for a dev job instead.
Sorry - you lost me at manage with NO direct reports. You, maybe, manage the coffee orders for the board of directors? I don't know if they exist anymore, but IBM, Microsoft, HP used to call you folks "Fellows" not CTO's and a nice position if you can get it but get over yourself.
I manage too many to code. I can hardly qa it all. Instead i have been vibe coding on my own for fun. I usually do it before anyone else wakes up. I like to think it helps me stay fresh
Well the only thing this post proves is that it's not because people call you CTO that you actually are one. While I do think CTOs should keep a pulse on code quality, process and dev experience, I don't think this is the way to do it.
People are dunking on this guy, but as a founder I can say that if you’re a CTO at an early to early-mid stage company, you better be getting your hands dirty with your tech base, both the hardware and software.
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.
> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie.
This bit got me. It's a direct quote from the linked post for those who haven't read it
(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.
My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.
I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.
In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).
I'm glad you are comfortable coming forward and for sharing your thoughts. Not to pile on with the others here but you may go fast alone but you go far together when you build the right team. Being an individual contributor CTO is not being a CTO for a business that succeeds at scale. Don't stop doing what you love if you feel that's more important but it's probably best to step back from being a CTO and hire someone to manage that role so you can code if you don't want to do the job.
You mention in the article you have no direct reports. Who does engineering report into in that case?
It sounds like you are CTO in title only
This can work, imho, IFF the organization has both a CTO and CIO (or someone else tasked with managing the org). I've seen lots of places where the CTO is purely the technical visionary/advisor/final decision maker, and doesn't directly manage the technical organization.
This scenario is far more common outside of the tech industry, where you usually have a CIO running the IT cost center, and a CTO making decisions about technology adoption strategy.
You're not describing a CTO, then
"CTO" is defined by whoever confers the title and accepts the role. Titles are often vague and amorphous.
The technical capacity of a CTO matters less then the CTOs ability to stay in their lane (for a lack of a better term).
I once worked for a company with a self taught CTO (and not the good kind). They had a number of star players, and this CTO would frequently lash out at them. All because he was getting in the way of them doing their jobs, doing work he wasn't qualified to do, trying forcing them to clean up after him, and then yelling at them for it. It was insanely toxic. I only lasted a few months. It was so bad I back channelled patches and project briefs to people he liked to get them approved.
Had this CTO remained people, project and product focused everything would have been fine.
Self taught in the programming sense, or the people management sense? Because I feel like the letter is much more common than not in software. Just curious in case there's an expected background you're thinking of when you say that. I have no point of reference for CTO backgrounds beyond generic MBAs or senior devs that either gave themselves the titles as founders or failed upwards.
> this CTO would frequently lash out at them [...] doing work he wasn't qualified to do, trying forcing them to clean up after him [...] and then yelling at them for it
Was that a Fintech in Germany, by any chance? :)
I once witnessed a meeting between a CTO and a Tech Lead. The CTO was attending from his laptop in an open office, and he was yelling in Russian for one hour straight at another Tech Lead because he wanted the tech lead to finish his work. It was a pathetic display, with the whole company watching and wondering what was going on.
Eventually he was "phased out" by having a few people promoted to VP of engineering who would deal directly with the CEO instead of him.
Last I heard he tried to rewrite the financial core in Golang by himself, but he failed since nobody wanted to work together with him and he doesn't really knew the language.
CTO, CIO, and the head of engineering (the latter of which can often be split among different groups) are often very distinct things, especially at larger companies. And, yes, while the CTO probably has a seat at the table for technology direction is often primarily a public technology face of the company as opposed to someone involved in a lot of hands-on day to day technology implementation.
“Probably has a seat at the table for technology direction” is a wild take to me. So much so that I can’t even formulate a response other than “what…?!”
I'm not sure what you find confusing. Someone can have an advisory and essentially technology evangelist role without necessarily being the ultimate decision maker. (And, at a larger company, a variety of folks--including the board--will ultimately make final consequential decisions.)
How can the Chief Technical Officer not be the one chiefly responsible for technology decisions?
I thought it's typically Chief Technology Officer
In most companies I've been a part off, including multiple >$1B tech companies, the CTO's focus is not on the engineering. That's the job of a VP Engineering or some similar position.
CTO (which will sometimes have a "CTO office") is to work besides the engineering on investigating new technologies and ideas that are beyond what the engineering organization would have otherwise done on the day to day. They are also an authority on all technology in the company but are not in the engineering "chain of command".
That said this is not universal, there are organizations where the CTO does lead the engineering organization. I think that's sub-optimal because there is always going to be tension between the day to day and the broader scope and those should be different roles.
In a startup, it is more common for a CTO to lead engineering because there is not yet enough to justify having both a VP Eng and a CTO and perhaps most of the work is around figuring out technologies. But as the company grows it makes sense to separate those functions.
This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.
When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.
As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.
I've seen both. A CTO office that also leads engineering--typically via a direct report to the CTO--and an organization where the CTO is largely an external evangelist (typically with a small staff) while engineering is a separate organization--though hopefully aligned. The view here where CTO is also the head of day-to-day engineering operations and technical vision is more of a small company/startup thing. The two are often separated to at least some degree at larger operations.
Because, title notwithstanding, they may not be the person solely responsible for technical decisions especially at the detailed (or macro) level.
There is a big leap between them not being the sole person responsible for technical decisions and them not even necessarily having a seat at the table for technology direction. The former is understandable. Later - quite surprising.
I'm not sure what I wrote that's contrary to any of that? Maybe I shouldn't have used the word "probably"? There are a lot of people responsible for the technical direction of a large company of which the CTO is important but hardly the only one.
Also: "I currently manage no direct reports and ship a lot of code." So essentially he is just a staff engineer with a fancy title
Then why are you the CTO!!
Dude just wants to be a staff engineer
He mentions he has nobody reporting to him. That sounds like he’s really a staff engineer with a vanity CTO title, plus a lot of sway in strategic decision making.
It’s not a guaranteed recipe for disaster, but it depends critically on his relationship with whoever actually manages the engineering org. If they don’t pull in the same direction, things go south very quickly and you end up with a little civil war.
Either way it’s a red flag and I wouldn’t work there. Another red flag is that he wrote this blog post at all. Given how clearly negative the reaction to it was going to be, it’s a strong signal he doesn’t really think things through and has a ego wrapped up in his “coding” prowess and ability to circumvent process. People mention Woz as an example of a technical co-founder in a non-management role, but he is a humble guy and wouldn’t brag like this.
How big is assembled in terms of headcount? That should resolve most of the questions we are raising.
LinkedIn suggests "50-200". 54 work in San Francisco, and 154 people are associated with it. So probably closer to 150, but that includes a lot of Sales and Marketing related roles. Maybe the "engineering" org is ~100 or just under that.
FWIW Carmack did this as CTO of Oculus [0]. Another configuration I've seen is for the CTO to have like 1 direct (VP Eng) who does actual eng managing. You could argue it's a staff engineer role but I've never seen staff engineers actually get much say over org direction/structure or be empowered to break gridlock like this.
[0]: https://www.uploadvr.com/john-carmacks-app-reviews-series/
Maybe. If he’s a technical founder though what other position would you hold?
It's not that uncommon to keep the "CTO" title and not be the primary manager of the engineering organization. There are all kinds of things you can do with the org chart. If I recall correctly, Clickhouse works this way.
The company's cofounders comprise three people [1]:
* Aaron, a sales-oriented CEO from Elastic and Salesforce
* Alexey, the original Clickhouse developer, as CTO
* Yury, an experienced engineering executive from Google/Netflix as "President"
An excerpt from the launch announcement [2]:
> While negotiations were still ongoing, Katz decided they needed a third co-founder. “I kept thinking, if I could get a third co-founder to run product and engineering, and if I could find someone with the same level of experience building distributed systems on open-source that I have on go-to-market, it could be a really compelling combination,” Katz says.
---
---
[1] https://clickhouse.com/company/our-story
[2] https://www.indexventures.com/perspectives/the-fast-and-the-...
Staff engineer. Founders don’t necessarily need to hold CXO titles to work in the startups they founded.
A few examples that spring to mind, Steve Wozniak and Mitchell Hashimoto
Wasn't Mitchell Hashimoto only a non-CxO for a handful of months between stepping down and selling the company?
I'm not that familiar with his employment history; you could be right. Either way, he'd still be an example. If you have longer term ones, I'm sure it would add to the discussion
I recall James Goodnight of SAS coding while being a CEO. As per https://www.forbes.com/sites/peterhigh/2014/05/12/an-intervi..., he still programs from time to time but doesn't have a specific part in development. In looking at the articles to refresh my memory, it is clear he is one of the good CEO's
I don't think that's the model we should be looking at here. I'd add Stephen Wolfram to the very short list of similar technical CEOs.
Tobi Luetke at Shopify too
I would say that's the job of a CTO
Hahaha I would have led with this honestly.
I’m the chief legal officer but at the end of the day I’m just like bruh, chill, who gives a shit
Dude is a staff engineer, not a CTO.
> 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
You need to exercise your god given right to mog goons below you.
Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.
Business value? The ego trip is a business value!
God forbid you'd actually have to do any real work when there's so many design, retro, and daily sync meetings to attend and so many jira issues to groom.
You're conveniently skipping over the fact that he has full control over those things. He is the CHIEF Technology Officer.
Only indirectly (through management) and still having control is exactly my point. Obviously if you need to do that over and over there’re some other actions need to be taken
Ive worked on both ends of the spectrum and id prefer too much process to too little
With too little process, people release bugs that I then have to scramble to fix. The CEO who pushed to skip QA and unit testing and everything in the name of release never has to deal with the consequences of their impatience
That same CEO would likely also push to have all of the things including no bugs, then complain people aren't productive enough when arbitrary and unrealistic deadlines aren't met.
Source: my personal experience. Very few of the managers who can code that I've worked with were better than any of the ones who couldn't, and those who did actively code while managing were universally worse.
Trouble is, I don't think they'll just get it and then set about to changing the processes. Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.
Exactly. Why change a process when you can be a superstar by ignoring it?
Fuck the customers, fuck the employees, fuck the investors. My ego is more important than any of this.
Unless you're at a very small company, CTOs set technical vision, choose high level tooling strategy and outline engineering culture in broad strokes, but the nitty gritty of process will be from an engineering director or other role below the CTO. The CTO will probably provide feedback if needed, but they're not in the weeds and won't be able to see problems unless they're raised.
You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so.
I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.
Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.
> If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok.
If the CTO has rank then why not work to solve the unresponsiveness or undesirable things?
If someone--even a founder--can act as a loose cannon then there is a risk that they'll introduce problems like instability, security vulnerabilities, or unnecessary conflict or resentment. Compliance programs like SOC and PCI don't look fondly on staff bypassing SDLC processes because of those risks.
Well if they dont and you have to demonstrate that again and again, then you know what to do and hopefully have the power to do it.
> Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.
Not ime
Cowboy development might fly in an early stage startup. But are you even really a CTO or are you just an overpaid mid-level developer?
Just this. CTO title doesn't even make sense until your org is large enough that engineering vision and strategy becomes decoupled from execution.
I think the answer is in the blog:
"I currently manage no direct reports and ship a lot of code."
That’s not a role that I’d normally associate with “Chief” anything (which, by definition, means direct reports). More like Principal Engineer, or Architect.
In smaller companies, this is probably fairly normal, but you can’t maintain this, as the company grows.
I had a similar path, in my career. I originally started as a regular engineer, in a two-person team, and eventually ended up managing a small team of up to ten engineers.
Towards the end, I couldn’t write any code (for the company), at all. I still needed to code, but did so, for volunteer/open-source stuff. I think it made me a better technical leader (I had an employment contract without a clause that interfered with outside coding).
I remember wanting to take an iOS training course, but the company wouldn’t support it, so I took vacation, and went on my own dime. I never regretted it, but it was discouraging.
The happy medium that the CTO did at the company where I worked where I was the architect guiding the technical direction, he would do non production level experimental coding as research - integrations with third party APIs, see if an AWS service was suitable - to take some of the load off of me hand the code over to me and I cleaned it up and made it production ready and championed it to the rest of the teams.
He still helped accelerate efforts, got his coding fix when he had time, wasn’t in the critical path of any work, and he made the entire org better.
Isn't this the fun part?
That’s not a CTO, that’s a dev.
I was about to ask how someone in the C suite has time to code at all, ever, but here we are.
> This is exactly what someone who can't be easily unseated should be doing at a company
I mean yeah, but hes the fucking CTO. If hes the CTO, _he_ is responsible for that process. Its his job to evolve it to make it fit for purpose.
What he's done is basically created a whole bunch of process debt, which is much harder to correct than tech debt.
(Author here): I hear what you’re saying, though I’ve never “crowed about regularly checking code in on Saturdays and Sundays” and I think that’s a false characterization of my article.
Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.
And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.
I'm guessing you are ~28, maybe married and no kids.
> I built and shipped a working version in a day.
If I were an engineer working under a CTO doing this, I’d find it extremely demotivating.
Why, as a CTO, are you not setting things up so that I can do it instead?
he's also casually trashing their engineering team... "I built it in a day" is suggesting no one else could have.
I personally don't think there's anything wrong with doing it (i.e. shipping a feature quickly that a customer needs), but writing a blog post about it is questionable.
No, he clearly points that anyone else would have to be taken off their existing work and would have to context-switch to the context he already has. That's not trashing his engineering team.
I code as a founder/CTO on weekends, I don't expect weekend work done by anyone else and most people rarely check in if ever on weekends.
The job profile of founder-CTO has not a lot of overlap with that of an individual contributor to be leading by example, the overlap is quite narrow even for senior engineering leadership.
Until recently[3] leaders with prior coding skills were always discouraged from code contributions and focus on management exclusively, for all the reasons some of them you describe.
--
I usually say that I am a part-time coder, not a professional one, and caution not to look at what I do as a benchmark or signal.
Vast majority of the code I write are DevEx or QoL for internal teams[4], or refactor tech debt that no one has time to deal with. Even mid-stage startups may not be large enough to invest in dedicated teams for this type of work.
Occasionally I have written such integrations like OP[1]. It is typically a PoC for a demo, never a production one to actual customers. It would be unfair (and failure prone) to expect anyone else to start supporting a production integration without the full tooling or documentation.
--
I agree it is a fine-line and you can err on the wrong side of it. It is easy and tempting to start focusing on production code and lose focus of the core job, but so many decisions as a founder are like that. I am hardly the best or optimal founder-CTO. However the value of being close to the metal is important and worth some risk in early to mid stage startups.
Perhaps there is also value in a CTO who understands what individual contributors are doing and is able to be more realistic about outcomes instead of being purely few layers above and not clued in.
--
[1] Not skipping legal that seems ridiculous, even if I wanted to, I can't imagine any partner would agree to it.
[3] Now I do encourage to try the new tools, it is not they contribute to production or be an IC, it is to get a sense of what is possible and what is not today. A lot of pipe-dreams are being sold in the industry, without hands on experience using the new tools ( which are rapidly evolving) managers can tend to overestimate or misunderstand what is doable.
[4]This is the core of the CTO job, writing code is rarely the bottleneck for productivity that was true even before generative coding tools, it is everything around that which creates friction. If you can reduce it, even writing some code to do so, it shouldn't be a problem or a flag.
- Edited for brevity(some).
If you want to work on the weekend - and occasionally I find myself doing so as a staff level IC consultant who does need to spend an inordinate amount of time mentoring, project management, suppprting sales, interviewing candidates, babysitting clients, etc… - don’t send messages on Slack or email outside of business hours. I schedule messages to go out Monday morning and I never mention I worked on the weekend.
I don’t want to set the expectation that people should work outside of business hours or that I’m willing to.
I kill slack app on weekends , that is largely to save battery on the laptop working out of coffee shops, but serves the same purpose :)
That’s the point — I and others would have the opposite reaction, it’s self selecting, so it’s doing its job. I didn’t even read the article because I thought “boring, nothing special about a CTO who codes, we all do.”
> regularly checking in code on Saturdays and Sundays
If you’re working on insurance SaaS, I agree.
If you’re building hard tech, I’d disagree entirely.
[flagged]
[flagged]
[flagged]
In that story, we don’t know why legal would need to be involved. Maybe it’s for a good and essential reason or maybe it’s for a sand-in-the-gears reason.
Maybe the CTO’s company uses GPLv3 or AGPL software and the customer’s legal department vomits all over AGPL and demands extensive review for GPLv3 for their developers. Or maybe they’re worried about later finger-pointing and support issues. Or ensuring the company is running on unmodified, mainline sources.
Those would all be reasons why the CTO’s company could ship without involving customer legal teams without it being a red flag to me.
Calling this guy a CTO is a stretch. He's a senior developer at a company with no CTO.
If you wanted to work yourself into a CTO position, his shop might not be a terrible choice, although I would imagine it would be a bit rough at first.
It seems like you're confusing technical founder CTO at a startup with professional CTO at a large org.
For the later, what you said makes some sense, and it definitely seems like you're more familiar with this archetype.
For the former, the article appears correct. If you've not worked at an early stage startup before, the culture is _very_ different.
As a side note: This article is doing it's job. People that are a good fit for the company will agree, and want to work with them. People that are not a good fit for the company will not agree, and naturally run the other way. Makes filtering out candidates easier.
At an early stage startup, shipping a feature should not require "many meetings across product, legal, and engineering". Especially not one that can be mostly built in a day.
Snake-style org vs Elephant-style org. Nature accomodates lot of survival strategies. People shouldn't unnecessarily criticize others.
Working at a startup can be rewarding, but it often means putting in founder-level effort while the founders capture most of the upside.
The "C" stands for "Cowboy"
> An engineer unfamiliar with that part of the codebase would spend quite a lot of time figuring out those details.
Your job is to delegate, yes, the first delegation is hard, but the engineer either grows, or doesn't (then you need to move or yeet).
Yes I understand that you want to code all the time, then you're not a CTO. A CTO leads from the front, leads with process, and context. Your job is to provide context so that your team can execute.
Don’t just back away slowly. Run for your life!
Prediction: this is the part of the AI boom that goes bust.
They brag about hiring on visas, so you can read between that post and the visa sponsorship as a 996 organization.
Agree. Let me say much the same through a parallel line of observation: maybe you dont need a this cto or any cto? Maybe you need to move this guy to sales.
Goodness gracious corporate america. Can we PLEASE stop with hustle and bs?
You ever heard buffet or munger say everyday they do some bill keeping in a double entry accounting system and AI makes them better? Never. Why? Because when you and your org are competent you're not constantly on the hussle. My guess if they need to, they do and as they have things on their mind they don't have time to blog about.
People know what management at Berkshire Hathaway stands for. Case closed.
Competent upper management can be a boon for orgs esp on cross functional management which builds the org and keeps ia from infighting and running in 10x different directions. This guy isn't that. Moreover that means other people on the board don't know that either.
Thank you for sharing this. The part about Warren Buffett and the contrast with hustle culture is particularly delightful. It highlights the importance of competence and meaningful leadership over performative busyness.
What’s your gripe with the part about the AI productivity boost? For anyone working in fairly standard web dev tech, I’d say it’s more of a red flag if a boss denies the productivity boost of these tools (at least when used by senior devs)
> Your job at the top is, more than anything else, pushing down a healthy culture. The CTOs role leading the tech folk to support business goals, which culture a part of. The healthy part is a subjective thing.
> During Thanksgiving break, I just decided to build it and knocked out a prototype.
You don’t want a boss that works on Thanksgiving and thus probably expects you to as well ?
I’d actually be ok with this if bro offered half a million total comp. I’ll deal with it for 5 years and then retire.
> foregoing required legal
depending on the legal requirement it may not have been foregoed but instead became legal because an executive did it
I took that a step farther and got written into our SOX compliance processes explicit “deviate from normal processes as much as required when this short list of people declare an emergency”, shamelessly cribbed from aviation law.
Slightly more details here: https://news.ycombinator.com/item?id=39174707
I fondly remember times when at one company CTO was doing round the dev section at 4:50pm and saying everyone close their machines. Go home or to pub, it's an order.
Once I sent an email at 5:45pm as I forgot to say something earlier about the project. I didn't get a response and in the morning got told off that I should never send an email outside of working hours, unless it is a personal matter that cannot wait.
Couple of years later the owners exited and new management replaced everyone with workers from consultancy of theirs. Company no longer exists.
Flabbergasted to say the least. Dude do your job. Fix the process. Don't set a bad example.
Frankly if you’re a CTO you aren’t incentivized by a salary. It makes sense in this case no different than you’d code on the weekends for your side hustle.
It only doesn’t make sense when this jackass thinks the salaried engineer needs this “grit”.
C-levels aren’t supposed to be “model employees”. The incentive structure is wildly weighted in their favor. Instead you should ask them to understand the difference, which is asking a lot of these sociopaths, but I digress.
So in your view c-level are all sociopaths? Let me guess you are not c-level. Or maybe you are but you’re the exception to the rule.
Hasn't it been repeatedly shown that C-level positions select for sociopaths?
Regarding culture:
Complete nonsense. The free market will tell him if he can do this or not. If he can get valid candidates pushing this culture and it’s legal, why shouldn’t he? You, anyone interviewing there or anyone working at their company presumably doesn’t have to work there. Most countries don’t have slavery for tech jobs!
No doubt he will lose many candidates with this culture (you and I included) but maybe that’s a strategy? Maybe he still gets plenty of candidates that are good and the culture he wants.
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.
Total team larger than 50 at that point,
and probably a lumbering ghost ship by one or more KPI.
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 everywhere. "Founder" instead of small business owner of a company with no customers.
Title inflation has been going on forever. For early stage companies, titles are mostly about perception and presentation, mostly for people outside the company.
Not any different from being the "VP/E" of a company with 3 employees.
When anyone mentions having the title CTO, it's guaranteed what follows will be also be pretentious BS.
> 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".
You can say this about any “C” title, such as the CEO who is spending his time in Figma or marketing or sales,…
In small startups, people wear multiple hats due to resource constraints. Executive roles and responsibilities change when the company grows.
you are what you do
> I am a CTO
> "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.
You’re also what you can do,
in the context of headhunting,
which is the context most use titles.
At any rate, Senior Engineer fits well here.
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.
What's the purity test for being a "real" CTO?
Like I keep saying, I don't think there's any such thing. The title by itself has the same kind of meaning as "employee of the month".
Then why even mention the CTO part?
Because it's the official title at my company?
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!
> The one thing I can think of is “organization-wide architecture oversight”, which is a pretty toxic role to assign.
I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches.
Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
Think about what it says, in a larger team staffed with competent technical talent, to have a single person across all of it reconciling decisions with their own personal mental model. I think it's an attractive idea for a lot of aspirants! Who wouldn't want to be President of Code? But ambiguity is resolved by practitioners at the sharp end of the system.
> But ambiguity is resolved by practitioners at the sharp end of the system.
I've been looking for a concise way to express this idea. I'll use this. Thank you.
It's not mine, it's Richard Cook's. Have fun with it!
I see, and I agree completely. I don’t see the CTO as having that role, but you’re right I guess some people do. That’s one reason it makes sense to at least try to put some definition to the role, isn’t it? To help people realize it’s not a technical role, but a people/organizational role that generally only large organizations need…
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)
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.
> it’s not what you do day to day.
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.
> 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"?
I liked your take and curious to know what you think a CTO should be doing here
Generally, I don't advocate for code getting thrown over the fence, regardless of the dynamics associated with the particular exchange. So the ideal approach here would be for the CTO to partner with a trusted engineer with some leadership capacity (tech lead, staff, etc.) and work through the architecture design and technical specifications for the project and get it off the ground and then hand that off to the tech lead that they partnered with so that they could carry it over the line, possibly with a team. Understanding the vision behind the project and why the CTO thought it was valuable is a critical aspect here. It turns what would otherwise be a low leverage project, mostly involving architecture and coding, into a much higher leverage project that's focused on educating and empowering other leaders in the organization. It also allows the CTO to stay close to the technical foundations and code so they don't lose touch with the organization that they're leading.
He's probably right that no-one else can do what he can, because competent Devs aren't going to work for a company that operates like this.
If you have to build something because "Devs are too busy working on other things", then you're just bad at prioritising tasks.
If your team "can't do what I can" then you're bad at hiring.
I don't mind if a CTO works on a bug ticket, but make it part of the usual process, not hero driven development. Otherwise, what's even the point of having a process in the first place?!
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
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.
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
How do you concern about strategy all day? Just sit down and think about it?
> How do you concern about strategy all day? Just sit down and think about it?
I'm not OP, but whenever your product is implemented by more than one team you will also have the need to coordinate and set strategic goals as well as accompany and steer each team towards where it's infrastructure/tech stack/systems architecture need to be.
If you do not offer guidance and determine technical directions, each engineer working in each team will happily fill the void and do their best to scratch their itch at the expense of the whole company becoming an unmaintainable big ball of mud.
Let's put things differently: what do you expect will be the output of a company if no one is responsible for things like directing the company's R&D effort, coordinate and specify the company's tech roadmap, even oversee product development.
This is an interesting question - I am a CTO at >1B tech company and there is no doubt that part of my role is exactly this - Technology Strategy.
How do I do it?
(1) It is my job to be familiar with a wide range of technologies, which might include tech stacks, but us mostly tech offerings. The tech offerings means lots of meetings with companies that build tech that we might use. Some of those are useful, most are painful.
(2) Actually using technology - IMHO - This is one of the most important aspects of the CTO job. I code all the time, but not for any of our products or operations. I code to learn so I can help make better decisions. We use Kafka for instance, and when we first started using it I built a cluster in my homelab so I had a better idea how it worked. The same with Hadoop, Cassendra, and a few different flavors of Kubernetes. The T in CTO is for 'technology', but it really should be for 'technical'.
(3) Perhaps the single most important thing - I try to hire people that are much smarter than I am, always. The amount I learn from people that are smarter/faster/better is many orders or magnitude greater and more valuable than the reverse.
(4) All the rest of the CTO job needs to support this - so budgeting, head count plans, spending strategy, patents and IP, roadmaps, decisions, etc. All of these details have to roll up and hopefully support a strategy.
Lots of conversations/meetings. Your job is to know what is happening and strategize accordingly.
You read, talk to people and write. Then you get feedback on your writing, and repeat the process.
you read gartner's publication and blindly ask AI to copy paste that info in a memo or powerpoint to pass it on to the middle management without trying to figure out if it makes sense.
At least that is how it looks from the engineers perspective.
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.
> 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?
As a leader, especially a CxO, the most important job they have is the allocation of resources. It was clearly NOT valuable if they couldn't apply any developer time towards it.
Exactly. The best reading is that they wasted their own time on it. The worst case is that a simple clearly valuable thing is something the company is incapable of doing. Both are dysfunctional.
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.
> Between org structure, roadmap incentives, and limited risk budget, few engineers can take months to pursue ambiguous bets.
> I can.
It's weird to hear a company executive say essentially "this work is important, but our company has too much bureaucracy and risk aversion for a regular IC to spend time working on this, so I just do it myself." Like, maybe that means you should actually be spending your time removing those roadblocks, instead?
It's no wonder why small companies innovate more than large companies. What is a wonder is, why many small companies intentionally make themselves more like large companies and lose their innovative spark as a result.
There are a few serious issues with this kind of "passion" in a work area outside of yours.
* PR reviews for your commits may not be honest, as people may hesitate to reject your code changes.
* You may not have time for your actual responsibilities.
* It may confuse people about your role.
* May be you are not letting some folks do their job.
* You are probably a coder at heart, not a CTO.
> PR reviews for your commits may not be honest [...]
True. That's already something I struggle being the most senior in my team. It is hard to find reviewer for my commits who dare to actually reject my code.
That sounds a bit odd. I am the most senior in my team and when I make mistakes, my peers reject it.
If people on the team don't dare to reject code from other members on the team, then it sounds like your team has some serious issues.
In a practical, work-world of humans, the org hierarchies do matter and impact the way these humans interact with each other. Maybe not for bots.
That's just a strawman argument. Or course, org hierarchies matters. I didn't say anything else.
> You may not have time for your actual responsibilities.
In your opinion, what are the actual responsibilities of a CTO?
This is such an interesting comment thread because people have such wildly different opinions and from my perspective the entire disagreement just comes from company size.
I am a "CTO" and I always put that in air quotes because I have one direct report and I spend the lion's share of my time doing IC work. I know what I do is not what people picture when they hear the title and I feel weird saying it. I use it because I do have to make the strategic technical decisions, there is no one else. When people are marketing technical B2B SaaS I am the one they are looking for.
From my perspective there just isn't nearly enough for me to do as a CTO to justify me not coding. If I were to hire someone just to manage them that would be an unjustifiable expense at this point. But I also get that as soon as we get to a reasonable size this would be totally unsustainable.
This sounds like myself as well. We are a small dev team of 6 (in a company of 30), however I also have a partial ownership stake in the company. Even though I spend a significant part of my time on "CTO" style work (client meetings, market assessments, product overviews, roadmap planning, third party collaboration, etc.) there also isn't near enough of that to fill my time or justify my salary. I code and review like my team does, but I also oversee technical direction for our whole portfolio and the responsibility for that technical success or failure rests on me. As we grow the coding will decrease I'm sure, but I see a lot of people here criticizing from a perspective of larger companies where a CTO would be a full time responsibility. In our situation the title (as much as I often dislike it) represents my level of responsibility, if not directly the full scope of my role.
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 don't want to come across as judgemental or anything, nor I did deep research on your background.
It appears like you became a CTO, because you co-founded the company, not because you rose to the rank.
If you were to join a different company with this approach you are taking, I doubt if you would even reach Staff level.
From your point of view, what's the approach taken by someone who rose to the rank? Is it mostly people and process management and less to do with tech?
Please, do not. Nobody will do a real code review for such a person. Nobody will start a discussion if this or that change makes sense. If you have managerial position stick to it and do not make other people's lives miserable
Depends a lot on the culture. I used to work for a small team of about 10-15 engineers and the CTO was a good person. He would write code about as much as the rest of us. He was just the leader, engi 0. So we treated his code reviews similarly. It was actually nice giving him review because asking questions would be met with more business context and would be a good way to learn about the development process.
Any good engineer will be grateful you find issues in their work, especially if you help track down solutions.
Of course, the CTO depending on AI to solve things may be less like that, IDK. Or even before AI I knew the type. I once gave a new CTO a whitepaper to read in private to understand some of the direction I was taking a project, and he basically flipped out. So YMMV.
> 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.
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
This is staff, principal, or even EM scope at many orgs. I have never seen anyone with a senior dev title directly managing juniors.
There are plenty of Principal Engineers (L8) at Google who have no reports. In fact, I think the majority have no reports.
Most of those engineers, outside of ones who have extremely specialized knowledge or skills, are essentially managing others still just without a direct reporting chain.
The commit log for most of these high-level engineers is extremely sparse. They're spending most of their time writing documents or influencing orgs, not writing code.
Yes. I was responding to the sentence "With no directs, even “principal” would be a stretch in any company of note." which talked about direct reports.
Oh, I see now.
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).
Not much is worse than working somewhere that a higher up is squatting a job title that they don't want to do. It just causes a dysfunctional lord of the flies situation where lower people fight for the reigns to get what they want.
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.
I was CTO of a <20 person startup. I recruited the entire tech team, collaborated with the CEO to build the product backlog and spec things out, presented to investors, but also had at least 50% time to code. Not all “CTO” roles are the same. At a small company they better be hands on.
This is very similar to my own role, but I didn't have (nor would I have accepted) that title.
On my resume, I usually list it as “Lead Engineer” since it fits the roles I’m applying to better.
I think a founder/early gets away with "CTO" on their resume, esp. if they're the only person in the org with the role (ie: it's a PM-style CTO, and there isn't a VP/PM; or: it's a VP/E-style CTO, and there isn't a VP/E). But outside that circumstance, given the choice, I'd rather have the VP/PM or VP/E role than "CTO".
(As we get deeper into these threads I am further out on a limb.)
Yes, I was one of the first hires. My role was closer to VP/E and "CTO" was mostly vanity, a reward for being early and getting a new company through the first couple years.
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.
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.
CTO without reports is just a "developer".
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.
Exactly. Most CTO's have tens if not hundreds of direct reports that rely on them regularly. Which is why their time must be used to support them leaving absolutely 0 time to do PR code contributions on the side (unless you work weekends).
Most comments here are assuming that there’s only “one, true CTO” role when in fact the role is essentially “everything that’s left over after you’ve delegated to others”.
> When I was figuring out my role as CTO, I read Greg Brockman’s blog post about defining the CTO role at Stripe. He talked to a bunch of other CTOs and realized there’s enormous variance in what the role looks like. Some CTOs are technical visionaries, some are org builders, some are infrastructure-focused. The commonality is that great CTOs figure out where they can create the most value given their particular skills, interests, and company context.
> For me, that’s meant writing a lot of code. It works because of my particular context: I enjoy building software more than org design, I have deep customer and codebase knowledge that makes me particularly effective, and we’ve hired strong engineering managers.
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
So you're not an officer
> Because it’s what I love and what I’m good at. I don’t particularly enjoy building orgs and figuring out people stuff.
Was my first guess as well.
Pricing section of your website has no prices, I'd suggest calling that section something else.
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.
I appreciated the sentiment but I do wonder how on earth a CTO has enough time to write one line of code, let along several thousands. Even before reaching the C-suite roles, higher ups tend to be in meetings all day, back to back. In the short amount of non-meeting time they find, they typically have to do other admin related things or information sharing.
I guess that CTO uses weekends or works super long hours which I is fine if they don't push that expectation onto others.
I'd only really expect a CTO in an early stage startup to be pushing code like this (and eventually stepping back when they grow).
Seems like the author has not yet learned to delegate and trust. I think it's an example of what not to do as a CTO.
While I think CTOs should take steps back from pushing to production systems because there's a lot of I dotting and T crossing that needs to happen with production systems that CTOs don't reasonably have time for, if a CTO wasn't writing experiments and building test systems to determine technical direction, or at least getting their hands dirty with said systems produced by their top principles, I wouldn't trust their judgment to set direction.
The last time I worked for a product company was 2020. I was the second technical hire by a then new CTO of a growing company started by a two non technical brothers who hired an outside consulting company to do all of the work.
When the company found product market fit, they hired the CTO to bring the technology leadership in house. Early on he would do experimental POC work that he passed on to me to make it a working system as I was swamped doing my own architectural herding cats work as the company was growing.
But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team.
I’ve been working full time for consulting departments/companies since mid 2020. My goal on any project I’m on with more junior people is to development them. I purposefully give them ambiguous technical requirements with broad guardrails so they have the autonomy to learn and grow and then help them when needed and I put them in front of the customer early on to I present their “workstream”.
From a hands on keyboard side, I let them pick what they want to work on first and I take the left overs.
"But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team."
That is a good summary of the progression of a successful CTO. The capabilities of the team is a summation operations, not a selection operation.
This might be best said as you want your CTO to be ABLE to build and operate your products, but not actually do it.
I like to say that my job as a CTO is to be able to do the job of most the people that work for me, but most of the people that work for me are much much better at it.
If you are Founder/CEO/CTO of a company it could be up to them to define what their workday looks like though.
It was hard to tell if he means he doesn’t do meetings at all, though it’s kind of implied. There are lots of high leverage activities around advocating for engineering’s perspectives among the other executives and bringing the business context to engineering, both of which don’t involve directly managing reports.
But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones.
It seems like this sentiment relates closely to the ideas around dual track career progression, and having technical leadership tied to hiring and managing people. Hiring engineering talent is certainly important to the company, but is quite orthogonal to technical decision making and it seems like a natural place to split the role.
"But I’m also surprised to see so many comments advocating for the CTO disconnecting from the code in favor of doing more people management. As soon as they stop writing code their skills start decaying, their advice and technical direction is reduced to platitudes and thought leadership. It may seem like a CTO who doesn't code will stop making technical decisions and just delegate, but I’d posit that they make decisions regardless, just worse ones."
The distinction might be something more subtle - I think s good CTO should maintain a deep technical skill, but should do so without putting the technology of the company in jeopardy. I write code, and am a CTO, but I don't write code for our products. I write code in order to continue to develop and maintain deep technical skill. I also manage our technical operations, so I make an effort to a good understanding of the technical areas that are needed to operate - networking, device configuration, IP, etc. In a pinch I am fully capable of making a configuration change to a Cisco switch or a Palo Alto firewall, but in practice I have a team of people that are much better at those tasks. That allows delegation and understanding.
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.
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...
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 agree. As a company grows, the CTO must shift from coder to leader, architect, and culture-shaper.
Lots of naysaying this, and I don't necessarily disagree with the general skepticism, but there's something I learned in Military Science class in college that I found interesting: in the U.S. marines, every marine from generals to janitors is rated and trained as a capable combat marksman with a rifle regardless of their specialization.
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?
Unfortunately this meme that CTO and other members of executive team only supposed to be doing "thought leadership" is really pervasive now
The backlash is really telling of how bad things have gotten when a Chief Technology Officer coding in a software startup is disqualifying.
Maybe Staff Engineer would be a better title here. He doesn't seem to be doing much in the way of ya know, managing or running things.
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.
This is not really a good analogy. Tech is different.
I am not saying you should sit down and write code. But in IT you know the difference between a tech lead who knows technology, who knows what works, for what reason. And the one that just demands results but knows nothing about the details of the technology. Has never gotten his hands on it.
> This is not really a good analogy. Tech is different.
Why? Seriously: Give me a convincing reason why tech is different from every other field, where this happens regularly.
> I am not saying you should sit down and write code.
But that's the whole premise of this conversation. It's entirely possible to understand something deeply without doing the thing yourself.
It's entirely possible for a CTO to deeply understand technology without writing any code themselves, opening up a terminal, tinkering with anything, or even what individual contributors are doing day-to-day. I would actually say that's the hallmark of a good CTO.
Because one is an intellectual activity, the other is not. You cannot expect the 60+ year old coach to run and train with the team members. But you can as a CTO try out technology, open the terminal, run a docker container to see the technology. Otherwise you are too far away from the things you try to orchestrate. Here the analogy of a master chef comes to mind. She doesn't have to work with her sous-chefs, but it helps to be able to still master the knife, make sushi or make a Crème brûlée, or even an omelette. All while mostly focusing on the big picture.
The struggle I found in coding as a CTO was that executive team priorities would come along that would take precedence over my ability to maintain my coding contributions, and in my experience no developer team wants to inherit and maintain code from their CTO. I found myself ultimately more drawn to coding tasks that improved developer experience or validated proof-of-concept work.
I agree with the author that CTO positions are incredibly varied, so I appreciate them sharing what works for them personally and in their organization, even if it doesn't match what has worked for me.
A CTO who codes and who has no reports?
Every hour they spend coding is time not spent doing the things only the CTO can do.
They really need to hire a programmer or two and focus on their job.
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.
Man, we have got to bring the “chief engineer” title back into more companies.
CTO-titled people who self admittedly aren’t interested in leading groups of people set a terrible example for smaller outfits, and a confusing and tempting example for eng leadership at larger ones.
The new SEO fad is CEOs and CTOs writing articles trying to look like a regular guy.
Also the "C" in CTO means Chief, as in main manager (of managers); if you have no direct report you are not a manager, let alone a "chief" one; call yourself Founder/Distinguished Engineer
I respectfully agree with many of the comments here, but I can also recognize the value and effort of someone sharing their experience. It shows character, boldness and opens up dialogue. People are central to any effort in accomplishing a certain goal, even if it is a single individual. Organization is meant to facilitate the joint effort in accomplishing the common goals in a structured and systematic way. Having had the experience of taking technical leadership without the title or stake on the company, I still value people who actually care. And that is precisely what I can extract from reading this post. Keep the genuine love for the craft going, don't let yourself down by people who don't get it.
>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've experienced small companies that "scaled" their org and added unnecessary layers of management "because we're going to need it sooner than later." They never needed it. The leaders were out of touch with what was actually happening. Complete dysfunction ensued...
This is just a pride post with little self awareness.
I'm a former startup CTO, and I have... err, views.
In very small startups, CTOs need to code. You need as many people who can code checking in as possible, but you are trying to extend runway and so you don't have too many people on the team yet.
Critically, at this stage of the company your attention is not needed elsewhere as much as it will be one day: governance is light, the team size is small and everyone in the business is talking about product market fit all the time.
In more established businesses, CTOs can't code. I don't mean they don't have the ability, I mean they don't have time at first, and eventually they lose touch with the code base and tools to the point where getting involved slows everyone down, so please, on behalf of your staff, don't.
These CTOs are not "stuck in meetings" - the meetings are the work. Meetings are work. If a meeting isn't work for you, the questions is why are you there. Every meeting a CTO is asked to attend should (and probably does), need strategic technical/engineering input.
The CTO is going (or at least should be), because they have the experience, skills and ability to synthesise decisions and move everyone forward without having to drag all the rest of the senior engineering staff in. They are doing that work so that others don't have to.
They may also sit at the top of the org chart for a section of the company that means HR, Finance or other senior stakeholders want to engage them in order to drive strategic changes.
For a long time, I joked I was in the middle: I worked for startups that were small enough I had to code, but I didn't have the time because of everything else. So I coded, but I was exhausted.
And now you know why it's "former" CTO. This stage is painful. The temptation is to do both. Perhaps start working long days or weekends, but that sends a poor signal to your team.
Complaining or boasting about being very busy or working long days is not the badge of honour you might think it is: it's a signal to your team that you can't manage your time, and you don't value work/life balance. They will vote with their feet if that carries on for more than a month or two.
The better solution is, in my view, find the work/life balance, prioritise and say no to things that don't fit. It's often easier to say no to coding tasks, which you can hire other people to do, than it is to say no to the CEO about something they need doing, which you can't hire other people to do (at least, not without replacing you). Make clear - and signal to others - that you're going to choose how you spend your time carefully, but not because you are a precious resource but because that's the culture you want to instil and for them to do the same. Lead by example, always.
As an aside, even in small startups, when you are coding as a CTO, you should not choose the things that excite you the most, but the things that get in the way of your team the most.
Your engineering staff don't want you to take the meaty things that customers value - they want to do that, it's why they took a crap salary and the promise of untold options-based riches, because at least they get to work on meaningful things customers get excited by.
What they'll value is that horrid piece of refactoring that nobody wants to go near just going away, or that nasty new feature that needs integrating with that third party API everyone hates working with.
Your job as CTO is not to be "the best guy in engineering", it's to move all the obstacles out of the way of the engineering team to make them all the best they can possibly be.
Get rid of their reasons/excuses for failure, by doing whatever it is that needs to be done to help them succeed.
Sometimes, that means focusing on being in meetings to make sure that new policies or product directions aren't going to chop their feet out from underneath them. That means you need to realise that meetings are the work. Get over it.
And if you don't want to do that, and instead throw PRs over the wall that you & AI put together on a Saturday morning and expect a round of applause and hearty thanks... again, expect people to vote with their feet eventually.
I wish I worked for you!
If you don’t have direct reports, why are you “CTO” and not founding or principal engineer?
I think it’s great when a CTO keeps coding, that’s a solid habit. But using that as a reason to push overtime? Definitely not a good idea.
Summary: CTO of a small company codes. I don't see any issues, and it's not surprising.
I've heard of plenty of CTOs coding at small startups, but the surprising part is he has no direct reports.
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.
It's amazing that this guy can deliver so much despite only typing with one hand.
This made me laugh. Take my upvote.
> 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.
I like to code as a cat. Coding as a dog is ruffer though.
I stopped reading when he said "I have no direct reports" in the first paragraph. If you are the CTO and have no direct reports, you are pretending to be a CTO because that is not what a CTO does.
(Actually, I did read more, but with contempt stuck in my eyes...)
AI coding tools are great, and the biggest problem they create is that inexperienced people think they can now make technical contributions AND management. Totally untrue. Coding is a tiny part of the technical contribution, and AI tools right now mostly do ONLY that. Troubleshooting and debugging, and communication, and gathering customer requirements are much harder to delegate to AI tools. And, maintenance of code is the real cost center, and AI tools have yet to be proven on that front, and my experiences so far make me think this will be marginal improvements, not 10x improvements.
I'm going to paraphrase his comment about "shipping a vital customer feature by myself because I'm a big boy coder" (maybe I added something there, not sure) because I don't want to deal with the pain of reading it again. I see this all the time where CTOs brag about vibe coding something, and it is always to prove to the team how fast they can go as if that's the main problem. Focusing on that work means you are not writing down coding standards, managing team dynamics, and dealing with the hard problems. Those problems don't go away on their own, they are the real problems, and the downstream effects are what experienced CTOs and technical managers know all too well.
There are lots of different types of CTO. Who are you to say which is right and which is wrong?
Who said a janitor can't call himself a CTO?
I’m not totally against CTOs who code (I like having management that I respect technically) but it sounds like this CTO is pretty clearly doing too much coding and not enough CTO-ing.
Posts like these show why the founding engineer is the most underpaid person in Silicon Valley. This CTO probably has 30% of the company. There’s probably a founding engineer doing 90% of the same work for years (and likely doing the technical bits better) for 1-1.5% of the company max.
A yet this people still exist.
I will say it over and over. Do not code as a CTO.
I've always wondered: Why did we switch to "code" instead of "program"?
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.
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.
Because it's not his job. He should elevate someone else into that IC role instead of holding it for himself. The way he describes it, there is no one else in the company who can do the IC work he is doing, which is long-term bad.
Coding IC work takes a lot of focus and context that someone who is operating at the company-level should not really be in sole possession of.
To me, the whole point of these positions is to take the hit on random bullshit, planning, people management, etc and give your ICs space to do the kind of work he is taking on.
That doesn't mean you have no technical context or involvement in the development process, but it does mean you should probably be at least one step removed from it.
Hell yeah. I was honestly pretty surprised by this reaction here. On one hand, I can agree with the argument about focusing on strategy rather than coding — it makes sense. But on the other hand, I’m personally so tired of all this management bullshit out there, where the higher-ups have no idea about even the high-level technical abstractions of what’s going on under the hood in the projects they’re leading. Just imagine the level of incompetence when a Staff Engineer can mislead a Project Owner about the complexity of implementing simple pagination — and the POs and PMs are totally fine with it, like, “let’s just postpone it.” Hell yeah.
Is it common for a CTO to not have any direct reports?
In my experience, yes in startups, and no in large corporations.
Yes, usually company hires 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.
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.
Been there done that. As a cto you don't spend time with details. Impossible to go deep and wide at the same time. Super humans don't exist. Fine to coach or teach people by coding. But shipping weekend products and bypassing team processes isn't really motivating. Apply for a dev job instead.
I am the CTO of zero employees and I code all day.
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.
Sorry - you lost me at manage with NO direct reports. You, maybe, manage the coffee orders for the board of directors? I don't know if they exist anymore, but IBM, Microsoft, HP used to call you folks "Fellows" not CTO's and a nice position if you can get it but get over yourself.
I manage too many to code. I can hardly qa it all. Instead i have been vibe coding on my own for fun. I usually do it before anyone else wakes up. I like to think it helps me stay fresh
wait i thought amd changed their logo and wondering why their cto is coding.
Well the only thing this post proves is that it's not because people call you CTO that you actually are one. While I do think CTOs should keep a pulse on code quality, process and dev experience, I don't think this is the way to do it.
People are dunking on this guy, but as a founder I can say that if you’re a CTO at an early to early-mid stage company, you better be getting your hands dirty with your tech base, both the hardware and software.
Stopped reading at “CTO with no direct reports”. Chief of who?
[dead]
[flagged]
I hate fluff pieces, self promoting garbage.
This may as well be titled “Why I code…as an ex-Google Millionaire.”
Because that’s how ridiculous this person is.
This reads like an engineer that got promoted to his level of incompetence.
I don't want my CTO to code, I want my CTO to have a clear vision and listen to engineers