Writing code makes you a better CTO
How to stay hands-on without becoming a bottleneck for your team
đ Welcome to todayâs edition of Build & lead (formerly the CTO blueprint), a newsletter by Appolica. Every two weeks, we dive deep into the tech, product, and leadership challenges that keep founders up at night.
Both the CTO and the Engineering manager write code at Appolica. They jump into PRs, review decisions, debug issues, and sometimes even ship features.
This isnât typical. Most CTOs donât write code, and many will push back when you suggest they should. Common objections include:
âI have more important things to do - hiring, strategy, fundraising.â
âIf I do the coding myself, Iâm not giving my team the space to grow, make decisions, and take ownership of technical challenges themselves.â
âMy team should be independent. If they need me in the codebase, Iâve failed.â
These arguments sound reasonable. But theyâre misguided. Writing code (even occasionally) makes you a better CTO. It keeps you relevant. It helps you make smarter technical decisions. It earns trust from your team. And it ensures you never become the kind of executive who makes engineering calls without understanding the trade-offs.
Generally, there are plenty of opinions on this topic. Some say whether the CTO should write code depends on the company stage. Others believe stepping away from coding is necessary to be an effective leader.
In this article, weâll walk through different scenarios (early-stage, scaling, and later-stage companies) to explain how we see CTOs writing code at each stage of growth.
In an early-stage startup, the CTO is the engineering team
In an early-stage startup, thereâs no debate: you have to write code.
Thereâs no engineering department. You have no team to manage, no processes to optimize, and no one to delegate to. Thereâs rarely a high-level strategy to refine, so if youâre not hands-on, youâre just a founder with a technical background, not a CTO.
This early, a CTO is the senior engineer, the solution architect, the junior developer, and even the food delivery guy. In reality, he is the entire engineering department.
This should be obvious. And yet, some early-stage CTOs hesitate to get their hands dirty. They worry about âacting like a leaderâ instead of focusing on the one thing that actually matters: building.
Scaling up: the CTO role changes
As a company grows, so does its engineering team.
The CTO is no longer the only developer, but this doesnât mean he should stop coding entirely. I strongly believe the best CTOs stay technical. They just do it differently.
At this stage, coding shouldnât be a daily task. Two reasons:
Tunnel vision. If theyâre buried in delivery work, theyâll miss the bigger picture. The focus should be on strategy and the future, not just shipping features.
Team dependency: If the team canât function without the CTO writing code, he has failed to empower them. His #1 job is to build a strong, independent team. If every big decision still runs through the CTO, he is a bottleneck.
At Appolica, we've seen firsthand what happens when the CTO tries to stay too involved in every technical decision. The team slows down. Engineers hesitate to merge anything without approval. Instead of making their own decisions, they wait for input. Moreover, this bottleneck erodes ownership - if the CTO is going to review everything anyway, why should anyone take full responsibility for a feature?
These are natural scaling problems. Moving from a hands-on builder to a technical leader is a difficult transition. Itâs tempting to stay in your comfort zone (whether thatâs coding too much or avoiding it entirely). But a great CTO needs to learn to set boundaries for when and why they write code.
Hereâs a framework to do that:
Limit direct contributions. A CTO shouldnât own critical production features. Instead, focus on architectural guidance, prototyping, or internal tooling.
Trust your team. Let your engineers own technical decisions, but stay involved in key architectural discussions.
Avoid being a blocker. If youâre reviewing code, do it fast. If the team is waiting on you, youâre slowing them down.
Stay sharp on the side. Explore new technologies, experiment in sandboxes, or work on projects that donât disrupt the teamâs workflow.
Help where it matters. When things go wrong, jump into debugging sessions. Engineers appreciate a leader whoâs willing to get their hands dirty (but only when it actually helps).
Later stages: staying relevant without becoming a bottleneck
As the company scales, stepping away from daily coding is necessary.
Engineering grows into multiple teams. A CTOâs role shifts from guiding a single team to aligning multiple teams, keeping dev efforts tied to business goals.
However, this doesnât mean losing touch. It does mean being intentional about how you stay involved. Some CTOs check out completely and drift into irrelevance. Others micromanage every decision and slow the team down. Neither works.
Hereâs what changes for a CTO in a later-stage company:
Manage across teams, not within them. Engineering is no longer a single unit. There are multiple teams shipping specific features. A CTOâs role is to align them, remove cross-team bottlenecks, and ensure theyâre working toward the same vision.
Technical strategy matters more than technical execution. A CTO shouldnât be in the trenches solving coding problems. They need to make long-term calls on architecture, scaling, and how to balance speed vs. quality across the org.
Remove bottlenecks and friction. Teams need to make decisions without the CTO. If every technical choice still requires approval from him, he is holding the company back. Instead of writing code directly, focus on defining technical principles that allow teams to move fast independently.
By this stage, staying technical doesnât mean coding. It means having enough depth to challenge ideas, support teams, and guide the companyâs technical future.
The AI angle
If thereâs one responsibility every CTO shares, no matter the company stage, itâs making AI a core part of how their teams build and ship software. If youâre not leading AI adoption, youâre not doing your job.
AI changed how code is written. The gap between engineers who understand product, business, and customers, and those who simply execute specs will only widen. As a CTO, you need to transform your team(s) and shift the focus away from just writing code and toward building products that solve real problems.
Hereâs what that means:
Form smaller teams made up of product builders with a focus on creating a product that provides value to users.
Identify a few deep tech experts handling architecture, security, and all the stuff AI canât solve (yet).
Get an even stronger focus on user insights and problem-solving.
This shift wonât happen on its own. CTOs need to drive it. However, before restructuring teams or redefining roles, the first step is successfully integrating AI into the development workflow.
At Appolica, weâve embraced AI as a core part of how we build, review, and ship software. Instead of using AI tools occasionally, weâve embedded them into our engineering process. Hereâs what made the biggest impact:
Weâve tested various tools, including Copilot, Codeium, and Tabnine, but Cursor has proven to be the most effective. Engineers using Cursor have seen a 4â5x boost in productivity.
Before AI, manual code reviews took up a large portion of our senior engineersâ time. Now, AI flags potential issues in PRs automatically, reducing review time by 60%.
Engineers rarely enjoy writing documentation, so we use AI to automate a big portion of the process.
The bottom line
Your role as CTO isnât static.
In the early days, youâre coding because thereâs no one else to do it.
As the company scales, your job shifts to hiring, setting technical direction, and making sure engineering supports business goals. That doesnât mean you should stop coding entirely.
CTOs should write code, but not out of necessity. They should do it to stay relevant and build trust.
Thoughts on todayâs issue?
Got feedback or just want to get in touch? Reply to this email and weâll get back to you.
Want to see more of us? Have a look at our LinkedIn account. Interested in what we do? Visit appolica.com.
Thanks for reading & until next time.
Best,
Martin, Deyan & the Appolica team