The wartime CTO

In The Godfather, just before the family moves its business to Las Vegas, Michael Corleone tells Tom Hagen that he is out. Tom is the consigliere, the family lawyer, almost a son to Vito, and a brilliant negotiator. He asks why. Michael answers with one line; "You're not a wartime consigliere."

The idea of applying this scene to the people who run companies is not mine. As far as I know, it was Ben Horowitz who did it first, in a post titled Peacetime CEO/Wartime CEO, back in April 2011 (the occasion was Eric Schmidt stepping down as CEO of Google and Larry Page taking over). His point was simple; the CEO who is great while the company is winning is not always the one you need when it fights for its life.

I have been thinking about the CTO (Chief Technology Officer) version of this for some years now. I believe it holds even more for us than for CEOs, and in 2026 it is not a thought experiment anymore.

Peace and war

So, what is the difference?

A peacetime CTO optimises. The company grows, the market is stable, and the job is to refine; better processes, better careers, consensus, small improvements that compound over the years. It is a good job, and many people are excellent at it.

A wartime CTO works under existential pressure. The runway is collapsing, or a competitor is eating your market (usually a small one, that everyone misread as weak), or the platform has to be rewritten, or a migration has to ship before the quarter ends, or the biggest customer is leaving. Survival comes before optimisation. Decisions are made fast, with incomplete information, and the CTO answers for them personally, in weeks rather than years.

Of course, wartime is not a virtue. It is a cost, and nobody should go looking for it (a leader who manufactures crises because they enjoy them is a different problem, and a worse one). But the most expensive mistake I know is the opposite; running peacetime plays while you are at war. Consensus meetings while the runway burns. A beautiful target architecture for a company that may not exist in eighteen months.

Everything is a pivot

I wrote my first program in 1984, and I have lived through several of these shifts since. Mobile over the web, and native apps over the mobile web; the cloud, whose managed services removed a big part of the DevOps work; Kubernetes, which is a bureaucracy, but a contained one. Each of them was a war for some companies. But you usually had a few years to adapt.

AI is different, because it keeps changing form. First it was a chat. Then an API you chat with, where you keep the memory yourself. Then reasoning models, then harnesses, and now agents. Largely the same models underneath, with a new layer on top every year. How code is produced, how it is reviewed, how it is scaled and delivered, how it is secured; all of it moves at the same time. And the companies built on a rented frontier model learn what war means the morning their provider changes its prices.

I am dating this claim on purpose; this is October 2026. In five years it may not hold, and maybe the wartime CTO will be something else by then. But today, for most of us, wartime is not the exception. We are constantly on the pivot.

What changes

From my experience, three things change, and none of them is about technology.

The first; the CTO is the stakeholder. A lot of the advice for technical leaders is about the art of saying no; how to decline the CEO's pet project, how to push back on sales. I think this is the most common mistake a technology leader makes. The CTO is the representative of the business inside tech, not the chief of a tech tribe conducting its own politics against the other executives. You sit at the table where the decision is made, and once it is made, there is nothing left to say no to. The measure of every piece of technical work is the value it brings to the company, and anyone in your organisation should be able to answer, at any moment, how their work does that. If delivering the value means hacking something, you hack it. There are exactly two exceptions, performance and security; hack those and the system will break, or someone will break it for you.

The second; small teams beat the org chart. Everyone has an eight-month button. In an organisation of 600 to 800 engineers, someone asks for a button to change colour, and eight months later it reaches production (a true story, and not the only one I have). Nothing in that delay is engineering; the change takes minutes. The months go to finding the owner, getting into a backlog, getting prioritised and waiting for the release train. In peacetime this is an irritation. In wartime it is fatal. So the wartime CTO keeps a small team of about five people, never more than seven or eight, that can act end to end across the whole system (I wrote about this here a few years ago). They do not have to do all the work themselves. But when you agree something with them, it happens, and the accountability is theirs.

The third; you remove process. People always have the tendency to add processes, and the CTO must always have the tendency to remove them. I once had the following release chain; engineering tested, QA ran their harnesses, product gave the final yes, and only then did it go to production. Everyone was waiting for everyone else. So I removed the QA step. Engineering became responsible for the app not crashing and meeting the requirements, and product for deciding that this is what we ship to clients. Did the bugs increase? Yes, they did. But they were bugs that automated systems should catch, not people. Nobody adds a process in bad faith, by the way. The people inside a process find ways to fulfil its purpose, they stay busy, and they genuinely believe it is right. That is exactly why someone has to take it away.

In the arena

Then there is the person. A wartime CTO leads from the front; you face the same risks as your engineers and you fight alongside them, instead of ordering them into battle. But being in the arena is not the same as doing everyone's work, and the difference is where most of us get it wrong.

You have to know what is going on. During an incident, the worst sentence a CTO can say is "the team is looking at it". Everyone has to see that you understand the problem, that there is a solution, and that you can explain it to the CEO in one message. The engineers do the job; you take the hard decisions (restart the database, scale out to five thousand instances) and the accountability that comes with them. That requires being technical, not at the level of building the button on the web page, but deep enough to understand how things actually work. And that takes study. Every night, for years (a 30-minute Python course on Udemy first thing in the morning is fine for learning, but it is not a CTO thing).

You also have to see the wall before it is there. I remember a brilliant principal engineer who once cut the average latency of our API from 400 to 250 milliseconds. People were cheering. The same day I told him that the way it was deployed would break, in around nine months; the business was growing fast, and everything still relied on a single database with, in practice, one read replica. He looked at me and said nothing (years later he admitted he had not understood why). We built the replacement together. Nine months later, while we were polishing it, the old system had its first downtimes. We were ready. You do not join the cheering; that is the job.

And you have to get yourself off the critical path. For years the DevOps engineers gave me admin access to everything, out of inertia, because that is what you do for the CTO. When we moved to a new system, they found that almost eighty percent of my accounts had never been initialised. I had never logged in. Access is a quiet way of becoming the bottleneck; if you can change a system, sooner or later someone will ask you to, and sooner or later you will.

The cost is real, and I paid it. During COVID, the most demanding period of my working life, I did a lot of hands-on work and delivered a lot of features. Most of them are still in use, and they were the right call. But delivering is addictive; each feature you ship makes the next one feel more urgent. I neglected the exercise and the routine, and I had to correct for it afterwards. The body is the only protected time a CTO has.

Epilogue

Which brings me back to Tom Hagen. In the same scene, Vito tells Tom that he never thought he was a bad consigliere; the bad one, in his view, had been Santino as a Don.

That is the part people forget. Sonny was the wartime leader everyone imagines; loud, brave, always on the front line. And he did not survive the war (no spoiler, the film is from 1972 :) ). The family came through it with Michael, who was calm, patient and saw the threat coming long before anyone else did. Tom was not thrown out either; he was moved, because he was still the best lawyer they had.

So when someone tells me that the wartime CTO is the one who shouts, codes through the night on pizza and coffee and fires people on impulse, I think of Sonny. Wartime does not need more heroism. It needs someone boring to death; someone who sleeps seven hours, studies every night, asks the same question two years later ("we decided this, is it still the case?"), replaces the people who cannot make the transition (friends included), and takes the blame in public when things break. Credit goes down to the team, accountability goes up to you.

Not everyone is cut out for this, and that is not a criticism. But the bill for a bad Don, as Vito knew, is always paid by the family.