[HN Gopher] Why I code as a CTO
       ___________________________________________________________________
        
       Why I code as a CTO
        
       Author : johnjwang
       Score  : 290 points
       Date   : 2025-10-24 16:03 UTC (2 days ago)
        
 (HTM) web link (www.assembled.com)
 (TXT) w3m dump (www.assembled.com)
        
       | 29athrowaway wrote:
       | 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 wrote:
         | I agree. As a company grows, the CTO must shift from coder to
         | leader, architect, and culture-shaper.
        
       | sarabande wrote:
       | 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 wrote:
         | " 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 wrote:
       | 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 wrote:
       | 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 wrote:
         | 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 wrote:
         | 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 wrote:
         | 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.
        
         | lbreakjai wrote:
         | 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.
        
         | mexicocitinluez wrote:
         | > 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".
        
           | swat535 wrote:
           | You can say this about any "C" title, such as the CEO who is
           | spending his time in Figma or marketing or sales,...
           | 
           | In small startups, people wear multiple hats due to resource
           | constraints. Executive roles and responsibilities change when
           | the company grows.
        
           | kgwxd wrote:
           | Then why even mention the CTO part?
        
             | mexicocitinluez wrote:
             | Because it's the official title at my company?
        
           | dijksterhuis wrote:
           | you are what you do
           | 
           | > I am a CTO
           | 
           | > "but I don't really do CTO things"
           | 
           | so you're not a CTO according to your own definition of what
           | a CTO does then.
           | 
           | my previous employment i was "lead engineer". i got to pick
           | that title. had a 1 day per week part timer reporting to me.
           | similar company description. making technical decisions.
           | strategy meetings with CEO and founder etc.
           | 
           | i was not a lead engineer and ive since changed my linkedin
           | page/cv to just say "engineer". who or what was i leading? a
           | contractor in ukraine who did work for us one day a week?
           | nah, need a team (ie more than 1) to be able to lead.
           | 
           | do the brave thing and call bullshit on yourself. this is
           | something good leaders do.
        
             | tptacek wrote:
             | People here want "CTOs" to be brave enough to call bullshit
             | on their "CTO-hood" but nobody here is brave enough to call
             | bullshit on the title itself, which is the truer and more
             | important observation.
        
               | mexicocitinluez wrote:
               | What's the purity test for being a "real" CTO?
        
               | tptacek wrote:
               | Like I keep saying, I don't think there's any such thing.
               | The title by itself has the same kind of meaning as
               | "employee of the month".
        
         | kgwxd wrote:
         | When anyone mentions having the title CTO, it's guaranteed what
         | follows will be also be pretentious BS.
        
       | thom wrote:
       | 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 wrote:
       | > 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 wrote:
       | 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 wrote:
         | 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!
        
           | dnw wrote:
           | Exactly. Role and title are amorphous and depends on the
           | industry, stage of the company, etc.
           | 
           | Look at this CEO who codes: https://github.com/lattner :-)
           | (He was fund raising in July, August)
        
           | dahart wrote:
           | > The one thing I can think of is "organization-wide
           | architecture oversight", which is a pretty toxic role to
           | assign.
           | 
           | I don't know that I understand what you mean by toxic or why,
           | but I've only ever seen the architecture overseer kind of
           | thing in pretty small companies. In big companies, where
           | there are multiple VPs of engineering and product management,
           | that feels like the only time CTO even makes sense, and I
           | expect they need to be setting vision and deciding where to
           | invest (i.e. setting budgets) sometimes handling legal
           | issues. In such large companies I've never seen a CTO
           | providing architecture oversight, let alone coding. They
           | might mandate the use or avoidance of some tech for reasons
           | of corporate politics, but they are never in the trenches.
           | 
           | Having been a founding engineer in a startup where I was
           | called CTO and mostly wrote code, I feel like this is a
           | 'cute' thing we do, using C-level role names for everyone in
           | a 3 person company. I didn't feel like a real CTO, or VP, and
           | I feel like using C-level names for roles in startups and
           | small companies is a little goofy and awkward. A lot of
           | people seem to like inflated role titles, and VCs seem to
           | like having someone in key roles who can both lead well and
           | take all responsibility and blame. I feel like ideally the
           | name CTO shouldn't be used until it's needed, which isn't
           | until there are enough devs to need managers, and enough
           | managers to need VPs and enough VPs to need a CTO. If that
           | were the case, then the possible things on the list of CTO
           | responsibilities is a lot smaller and more definable than if
           | we say CTO can be anything including the 2nd founder who's
           | more interested in coding than pitching or marketing.
        
             | tptacek wrote:
             | Think about what it says, in a larger team staffed with
             | competent technical talent, to have a single person across
             | all of it reconciling decisions with their own personal
             | mental model. I think it's an attractive idea for a lot of
             | aspirants! Who wouldn't want to be President of Code? But
             | ambiguity is resolved by practitioners at the sharp end of
             | the system.
        
               | dahart wrote:
               | I see, and I agree completely. I don't see the CTO as
               | having that role, but you're right I guess some people
               | do. That's one reason it makes sense to at least try to
               | put some definition to the role, isn't it? To help people
               | realize it's not a technical role, but a
               | people/organizational role that generally only large
               | organizations need...
        
         | emilsoman wrote:
         | > 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
        
         | brabel wrote:
         | 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.
        
           | matwood wrote:
           | > So you think coding is not high leverage on a tech company.
           | 
           | At the CTO level of a growing company it is one of the lower
           | leverage things they can do. Setting technical direction,
           | hiring the right people, and putting the right people in
           | positions of power will all have much more impact than
           | writing some code on the weekend.
        
             | brabel wrote:
             | You're wrong man. These things you mentioned happen rarely,
             | it's not what you do day to day. If you don't do some high
             | value coding you have no clue how to steer a tech company
             | at a technical level.
        
               | BoxFour wrote:
               | > it's not what you do day to day.
               | 
               | I don't know about that. I was a "CTO" for a small
               | (10-person) and a slightly larger (around 100-person) VC-
               | backed startup. Hiring was always top of mind at both
               | places. Not even "people management", just hiring alone.
               | I'm not saying this universal, but when a company is
               | expected to scale rapidly (as is often the case with
               | venture-backed firms), managing people can easily consume
               | your entire workday even at a relatively small size
               | company.
               | 
               | Of course, I'm not saying that's everyone's experience.
               | There are obviously lots of reasons that dynamic might be
               | different: For example if you're not a VC-backed company,
               | or a CTO who's a world-renowned technical expert in a
               | particular field (nobody's bringing Ilya on board for his
               | ability to hire).
               | 
               | But it's very, very easy for people management to be a
               | day-to-day thing and I don't think it's a waste of time
               | compared to direct contributions.
        
               | icedchai wrote:
               | As a former "CTO" at a small company and an early stage
               | employee at several others, hiring was a ton of work for
               | everyone. It was honestly the hardest thing I had to do.
               | However, it was by no means a constant, day-to-day thing.
        
               | BoxFour wrote:
               | More power to you - I easily spent weeks at a times
               | sifting through resumes and interviewing, and even once
               | someone was hired making sure they were onboarding well
               | and feeling well-supported and etc.
               | 
               | By the time everything was humming along we were either
               | raising a new round (and thus hiring more), or someone
               | was leaving and we had to refill that role.
        
           | rpdillon wrote:
           | I think me mentioning a list of responsibilities sort of
           | derailed the conversation a little bit.
           | 
           | It's not about them avoiding what they enjoy. It's about
           | empowering and scaling a human organization to take on larger
           | and larger scope over time. And at a technical company, the
           | CTO is uniquely positioned to understand organizational
           | scalability and technical scalability. So the risk I see with
           | a CTO that focuses predominantly on coding is that they may
           | be neglecting higher impact work that they could be doing
           | that would set the organization up to empower more people to
           | do the kind of work that they think is necessary.
           | 
           | The other risk I observed with a CTO that predominantly codes
           | is that they become a bottleneck and are not actually able to
           | ship the really experimental and product-altering features
           | that they envision, and so they end up handing off
           | essentially half-done ideas to teams who are then responsible
           | for picking up the half-done mess and getting it to something
           | that's suitable for production. I think this is probably
           | avoidable in some way, but I do think it's an intrinsic risk
           | of taking on large projects as a single coder while having
           | other responsibilities to the company.
        
       | willio58 wrote:
       | > 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 wrote:
         | No it isn't. Lots of CTOs don't have reports.
        
           | orliesaurus wrote:
           | really? like who?
        
             | tptacek wrote:
             | 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 wrote:
               | what's the most effective model you've seen?
        
               | tptacek wrote:
               | 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.
        
             | Cpoll wrote:
             | I've been at several companies that have a CTO and a
             | Director of Engineering. The CTO sets the strategy, and the
             | Director of Engineering handles the execution. In theory
             | the Director "reports" to the CTO (I.e. is under in the org
             | chart), but not necessarily. Sometimes the Director reports
             | to the CEO, and/or takes a more collaborative role with the
             | CTO.
        
               | tptacek wrote:
               | This does not apply at my current company, where the CTO
               | has their title as an artifact of how the founding team
               | was structured, but if I was founder/early at a company,
               | progressed to a senior role, and then was told that I
               | should take a role where I "set engineering strategy", I
               | would immediately conclude that I was being managed out.
               | "Strategy", in particular, is the kiss of death.
        
           | dijit wrote:
           | I have a terribly hard time understanding the effectiveness
           | of a CTO who has no reports, especially in a technology
           | company.
        
             | tptacek wrote:
             | What is it that you think a CTO does? There isn't a
             | standard answer to this question.
        
               | kjgkjhfkjf wrote:
               | CTO is usually the exec responsible for the entire tech
               | org. The CTO reports to the CEO, and the top managers and
               | maybe a few ICs in the tech org report to the CTO.
        
               | tomnipotent wrote:
               | It's very common to see a VP of Engineering managing the
               | day-to-day operations while the CTO acts in a capacity
               | like this.
        
               | dijit wrote:
               | I've seen that too, but then the VP of Engineering tends
               | to report to the CTO, and not to- say, the CEO directly.
        
               | tomnipotent wrote:
               | Dotted line reporting is very different. In these
               | instances the VP/E is usually directly interfacing with
               | other executives as the CTO's peer. This is even more
               | true when the budget is managed by the VP/E and the CTO
               | is more customer/sales facing.
        
               | tptacek wrote:
               | You're saying "usually" about something that has
               | definitely not been a norm in my career. It seems like
               | there's really only two ways to interpret that
               | arrangement: either the CTO is in fact the EVP/E (fair
               | enough! lots of CTOs are other exec roles with a funny
               | hat), or the CTO has _a single top-level manager report_
               | , in which case what really happened is that the org
               | hired a pro to run engineering and put the "CTO" out to
               | pasture.
        
               | icedchai wrote:
               | I was CTO of a <20 person startup. I recruited the entire
               | tech team, collaborated with the CEO to build the product
               | backlog and spec things out, presented to investors, but
               | also had at least 50% time to code. Not all "CTO" roles
               | are the same. At a small company they better be hands on.
        
               | tptacek wrote:
               | This is very similar to my own role, but I didn't have
               | (nor would I have accepted) that title.
        
               | icedchai wrote:
               | On my resume, I usually list it as "Lead Engineer" since
               | it fits the roles I'm applying to better.
        
               | tptacek wrote:
               | I think a founder/early gets away with "CTO" on their
               | resume, esp. if they're the only person in the org with
               | the role (ie: it's a PM-style CTO, and there isn't a
               | VP/PM; or: it's a VP/E-style CTO, and there isn't a
               | VP/E). But outside that circumstance, given the choice,
               | I'd rather have the VP/PM or VP/E role than "CTO".
               | 
               | (As we get deeper into these threads I am further out on
               | a limb.)
        
           | stackedinserter wrote:
           | CTO without reports is just a "developer".
        
         | cjblomqvist wrote:
         | 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).
        
         | raw_anon_1111 wrote:
         | 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.
        
           | Thorrez wrote:
           | There are plenty of Principal Engineers (L8) at Google who
           | have no reports. In fact, I think the majority have no
           | reports.
        
             | raw_anon_1111 wrote:
             | Let me clarify. I know there are principals with no
             | directs. I'm more calling out that the "scope" of a
             | principal is a high bar at Big Tech and if he is spending
             | all of his time coding at a startup, I doubt that he is
             | working at the level of a principal at BigTech.
             | 
             | My own anecdote is that the level of work I was doing as an
             | "architect" at a 60 person startup where I was the second
             | technical hire when the new CTO was hired to bring tech
             | leadership in house from a third party consulting company
             | mapped to a mid level L5 consultant at AWS ProServe (to be
             | fair I only had two and a half years of AWS experience at
             | the time I was hired by AWS) and now while I'm a "Staff
             | consultant" at a third party AWS consulting firm with
             | around 1000 people, looking at the leveling guidelines and
             | expectations at my current company, AWS and GCP, it maps to
             | a "senior"
        
             | BoxFour wrote:
             | Most of those engineers, outside of ones who have extremely
             | specialized knowledge or skills, are essentially managing
             | others still just without a direct reporting chain.
             | 
             | The commit log for most of these high-level engineers is
             | extremely sparse. They're spending most of their time
             | writing documents or influencing orgs, not writing code.
        
           | mock-possum wrote:
           | Yeah 60% coding 40% managing juniors is basically what senior
           | dev has looked like me for the past few jobs, even at smaller
           | (~15-30 employees) outfits
        
             | willseth wrote:
             | This is staff, principal, or even EM scope at many orgs. I
             | have never seen anyone with a senior dev title directly
             | managing juniors.
        
         | roenxi wrote:
         | 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.
        
         | indigodaddy wrote:
         | Sounds more like a "distinguished engineer" ?
        
         | mobeigi wrote:
         | 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).
        
         | citizenpaul wrote:
         | 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.
        
       | xpasky wrote:
       | 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.
        
       | herval wrote:
       | 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 wrote:
       | 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 wrote:
         | It depends on what that founder wanted to do! Lots of founders
         | code for the whole ride.
        
       | rubenvanwyk wrote:
       | If you don't have direct reports, why are you "CTO" and not
       | founding or principal engineer?
        
       | bongodongobob wrote:
       | 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.
        
       | raw_anon_1111 wrote:
       | 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 wrote:
         | 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 wrote:
           | 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 wrote:
         | 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.
        
           | justsomehnguy wrote:
           | The self burn is the best burn.
           | 
           | But yes, I've been a CTO with a zero reports and doing
           | everything while working in a company with > 200 employs. And
           | while revenue was fine %he payment was shit.
        
         | cultofmetatron wrote:
         | The role of CTO is more about accountability, responsibility
         | and autonomy.
         | 
         | I try to minimize meetings to the minimum necessary to get
         | everyone on the same page with what our next goal is. From
         | there, I'm right there in the trenches with my team working to
         | get these sprints done. sure, it sounds like a senior lead
         | developer and if you're in a small startup, it kind of is. The
         | CTO part comes in twofold, if the project is falling behind,
         | its on me to figure out whats keeping us from hitting the
         | dealing and resolving it. I've let people go who
         | underperformed. Its also my job to see who's getting burned out
         | and making sure they get some time off so that they can come
         | back refreshed and ready to push again.
         | 
         | Ss far as promise of "equity," Im currnetly pretty happy that I
         | maxed out equity at the beginning.
         | 
         | CTOs come in all shapes and forms
        
           | raw_anon_1111 wrote:
           | And if when you sat for a behavioral interview at a company
           | of any size and they leveled you based on "scope" and
           | "impact", you would be leveled as a senior engineer or a team
           | lead.
           | 
           | And the "two parts" of your responsibility were those of
           | senior/lead devs at the last 60 person company I worked for
           | in 2020.
           | 
           | Equity in private companies is statistically meaningless and
           | will be worthless. I'm at a point in my career where I only
           | care about cash and RSUs in public companies that I can
           | easily sell when they vest
        
         | andy99 wrote:
         | 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.
        
         | IanCal wrote:
         | 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.
        
           | matwood wrote:
           | > If nobody had the space, why? You're a C-suite exec, saying
           | something is clearly valuable, why can't you get someone to
           | work on it for a few days?
           | 
           | As a leader, especially a CxO, the most important job they
           | have is the allocation of resources. It was clearly NOT
           | valuable if they couldn't apply any developer time towards
           | it.
        
         | brabel wrote:
         | How do you concern about strategy all day? Just sit down and
         | think about it?
        
           | dyauspitr wrote:
           | Lots of conversations/meetings. Your job is to know what is
           | happening and strategize accordingly.
        
           | matwood wrote:
           | You read, talk to people and write. Then you get feedback on
           | your writing, and repeat the process.
        
           | motorest wrote:
           | > How do you concern about strategy all day? Just sit down
           | and think about it?
           | 
           | I'm not OP, but whenever your product is implemented by more
           | than one team you will also have the need to coordinate and
           | set strategic goals as well as accompany and steer each team
           | towards where it's infrastructure/tech stack/systems
           | architecture need to be.
           | 
           | If you do not offer guidance and determine technical
           | directions, each engineer working in each team will happily
           | fill the void and do their best to scratch their itch at the
           | expense of the whole company becoming an unmaintainable big
           | ball of mud.
           | 
           | Let's put things differently: what do you expect will be the
           | output of a company if no one is responsible for things like
           | directing the company's R&D effort, coordinate and specify
           | the company's tech roadmap, even oversee product development.
        
           | prmoustache wrote:
           | you read gartner's publication and blindly ask AI to copy
           | paste that info in a memo or powerpoint to pass it on to the
           | middle management without trying to figure out if it makes
           | sense.
           | 
           | At least that is how it looks from the engineers perspective.
        
       | secondcoming wrote:
       | It's amazing that this guy can deliver so much despite only
       | typing with one hand.
        
         | notpachet wrote:
         | This made me laugh. Take my upvote.
        
       | qwertyuiop_ wrote:
       | I am the CTO of zero employees and I code all day.
        
       | gbransgrove wrote:
       | 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.
        
       | firefoxd wrote:
       | 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 wrote:
       | 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 wrote:
         | The backlash is really telling of how bad things have gotten
         | when a Chief Technology Officer coding in a software startup is
         | disqualifying.
        
           | hooverd wrote:
           | 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 wrote:
         | Unfortunately this meme that CTO and other members of executive
         | team only supposed to be doing "thought leadership" is really
         | pervasive now
        
         | BoxFour wrote:
         | 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 wrote:
           | 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.
        
             | BoxFour wrote:
             | > This is not really a good analogy. Tech is different.
             | 
             | Why? Seriously: Give me a convincing reason why tech is
             | different from every other field, where this happens
             | regularly.
             | 
             | > I am not saying you should sit down and write code.
             | 
             | But that's the whole premise of this conversation. It's
             | entirely possible to understand something deeply without
             | doing the thing yourself.
             | 
             | It's entirely possible for a CTO to deeply understand
             | technology without writing any code themselves, opening up
             | a terminal, tinkering with anything, or even what
             | individual contributors are doing day-to-day. I would
             | actually say that's the hallmark of a _good_ CTO.
        
               | submeta wrote:
               | Because one is an intellectual activity, the other is
               | not. You cannot expect the 60+ year old coach to run and
               | train with the team members. But you can as a CTO try out
               | technology, open the terminal, run a docker container to
               | see the technology. Otherwise you are too far away from
               | the things you try to orchestrate. Here the analogy of a
               | master chef comes to mind. She doesn't have to work with
               | her sous-chefs, but it helps to be able to still master
               | the knife, make sushi or make a Creme brulee, or even an
               | omelette. All while mostly focusing on the big picture.
        
       | indigodaddy wrote:
       | Is it common for a CTO to not have any direct reports?
        
         | dilyevsky wrote:
         | 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 wrote:
         | In my experience, yes in startups, and no in large
         | corporations.
        
       | CSMastermind wrote:
       | If your job functions leave you time to code you probably
       | shouldn't have the title of CTO.
        
         | mrbluecoat wrote:
         | A CTO with atrophied skills (or no hands-on technical skills in
         | the first place) can be just as dangerous.
        
       | theptip wrote:
       | 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.)
        
       | iheartrms wrote:
       | I've always wondered: Why did we switch to "code" instead of
       | "program"?
        
       | fsckboy wrote:
       | > _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 wrote:
         | 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 wrote:
           | 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 wrote:
             | 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 wrote:
       | 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.
        
         | ctxc wrote:
         | Flabbergasted to say the least. Dude do your job. Fix the
         | process. Don't set a bad example.
        
         | dilyevsky wrote:
         | > 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
        
           | OccamsMirror wrote:
           | Cowboy development might fly in an early stage startup. But
           | are you even really a CTO or are you just an overpaid mid-
           | level developer?
        
             | CuriouslyC wrote:
             | Just this. CTO title doesn't even make sense until your org
             | is large enough that engineering vision and strategy
             | becomes decoupled from execution.
        
             | mytailorisrich wrote:
             | I think the answer is in the blog:
             | 
             | " _I currently manage no direct reports and ship a lot of
             | code._ "
        
               | ChrisMarshallNY wrote:
               | That's not a role that I'd normally associate with
               | "Chief" anything (which, by definition, means direct
               | reports). More like Principal Engineer, or Architect.
               | 
               | In smaller companies, this is probably fairly normal, but
               | you can't maintain this, as the company grows.
               | 
               | I had a similar path, in my career. I originally started
               | as a regular engineer, in a two-person team, and
               | eventually ended up managing a small team of up to ten
               | engineers.
               | 
               | Towards the end, I couldn't write any code (for the
               | company), at all. I still needed to code, but did so, for
               | volunteer/open-source stuff. I think it made me a better
               | technical leader (I had an employment contract without a
               | clause that interfered with outside coding).
               | 
               | I remember wanting to take an iOS training course, but
               | the company wouldn't support it, so I took vacation, and
               | went on my own dime. I never regretted it, but it was
               | discouraging.
        
               | raw_anon_1111 wrote:
               | The happy medium that the CTO did at the company where I
               | worked where I was the architect guiding the technical
               | direction, he would do non production level experimental
               | coding as research - integrations with third party APIs,
               | see if an AWS service was suitable - to take some of the
               | load off of me hand the code over to me and I cleaned it
               | up and made it production ready and championed it to the
               | rest of the teams.
               | 
               | He still helped accelerate efforts, got his coding fix
               | when he had time, wasn't in the critical path of any
               | work, and he made the entire org better.
        
               | rzzzt wrote:
               | Isn't this the fun part?
        
               | taneq wrote:
               | That's not a CTO, that's a dev.
               | 
               | I was about to ask how someone in the C suite has time to
               | code at all, ever, but here we are.
        
           | prerok wrote:
           | Trouble is, I don't think they'll just get it and then set
           | about to changing the processes. Besides, the process doesn't
           | come from the middle management, it originates from the top,
           | usually the CTO.
        
             | CuriouslyC wrote:
             | Unless you're at a very small company, CTOs set technical
             | vision, choose high level tooling strategy and outline
             | engineering culture in broad strokes, but the nitty gritty
             | of process will be from an engineering director or other
             | role below the CTO. The CTO will probably provide feedback
             | if needed, but they're not in the weeds and won't be able
             | to see problems unless they're raised.
        
               | prerok wrote:
               | You are correct, my post was more for the situation where
               | the CTO is also the engineering director but in larger
               | orgs that is not usually so.
               | 
               | I do think, however, that the coding CTO is not the way
               | to go about to change the process. If it's too
               | cumbersome, the CTO should talk with engineering director
               | to find a way to make it less so, not just bypass the
               | process.
        
               | fooster wrote:
               | Surely there is room for both. Most people don't found
               | companies because they want to sit around on their ass.
               | They're typically driven and do'ers. If things are not
               | working as they want, and folks are not being responsive
               | enough... they'll do it themselves and that is ok. After
               | all THEY founded the company.
        
               | paulryanrogers wrote:
               | > If things are not working as they want, and folks are
               | not being responsive enough... they'll do it themselves
               | and that is ok.
               | 
               | If the CTO has rank then why not work to solve the
               | unresponsiveness or undesirable things?
               | 
               | If someone--even a founder--can act as a loose cannon
               | then there is a risk that they'll introduce problems like
               | instability, security vulnerabilities, or unnecessary
               | conflict or resentment. Compliance programs like SOC and
               | PCI don't look fondly on staff bypassing SDLC processes
               | because of those risks.
        
             | whstl wrote:
             | Exactly. Why change a process when you can be a superstar
             | by ignoring it?
             | 
             | Fuck the customers, fuck the employees, fuck the investors.
             | My ego is more important than any of this.
        
             | dilyevsky wrote:
             | Well if they dont and you have to demonstrate that again
             | and again, then you know what to do and hopefully have the
             | power to do it.
             | 
             | > Besides, the process doesn't come from the middle
             | management, it originates from the top, usually the CTO.
             | 
             | Not ime
        
           | wiseowise wrote:
           | You need to exercise your god given right to mog goons below
           | you.
           | 
           | Show everyone that system (that you've created) is shit and
           | when some lowly SE thinks he's above them all, you publicly
           | flay him and make example for all that you're the god
           | emperor.
           | 
           | Business value? The ego trip is a business value!
        
             | dilyevsky wrote:
             | God forbid you'd actually have to do any real work when
             | there's so many design, retro, and daily sync meetings to
             | attend and so many jira issues to groom.
        
               | shortrounddev2 wrote:
               | Ive worked on both ends of the spectrum and id prefer too
               | much process to too little
               | 
               | With too little process, people release bugs that I then
               | have to scramble to fix. The CEO who pushed to skip QA
               | and unit testing and everything in the name of release
               | never has to deal with the consequences of their
               | impatience
        
               | zdragnar wrote:
               | That same CEO would likely also push to have all of the
               | things including no bugs, then complain people aren't
               | productive enough when arbitrary and unrealistic
               | deadlines aren't met.
               | 
               | Source: my personal experience. Very few of the managers
               | who can code that I've worked with were better than any
               | of the ones who couldn't, and those who did actively code
               | while managing were universally worse.
        
               | ambicapter wrote:
               | You're conveniently skipping over the fact that he has
               | full control over those things. He is the CHIEF
               | Technology Officer.
        
               | dilyevsky wrote:
               | Only indirectly (through management) and still having
               | control is exactly my point. Obviously if you need to do
               | that over and over there're some other actions need to be
               | taken
        
           | KaiserPro wrote:
           | > This is exactly what someone who can't be easily unseated
           | should be doing at a company
           | 
           | I mean yeah, but hes the fucking CTO. If hes the CTO, _he_ is
           | responsible for that process. Its his job to evolve it to
           | make it fit for purpose.
           | 
           | What he's done is basically created a whole bunch of process
           | debt, which is much harder to correct than tech debt.
        
         | jumploops wrote:
         | > regularly checking in code on Saturdays and Sundays
         | 
         | If you're working on insurance SaaS, I agree.
         | 
         | If you're building hard tech, I'd disagree entirely.
        
         | stuffn wrote:
         | 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.
        
           | brabel wrote:
           | So in your view c-level are all sociopaths? Let me guess you
           | are not c-level. Or maybe you are but you're the exception to
           | the rule.
        
             | immibis wrote:
             | Hasn't it been repeatedly shown that C-level positions
             | select for sociopaths?
        
         | manquer wrote:
         | I code as a founder/CTO on weekends, I don't expect weekend
         | work done by anyone else and most people rarely check in if
         | ever on weekends.
         | 
         | The job profile of founder-CTO has not a lot of overlap with
         | that of an individual contributor to be leading by example, the
         | overlap is quite narrow even for senior engineering leadership.
         | 
         | Until recently[3] leaders with prior coding skills were always
         | discouraged from code contributions and focus on management
         | exclusively, for all the reasons some of them you describe.
         | 
         | --
         | 
         | I usually say that I am a part-time coder, not a professional
         | one, and caution not to look at what I do as a benchmark or
         | signal.
         | 
         | Vast majority of the code I write are DevEx or QoL for internal
         | teams[4], or refactor tech debt that no one has time to deal
         | with. Even mid-stage startups may not be large enough to invest
         | in dedicated teams for this type of work.
         | 
         | Occasionally I have written such integrations like OP[1]. It is
         | typically a PoC for a demo, never a production one to actual
         | customers. It would be unfair (and failure prone) to expect
         | anyone else to start supporting a production integration
         | without the full tooling or documentation.
         | 
         | --
         | 
         | I agree it is a fine-line and you can err on the wrong side of
         | it. It is easy and tempting to start focusing on production
         | code and lose focus of the core job, but so many decisions as a
         | founder are like that. I am hardly the best or optimal founder-
         | CTO. However the value of being close to the metal is important
         | and worth some risk in early to mid stage startups.
         | 
         | Perhaps there is also value in a CTO who understands what
         | individual contributors are doing and is able to be more
         | realistic about outcomes instead of being purely few layers
         | above and not clued in.
         | 
         | --
         | 
         | [1] Not skipping legal that seems ridiculous, even if I wanted
         | to, I can't imagine any partner would agree to it.
         | 
         | [3] Now I do encourage to try the new tools, it is not they
         | contribute to production or be an IC, it is to get a sense of
         | what is possible and what is not today. A lot of pipe-dreams
         | are being sold in the industry, without hands on experience
         | using the new tools ( which are rapidly evolving) managers can
         | tend to overestimate or misunderstand what is doable.
         | 
         | [4]This is the core of the CTO job, writing code is rarely the
         | bottleneck for productivity that was true even before
         | generative coding tools, it is everything around that which
         | creates friction. If you can reduce it, even writing some code
         | to do so, it shouldn't be a problem or a flag.
         | 
         | - Edited for brevity(some).
        
           | raw_anon_1111 wrote:
           | If you want to work on the weekend - and occasionally I find
           | myself doing so as a staff level IC consultant who does need
           | to spend an inordinate amount of time mentoring, project
           | management, suppprting sales, interviewing candidates,
           | babysitting clients, etc... - _don't_ send messages on Slack
           | or email outside of business hours. I schedule messages to go
           | out Monday morning and I never mention I worked on the
           | weekend.
           | 
           | I don't want to set the expectation that people should work
           | outside of business hours or that I'm willing to.
        
             | manquer wrote:
             | I kill slack app on weekends , that is largely to save
             | battery on the laptop working out of coffee shops, but
             | serves the same purpose :)
        
         | xnx wrote:
         | The "C" stands for "Cowboy"
        
         | sa-code wrote:
         | > 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
        
           | lqstuart wrote:
           | Hahaha I would have led with this honestly.
           | 
           | I'm the chief legal officer but at the end of the day I'm
           | just like bruh, chill, who gives a shit
        
           | dbbk wrote:
           | Then why are you the CTO!!
           | 
           | Dude just wants to be a staff engineer
        
             | Lio wrote:
             | Maybe. If he's a technical founder though what other
             | position would you hold?
        
               | senorrib wrote:
               | Staff engineer. Founders don't necessarily need to hold
               | CXO titles to work in the startups they founded.
        
               | SJMG wrote:
               | A few examples that spring to mind, Steve Wozniak and
               | Mitchell Hashimoto
        
               | doctorleff wrote:
               | I recall James Goodnight of SAS coding while being a CEO.
               | As per
               | https://www.forbes.com/sites/peterhigh/2014/05/12/an-
               | intervi..., he still programs from time to time but
               | doesn't have a specific part in development. In looking
               | at the articles to refresh my memory, it is clear he is
               | one of the good CEO's
        
               | eitally wrote:
               | I don't think that's the model we should be looking at
               | here. I'd add Stephen Wolfram to the very short list of
               | similar technical CEOs.
        
               | obiefernandez wrote:
               | Tobi Luetke at Shopify too
        
               | tanjtanjtanj wrote:
               | Wasn't Mitchell Hashimoto only a non-CxO for a handful of
               | months between stepping down and selling the company?
        
               | SJMG wrote:
               | I'm not that familiar with his employment history; you
               | could be right. Either way, he'd still be an example. If
               | you have longer term ones, I'm sure it would add to the
               | discussion
        
               | noleary wrote:
               | It's not that uncommon to keep the "CTO" title and not be
               | the primary manager of the engineering organization.
               | There are all kinds of things you can do with the org
               | chart. If I recall correctly, Clickhouse works this way.
               | 
               | The company's cofounders comprise three people [1]:
               | 
               | * Aaron, a sales-oriented CEO from Elastic and Salesforce
               | 
               | * Alexey, the original Clickhouse developer, as CTO
               | 
               | * Yury, an experienced engineering executive from
               | Google/Netflix as "President"
               | 
               | An excerpt from the launch announcement [2]:
               | 
               | > While negotiations were still ongoing, Katz decided
               | they needed a third co-founder. "I kept thinking, if I
               | could get a third co-founder to run product and
               | engineering, and if I could find someone with the same
               | level of experience building distributed systems on open-
               | source that I have on go-to-market, it could be a really
               | compelling combination," Katz says.
               | 
               | ---
               | 
               | ---
               | 
               | [1] https://clickhouse.com/company/our-story
               | 
               | [2] https://www.indexventures.com/perspectives/the-fast-
               | and-the-...
        
             | libraryofbabel wrote:
             | He mentions he has nobody reporting to him. That sounds
             | like he's really a staff engineer with a vanity CTO title,
             | plus a lot of sway in strategic decision making.
             | 
             | It's not a _guaranteed_ recipe for disaster, but it depends
             | critically on his relationship with whoever actually
             | _manages_ the engineering org. If they don't pull in the
             | same direction, things go south very quickly and you end up
             | with a little civil war.
             | 
             | Either way it's a red flag and I wouldn't work there.
             | Another red flag is that he wrote this blog post at all.
             | Given how clearly negative the reaction to it was going to
             | be, it's a strong signal he doesn't really think things
             | through and has a ego wrapped up in his "coding" prowess
             | and ability to circumvent process. People mention Woz as an
             | example of a technical co-founder in a non-management role,
             | but he is a humble guy and wouldn't brag like this.
        
             | cantor_S_drug wrote:
             | How big is assembled in terms of headcount? That should
             | resolve most of the questions we are raising.
        
               | boulos wrote:
               | LinkedIn suggests "50-200". 54 work in San Francisco, and
               | 154 people are associated with it. So probably closer to
               | 150, but that includes a lot of Sales and Marketing
               | related roles. Maybe the "engineering" org is ~100 or
               | just under that.
        
             | rgbrgb wrote:
             | FWIW Carmack did this as CTO of Oculus [0]. Also pretty
             | common for CTO to have like 1 direct (VP Eng) who does
             | actual eng managing. You could argue it's a staff engineer
             | role but I've never seen staff engineers actually get much
             | say over org direction/structure or be empowered to break
             | gridlock like this.
             | 
             | [0]: https://www.uploadvr.com/john-carmacks-app-reviews-
             | series/
        
           | eitally wrote:
           | This can work, imho, IFF the organization has both a CTO and
           | CIO (or someone else tasked with managing the org). I've seen
           | lots of places where the CTO is purely the technical
           | visionary/advisor/final decision maker, and doesn't directly
           | manage the technical organization.
           | 
           | This scenario is far more common outside of the tech
           | industry, where you usually have a CIO running the IT cost
           | center, and a CTO making decisions about technology adoption
           | strategy.
        
             | ghaff wrote:
             | CTO, CIO, and the head of engineering (the latter of which
             | can often be split among different groups) are often very
             | distinct things, especially at larger companies. And, yes,
             | while the CTO probably has a seat at the table for
             | technology direction is often primarily a public technology
             | face of the company as opposed to someone involved in a lot
             | of hands-on day to day technology implementation.
        
               | LgWoodenBadger wrote:
               | "Probably has a seat at the table for technology
               | direction" is a wild take to me. So much so that I can't
               | even formulate a response other than "what...?!"
        
               | ghaff wrote:
               | I'm not sure what you find confusing. Someone can have an
               | advisory and essentially technology evangelist role
               | without necessarily being the ultimate decision maker.
               | (And, at a larger company, a variety of folks--including
               | the board--will ultimately make final consequential
               | decisions.)
        
               | acron0 wrote:
               | How can the Chief Technical Officer not be the one
               | chiefly responsible for technology decisions?
        
               | ghaff wrote:
               | Because, title notwithstanding, they may not be the
               | person solely responsible for technical decisions
               | especially at the detailed (or macro) level.
        
               | ludwik wrote:
               | There is a big leap between them not being the sole
               | person responsible for technical decisions and them not
               | even necessarily having a seat at the table for
               | technology direction. The former is understandable. Later
               | - quite surprising.
        
               | ghaff wrote:
               | I'm not sure what I wrote that's contrary to any of that?
               | Maybe I shouldn't have used the word "probably"? There
               | are a lot of people responsible for the technical
               | direction of a large company of which the CTO is
               | important but hardly the only one.
        
               | YZF wrote:
               | I thought it's typically Chief Technology Officer
               | 
               | In most companies I've been a part off, including
               | multiple >$1B tech companies, the CTO's focus is not on
               | the engineering. That's the job of a VP Engineering or
               | some similar position.
               | 
               | CTO (which will sometimes have a "CTO office") is to work
               | besides the engineering on investigating new technologies
               | and ideas that are beyond what the engineering
               | organization would have otherwise done on the day to day.
               | They are also an authority on all technology in the
               | company but are not in the engineering "chain of
               | command".
               | 
               | That said this is not universal, there are organizations
               | where the CTO does lead the engineering organization. I
               | think that's sub-optimal because there is always going to
               | be tension between the day to day and the broader scope
               | and those should be different roles.
               | 
               | In a startup, it is more common for a CTO to lead
               | engineering because there is not yet enough to justify
               | having both a VP Eng and a CTO and perhaps most of the
               | work is around figuring out technologies. But as the
               | company grows it makes sense to separate those functions.
        
               | ghaff wrote:
               | I've seen both. A CTO office that also leads engineering
               | --typically via a direct report to the CTO--and an
               | organization where the CTO is largely an external
               | evangelist (typically with a small staff) while
               | engineering is a separate organization--though hopefully
               | aligned. The view here where CTO is also the head of day-
               | to-day engineering operations and technical vision is
               | more of a small company/startup thing. The two are often
               | separated to at least some degree at larger operations.
        
             | richardlblair wrote:
             | The technical capacity of a CTO matters less then the CTOs
             | ability to stay in their lane (for a lack of a better
             | term).
             | 
             | I once worked for a company with a self taught CTO (and not
             | the good kind). They had a number of star players, and this
             | CTO would frequently lash out at them. All because he was
             | getting in the way of them doing their jobs, doing work he
             | wasn't qualified to do, trying forcing them to clean up
             | after him, and then yelling at them for it. It was insanely
             | toxic. I only lasted a few months. It was so bad I back
             | channelled patches and project briefs to people he liked to
             | get them approved.
             | 
             | Had this CTO remained people, project and product focused
             | everything would have been fine.
        
               | whstl wrote:
               | _> this CTO would frequently lash out at them [...] doing
               | work he wasn 't qualified to do, trying forcing them to
               | clean up after him [...] and then yelling at them for it_
               | 
               | Was that a Fintech in Germany, by any chance? :)
               | 
               | I once witnessed a meeting between a CTO and a Tech Lead.
               | The CTO was attending from his laptop in an open office,
               | and he was yelling in Russian for one hour straight at
               | another Tech Lead because he wanted the tech lead to
               | finish his work. It was a pathetic display, with the
               | whole company watching and wondering what was going on.
               | 
               | Eventually he was "phased out" by having a few people
               | promoted to VP of engineering who would deal directly
               | with the CEO instead of him.
               | 
               | Last I heard he tried to rewrite the financial core in
               | Golang by himself, but he failed since nobody wanted to
               | work together with him and he doesn't really knew the
               | language.
        
             | straydusk wrote:
             | You're not describing a CTO, then
        
           | wonderwonder wrote:
           | Also: "I currently manage no direct reports and ship a lot of
           | code." So essentially he is just a staff engineer with a
           | fancy title
        
           | santoshalper wrote:
           | Dude is a staff engineer, not a CTO.
        
           | johnjwang wrote:
           | (Author here) I stand by this comment and I think it's really
           | important for engineers to recognize that everyone has
           | different places where they gain and lose energy.
           | 
           | My team and I have been extremely lucky in hiring Joe, our
           | excellent head of engineering, and an extremely strong set of
           | engineering managers. Not to mention incredibly strong
           | product and user experience management.
           | 
           | I think it's pretty obvious that my approach wouldn't work if
           | I didn't have this bench of talented managers, but because I
           | do it affords me the luxury to spend time doing things that I
           | love and which are also valuable to the company.
           | 
           | In general, I wrote this article because I think that the
           | classical approach to engineering management isn't the only
           | path you need to take, and a lot depends on the team you work
           | with (thankfully we have a team that complements each other
           | really well).
        
             | Kudos wrote:
             | You mention in the article you have no direct reports. Who
             | does engineering report into in that case?
        
             | godzillabrennus wrote:
             | I'm glad you are comfortable coming forward and for sharing
             | your thoughts. Not to pile on with the others here but you
             | may go fast alone but you go far together when you build
             | the right team. Being an individual contributor CTO is not
             | being a CTO for a business that succeeds at scale. Don't
             | stop doing what you love if you feel that's more important
             | but it's probably best to step back from being a CTO and
             | hire someone to manage that role so you can code if you
             | don't want to do the job.
        
           | 333c wrote:
           | I would say that's the job of a CTO
        
         | jaccola wrote:
         | Regarding culture:
         | 
         | Complete nonsense. The free market will tell him if he can do
         | this or not. If he can get valid candidates pushing this
         | culture and it's legal, why shouldn't he? You, anyone
         | interviewing there or anyone working at their company
         | presumably doesn't have to work there. Most countries don't
         | have slavery for tech jobs!
         | 
         | No doubt he will lose many candidates with this culture (you
         | and I included) but maybe that's a strategy? Maybe he still
         | gets plenty of candidates that are good and the culture he
         | wants.
        
         | mdrachuk wrote:
         | > 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.
        
         | cloudhead wrote:
         | 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."
        
         | mritchie712 wrote:
         | 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.
        
           | switz wrote:
           | No, he clearly points that anyone else would have to be taken
           | off their existing work and would have to context-switch to
           | the context he _already_ has. That 's not trashing his
           | engineering team.
        
         | swaits wrote:
         | Don't just back away _slowly_. Run for your life!
         | 
         | Prediction: this is the part of the AI boom that goes bust.
        
         | Rover222 wrote:
         | 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)
        
         | dangoodmanUT wrote:
         | 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.
        
           | fogzen wrote:
           | Working at a startup can be rewarding, but it often means
           | putting in founder-level effort while the founders capture
           | most of the upside.
        
           | paholg wrote:
           | At an early stage startup, shipping a feature should not
           | require "many meetings across product, legal, and
           | engineering". Especially not one that can be mostly built in
           | a day.
        
           | cantor_S_drug wrote:
           | Snake-style org vs Elephant-style org. Nature accomodates lot
           | of survival strategies. People shouldn't unnecessarily
           | criticize others.
        
         | singleshot_ wrote:
         | 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.
        
         | varispeed wrote:
         | 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.
        
         | 999900000999 wrote:
         | > During Thanksgiving break, I just decided to build it and
         | knocked out a prototype.
         | 
         | You don't want a boss that works on Thanksgiving and thus
         | probably expects you to as well ?
         | 
         | I'd actually be ok with this if bro offered half a million
         | total comp. I'll deal with it for 5 years and then retire.
        
         | KaiserPro wrote:
         | > 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.
        
         | yieldcrv wrote:
         | > foregoing required legal
         | 
         | depending on the legal requirement it may not have been
         | foregoed but instead became legal because an executive did it
        
           | sokoloff wrote:
           | I took that a step farther and got written into our SOX
           | compliance processes explicit "deviate from normal processes
           | as much as required when this short list of people declare an
           | emergency", shamelessly cribbed from aviation law.
           | 
           | Slightly more details here:
           | https://news.ycombinator.com/item?id=39174707
        
         | sokoloff wrote:
         | 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.
        
         | whiplash451 wrote:
         | > I built and shipped a working version in a day.
         | 
         | If I were an engineer working under a CTO doing this, I'd find
         | it extremely demotivating.
         | 
         | Why, as a CTO, are you not setting things up so that _I_ can do
         | it instead?
        
         | johnjwang wrote:
         | (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.
        
           | ketamine wrote:
           | I'm guessing you are ~28, maybe married and no kids.
        
         | scrubs wrote:
         | 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.
        
       | bargainbin wrote:
       | Stopped reading at "CTO with no direct reports". Chief of who?
        
       | kittikitti wrote:
       | 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 wrote:
         | 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 wrote:
         | 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 wrote:
       | I like to code as a cat. Coding as a dog is ruffer though.
        
       | mobeigi wrote:
       | 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 wrote:
         | 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 wrote:
         | If you are Founder/CEO/CTO of a company it could be up to them
         | to define what their workday looks like though.
        
         | CuriouslyC wrote:
         | 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 wrote:
           | 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 wrote:
       | > 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.
        
       | mrasong wrote:
       | 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 wrote:
       | 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.
        
         | guilhermesfc wrote:
         | I wish I worked for you!
        
       | vader_n wrote:
       | I hate fluff pieces, self promoting garbage.
        
       | xedarius wrote:
       | Pricing section of your website has no prices, I'd suggest
       | calling that section something else.
        
       | sharts wrote:
       | This may as well be titled "Why I code...as an ex-Google
       | Millionaire."
       | 
       | Because that's how ridiculous this person is.
        
       | xrd wrote:
       | 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 wrote:
         | There are lots of different types of CTO. Who are you to say
         | which is right and which is wrong?
        
           | stackedinserter wrote:
           | Who said a janitor can't call himself a CTO?
        
       | zkmon wrote:
       | 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 wrote:
         | > 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 wrote:
           | 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 wrote:
             | 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.
        
       | lonelyprograMer wrote:
       | Summary: CTO of a small company codes. I don't see any issues,
       | and it's not surprising.
        
         | Cyclone_ wrote:
         | I've heard of plenty of CTOs coding at small startups, but the
         | surprising part is he has no direct reports.
        
       | andsoitis wrote:
       | 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 wrote:
       | This reads like an engineer that got promoted to his level of
       | incompetence.
        
       | gdsdfe wrote:
       | 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 wrote:
       | 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 wrote:
       | 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 wrote:
         | 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 wrote:
       | 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 wrote:
       | 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.
        
       | habosa wrote:
       | 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.
        
       | alexnewman wrote:
       | 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 wrote:
       | This is just a pride post with little self awareness.
        
       | dccoolgai wrote:
       | 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 wrote:
       | 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 wrote:
         | 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 thing. 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 wrote:
       | 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 wrote:
       | wait i thought amd changed their logo and wondering why their cto
       | is coding.
        
       | lazyant wrote:
       | 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 wrote:
       | 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.
        
       | LouisSayers wrote:
       | 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 wrote:
       | 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 wrote:
       | 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 wrote:
       | > 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 wrote:
       | A yet this people still exist.
       | 
       | I will say it over and over. Do not code as a CTO.
        
       | hacb wrote:
       | I don't want my CTO to code, I want my CTO to have a clear vision
       | and listen to engineers
        
       | holoduke wrote:
       | 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 wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2025-10-26 23:01 UTC)