Should you still be writing code as a CTO? Yes, but not the way you think

Should you still be writing code as a CTO?

In 2025, 99 percent of CTOs say technical debt is a risk, and they’re right. The longer it sits, the harder it gets to fix, and the more it drags teams down. That stat from Softtek should hit home, because debt isn’t a spreadsheet problem. It’s a codebase problem, and it shows up in production at 2 a.m. So yes, you should still be writing code, but only in ways that cut risk and lift the team’s output.

Should a CTO still write code in 2025?

Most CTOs I talk to miss coding for one reason: it’s clean. Code either works or it doesn’t. Leadership work is messier, and it comes with people dynamics you can’t lint away.

But the job changed. AI tools now draft a lot of what teams used to type. Datacenters.com calls AI assistants “indispensable members of software teams” in 2025, and that matches what I see in orgs with 50 to 500 engineers. Your edge as CTO isn’t typing speed. It’s choosing the right work, shaping the system, and growing leaders who can run it without you.

Here’s the framing I use.

A CTO should write code when it improves decisions, reduces delivery risk, or teaches the org.

And a CTO should not write code when it steals ownership from teams, or masks real delivery problems.

What “writing code” means now

A lot of CTOs hear “stay technical” and picture shipping features. That’s the trap.

In 2025, “writing code” for a CTO can mean:

• Prototyping a risky integration in 2 hours to test an assumption.
• Reading code to validate an architecture claim in a design review.
• Pairing with a staff engineer on a hard incident fix.
• Writing a reference implementation for a platform pattern.
• Building internal tooling that removes friction for 150 engineers.

It can also mean writing prompts and guardrails for AI tools. Addy Osmani notes that leaders shift from “how” to “why and what,” while still owning quality and direction in GenAI-heavy teams. He also cites a study of 4,800 developers that found AI assistants boosted productivity by 26 percent, after a learning curve. That learning curve is a leadership problem, not a tooling problem. You can’t hand-wave it away or delegate it into existence. You have to shape it. Source: Leading Effective Engineering Teams in the Age of GenAI.

The competitor gap: most advice ignores org size

Most posts on this topic treat “CTO” like one job. It isn’t.

A CTO at a 20 person startup can code on the critical path. A CTO at a 2,000 person enterprise shouldn’t touch the critical path. The right answer depends on your span, your risk profile, and your team’s maturity.

So here’s a model you can use on Monday.

How much should a CTO code? Use the CTO Coding Ladder

I use a simple model with four rungs. Pick one rung per quarter. Don’t drift.

The CTO Coding Ladder

Most CTOs in growth stage should sit at rung 1 or 2.

If you want a rule of thumb, use this.

• Under 30 engineers: rung 2 to 3.
• 30 to 150 engineers: rung 1 to 2.
• 150+ engineers: rung 0 to 1, with rare rung 2 bursts.

One question matters here: are you coding to learn, or coding to feel useful? If it’s the second one, you’ll hurt the org.

A decision matrix you can share with your CEO

Use this quick matrix before you open your editor.

CTO Coding Decision Matrix

This matrix works well in exec conversations. It turns “CTO should code” into a straight risk trade.

What do you lose when you code too much?

The cost isn’t your time. The cost is the work only you can do.

Oregon’s 2025 to 2027 CTO outlook calls out technical debt and organizational debt, and it makes a point leaders forget. Debt isn’t failure. Debt is change. But the “interest” compounds, and the cost of doing nothing climbs over time. That compounding happens in systems and in teams. Source: Chief Technology Officer 2025-2027 Biennial Outlook.

When you code too much, you create organizational debt.

You become the hidden dependency

I’ve seen this pattern in a 120 engineer SaaS company.

The CTO owned a key service “just for now.” It handled billing events and webhooks. It also had the worst test coverage in the company. Every quarter, the CTO promised to hand it off. Every quarter, the team avoided it.

The result was predictable:

• A billing incident took 9 hours to resolve.
• The CTO got pulled into the incident bridge.
• Two staff engineers waited for decisions.
• The roadmap slipped by two weeks.

The CTO didn’t fail at coding. The CTO failed at delegation and system design.

You steal growth from your strongest engineers

Your staff and principal engineers need real ownership. If you take the hardest work, you cap their ceiling.

The Pragmatic Engineer writes that tech leads often code alongside the team, while engineering managers focus on technical oversight and stakeholder work. That split exists for a reason. It protects focus and creates growth paths. Source: Leading Effective Engineering Teams: a Deepdive.

As a CTO, you sit above that split. If you code like a tech lead, you leave a leadership vacuum.

You trade strategy for dopamine

Coding gives fast feedback. Strategy gives slow feedback.

Softtek’s 2025 CTO challenges report talks about market expectations hitting a tipping point in 2025, and it ties that to stack choices and debt. That’s CTO work. It’s stack, debt, and operating model. Not just commits. Source: CTO: Challenges for 2025.

If you spend 10 hours a week coding, you will skip:

• The hard vendor negotiation.
• The org design fix.
• The roadmap trade with sales.
• The security posture review.

Those are the jobs that keep you employed.

How AI coding tools change the “should I code” question

AI changes two things at once.

• It lowers the cost of producing code.
• It raises the cost of reviewing and validating code.

So CTO coding shifts from “write” to “verify.”

Budget and governance matter more than your personal output

AI coding tools aren’t free. They also create new spend paths.

Dr. Brian Scott Glassman lays out model pricing trends and budgeting for AI coding tools, aimed at CTOs. Even if you buy per seat tools like Copilot, you still pay in training time, security review, and policy work. Source: What a CTO Must Budget for AI Coding Tools.

If you code as a CTO, use that time to set standards for AI use:

• What code can be generated from internal repos.
• What data can go into prompts.
• What review rules apply to AI authored diffs.

This is also where internal tools like our Command Center can help. Track AI tool rollout as a portfolio change, not a side project. Tie it to incident rates, cycle time, and security findings. See: Command Center for tech debt and risk tracking.

Measure the right thing or you will fool yourself

Teams love to report “we ship faster with AI.” That can be true and still be bad.

Metacto suggests tracking ratios like coding time versus review and wait time. AI can speed up coding and jam your review queue. That creates a new bottleneck and more defects. Source: Key Productivity Metrics for AI-Enabled Engineering Teams.

If you want a clean measurement set, use your existing metrics stack.

• Track DORA and review latency in our Engineering Metrics Dashboard for DORA metrics.
• Track incident volume and severity with our incident postmortem guide.

And keep one rule.

• If AI increases PR throughput but raises escaped defects, you did not win.

CTO coding becomes “write the guardrails”

In AI heavy teams, the CTO’s best coding often looks like:

• A repo template with secure defaults.
• A policy as code rule in CI.
• A reference service with auth, logging, and SLO hooks.

That work scales. Feature work doesn’t.

What should CTOs do instead of coding? A practical operating plan

You don’t need a moral stance on coding. You need an operating plan that fits your org.

This section gives you one.

Immediate actions: next 14 days

1. Pick your rung. Choose a CTO Coding Ladder rung for this quarter. Put it on your calendar.
2. Define a “no critical path” rule. Don’t take tickets tied to a launch date.
3. Schedule code reading. Block 2 sessions per week for reading diffs and tracing flows.
4. Pair on one incident. Join one incident review, then pair for 60 minutes on the fix.
5. Baseline AI tool usage. Count seats, repos, and top use cases. Track spend.

If you need a place to track this work, treat it like a migration. Use our Build vs Buy Matrix for AI coding tools to decide between hosted tools, self hosted models, or a hybrid.

Policy framework: rules that stop chaos

1. Ownership. Every repo has a named owner at staff level or above.
2. Review. No direct commits to main, including yours.
3. AI disclosure. PRs label AI generated code in the description.
4. Security. Prompts never include secrets, customer data, or private keys.
5. Maintenance. Any CTO written tool needs a handoff plan in 30 days.

Oregon’s outlook calls out contracting and “as a service” delivery shifts, with clear service levels and security requirements. That mindset applies inside your org too. Treat internal platforms like services with owners and SLOs. Source: CTO Trends Outlook 2025-27.

Architecture principles: where CTO coding pays off

1. Thin waist. Code the interfaces, not the features. APIs and events beat custom glue.
2. Golden paths. Build one paved road for common services, then enforce it in CI.
3. Debt visibility. Track debt like incidents, with owners and dates.

Softtek’s report says 99 percent of CTOs see debt as a risk. Treat that as permission to run debt like a product. Source: Softtek CTO Challenges for 2025.

If you want to document these principles, model them. Use our ArchiMate Modeler for architecture documentation.

A checklist for “safe CTO coding”

This is the list I keep in my notes.

• I’m not the owner of the repo.
• I’m not on the critical path for a launch.
• A staff engineer pairs with me or reviews within 24 hours.
• The change is small. Under 200 lines is a good cap.
• The change reduces risk. Security, reliability, toil, or clarity.
• There is a handoff plan. Owner, date, and next steps.

If you can’t check five of six, don’t code.

Enterprise implications: why this matters for CTOs

1. AI raises the review burden. Teams generate more code per day, so your org needs better review, testing, and security gates. If you code, code those gates.
2. Debt compounds across systems and org charts. Oregon’s outlook treats technical and organizational debt as linked. CTOs who code too much create org debt, even if the code.
3. Credibility still matters. Hacker News threads about managers coding get heated for a reason. Engineers can spot a leader who never touches the work. But they also spot a leader who grabs the fun parts and leaves the grind. Source: Coding as an Engineering Manager.
4. Budget pressure shifts to tools and training. AI coding spend is now a line item. You need a plan for seats, model usage, and training time. Glassman’s budgeting view helps frame it for finance. Source: AI coding tool cost forecast.

Bigger picture: the CTO role is splitting into two skills

We’re watching a split.

One skill is system design at scale. That includes security defaults, platform patterns, and debt management. The other skill is people design at scale. That includes hiring, incentives, and decision rights.

Coding can support both skills, but only if you treat it as a tool for learning and teaching.

If you want to stay hands-on, do it like a doctor in a teaching hospital. You take the hard cases, you teach in public, and you build the next generation of leaders. You don’t run every routine appointment.

The question is simple: are you writing code that makes your team stronger, or writing code that makes you feel safe?

Sources

1. Softtek, CTO: Challenges for 2025 (PDF)
2. State of Oregon, Chief Technology Officer 2025-2027 Biennial Outlook (PDF)
3. Datacenters.com, Software Development Trends 2025
4. Dr. Brian Scott Glassman, Towards AI, AI coding tool cost forecast
5. Addy Osmani, Leading Effective Engineering Teams in the Age of GenAI
6. Hacker News, Coding as an Engineering Manager
7. Metacto, Key Productivity Metrics for AI-Enabled Engineering Teams