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
> 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
(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.
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.
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.”
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.
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.
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.
> 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.
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.
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.
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?
> 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".
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!
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.
> 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
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
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.
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.
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.
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.
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.
> 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.
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?
> 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.
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.
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).
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.
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.)
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 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 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 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.
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.
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.
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.
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.
>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?
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.
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.
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.
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 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
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.
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.
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.
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.
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.
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.
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.
CobrastanJorji|4 months ago
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.
sa-code|4 months ago
This bit got me. It's a direct quote from the linked post for those who haven't read it
dilyevsky|4 months ago
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
johnjwang|4 months ago
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.
whiplash451|4 months ago
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?
mritchie712|4 months ago
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.
manquer|4 months ago
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).
cloudhead|4 months ago
jumploops|4 months ago
If you’re working on insurance SaaS, I agree.
If you’re building hard tech, I’d disagree entirely.
swaits|4 months ago
Prediction: this is the part of the AI boom that goes bust.
singleshot_|4 months ago
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.
xnx|4 months ago
dangoodmanUT|4 months ago
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.
sokoloff|4 months ago
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.
varispeed|4 months ago
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.
KaiserPro|4 months ago
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.
unknown|4 months ago
[deleted]
yieldcrv|4 months ago
depending on the legal requirement it may not have been foregoed but instead became legal because an executive did it
CyanLite2|4 months ago
Rover222|4 months ago
mdrachuk|4 months ago
scrubs|4 months ago
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.
999900000999|4 months ago
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.
ctxc|4 months ago
stuffn|4 months ago
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.
jaccola|4 months ago
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.
tptacek|4 months ago
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.
peter422|4 months ago
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.
alexpotato|4 months ago
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.
lbreakjai|4 months ago
sarabande|4 months ago
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?
xnx|4 months ago
kgwxd|4 months ago
mexicocitinluez|4 months ago
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".
rpdillon|4 months ago
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.
tptacek|4 months ago
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!
brabel|4 months ago
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.
emilsoman|4 months ago
I liked your take and curious to know what you think a CTO should be doing here
LouisSayers|4 months ago
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?!
raw_anon_1111|4 months ago
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
hdjrudni|4 months ago
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.
cultofmetatron|4 months ago
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
brabel|4 months ago
IanCal|4 months ago
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.
noir_lord|4 months ago
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.
andy99|4 months ago
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.
wavemode|4 months ago
> 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.
xpasky|4 months ago
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.
sponaugle|4 months ago
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.
zkmon|4 months ago
* 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.
jenadine|4 months ago
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.
emilsoman|4 months ago
In your opinion, what are the actual responsibilities of a CTO?
morsecodist|4 months ago
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.
51Cards|4 months ago
funnyfoobar|4 months ago
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.
emilsoman|4 months ago
willio58|4 months ago
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.
roenxi|4 months ago
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.
raw_anon_1111|4 months ago
cjblomqvist|4 months ago
citizenpaul|4 months ago
indigodaddy|4 months ago
tptacek|4 months ago
mobeigi|4 months ago
majgr|4 months ago
nixpulvis|4 months ago
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.
theptip|4 months ago
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.)
jt2190|4 months ago
> 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.
eviks|4 months ago
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.
xedarius|4 months ago
sarabande|4 months ago
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?
stoneman24|4 months ago
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.
thom|4 months ago
gbransgrove|4 months ago
firefoxd|4 months ago
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...
29athrowaway|4 months ago
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.
liqilin1567|4 months ago
mobeigi|4 months ago
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).
prerok|4 months ago
CuriouslyC|4 months ago
mewpmewp2|4 months ago
submeta|4 months ago
dilyevsky|4 months ago
kittikitti|4 months ago
BoxFour|4 months ago
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.
rstephenson2|4 months ago
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.
sponaugle|4 months ago
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.
dccoolgai|4 months ago
blinkymach12|4 months ago
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.
t-writescode|4 months ago
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.
andsoitis|4 months ago
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.
fsckboy|4 months ago
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"?
freddie_mercury|4 months ago
holoduke|4 months ago
lazyant|4 months ago
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
solodev222|4 months ago
zbentley|4 months ago
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.
drunken_thor|4 months ago
unknown|4 months ago
[deleted]
rubenvanwyk|4 months ago
PaulRobinson|4 months ago
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.
guilhermesfc|4 months ago
mrasong|4 months ago
unknown|4 months ago
[deleted]
lonelyprograMer|4 months ago
Cyclone_|4 months ago
aidos|4 months ago
Edit: relatedly - at what size do you need a cto?
tptacek|4 months ago
unknown|4 months ago
[deleted]
secondcoming|4 months ago
notpachet|4 months ago
ecshafer|4 months ago
Very loose definition of a CTO.
alexnewman|4 months ago
kristianp|4 months ago
iheartrms|4 months ago
algernonramone|4 months ago
CSMastermind|4 months ago
mrbluecoat|4 months ago
xrd|4 months ago
(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.
fooster|4 months ago
habosa|4 months ago
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.
unknown|4 months ago
[deleted]
gdsdfe|4 months ago
mocmoc|4 months ago
I will say it over and over. Do not code as a CTO.
kittikitti|4 months ago
ZephyrBlu|4 months ago
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.
re-lre-l|4 months ago
unknown|4 months ago
[deleted]
unknown|4 months ago
[deleted]
unknown|4 months ago
[deleted]
herval|4 months ago
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.
indigodaddy|4 months ago
dilyevsky|4 months ago
dahart|4 months ago
qwertyuiop_|4 months ago
BenFranklin100|4 months ago
bongodongobob|4 months ago
alwahi|4 months ago
unknown|4 months ago
[deleted]
PerilousD|4 months ago
bargainbin|4 months ago
foreverwtz|3 months ago
[deleted]
foreverwtz|3 months ago
[deleted]
alshival|4 months ago
[deleted]
vinar78|4 months ago
[deleted]
vader_n|4 months ago
sharts|4 months ago
Because that’s how ridiculous this person is.
throw-10-13|4 months ago
hacb|4 months ago