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.