Should a CTO Write Code? Stop Asking the Wrong Question

The same fight flares up again every week. On one side, the people who say “a CTO who writes code is a CTO who never learned to delegate.” On the other, the ones who say “a CTO who steps away from the keyboard gives up their authority too.” And in between, thousands of people sharing cartoons and picking sides. Everyone is certain; everyone mistakes their own story for everyone’s story.

Every time I run into this fight, I think the same thing: they’re arguing the wrong question.

“Should a CTO write code?” is as empty as asking “should a doctor perform surgery?” Which doctor? The ER physician, the radiologist, the chief of medicine? Looking for a universal answer to a question stripped of its context produces just one thing: professionals who’ve fallen out with each other.

So let’s throw the question out as it is. Let’s put a useful one in its place: at which stage, in which context, should they write what? As we look for the answer, we’ll see there’s no single job called “CTO”; as the company grows, the role keeps changing its shell.

There’s No Single Answer to “What Is a CTO?”

CTO is the loosest label in software. Two people carrying the same business card can have days that look nothing alike. One opens the IDE in the morning and ships code to production; the other is in the board room at that hour, defending a five-year technology budget. Both are CTOs, both are doing the job right.

The reason is simple. The role is tailored to the size of the company. At a five-person startup, the CTO is the lead engineer. At fifty, the conductor. At five hundred, the cartographer. One title, three separate professions.

Vadim Kravcenko sums it up in a single line: the smaller the company, the fewer people a CTO deals with; the bigger it gets, the less technology. One end of the spectrum is pure code, the other pure strategy. And most of us spend our careers sliding back and forth along that line.

This is exactly where the arguments go wrong. They put the CTO of a five-person startup and the CTO of a five-hundred-person company on the same scale, then fight over “should they write code?” It’s the technology version of weighing apples against pears.

Let’s walk the line together, from one end to the other.

The CTO in a 5-Person Team: The Head Cook

In the Book of Dede Korkut, the old Turkic epic, there’s a figure: the wise elder of the camp. Warrior, advisor, and healer all at once. He carries several jobs at the same time, because the camp is small, resources are tight, and the luxury of division of labor doesn’t exist.

The CTO of a small startup is that wise elder.

In the morning you write the MVP’s backend. At noon you give the customer a demo. In the evening you set up the deploy pipeline, and at night you chase a bug blowing up in production. The next morning you explain the architecture to an investor. You answer the “which stack?” question too, because there’s no one else to ask.

There’s no luxury here of “maybe I shouldn’t write code.” If you don’t write it, who will? You’ve got an engineer or two beside you, maybe not even that. Whether the startup gets to breathe depends on how fast you touch the keyboard.

And the job isn’t only code. Build or buy, that call is yours. The stack choice is yours. The first customer’s technical question, the investor’s “will it scale?” worry, who gets grabbed by the collar when production goes down, all of it is yours.

Here’s the sneaky part: the first engineers you hire in this period build the company’s technical character. The first five people set the temperament of the next fifty. You’re writing that temperament, and in a way that outlasts any production code you’ll ever write.

But a trap is waiting in ambush: dependence on speed.

You get so used to doing every job yourself that even after the team grows, you say “it’s faster if I do it.” That sentence is the very thing that keeps a startup running in place. Because yes, today you really are faster. But if you’re still the one doing the work tomorrow, and six months from now, then why is the team standing there?

Picture a restaurant. Five tables. The chef is at the stove, on the menu, and at the register. Perfectly normal. But if that same chef tries to plate every dish by hand in a hundred-table dining room, everyone at the tables goes hungry.

The one rule of this period: write code, but don’t fall in love with it. Let every commit also be a lesson. Pair program, write the architectural decision down, get what’s in your head out. Because one day you’ll put that keyboard down. If the team doesn’t know what was in your head that day, the company stops right along with you.

At this stage your most valuable weapon is your technical depth. Framework, architecture, build-vs-buy, the final word on all of it is yours. But when you climb to the next step, that same weapon starts to feel heavy in your hand.

The CTO in a 50-Person Team: The Conductor

There’s a fine balance in the semah, the turning dance of the Alevi tradition: everyone spins on their own axis, but the turning is shared. There are individual movements, and above them all, a single whole. No one spins alone, no one mimics their neighbor. Everyone knows their place, and what emerges is greater than the sum.

Leading a fifty-person team is exactly this. And here the role changes at its root.

The most critical pull request no longer comes from you. You’re no longer the one solving the nastiest bug. Maybe it’s been weeks since you opened the IDE. All of it is normal.

Because your product is no longer code, it’s the team. Your commits aren’t merges, they’re decisions. Your deploys aren’t features, they’re processes.

I remember the days I started my own agency. At first I touched every line of every project, chasing production errors at night. Then we became five, then ten. One day I realized the moments I added the most value weren’t the ones where I wrote code. They were the ones where I explained the “why” behind a decision to a junior, settled a technical fight between two teams, translated technical debt into the language of money for a client. Being able to take a deep subject like data integrity in distributed systems and turn it into language everyone at the table understands, that’s the most expensive skill of this stage.

This transition isn’t easy, especially if you’re someone who learned by doing. Stepping away from the keyboard feels like losing control. But you’re doing the opposite: you’re multiplying control. Ten people carrying your knowledge are always stronger than one person limited to it.

The day flows differently now too. You go into standup not to say “here’s what I did yesterday,” but to clear the rocks in front of people. Is there a blocked dependency, a pending architectural decision? In the afternoon, the customer, the retro, the technical-debt negotiation. You look at PRs, but not all of them; only the ones that set a precedent, the decisions that bend the architecture. In the evening, the map of the coming quarter: which investment, which debt, which talent.

The biggest trap of this period is missing the code. The thought “let me just ship that PR myself” will knock on your door every day. Sometimes it’ll even be right, you really would do it faster. But every time you say “let me do it,” you’re stealing someone’s turn to learn. Six months later you’re doing it again, because that person never got to learn.

The hardest fight isn’t with the team, it’s with yourself. For someone who measured their worth in lines of code for years, ending the day having written none leaves a strange emptiness. Your contribution graph fades, and a voice inside says “I’m not producing anymore.”

You are producing, actually. Your product just changed. What you produce now is people who can produce. Managing CRM teams in the energy sector in Europe, I saw this with my own eyes: the team’s youngest engineer used a pattern I’d shown in pair programming a year earlier to solve the customer’s most critical integration problem. That’s when I understood, my best code had come out of someone else’s hands.

The CTO at 500+: The Cartographer

At this scale the role is entirely strategic. No code in daily life; maybe you haven’t even opened a terminal in months. And that’s right.

Because your job now is to set the company’s technology direction and line it up with the business strategy. You present the five-year map to the board. You design the organization with your VPs of Engineering. Cloud migration, platform shifts, big build-vs-buy decisions all pass across your desk.

Your “code” is written in another language now: the strategy document, the org chart, the technology radar. Your output isn’t a commit, it’s direction.

There’s a cliff here too: losing touch with the tech. Stopping writing code is right; stopping following technology is a disaster. The good CTOs at this scale keep their minds sharp either by experimenting on personal projects or by setting up regular deep-dive sessions with their most technical people. The ones who do neither become, three years later, the “former engineer” who can’t answer a technical question in the board room.

And here a nice paradox shows up: at this scale your strongest weapon isn’t your technical knowledge, it’s your ability to translate. The person who answers the CFO’s “why should we put money into this refactoring?” with a customer-churn number; who explains to the engineer “why is this feature being delayed?” with market data. The bridge standing between two worlds.

As Gerald Weinberg put it, no matter how technical it looks, everything is really a people problem. A platform migration isn’t just a technical project, it’s a transformation that changes how hundreds of people do their work. The move from Mattermost to Matrix was a serious decision even on a small team; imagine the weight of that decision in a structure of hundreds.

The CTO in the Age of AI: A New Equation

Few people, little ammunition, little time. These are often the conditions of a war of independence, and it’s exactly that scarcity that breeds strategic intelligence. You’re forced to use every resource you have by multiplying it.

The CTO’s situation in the age of AI is similar. The resources are the same, but the multiplier on each one has changed. I’ve written at length before about how AI is reshaping software; here I’ll look at the side of that wave that hits the CTO role directly.

An engineer today produces code two or three times faster with AI-assisted tools. But this means not fewer engineers, but different engineers. People who can weigh the code AI spits out, steer it, and put it in its place.

This has three consequences for the CTO.

First, “writing code” has been redefined. You don’t have to type every line by hand. But knowing which line needs to be written, seeing the quality of the code that comes out, provoking the tool in the right direction, that’s the new technical competence.

Second, the shape of the team shifts. Agents now take on the simple work. That means rethinking the team plan from scratch. Which work goes to AI, which role transforms, which new role is born?

Third, and most important, decision speed has gone up. The prototype-test-iteration loop has shortened. An idea we used to say “let’s put in a two-week sprint” we now turn into a working prototype in a few hours. As the cost of trying drops, the distance between strategy and tactics narrows too.

But careful: AI is a tool, not a strategy. “We use AI” is turning into a sentence as empty as “we use computers.” The point is where and how you use the tool. The one making that call is still a human.

In this age the CTO carries one more debt: getting the team ready to work with AI. It doesn’t end with “go install this tool.” You have to make sure the engineer can run AI output through a critical eye, teach them where the tool stumbles, build a culture that holds the line between “code that works” and “code that’s right.” AI produces working code easily. Right code still asks for human judgment.

So When Should You Touch the Keyboard?

So far we’ve drawn a line: code on a small team, strategy on a big one. Real life isn’t that clean, of course. The CTO of a fifty-person team writes code now and then too, and the CTO of a five-hundred-person structure opens a terminal now and then too.

The question isn’t “to write or not to write?” The question is: why am I writing?

Over the years I’ve picked up a few compasses for myself.

Yes, touch it:

• In a crisis. If production is on fire and you know that system’s architecture best, stepping in is a responsibility. But once the fire is out, ask: could it be put out without me next time?
• In a prototype. Trying a new approach with your own hands raises the quality of your decision. Sometimes testing it directly is faster and more accurate than delegating and adding a translation layer in between. Just don’t forget the deadly valley between prototype and product: a prototype is there to prove something, not to be the product itself.
• To teach. The code you write in pair programming isn’t “let me do it, it’s faster,” it’s knowledge transfer. That’s worthwhile.
• In your own garden. In side projects and personal experiments, the door is always open to keep your technical muscles in shape.

No, let it go:

• If you’re saying “I’d do it faster.” That sentence is a confession that you couldn’t delegate and didn’t invest in your team.
• If you’re building a feature. If the CTO has their own task in the sprint backlog, either the team is short-staffed or the priorities are tangled.
• If you’re writing for ego. You don’t need to prove “I can still write code.” The team listens to you by the quality of your last decision, not the date of your last commit.
• If you’ve become the bottleneck. If nothing merges without your approval, if no one understands what you wrote, if the deploy stops when you’re away, the problem isn’t in the code, it’s in you.

The essence of all of it in one sentence: writing code is a tool, not an identity. A CTO’s identity shouldn’t be “the person who writes code” but “the person who makes the right call.” Sometimes the right call is to write code; most of the time it isn’t. And this compass isn’t fixed either; the same person, at the same company, turns a different way in a different period. When a new product line opens you might switch into prototype mode for a few weeks; during a big organizational change you might not write a line for months.

The CTO’s Real Code: Culture Engineering

A company’s technology culture is the CTO’s longest-living code. Frameworks change, languages evolve, architecture gets refactored. But how the team decides, how it meets failure, how it shares knowledge keeps running for years.

When I think about real CTO output, what comes to mind isn’t the lines written, it’s the mechanisms built:

• The blameless postmortem. Not the person who made the mistake, but the system that allowed it, is put on the table.
• A transparent decision record. ADRs, RFCs, technical writing circulating internally.
• An environment where a junior can ask a question without flinching. “There are no stupid questions” lives in the hallway, not on the wall.
• Technical debt translated into the language of money. Not “we should refactor this,” but “this is the source of a third of the complaints.”
• A culture of experiment. A climate where failure isn’t punished and learning is rewarded.

None of this asks for a single line of code. But all of it asks for engineering discipline, patience, and empathy. And the paradox of it is that it asks for technical depth too; because only someone who knows how software is made down to their bones can build this culture.

Leading the software team at a security company, we had our most technically brilliant engineer. He solved every problem on his own. When the team grew, that “I’ll handle everything” reflex paralyzed the team. No one took initiative, because the expectation “he’ll do it anyway” had set in. My job wasn’t to stop that person, it was to build the mechanism that would multiply his knowledge. A code-review standard, a pair-programming routine, a documentation habit. These spread what was in one head to ten.

That’s the CTO’s real code: building systems that multiply knowledge, speed up decisions, and turn mistakes into lessons. The best code is the code no one notices; it looks like infrastructure, invisible, but it holds everything up.

From the Wrong Question to the Right Answer

We set out with “should a CTO write code?” I hope that by the time we got here, it’s clear how incomplete that question is.

The right thing isn’t a single question, it’s a series of them:

• Which stage of the company am I in?
• Where does my team need me most?
• Do I create more value by writing code, or some other way?
• Can someone else write tomorrow the code I’m writing today?
• Is my reason for writing the team’s need, or my own?

The answer changes from person to person, company to company, even month to month. That’s the beauty of the role: there’s no fixed job description, no fixed “right.” The only constant is the constant changing of shells. From head cook to conductor, from there to cartographer. And at every step, asking again: “what’s the right thing now?”

Let’s go back to the fight we started with: both sides are right, both are wrong. Because the question itself is contextless, and a contextless question has no answer. The person who knows the context best is the one sitting in that chair. Being able to set the ego aside and ask “where’s the biggest bottleneck right now?” is a more valuable skill than technical intelligence.

In the end, a CTO’s real job is neither writing code nor not writing it. The real job is being able to honestly answer, every day, the question “where do I create the biggest impact today?” The answer is some days in a terminal window, most days in front of a whiteboard, every day among people. And maybe most important of all: never stopping asking this question. Technology doesn’t stop, the company doesn’t stop, the market doesn’t stop; so the CTO mustn’t stop either. This question is the most critical unit test a CTO rewrites for themselves every quarter.

The Turkish version of this piece is here.