There’s a persistent debate in tech leadership circles: should CTOs write code? The conventional wisdom says no—your time is better spent on strategy, people, and architecture. I disagree.

The Context Switch Problem

As an engineering leader, you face constant pressure to step away from the keyboard. Meetings multiply. Strategic planning demands attention. Stakeholder management becomes a full-time job. Before you know it, code becomes something “other people do.”

This is a mistake.

The Technical Debt of Distance

When you stop coding, several things happen:

You lose credibility. Engineers can smell a manager who’s lost touch. Your architectural decisions become theoretical rather than practical. Your technology choices lack the nuance that comes from implementation experience.

You miss the details. The friction points in your systems—the ones that slow down your team daily—become invisible. You can’t feel the pain of poorly designed APIs or awkward development workflows.

You disconnect from reality. Your estimates become wishful thinking. Your technical roadmap drifts from what’s actually feasible. The gap between vision and execution widens.

What “Writing Code” Actually Means

I’m not suggesting CTOs should be on the critical path for features. That’s a different failure mode. Instead, writing code as a CTO means:

  • Building tools and automation that make your team more productive
  • Prototyping new approaches before asking others to implement them
  • Investigating production issues directly rather than through layers of reports
  • Maintaining a small piece of infrastructure that keeps you connected to deployment reality

My rule: I ship code at least once a week. Not heroic features. Not critical path work. But real code that runs in production.

The PoC Advantage

As a technical leader, you have a superpower: the ability to validate ideas quickly without the pressure of production quality. Use it.

When we considered moving to a new AI pipeline architecture, I didn’t write a spec document and delegate. I spent three days building a proof of concept. The learnings from that week informed months of team work and saved us from several dead ends.

PoCs are where CTOs should code most. They’re high-leverage, low-risk, and give you the credibility to make informed technical bets.

The Balance

Yes, your primary job is leadership. But leadership in engineering requires technical credibility, and credibility requires practice. The goal isn’t to be the best coder on your team—it’s to maintain enough context to make good decisions and command respect.

Write enough code to stay dangerous. Ship enough to stay humble. Build enough to stay credible.

Practical Implementation

Here’s how I make this work:

  1. Protected time: Block 4-6 hours per week for hands-on work
  2. Scope control: Only work on things that won’t block others
  3. Infrastructure focus: Prefer tools, automation, and internal systems
  4. PoC mindset: Use it to validate ideas and learn, not to ship features
  5. Public commits: Make your code visible to maintain accountability

The strongest technical leaders I know haven’t stopped coding. They’ve just changed what they code and why.

What’s your take? I’m @yaroslav_nasonov on Telegram.