Ben Horowitz describes peacetime and wartime CEOs in The Hard Thing About Hard Things. Andrew Grove writes about similar changes in management under pressure in High Output Management.
I think the distinction is useful for CTOs too, with one important warning: many companies declare war when they are merely behind on the roadmap.
Wartime is not “we would like everybody to move faster”. It is an incident, a severe security problem, a sudden loss of revenue, a regulatory deadline that threatens the business, or another situation where failing to act has serious consequences.
If everything is a war, you do not have a wartime organisation. You have an exhausted one.
The CTO role changes with the situation
In peacetime, the CTO builds capability. The company has enough stability to improve systems, develop people, explore options, and make decisions with a longer horizon.
In wartime, the CTO narrows the field. The organisation needs a clear priority, faster decisions, and shorter communication loops. Work that normally matters may have to stop for a while.
The values should not change. The operating mode does.
That difference matters because urgency can tempt leaders to discard trust, honesty, and respect as if they were peacetime luxuries. They are not. They are the things that let people coordinate when the situation is difficult.
What peacetime is for
Peacetime is not passive. It is when you make the organisation stronger before you need that strength.
A peacetime CTO should focus on:
- connecting technology choices to the company strategy;
- improving delivery, reliability, security, and observability;
- developing leaders and reducing dependence on key individuals;
- simplifying systems and paying the debt that slows change;
- creating room for experiments; and
- building honest relationships across engineering, product, and the business.
This work can look less dramatic than rescuing a production system at 02:00. It is also what makes the rescue less likely.
Peacetime is where you create useful defaults: tested recovery plans, clear service ownership, a deployment process people trust, and communication channels that already work. Do not wait for a crisis to discover who can make which decision.
Recognising wartime
Before changing the operating mode, name the threat.
What exactly has happened? What will occur if the company does nothing? How much time is available? Which part of the business is at risk?
Real wartime conditions may include:
- a serious incident or security breach;
- an existential cash or revenue problem;
- a regulatory or contractual threat;
- a competitor or market shift that removes a core assumption; or
- a critical technical failure blocking the company from operating.
A missed internal target may be urgent. That does not automatically make it existential.
This check prevents “wartime” from becoming a leadership style chosen because decisiveness feels good.
How I would run wartime
State one priority
People need to know what wins when two important tasks conflict. During a major security incident, containing the breach may override feature delivery. During a cash crisis, work connected to retention and revenue may override longer-term platform improvements.
Write the priority down. Repeat it. Explain which work has stopped and why.
Shorten decisions
Make decision rights explicit. A smaller group may need authority to act quickly, but “move fast” should not mean “nobody knows who decided”.
Record important decisions, assumptions, and risks as you go. Memory becomes very creative under pressure.
Increase communication
Wartime needs more communication, not more secrecy.
Set a regular cadence for updates. Separate confirmed facts from assumptions. Say when the next update will arrive, even if you expect no new information. This reduces the rumours and repeated questions that otherwise consume the organisation.
Protect the path to recovery
Do not create three new crises while solving the first one. Keep review, testing, backups, and security controls proportional to the risk. Speed comes from focus and small decisions, not from switching off every safeguard.
Watch the people
Sustained emergency work has a cost. Rotate people, make rest explicit, and notice who has been carrying the invisible load. Heroics may occasionally be necessary; building a system that depends on them is a management failure.
What does not change
Pressure is not permission to humiliate people, hide information, or make every decision alone.
A wartime CTO may be more directive. That can be appropriate when time is short and coordination is critical. But explain the reason, keep challenge possible, and return decision-making when the immediate threat passes.
Psychological safety matters especially during a crisis. You need bad news quickly. If people expect punishment, you will get comfortable news slowly instead.
The organisation also needs honesty about trade-offs. “We are accepting this reliability risk for two weeks to protect the company” is a decision. “Quality does not matter now” is an invitation to create an unknown amount of damage.
Returning to peacetime
The switch back does not happen automatically. Crisis habits have a way of staying because leaders become accustomed to the control and teams become accustomed to waiting for orders.
When the threat is contained:
- Say that the operating mode is changing.
- Review what happened without searching for a villain.
- Keep the temporary practices that genuinely helped.
- Remove the temporary decision structures that are no longer needed.
- Replan the work that stopped.
- Give people time to recover.
Also recognise what the team achieved. Not with a speech about being a family, but with specific thanks, time, and follow-through on the improvements the crisis exposed.
Prepare in peace
The best wartime tool is a well-run peacetime organisation.
Clear ownership, small releases, reliable recovery, good observability, trusted relationships, and leaders at more than one level all create options during a crisis. You cannot write a plan for every event, but you can build a company that notices problems and coordinates a response.
The CTO has to change pace when the situation changes. The difficult judgement is knowing when to do it—and having the discipline to change back.