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:

1. 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.

2. 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:

1. Limit direct contributions. A CTO shouldn’t own critical production features. Instead, focus on architectural guidance, prototyping, or internal tooling.

2. Trust your team. Let your engineers own technical decisions, but stay involved in key architectural discussions.

3. Avoid being a blocker. If you’re reviewing code, do it fast. If the team is waiting on you, you’re slowing them down.

4. Stay sharp on the side. Explore new technologies, experiment in sandboxes, or work on projects that don’t disrupt the team’s workflow.

5. 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.