Andi Smith

Technical Leader Product Engineer AI Consultant

Peacetime vs Wartime

  • By Andi Smith
  • 5 minute read

Your monolith is buckling under heavy traffic growth.

The quick fix is to beef up the server through vertical scaling and buy yourself six months. The right fix is a four month microservices migration that will either save the company or kill it if you miss the deadline. Meanwhile your $2m client is demanding new features or they'll go elsewhere.

That's the kind of decision making situation Ben Horowitz captures in The Hard Thing About Hard Things. The book is a thoroughly insightful read on the challenges that face CEOs and a recurring theme throughout the book is the contrast between a peacetime CEO and a wartime CEO.

Peacetime usually occurs when a company has a large advantage against its competitors in its core market, and its market is growing. The company can focus on expanding the market and reinforcing its strengths.

Wartime usually occurs when a company is fending off an imminent existential threat from competition or a dramatic economic change.

The core philosophy in the book is that during peacetime, leaders must maximise and broaden the current opportunity using techniques to encourage broad-based creativity across diverse objectives. Whilst in wartime, the company must hit the target - survival depends on strict adherence to the defined mission.

Applying this Philosophy to CTOs

Reading this book led me to think about how this applies to CTOs. For many of the points made in the book about CEOs, they can be applied equally to CTOs. But there are some additional peacetime/wartime scenarios that are worth thinking about:

Strategy

  • Peacetime CTO balances new feature development with platform improvements. Wartime CTO ships only features that directly impact survival metrics.
  • Peacetime CTO invests in monitoring, automation processes and scalable infrastructure. Wartime CTO focuses on keeping the lights on with minimal viable infrastructure and manual processes if needed.
  • Peacetime CTO plans for disaster recovery and business continuity. Wartime CTO takes on risk if it buys another day of survival.

Technology

  • Peacetime CTO encourages experimentation with new technologies and proof of concepts. Wartime CTO sticks with known, boring technologies.
  • Peacetime CTO may opt for a microservices architecture. Wartime CTO accepts a monolithic solution to ship faster.
  • Peacetime CTO lets the team decide their technical stack. Wartime CTO makes immediate decisions based on the fastest outcome and avoids unnecessary rewrites and refactoring.
  • Peacetime CTO allows for experimenting with the best tool for the job. Wartime CTO optimises for cost as if every penny were coming out of their own pocket.

Team

  • Peacetime CTO guides the team through career development and improvement. Wartime CTO hires and fires without hesitation to get the right team.
  • Peacetime CTO invests in developer experience and tooling. Wartime CTO tolerates developer friction if it means faster time to market.

Security

  • Peacetime CTO implements comprehensive security frameworks and compliance protocols. Wartime CTO goes for "good enough" to not get breached while moving fast.

Scenarios

Wartime Scenarios

  • A startup trying to find their product market fit with limited funding.
  • An e-commerce platform during Black Friday with revenue on the line.
  • A fintech startup racing to achieve compliance before funding runs out.
  • A company during a viral growth spike that's breaking infrastructure.

Peacetime Scenarios:

  • A dominant streaming platform, focusing on global infrastructure.
  • A successful enterprise software company investing in developer productivity.
  • A mature startup with product-market fit optimizing for long-term scalability.

To understand what mode you should be in, you need to be taking regular assessments of where your business is at internally and within the market. How much runway do you have? Who are your biggest competitors? Is your revenue trending upward?

The Adaptive CTO

To be an effective CTO you need to be skilled at recognising which mode you are in and adapting your leadership style accordingly.

Your technical judgement needs to be good enough to understand what are real vs perceived risks. You need to know when your team are pushing for improving technical debt that will actually cause pain vs code that is ugly but functional.

Communicating under pressure is key to being able to successfully operate. You'll need to translate complex technical issues into language understood by stakeholders and be comfortable with difficult conversations about trade-offs.

You'll also need to be an expert at reading team morale and understanding the teams' stress levels. You'll need to know when you can push them hard vs when you need to give them space. To do that, you need to build relationships and trust that persists through both good times and in times of crisis.

There are some practical exercises in scenario planning, decision training and communication style training that can help you to build up these skills. For example:

  • If you had to cut costs by 50% tomorrow, what would you do?
  • Make a technical decision with incomplete information
  • Write a status update in the tones of "everything is under control" and "urgent action needed".

The best CTOs develop an instinctive ability to sense when the environment is shifting and proactively adjust their leadership style before being forced to by circumstances. If you look at your roadmap today, are you acting like it's peacetime or wartime? ...and are you absolutely sure you are in the right mode?

Please note: As an Amazon affiliate I earn from qualifying purchases.

Andi Smith

By Andi Smith

Andi Smith is a passionate technical leader who excels at building and scaling high-performing product engineering teams with a focus on business value. He has successfully helped businesses of all sizes from start up, scale up to enterprise build value-driven solutions.

Related Blog Posts

  • Ship Fast, Scale Clean - Building MVPs That Last

    Your founder comes to you with the classic Minimum Viable Product (MVP) dilemma. We need to build quickly for speed to market, but make it maintainable so it can scale as we grow.

  • Lessons from Startup Life

    Some things I learnt during my time working as tech employee #1 at a startup.

  • Keeping SaaS Costs Down

    It's very easy to fall in to the trap of tool sprawl and escalating costs - particularly in the high speed world of startups. Let's take a look at some techniques we can use to keep a handle on it.

  • Buy vs. Build

    When you're building a product at a startup, every engineering hour counts. You can't build everything from scratch, but you also can't buy your way out of every problem. The key is knowing where to draw the line.