9 ms·

Why I code as a CTO

• 29athrowaway 11mo ago
  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.
  • liqilin1567 11mo ago
    I agree. As a company grows, the CTO must shift from coder to leader, architect, and culture-shaper.
• sarabande 11mo ago
  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?
  • stoneman24 11mo ago
    “ how are you able to manage conflict between org builders and your technical vision?” That for me, is the core of the issue. I have been in a few places where senior management (up to c level) still code and are critical parts of the project team. The problem is who keeps them to schedules and co-ordination with the other people on the project. Hard to complain about team level issues if the failing person is also the boss of the technical staff. Build a demo perhaps to illustrate the idea/vision but don’t code, focus on the high level management and direct the ICs to build out the production version. Both roles (management and coding) are difficult, demanding positions to do well, deserving of respect and commitment. Just my opinion after bad experiences.
• t-writescode 11mo ago
  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.
• tptacek 11mo ago
  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.
  • sarabande 11mo ago
    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?
  • peter422 11mo ago
    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.
  • alexpotato 11mo ago
    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.
• thom 11mo ago
  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.
• ecshafer 11mo ago
  > 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.
• rpdillon 11mo ago
  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.
  • tptacek 11mo ago
    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!
• willio58 11mo ago
  > 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.
  • tptacek 11mo ago
    No it isn't. Lots of CTOs don't have reports.
    • orliesaurus 11mo ago
      really? like who?
      • tptacek 11mo ago
        Both in my own personal direct experience and in 15 years of consulting, primarily for tech startups, the modal CTO I encountered had in reality a product manager role with a special title that was helpful in important pre-sales meetings --- and they did not tend to be the de facto VP/PM.
        • aaronblohowiak 11mo ago
          what's the most effective model you've seen?
          • tptacek 11mo ago
            I think CTO as "other, better-defined kind of exec, but with a funny hat" is a perfectly cromulent model. I think CTO as "PM that customers feel flattered to talk to" is another perfectly cromulent model. To me, "CTO" is almost an honorific, or like a title of nobility.
• deleted 11mo ago
  [deleted]
• xpasky 11mo ago
  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.
  • sponaugle 11mo ago
    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.
• herval 11mo ago
  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.
• aidos 11mo ago
  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?
  • tptacek 11mo ago
    It depends on what that founder wanted to do! Lots of founders code for the whole ride.
• rubenvanwyk 11mo ago
  If you don’t have direct reports, why are you “CTO” and not founding or principal engineer?
• bongodongobob 11mo ago
  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.
• secondcoming 11mo ago
  It's amazing that this guy can deliver so much despite only typing with one hand.
  • notpachet 11mo ago
    This made me laugh. Take my upvote.
• raw_anon_1111 11mo ago
  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
  • noir_lord 11mo ago
    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.
    • raw_anon_1111 11mo ago
      People find it strange when I interview candidates, I don’t even look at resumes. I don’t need to. I ask questions to measure among other things the size and complexity of projects they were responsible for, the level of complexity, and what they actually accomplished. If he came in and call himself a “CTO” and then he described his day to day work, that would be a red flag for me.
  • hdjrudni 11mo ago
    I'm a CTO that codes. I have zero reports. We also have zero employees and relatively little revenue :-) I think my role would indeed have to shift if we were to employ people and I don't like it, but I think you're not wrong.
    • 11mo ago
• deleted 11mo ago
  [deleted]
• qwertyuiop_ 11mo ago
  I am the CTO of zero employees and I code all day.
• gbransgrove 11mo ago
  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.
• deleted 11mo ago
  [deleted]
• firefoxd 11mo ago
  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...
• submeta 11mo ago
  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?
  • kittikitti 11mo ago
    The backlash is really telling of how bad things have gotten when a Chief Technology Officer coding in a software startup is disqualifying.
    • hooverd 11mo ago
      Maybe Staff Engineer would be a better title here. He doesn't seem to be doing much in the way of ya know, managing or running things.
  • dilyevsky 11mo ago
    Unfortunately this meme that CTO and other members of executive team only supposed to be doing "thought leadership" is really pervasive now
  • BoxFour 11mo ago
    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.
    • submeta 11mo ago
      This is not really a good analogy. Tech is different. I am not saying you should sit down and write code. But in IT you know the difference between a tech lead who knows technology, who knows what works, for what reason. And the one that just demands results but knows nothing about the details of the technology. Has never gotten his hands on it.
• indigodaddy 11mo ago
  Is it common for a CTO to not have any direct reports?
  • dilyevsky 11mo ago
    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.
  • dahart 11mo ago
    In my experience, yes in startups, and no in large corporations.
• CSMastermind 11mo ago
  If your job functions leave you time to code you probably shouldn't have the title of CTO.
  • mrbluecoat 11mo ago
    A CTO with atrophied skills (or no hands-on technical skills in the first place) can be just as dangerous.
• theptip 11mo ago
  I think the linked https://blog.gregbrockman.com/figuring-out-the-cto-role-at-stripe 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.)
• iheartrms 11mo ago
  I've always wondered: Why did we switch to "code" instead of "program"?
  • algernonramone 11mo ago
    I don't know, but I hate it.
• deleted 11mo ago
  [deleted]
• fsckboy 11mo ago
  >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"?
  • freddie_mercury 11mo ago
    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?
    • dilyevsky 11mo ago
      This is a series B company not an international pharmaceutical conglomerate. Perfectly reasonable for a CTO to participate in engineering work at this stage. I've experienced a few early companies where CTO just did meetings or that didn't have someone within the leadership team who dug into engineering at all and it wasn't pretty...
      • icedchai 11mo ago
        I've experienced small companies that "scaled" their org and added unnecessary layers of management "because we're going to need it sooner than later." They never needed it. The leaders were out of touch with what was actually happening. Complete dysfunction ensued...
• CobrastanJorji 11mo ago
  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.
  • mdrachuk 11mo ago
    > 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.
  • ctxc 11mo ago
    Flabbergasted to say the least. Dude do your job. Fix the process. Don't set a bad example.
  • dilyevsky 11mo ago
    > 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
• bargainbin 11mo ago
  Stopped reading at “CTO with no direct reports”. Chief of who?
• kittikitti 11mo ago
  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.
  • re-lre-l 11mo ago
    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.
  • ZephyrBlu 11mo ago
    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.
• kristianp 11mo ago
  I like to code as a cat. Coding as a dog is ruffer though.
• mobeigi 11mo ago
  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).
  • prerok 11mo ago
    Seems like the author has not yet learned to delegate and trust. I think it's an example of what not to do as a CTO.
  • mewpmewp2 11mo ago
    If you are Founder/CEO/CTO of a company it could be up to them to define what their workday looks like though.
  • CuriouslyC 11mo ago
    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.
    • raw_anon_1111 11mo ago
      The last time I worked for a product company was 2020. I was the second technical hire by a then new CTO of a growing company started by a two non technical brothers who hired an outside consulting company to do all of the work. When the company found product market fit, they hired the CTO to bring the technology leadership in house. Early on he would do experimental POC work that he passed on to me to make it a working system as I was swamped doing my own architectural herding cats work as the company was growing. But as the company grew he had to deal with more of the business side of the things. He still set the broad outline of priorities. But he gave me mostly free reign of determining how and I would just give him a brief high level of overview of my decisions. He did what a CTO was supposed to to do - grew the capabilities of his team. I’ve been working full time for consulting departments/companies since mid 2020. My goal on any project I’m on with more junior people is to development them. I purposefully give them ambiguous technical requirements with broad guardrails so they have the autonomy to learn and grow and then help them when needed and I put them in front of the customer early on to I present their “workstream”. From a hands on keyboard side, I let them pick what they want to work on first and I take the left overs.
• eviks 11mo ago
  > 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.
• deleted 11mo ago
  [deleted]
• mrasong 11mo ago
  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.
• PaulRobinson 11mo ago
  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.
• vader_n 11mo ago
  I hate fluff pieces, self promoting garbage.
• xedarius 11mo ago
  Pricing section of your website has no prices, I'd suggest calling that section something else.
• sharts 11mo ago
  This may as well be titled “Why I code…as an ex-Google Millionaire.” Because that’s how ridiculous this person is.
• deleted 11mo ago
  [deleted]
• xrd 11mo ago
  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.
  • fooster 11mo ago
    There are lots of different types of CTO. Who are you to say which is right and which is wrong?
    • stackedinserter 11mo ago
      Who said a janitor can't call himself a CTO?
• zkmon 11mo ago
  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.
  • jenadine 11mo ago
    > 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.
    • tuwtuwtuwtuw 11mo ago
      That sounds a bit odd. I am the most senior in my team and when I make mistakes, my peers reject it. If people on the team don't dare to reject code from other members on the team, then it sounds like your team has some serious issues.
      • zkmon 11mo ago
        In a practical, work-world of humans, the org hierarchies do matter and impact the way these humans interact with each other. Maybe not for bots.
        • tuwtuwtuwtuw 11mo ago
          That's just a strawman argument. Or course, org hierarchies matters. I didn't say anything else.
  • emilsoman 11mo ago
    > You may not have time for your actual responsibilities. In your opinion, what are the actual responsibilities of a CTO?
• deleted 11mo ago
  [deleted]
• lonelyprograMer 11mo ago
  Summary: CTO of a small company codes. I don't see any issues, and it's not surprising.
  • Cyclone_ 11mo ago
    I've heard of plenty of CTOs coding at small startups, but the surprising part is he has no direct reports.
• vinar78 11mo ago
  [flagged]
• andsoitis 11mo ago
  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.
• throw-10-13 11mo ago
  This reads like an engineer that got promoted to his level of incompetence.
• gdsdfe 11mo ago
  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.
• BenFranklin100 11mo ago
  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.
• majgr 11mo ago
  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
  • nixpulvis 11mo ago
    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.
• jt2190 11mo ago
  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.
• funnyfoobar 11mo ago
  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.
  • emilsoman 11mo ago
    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?
• habosa 11mo ago
  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.
  • deleted 11mo ago
    [deleted]
• alexnewman 11mo ago
  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
• drunken_thor 11mo ago
  This is just a pride post with little self awareness.
• dccoolgai 11mo ago
  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.
• morsecodist 11mo ago
  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.
  • 51Cards 11mo ago
    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.
• solodev222 11mo ago
  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.
• alwahi 11mo ago
  wait i thought amd changed their logo and wondering why their cto is coding.
• alshival 11mo ago
  [dead]
• lazyant 11mo ago
  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
• rstephenson2 11mo ago
  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.
  • sponaugle 11mo 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." 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.
• LouisSayers 11mo ago
  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?!
• PerilousD 11mo ago
  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.
• zbentley 11mo ago
  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.
• wavemode 11mo ago
  > 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.
• mocmoc 11mo ago
  A yet this people still exist. I will say it over and over. Do not code as a CTO.
• hacb 11mo ago
  I don't want my CTO to code, I want my CTO to have a clear vision and listen to engineers
• holoduke 11mo ago
  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.
• blinkymach12 11mo ago
  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.
• foreverwtz 10mo ago
  [dead]
• foreverwtz 10mo ago
  [dead]