HN Reader

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.

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.

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?!

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.

> 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.

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

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.

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.

There are a few serious issues with this kind of "passion" in a work area outside of yours.

* PR reviews for your commits may not be honest, as people may hesitate to reject your code changes.

* You may not have time for your actual responsibilities.

* It may confuse people about your role.

* May be you are not letting some folks do their job.

* You are probably a coder at heart, not a CTO.

I don't want to come across as judgemental or anything, nor I did deep research on your background.

It appears like you became a CTO, because you co-founded the company, not because you rose to the rank.

If you were to join a different company with this approach you are taking, I doubt if you would even reach Staff level.

> 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.

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

I think the linked https://blog.gregbrockman.com/figuring-out-the-cto-role-at-s... is much more interesting, it gives more actionable detail and advice.

As Brockman says, you need a very strong VP Eng to make this possible.

It’s an important milestone for the technical founder(s) to decide if they are going to hang up their spurs and become a manager/leader, or keep doing the technical work. (A common failure mode is trying to do both.)

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 currently manage no direct reports

So you're not an officer

> Because it’s what I love and what I’m good at. I don’t particularly enjoy building orgs and figuring out people stuff.

Was my first guess as well.

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?

Pricing section of your website has no prices, I'd suggest calling that section something else.

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).

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?

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.

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.

A CTO who codes and who has no reports?

Every hour they spend coding is time not spent doing the things only the CTO can do.

They really need to hire a programmer or two and focus on their job.

>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"?

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.

This is just a pride post with little self awareness.

If you don’t have direct reports, why are you “CTO” and not founding or principal engineer?

I think it’s great when a CTO keeps coding, that’s a solid habit. But using that as a reason to push overtime? Definitely not a good idea.

Summary: CTO of a small company codes. I don't see any issues, and it's not surprising.

Question for people who have gone through the journey of being tech founders that have grown a company. At what size of org / engineering team would you expect the founder to not code at all anymore?

Edit: relatedly - at what size do you need a cto?

It's amazing that this guy can deliver so much despite only typing with one hand.

> I currently manage no direct reports and ship a lot of code. Not in an “I dabble when I have free time in between meetings” way, but in an “I shipped multiple substantial features last quarter” way

Very loose definition of a CTO.

I 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 like to code as a cat. Coding as a dog is ruffer though.

I've always wondered: Why did we switch to "code" instead of "program"?

If your job functions leave you time to code you probably shouldn't have the title of CTO.

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.

A yet this people still exist.

I will say it over and over. Do not code as a CTO.

The amount of commentators that downright oppose and ridicule a CTO coding is why enshittification is so pervasive. If a CTO understands the codebase to the point where they can contribute to it, I presume that's a good thing. I sense so much fear of actual engineering and technology in the comments and it really highlights why startups are failing to innovate and create compelling products.

I worked with plenty of founders like this - they carry a C level title, but never stop being just an engineer or sales guy or designer.

That’s all fine when you have no employees - C titles are bullshit when it’s just two bros in a dorm - but it invariably hurts the company prospects as the team grows.

The common hack is hiring a “VP of Eng” to take care of the actual C-level work.

Mind you, there’s absolutely nothing wrong in wanting to be the guy who sits in a corner and codes. Just don’t call it “leadership” or “chief” anything, since you’re sitting in a role and not acting the part.

I am the CTO of zero employees and I code all day.

Is it common for a CTO to not have any direct reports?

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.

This is just title inflation. If this is what you're doing, you're not a CTO or you're not doing your job properly.

wait i thought amd changed their logo and wondering why their cto is coding.

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.

Stopped reading at “CTO with no direct reports”. Chief of who?

I hate fluff pieces, self promoting garbage.

This may as well be titled “Why I code…as an ex-Google Millionaire.”

Because that’s how ridiculous this person is.

This reads like an engineer that got promoted to his level of incompetence.

I don't want my CTO to code, I want my CTO to have a clear vision and listen to engineers

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.