Assembled CTO John Wang on why coding makes him a better leader—and how AI tools are redefining what it means to build at scale.
Many CTOs I know stopped writing code years ago. The conventional wisdom is that as you become more and more senior, the less and less code you write until eventually you’re spending your days in back-to-back meetings.
That’s not how I operate. In fact, here’s what my last 12 months have looked like:
I currently manage no direct reports and ship a lot of code. Not in an “I dabble when I have free time in between meetings” way, but in an “I shipped multiple substantial features last quarter” way.
I think it’s one of the highest-leverage things I do as a technical leader.
What I actually build
People assume CTOs who code are either working on pet projects that never ship or doing ceremonial code reviews. That hasn’t been my experience. The code I write falls into three pretty distinct categories, each valuable for different reasons.
Long-horizon experimental projects
The number of people in an organization who can ship and build substantially new things is actually a scarce resource. Organizations are generally organisms built in a way to maintain status quo and scale current products. I've found there are only a handful of people (founders, a few executives, some really high leverage ICs) who are able to generate new products. 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.
I can. And I’m uniquely positioned to take these meaty experimental projects on as I know the customer pain and the architecture well enough to move fast.
I've had my share of duds, but I've also had some huge hits. 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. During Thanksgiving break, I just decided to build it and knocked out a prototype. I then worked with the team to productionize it into a multi-million dollar ARR product.
Critical customer asks that needed to be done yesterday
Sometimes a key customer needs something urgently and it becomes a blocker for a major deal or renewal. These situations require someone who can move fast, understands the full system, and can make pragmatic trade-offs.
Instead of pulling an engineer off their current sprint, I can often cut through the noise. I already have the context and I know the stakes.
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. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.
Bugfixes (the surprising one)
People are often shocked by this, but I fix a lot of bugs! And bugfixing is one of my favorite ways to maintain a mental map of our codebase.
When you're hunting down why pagination breaks on the third page of search results, or why WebSocket connections drop after exactly 60 seconds, you traverse huge swaths of the system. You get a visceral understanding of technical debt that's hard to get from code reviews or architecture discussions. This mental map helps me make better decisions about technical investments and where the team should focus.
Why I code
That’s what I ship. Here’s why I structure my role this way:
It keeps me up to date with what actually works
I use Claude Code, Codex, Cursor, and a bunch of other AI tools daily. This experience lets me understand what’s real and what’s bullshit when making strategic decisions about tooling and hiring.
Here’s a recent example: I spent hours this weekend trying to vibe-coding a feature that touched a few gnarly integrations, but made way more progress when I finally sat down and wrote it mostly by hand. It wasn’t very much code, but it had to be the exact right logic (terrible for LLMs). On the other hand, I’ve shipped a big feature almost entirely with Claude Code. Knowing where AI shines (crud, tests, boilerplate) and where it fails (precision, system nuance) always beats making decisions based on Twitter hype.
Being in the code also lets me know when to push and when to let off the gas. I can sense when architectures are overly complex or when technical debt is becoming a real problem. I’ve seen managers who rely only on what people tell them, and they can miss a lot. When you’re in the code, you develop an intuition for what’s real.
Because it’s what I love and what I’m good at
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.
That’s why we’ve hired great engineering managers and leaders. They’re better at it than I am, and they enjoy it. This lets me focus on the things that I love: building things, solving technical problems, and writing code.
Startups are kind of like a sprinting marathon, so I design my role around the work that keeps me excited and ready to run fast for a long time. That’s how I can continue doing this for years, which matters a lot for the company.
AI tools have changed the leverage I have
A few years ago, I struggled to find time to code while handling the strategic parts of my job. As the company grew, I was basically stuck in meetings all day, and I was operating outside my zone of genius. It was one of the toughest periods for me professionally.
But modern AI tools have fundamentally changed this equation (especially in the last few months). I’m probably 2–3x more productive than before. These tools haven’t replaced my judgment or technical knowledge, they’ve actually made those skills more valuable.
I can tell an AI tool, “Build a data export that matches the format of our existing CSV exports but includes these three additional fields from the user profile table,” and it’ll generate most of the code correctly because I know exactly what I need and where to find it. An engineer unfamiliar with that part of the codebase would spend quite a lot of time figuring out those details.
The job has shifted from “writing every line of code” to “providing context, making decisions, and evaluating solutions.” And luckily, I have a lot of context.
Figuring out what works for you
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.
But this is my particular path, not a prescription. The CTO role is remarkably flexible. Whether building orgs, or developing product strategy, or something else — technical leadership varies depending on your strengths, what energizes you, and what your company needs.
If you’re an engineer worried that leadership means abandoning technical work, know that there are many paths. The key is figuring out where you’re uniquely great.
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.
Thanks to Calvin French-Owen, Dan Robinson, Dave Story, and Cai Wangwilt for helping me hone my thoughts on this topic and to Whitney Beyer for reading drafts of this.
Read the original article
Comments
By CobrastanJorji 2025-10-265:2725 reply Man, if I'm trying to decide which company to work for, and I see a blog post from its CTO crowing about regularly checking in code on Saturdays and Sundays, I'd start backing slowly away. And when I got to the bit that said "AI has made me three times as productive," I'd turn and run.
Your job at the top is, more than anything else, pushing down a healthy culture. That includes things like setting an example of not working through the weekend. If you're doing it, your reports and their reports will feel the need to do it, too. Don't. And if you do anyway, certainly don't brag about it!
And then listen to this insanity:
> Our team had considered potentially having the customer build their own integration on top of our API in order to get around this requirement, and scoping it out properly would have required many meetings across product, legal, and engineering. I built and shipped a working version in a day. It wasn’t perfect, but it solved their immediate problem and preserved goodwill with the customer.
That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute, but, being above that process, you personally choose to circumvent it, foregoing required legal or engineering reviews, and shipping it immediately to your critically important customer? If one of the engineers who worked under you did that, you'd probably have fired him.
> I don’t particularly enjoy building orgs and figuring out people stuff. Engineering management involves navigating interpersonal dynamics, performance reviews, and organizational design. These are crucial functions, but they’re not where my strengths lie.
This bit got me. It's a direct quote from the linked post for those who haven't read it
(Author here) I stand by this comment and I think it’s really important for engineers to recognize that everyone has different places where they gain and lose energy.
My team and I have been extremely lucky in hiring Joe, our excellent head of engineering, and an extremely strong set of engineering managers. Not to mention incredibly strong product and user experience management.
I think it’s pretty obvious that my approach wouldn’t work if I didn’t have this bench of talented managers, but because I do it affords me the luxury to spend time doing things that I love and which are also valuable to the company.
In general, I wrote this article because I think that the classical approach to engineering management isn’t the only path you need to take, and a lot depends on the team you work with (thankfully we have a team that complements each other really well).
By godzillabrennus 2025-10-2622:27 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.
By Kudos 2025-10-2622:18 You mention in the article you have no direct reports. Who does engineering report into in that case?
By chipsrafferty 2025-10-271:49 It sounds like you are CTO in title only
By wonderwonder 2025-10-2615:231 reply 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
By tech_tuna 2025-10-3112:21 Also, probably an asshole
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.
By icedchai 2025-10-2714:55 "CTO" is defined by whoever confers the title and accepts the role. Titles are often vague and amorphous.
By richardlblair 2025-10-2619:162 reply 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.
By whstl 2025-10-2619:38 > 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.
By Greed 2025-10-2718:16 Self taught in the programming sense, or the people management sense? Because I feel like the letter is much more common than not in software. Just curious in case there's an expected background you're thinking of when you say that. I have no point of reference for CTO backgrounds beyond generic MBAs or senior devs that either gave themselves the titles as founders or failed upwards.
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.
By LgWoodenBadger 2025-10-2616:581 reply “Probably has a seat at the table for technology direction” is a wild take to me. So much so that I can’t even formulate a response other than “what…?!”
I'm not sure what you find confusing. Someone can have an advisory and essentially technology evangelist role without necessarily being the ultimate decision maker. (And, at a larger company, a variety of folks--including the board--will ultimately make final consequential decisions.)
How can the Chief Technical Officer not be the one chiefly responsible for technology decisions?
I thought it's typically Chief Technology Officer
In most companies I've been a part off, including multiple >$1B tech companies, the CTO's focus is not on the engineering. That's the job of a VP Engineering or some similar position.
CTO (which will sometimes have a "CTO office") is to work besides the engineering on investigating new technologies and ideas that are beyond what the engineering organization would have otherwise done on the day to day. They are also an authority on all technology in the company but are not in the engineering "chain of command".
That said this is not universal, there are organizations where the CTO does lead the engineering organization. I think that's sub-optimal because there is always going to be tension between the day to day and the broader scope and those should be different roles.
In a startup, it is more common for a CTO to lead engineering because there is not yet enough to justify having both a VP Eng and a CTO and perhaps most of the work is around figuring out technologies. But as the company grows it makes sense to separate those functions.
By ghaff 2025-10-2622:04 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.
By sponaugle 2025-10-2715:14 This description is accurate to what I have seen and what I do. I'm a CTO of a >$1B tech company, and my roles is focused around the technology innovation, and that includes evaluating and prototyping new tech. In my particular case that role also includes the operation of our technology because that is very central to our business - and also extremely focused on high reliability.
When I was CTO of my startup I had far more direct engineering development work, but that is typical in the building stage.
As for the core of this post, the one thing I do agree with is the ability of the CTO to actually be technical. I write code all of the time, but not for our products. The goal is to remain both technically proficient but also focus that proficiency on leadership.
Because, title notwithstanding, they may not be the person solely responsible for technical decisions especially at the detailed (or macro) level.
There is a big leap between them not being the sole person responsible for technical decisions and them not even necessarily having a seat at the table for technology direction. The former is understandable. Later - quite surprising.
By ghaff 2025-10-2621:31 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.
By tech_tuna 2025-10-3112:24 I worked at company where the VP of engineering regularly stated that he "hated managing people". This is also the same guy who literally deleted the main production database because he was testing something out.
By libraryofbabel 2025-10-2613:541 reply 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.
By cantor_S_drug 2025-10-2616:341 reply How big is assembled in terms of headcount? That should resolve most of the questions we are raising.
By boulos 2025-10-2617:17 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.
By rgbrgb 2025-10-2622:36 FWIW Carmack did this as CTO of Oculus [0]. Another configuration I've seen is for the CTO to have like 1 direct (VP Eng) who does actual eng managing. You could argue it's a staff engineer role but I've never seen staff engineers actually get much say over org direction/structure or be empowered to break gridlock like this.
[0]: https://www.uploadvr.com/john-carmacks-app-reviews-series/
Maybe. If he’s a technical founder though what other position would you hold?
By noleary 2025-10-2613:38 It's not that uncommon to keep the "CTO" title and not be the primary manager of the engineering organization. There are all kinds of things you can do with the org chart. If I recall correctly, Clickhouse works this way.
The company's cofounders comprise three people [1]:
* Aaron, a sales-oriented CEO from Elastic and Salesforce
* Alexey, the original Clickhouse developer, as CTO
* Yury, an experienced engineering executive from Google/Netflix as "President"
An excerpt from the launch announcement [2]:
> While negotiations were still ongoing, Katz decided they needed a third co-founder. “I kept thinking, if I could get a third co-founder to run product and engineering, and if I could find someone with the same level of experience building distributed systems on open-source that I have on go-to-market, it could be a really compelling combination,” Katz says.
---
---
[1] https://clickhouse.com/company/our-story
[2] https://www.indexventures.com/perspectives/the-fast-and-the-...
Staff engineer. Founders don’t necessarily need to hold CXO titles to work in the startups they founded.
A few examples that spring to mind, Steve Wozniak and Mitchell Hashimoto
By tanjtanjtanj 2025-10-2615:181 reply Wasn't Mitchell Hashimoto only a non-CxO for a handful of months between stepping down and selling the company?
By SJMG 2025-10-2619:55 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
By doctorleff 2025-10-2613:261 reply I recall James Goodnight of SAS coding while being a CEO. As per https://www.forbes.com/sites/peterhigh/2014/05/12/an-intervi..., he still programs from time to time but doesn't have a specific part in development. In looking at the articles to refresh my memory, it is clear he is one of the good CEO's
I don't think that's the model we should be looking at here. I'd add Stephen Wolfram to the very short list of similar technical CEOs.
By obiefernandez 2025-10-2614:48 Tobi Luetke at Shopify too
By lqstuart 2025-10-2610:26 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
By 333c 2025-10-2622:54 I would say that's the job of a CTO
By santoshalper 2025-10-2615:53 Dude is a staff engineer, not a CTO.
> That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well
You need to exercise your god given right to mog goons below you.
Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.
Business value? The ego trip is a business value!
God forbid you'd actually have to do any real work when there's so many design, retro, and daily sync meetings to attend and so many jira issues to groom.
By ambicapter 2025-10-2617:161 reply You're conveniently skipping over the fact that he has full control over those things. He is the CHIEF Technology Officer.
By dilyevsky 2025-10-2617:26 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
By shortrounddev2 2025-10-2612:531 reply 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
By zdragnar 2025-10-2615:01 That same CEO would likely also push to have all of the things including no bugs, then complain people aren't productive enough when arbitrary and unrealistic deadlines aren't met.
Source: my personal experience. Very few of the managers who can code that I've worked with were better than any of the ones who couldn't, and those who did actively code while managing were universally worse.
Trouble is, I don't think they'll just get it and then set about to changing the processes. Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.
By whstl 2025-10-2613:53 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.
By CuriouslyC 2025-10-267:411 reply Unless you're at a very small company, CTOs set technical vision, choose high level tooling strategy and outline engineering culture in broad strokes, but the nitty gritty of process will be from an engineering director or other role below the CTO. The CTO will probably provide feedback if needed, but they're not in the weeds and won't be able to see problems unless they're raised.
You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so.
I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.
Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.
By paulryanrogers 2025-10-2615:56 > 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.
By dilyevsky 2025-10-2617:17 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
By OccamsMirror 2025-10-266:552 reply 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?
By CuriouslyC 2025-10-267:44 Just this. CTO title doesn't even make sense until your org is large enough that engineering vision and strategy becomes decoupled from execution.
By mytailorisrich 2025-10-268:442 reply I think the answer is in the blog:
"I currently manage no direct reports and ship a lot of code."
By ChrisMarshallNY 2025-10-2610:091 reply 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.
By raw_anon_1111 2025-10-2613:081 reply 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.
By rzzzt 2025-10-2615:56 Isn't this the fun part?
By taneq 2025-10-2612:08 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.
By KaiserPro 2025-10-2618:39 > This is exactly what someone who can't be easily unseated should be doing at a company
I mean yeah, but hes the fucking CTO. If hes the CTO, _he_ is responsible for that process. Its his job to evolve it to make it fit for purpose.
What he's done is basically created a whole bunch of process debt, which is much harder to correct than tech debt.
(Author here): I hear what you’re saying, though I’ve never “crowed about regularly checking code in on Saturdays and Sundays” and I think that’s a false characterization of my article.
Do I love to code? For sure. Is it something I do on the weekends? Generally yes because it’s something incredibly fun for me, and it gives me a lot of energy. Now, is it an expectation I have of my team? No, it’s not because I want a sustainable pace for the team and I recognize not everyone has the same relationship with work or coding as I do.
And on the “circumventing process” bit — what I shared wasn’t an example of blowing past legal/security review recklessly. It was a case where I, as someone with full context, could quickly build something safe and unblock a customer, going through our normal code review and deploy process. I don’t expect anyone (myself included), to have any exceptions to this.
By ketamine 2025-10-2621:26 I'm guessing you are ~28, maybe married and no kids.
By whiplash451 2025-10-2619:30 > 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?
By mritchie712 2025-10-2612:571 reply 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.
By switz 2025-10-2615:22 No, he clearly points that anyone else would have to be taken off their existing work and would have to context-switch to the context he already has. That's not trashing his engineering team.
I code as a founder/CTO on weekends, I don't expect weekend work done by anyone else and most people rarely check in if ever on weekends.
The job profile of founder-CTO has not a lot of overlap with that of an individual contributor to be leading by example, the overlap is quite narrow even for senior engineering leadership.
Until recently[3] leaders with prior coding skills were always discouraged from code contributions and focus on management exclusively, for all the reasons some of them you describe.
--
I usually say that I am a part-time coder, not a professional one, and caution not to look at what I do as a benchmark or signal.
Vast majority of the code I write are DevEx or QoL for internal teams[4], or refactor tech debt that no one has time to deal with. Even mid-stage startups may not be large enough to invest in dedicated teams for this type of work.
Occasionally I have written such integrations like OP[1]. It is typically a PoC for a demo, never a production one to actual customers. It would be unfair (and failure prone) to expect anyone else to start supporting a production integration without the full tooling or documentation.
--
I agree it is a fine-line and you can err on the wrong side of it. It is easy and tempting to start focusing on production code and lose focus of the core job, but so many decisions as a founder are like that. I am hardly the best or optimal founder-CTO. However the value of being close to the metal is important and worth some risk in early to mid stage startups.
Perhaps there is also value in a CTO who understands what individual contributors are doing and is able to be more realistic about outcomes instead of being purely few layers above and not clued in.
--
[1] Not skipping legal that seems ridiculous, even if I wanted to, I can't imagine any partner would agree to it.
[3] Now I do encourage to try the new tools, it is not they contribute to production or be an IC, it is to get a sense of what is possible and what is not today. A lot of pipe-dreams are being sold in the industry, without hands on experience using the new tools ( which are rapidly evolving) managers can tend to overestimate or misunderstand what is doable.
[4]This is the core of the CTO job, writing code is rarely the bottleneck for productivity that was true even before generative coding tools, it is everything around that which creates friction. If you can reduce it, even writing some code to do so, it shouldn't be a problem or a flag.
- Edited for brevity(some).
By raw_anon_1111 2025-10-2613:141 reply 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.
By manquer 2025-10-2617:28 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 :)
By cloudhead 2025-10-2611:31 That’s the point — I and others would have the opposite reaction, it’s self selecting, so it’s doing its job. I didn’t even read the article because I thought “boring, nothing special about a CTO who codes, we all do.”
> regularly checking in code on Saturdays and Sundays
If you’re working on insurance SaaS, I agree.
If you’re building hard tech, I’d disagree entirely.
By HotGarbage 2025-10-267:181 reply [flagged]
By HotGarbage 2025-10-2618:53 [flagged]
By swaits 2025-10-2613:03 Don’t just back away slowly. Run for your life!
Prediction: this is the part of the AI boom that goes bust.
By singleshot_ 2025-10-2617:13 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.
By xnx 2025-10-269:22 The "C" stands for "Cowboy"
By dangoodmanUT 2025-10-2615:154 reply 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.
By paholg 2025-10-2616:34 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.
By fogzen 2025-10-2615:29 Working at a startup can be rewarding, but it often means putting in founder-level effort while the founders capture most of the upside.
By cantor_S_drug 2025-10-2616:43 Snake-style org vs Elephant-style org. Nature accomodates lot of survival strategies. People shouldn't unnecessarily criticize others.
By sokoloff 2025-10-2619:27 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.
By varispeed 2025-10-2617:34 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.
By KaiserPro 2025-10-2618:45 > 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.
> foregoing required legal
depending on the legal requirement it may not have been foregoed but instead became legal because an executive did it
By sokoloff 2025-10-2619:37 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
By CyanLite2 2025-10-270:47 They brag about hiring on visas, so you can read between that post and the visa sponsorship as a 996 organization.
By Rover222 2025-10-2613:20 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)
By mdrachuk 2025-10-269:44 > Your job at the top is, more than anything else, pushing down a healthy culture. The CTOs role leading the tech folk to support business goals, which culture a part of. The healthy part is a subjective thing.
Agree. Let me say much the same through a parallel line of observation: maybe you dont need a this cto or any cto? Maybe you need to move this guy to sales.
Goodness gracious corporate america. Can we PLEASE stop with hustle and bs?
You ever heard buffet or munger say everyday they do some bill keeping in a double entry accounting system and AI makes them better? Never. Why? Because when you and your org are competent you're not constantly on the hussle. My guess if they need to, they do and as they have things on their mind they don't have time to blog about.
People know what management at Berkshire Hathaway stands for. Case closed.
Competent upper management can be a boon for orgs esp on cross functional management which builds the org and keeps ia from infighting and running in 10x different directions. This guy isn't that. Moreover that means other people on the board don't know that either.
By vincenthwt 2025-10-271:21 Thank you for sharing this. The part about Warren Buffett and the contrast with hustle culture is particularly delightful. It highlights the importance of competence and meaningful leadership over performative busyness.
By 999900000999 2025-10-2618:00 > 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.
By ctxc 2025-10-265:36 Flabbergasted to say the least. Dude do your job. Fix the process. Don't set a bad example.
Frankly if you’re a CTO you aren’t incentivized by a salary. It makes sense in this case no different than you’d code on the weekends for your side hustle.
It only doesn’t make sense when this jackass thinks the salaried engineer needs this “grit”.
C-levels aren’t supposed to be “model employees”. The incentive structure is wildly weighted in their favor. Instead you should ask them to understand the difference, which is asking a lot of these sociopaths, but I digress.
By jaccola 2025-10-269:43 Regarding culture:
Complete nonsense. The free market will tell him if he can do this or not. If he can get valid candidates pushing this culture and it’s legal, why shouldn’t he? You, anyone interviewing there or anyone working at their company presumably doesn’t have to work there. Most countries don’t have slavery for tech jobs!
No doubt he will lose many candidates with this culture (you and I included) but maybe that’s a strategy? Maybe he still gets plenty of candidates that are good and the culture he wants.
Articles like these are kind of hard to parse because there's no well-defined meaning to the title of "CTO". Our "CTO" codes, probably more than anybody in the company, but that's because he's got a founder-inherited CTO title that mostly just means "he can do whatever he wants" --- we're happy with that, what he wants is practically always great.
That's one definition of a CTO. Another CTO type is the opposite: "the thing you call an engineering founder when they've done so much customer-facing work that you have to take their commit bit away from them". This is, I think, an even more common archetype than the other one.
Then you have the toxic CTO definitions --- CTO as "ultimate decision maker for engineering", or, God help you, CTO as "executive manager of all of engineering".
You'd have to be specific about what kind of CTO you are to really make the question of why you code interesting.
By peter422 2025-10-2520:58 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.
By alexpotato 2025-10-2521:491 reply 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.
By DANmode 2025-10-2719:37 Total team larger than 50 at that point,
and probably a lumbering ghost ship by one or more KPI.
By lbreakjai 2025-10-268:05 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.
By sarabande 2025-10-2520:41 I found the article interesting, even given a large range of possible definitions of CTO.
I do wonder if it is possible to agree on a general definition of the CTO from the perspective of the job to be done, rather than how they do it.
For example, we could say the job of the CTO is to ensure the company remains technically competitive. If they do it by means of building an organization then so be it. If they rather do it by writing code themselves, then why not?
Title inflation everywhere. "Founder" instead of small business owner of a company with no customers.
By kgwxd 2025-10-2614:48 When anyone mentions having the title CTO, it's guaranteed what follows will be also be pretentious BS.
By mexicocitinluez 2025-10-2610:533 reply > 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".
By swat535 2025-10-2612:20 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.
By dijksterhuis 2025-10-2615:373 reply 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.
By DANmode 2025-10-2719:40 You’re also what you can do,
in the context of headhunting,
which is the context most use titles.
At any rate, Senior Engineer fits well here.
People here want "CTOs" to be brave enough to call bullshit on their "CTO-hood" but nobody here is brave enough to call bullshit on the title itself, which is the truer and more important observation.
By mexicocitinluez 2025-10-2618:191 reply What's the purity test for being a "real" CTO?
By tptacek 2025-10-2618:39 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".
By mexicocitinluez 2025-10-2618:15 Because it's the official title at my company?
Possibly unpopular, but this is an interesting topic, so I'll post my counterpoint.
The question is: what are you not doing that is in the list of CTO responsibilities because you're coding? One of the reasons stated why you do this is "because you enjoy it", and on the list of reasons you need to do it is there are only a handful of people in the org that can ship new product surface area. That's...concerning. That seems like the kind of thing the CTO would want to fix, but I don't think having the CTO be the one to ship that surface area is highest-leverage use of time. If I'm reading this right, it's essentially that "because of the virtue of my position and autonomy, I can work on experimental projects for months at a time, but I don't empower my teams to do the same."
I have direct experience with this sort of attitude at companies between 200-400 people, and the messaging from top brass was framed as "innovation cannot be democratized". After seeing it in action for several years, I think it's a poor model. CTOs are technical visionaries, but coding is not a high-leverage activity. Good startup CTOs need to change their role multiple times over the course of the life of a company, and failing to understand the profound impact you can have as a leader is a common pitfall, because it doesn't fit with what you enjoy, or often what you have experience with. In the case of Assembled, Crunchbase says between 100-250 employees. If you get more towards 500-1000, I would seriously recommend you re-evaluate your thinking on coding as CTO, at least to the degree you are today.
One technical question: do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"? What happens when you don't have time to land the long-term experiment before you need to turn to the next concern? I ask these questions because they are the points where I've seen this system fail, and I'm curious if that has every been an issue for you.
Again, implies there is such a thing as a "list of CTO responsibilities". Companies can decide to give their CTO x or y portfolio, but by the time a company reaches the point where titles matter, it's hard to think of an intrinsically "CTO" responsibility that isn't covered by a VP/E or VP/PM. The one thing I can think of is "organization-wide architecture oversight", which is a pretty toxic role to assign.
In orgs where the CTO does a bunch of stuff, I think it usually makes more sense to think of them as a VP/E with a different-shaped hat (or a VP/PM).
There's definitely an interesting article to write about the VP/E who still codes!
> The one thing I can think of is “organization-wide architecture oversight”, which is a pretty toxic role to assign.
I don’t know that I understand what you mean by toxic or why, but I’ve only ever seen the architecture overseer kind of thing in pretty small companies. In big companies, where there are multiple VPs of engineering and product management, that feels like the only time CTO even makes sense, and I expect they need to be setting vision and deciding where to invest (i.e. setting budgets) sometimes handling legal issues. In such large companies I’ve never seen a CTO providing architecture oversight, let alone coding. They might mandate the use or avoidance of some tech for reasons of corporate politics, but they are never in the trenches.
Having been a founding engineer in a startup where I was called CTO and mostly wrote code, I feel like this is a ‘cute’ thing we do, using C-level role names for everyone in a 3 person company. I didn’t feel like a real CTO, or VP, and I feel like using C-level names for roles in startups and small companies is a little goofy and awkward. A lot of people seem to like inflated role titles, and VCs seem to like having someone in key roles who can both lead well and take all responsibility and blame. I feel like ideally the name CTO shouldn’t be used until it’s needed, which isn’t until there are enough devs to need managers, and enough managers to need VPs and enough VPs to need a CTO. If that were the case, then the possible things on the list of CTO responsibilities is a lot smaller and more definable than if we say CTO can be anything including the 2nd founder who’s more interested in coding than pitching or marketing.
Think about what it says, in a larger team staffed with competent technical talent, to have a single person across all of it reconciling decisions with their own personal mental model. I think it's an attractive idea for a lot of aspirants! Who wouldn't want to be President of Code? But ambiguity is resolved by practitioners at the sharp end of the system.
By dahart 2025-10-2617:55 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…
> But ambiguity is resolved by practitioners at the sharp end of the system.
I've been looking for a concise way to express this idea. I'll use this. Thank you.
By tptacek 2025-10-281:14 It's not mine, it's Richard Cook's. Have fun with it!
By dnw 2025-10-2521:26 Exactly. Role and title are amorphous and depends on the industry, stage of the company, etc.
Look at this CEO who codes: https://github.com/lattner :-) (He was fund raising in July, August)
So many things wrong with this sort of “CTO must not do what they enjoy but what is the list of responsibilities “ robotic thinking. So you think coding is not high leverage on a tech company. Do you even remember why your company exists anymore? Surely not to give people a living and let them be happy at work, according to you. Absolutely no, the only purpose of a company is to deliver value, but I bet you can’t even define value other than a hand wavy impact on ROI or whatever makes this quarter’s numbers look good.
In any company, only a small number of developers can ship a difficult feature within a reasonable time frame, and that will almost always include the CTO if they were a founder and probably wrote half of the code. Only many years of experience working on a particular code base will give you that so no matter what you do, it may be years for someone else to get to the same level and that may never happen because the product just grew so large no one can do that anymore. If a CTO is still in the position to ship a large feature in a day , you are having an extremely hard time arguing they still should not do that. What could be more valuable use of a day in their schedule? Meeting with the CEO to discuss KPIs?? Fuck that.
This hits close to home as you might have realized. But yes I am all for letting the c-level go back to the trenches once in a while to feel what the salaried guys are facing. They can’t fix things just based on third party accounts anyway.
> So you think coding is not high leverage on a tech company.
At the CTO level of a growing company it is one of the lower leverage things they can do. Setting technical direction, hiring the right people, and putting the right people in positions of power will all have much more impact than writing some code on the weekend.
You’re wrong man. These things you mentioned happen rarely, it’s not what you do day to day. If you don’t do some high value coding you have no clue how to steer a tech company at a technical level.
> it’s not what you do day to day.
I don't know about that. I was a "CTO" for a small (10-person) and a slightly larger (around 100-person) VC-backed startup. Hiring was always top of mind at both places. Not even "people management", just hiring alone. I'm not saying this universal, but when a company is expected to scale rapidly (as is often the case with venture-backed firms), managing people can easily consume your entire workday even at a relatively small size company.
Of course, I'm not saying that's everyone's experience. There are obviously lots of reasons that dynamic might be different: For example if you're not a VC-backed company, or a CTO who's a world-renowned technical expert in a particular field (nobody's bringing Ilya on board for his ability to hire).
But it's very, very easy for people management to be a day-to-day thing and I don't think it's a waste of time compared to direct contributions.
As a former "CTO" at a small company and an early stage employee at several others, hiring was a ton of work for everyone. It was honestly the hardest thing I had to do. However, it was by no means a constant, day-to-day thing.
By BoxFour 2025-10-2616:36 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.
By rpdillon 2025-10-2613:07 I think me mentioning a list of responsibilities sort of derailed the conversation a little bit.
It's not about them avoiding what they enjoy. It's about empowering and scaling a human organization to take on larger and larger scope over time. And at a technical company, the CTO is uniquely positioned to understand organizational scalability and technical scalability. So the risk I see with a CTO that focuses predominantly on coding is that they may be neglecting higher impact work that they could be doing that would set the organization up to empower more people to do the kind of work that they think is necessary.
The other risk I observed with a CTO that predominantly codes is that they become a bottleneck and are not actually able to ship the really experimental and product-altering features that they envision, and so they end up handing off essentially half-done ideas to teams who are then responsible for picking up the half-done mess and getting it to something that's suitable for production. I think this is probably avoidable in some way, but I do think it's an intrinsic risk of taking on large projects as a single coder while having other responsibilities to the company.
> do you find yourself developing the MVP of a particular feature to "get water through the pipes" and then handing that off to some other team to get it to "production ready"?
I liked your take and curious to know what you think a CTO should be doing here
By rpdillon 2025-10-273:07 Generally, I don't advocate for code getting thrown over the fence, regardless of the dynamics associated with the particular exchange. So the ideal approach here would be for the CTO to partner with a trusted engineer with some leadership capacity (tech lead, staff, etc.) and work through the architecture design and technical specifications for the project and get it off the ground and then hand that off to the tech lead that they partnered with so that they could carry it over the line, possibly with a team. Understanding the vision behind the project and why the CTO thought it was valuable is a critical aspect here. It turns what would otherwise be a low leverage project, mostly involving architecture and coding, into a much higher leverage project that's focused on educating and empowering other leaders in the organization. It also allows the CTO to stay close to the technical foundations and code so they don't lose touch with the organization that they're leading.
