Why I Code as a CTO

By John Wang, Co-Founder and CTO

October 22, 2025 2 min read Many CTOs I know stopped writing code years ago. The conventional wisdom suggests that as one advances in seniority, coding becomes less frequent, eventually leading to days filled with back-to-back meetings.

That's not how I operate. In fact, here's a glimpse into my last 12 months:

I currently manage no direct reports and ship a significant amount of code. This isn't merely "dabbling in free time between meetings," but rather "shipping multiple substantial features last quarter."

I believe it's one of the highest-leverage activities I undertake as a technical leader.

What I Actually Build

People often assume CTOs who code are either working on pet projects that never see the light of day or performing ceremonial code reviews. My experience has been different. The code I write falls into three distinct categories, each valuable for unique reasons.

Long-Horizon Experimental Projects

The ability to ship and build substantially new things is a scarce resource within an organization. Companies are generally structured to maintain the status quo and scale existing products. I've found that only a handful of individuals—founders, certain executives, and a few high-leverage ICs—are truly positioned to generate new products. Pushing new ideas is critical because it demands intentional, sustained effort. Given organizational structures, roadmap incentives, and limited risk budgets, few engineers can dedicate months to pursuing ambiguous bets.

I can. And I am uniquely positioned to take on these complex experimental projects because I understand both the customer pain points and the architecture well enough to move swiftly.

While I've had my share of projects that didn't pan out, I've also had some significant successes. A recent example: we had been discussing building an AI chat product for our customers. Its value was clear, but it seemed like a daunting task, and no one on the team had the time or mental space to take it on given their existing commitments. During a Thanksgiving break, I decided to build a prototype myself. Subsequently, I collaborated 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 urgently needs something that becomes a blocker for a major deal or renewal. These situations demand someone who can move quickly, comprehends the entire 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 possess the necessary context and understand the stakes involved.

Last month, a million-dollar-per-year customer approached us with a pressing need: full data redaction on one of our integrations for compliance reasons. Our team had considered the customer potentially building their own integration via our API to circumvent this requirement, and properly scoping it would have necessitated numerous meetings across product, legal, and engineering. I built and shipped a working version in a single day. It wasn't perfect, but it solved their immediate problem and preserved goodwill with the customer.

Bugfixes (The Surprising One)

People are often surprised by this, but I fix a lot of bugs! And bug fixing is one of my favorite ways to maintain a comprehensive mental map of our codebase.

When you're tracking down why pagination breaks on the third page of search results, or why WebSocket connections drop after exactly 60 seconds, you traverse vast segments of the system. This provides a visceral understanding of technical debt that's difficult to gain from code reviews or architecture discussions alone. This mental map helps me make better decisions regarding technical investments and where the team should concentrate its efforts.

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 various other AI tools daily. This hands-on experience allows me to discern what's genuinely effective from what's merely hype when making strategic decisions about tooling and hiring.

Here's a recent example: I spent hours one weekend trying to "vibe-code" a feature that involved a few intricate integrations, but I made significantly more progress when I finally sat down and wrote most of it manually. The code wasn't extensive, but it required precise logic (a challenge for LLMs). Conversely, I've shipped a major feature almost entirely with Claude Code. Knowing where AI excels (CRUD operations, tests, boilerplate) and where it struggles (precision, system nuance) consistently trumps making decisions based on Twitter hype.

Being actively in the code also provides an intuitive sense of when to push hard and when to ease off. I can perceive when architectures are becoming overly complex or when technical debt is escalating into a significant problem. I've observed managers who rely solely on what people tell them, and they can miss a great deal. When you're in the code, you develop an intuition for what's truly happening.

Because It’s What I Love and What I’m Good At

I don't particularly enjoy building organizations and managing "people stuff." Engineering management involves navigating interpersonal dynamics, conducting performance reviews, and designing organizational structures. These are crucial functions, but they aren't where my strengths lie.

That's why we've hired exceptional engineering managers and leaders. They are better at these tasks than I am, and they enjoy them. This arrangement allows me to focus on what I love: building things, solving technical problems, and writing code.

Startups are akin to a sprinting marathon, so I design my role around work that keeps me excited and prepared to run fast for an extended period. This approach enables me to continue contributing effectively for years, which is highly beneficial for the company.

AI Tools Have Changed the Leverage I Have

A few years ago, I struggled to find time to code while also managing the strategic aspects of my job. As the company expanded, I was essentially stuck in meetings all day, operating outside my zone of genius. It was one of the toughest periods of my professional life.

However, modern AI tools have fundamentally altered this equation (especially in recent months). I am likely 2–3 times more productive than before. These tools haven't replaced my judgment or technical knowledge; instead, they've actually made those skills more valuable.

I can instruct 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 will generate most of the code correctly because I know precisely what I need and where to find it. An engineer unfamiliar with that part of the codebase would spend considerable time figuring out those details.

The job has shifted from "writing every line of code" to "providing context, making decisions, and evaluating solutions." And fortunately, I possess a wealth of context.

Figuring Out What Works for You

When I was defining my role as CTO, I read Greg Brockman's blog post about establishing the CTO role at Stripe. He spoke with numerous other CTOs and realized the enormous variance in what the role entails. Some CTOs are technical visionaries, some are organizational builders, and some are infrastructure-focused. The common thread is that great CTOs identify where they can create the most value given their particular skills, interests, and company context.

For me, that has meant writing a lot of code. It works because of my specific context: I enjoy building software more than organizational design, I possess 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 universal prescription. The CTO role is remarkably flexible. Whether building organizations, developing product strategy, or something else entirely — technical leadership varies depending on your strengths, what energizes you, and what your company needs.

If you're an engineer concerned that leadership means abandoning technical work, know that many paths exist. The key is discovering where you are uniquely exceptional.

---

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.