Flowstate - Scenario planning

Your CEO just walked out of a board meeting where an activist investor pushed for 15% headcount reduction. She needs three options on her desk by tomorrow morning: what engineering looks like if you cut deep, cut moderately, or restructure without cutting. You’ve got a spreadsheet that took your finance partner two weeks to build last quarter. It models exactly one future. The one that’s no longer relevant.

This is where most engineering leaders get stuck. Not because they lack strategic thinking, but because their planning infrastructure can only produce one version of reality at a time.

The job

Scenario planning is the discipline of modelling multiple possible futures so you can make decisions today that hold up when circumstances change. It’s not forecasting — forecasting pretends you know what’s coming. Scenario planning acknowledges you don’t, and builds decision frameworks that work across a range of outcomes.

Engineers already solved this problem decades ago. Git branching lets you explore different implementations simultaneously, diff them against each other, and merge the one that works. Workforce planning should work exactly the same way — branch your plan, model the implications, compare the diffs, and commit to the path that makes sense.

The problem is that most organisations can produce one scenario in two weeks. What you actually need is three scenarios in 24 hours.

Why it matters

When you can only model one future, you’re not planning. You’re guessing and then defending your guess.

I’ve watched this play out at a Series C fintech that spent six weeks building their 2024 headcount plan. Beautiful spreadsheet. Perfectly reconciled with finance. Then their biggest enterprise client churned in January, revenue dropped 20%, and the entire plan was worthless. They spent another four weeks rebuilding it. That’s ten weeks of planning for a plan that survived three weeks of contact with reality.

The cost isn’t just the time. It’s the decisions you don’t make while you’re rebuilding. Every week without a valid plan is a week where hiring is frozen by default, where teams can’t commit to roadmap items, where your best engineers start updating their LinkedIn profiles because nobody can tell them what the next six months look like.

Engineering leaders who can produce multiple scenarios quickly earn a fundamentally different kind of trust from their boards and executive teams. You stop being the person who asks for headcount and starts being the person who presents options. That shift — from supplicant to strategist — changes everything about how engineering is perceived.

What good looks like

Struggling: One plan, built in a spreadsheet, maintained by one person who understands it. Takes two weeks to update. Nobody trusts the numbers because they’re always stale. Every board meeting triggers a fire drill.

Mature: Three scenarios maintained continuously. Any one of them can be pulled up, stress-tested, and presented within hours. The engineering leader walks into budget conversations with options already modelled, trade-offs already quantified, and a recommendation already formed.

Markers of excellence:

You can produce a new scenario in hours, not weeks
Every scenario includes cascade effects — if you cut Team A, what happens to the projects they support, the teams that depend on them, the roadmap items that slip?
Your scenarios are denominated in business outcomes, not just headcount numbers
You maintain a living “decision diff” — a one-slide summary of what changes between scenarios and what stays the same
Finance trusts your numbers because they’re derived from the same source data

The approach

1. Adopt the three-scenario framework

Every planning cycle should produce three scenarios: conservative, moderate, and aggressive. These aren’t arbitrary labels — they map to specific business conditions.

Conservative: What does engineering look like if revenue comes in 15-20% below forecast? What do we protect, what do we pause, what do we cut? This is your downside plan.
Moderate: What does engineering look like if we hit plan? This is your base case. Most organisations only build this one.
Aggressive: What does engineering look like if we exceed targets and want to accelerate investment? Where would you add capacity first? This is your upside plan.

The magic isn’t in any single scenario. It’s in the delta between them. When you can show your CFO that the difference between conservative and aggressive is four engineers on the payments team and a six-month acceleration of the platform migration, you’ve given them a decision framework, not just a number.

2. Map cascade effects

This is where most scenario planning falls apart. People model the headcount changes but forget that removing one senior engineer from the infrastructure team doesn’t just save £130K — it delays the Kubernetes migration by three months, which means the platform team can’t ship their Q3 commitments, which means the enterprise sales team loses a competitive feature.

For every change in each scenario, map:

Direct impact: Cost saved or added, capacity changed
Project impact: What ships later, what ships sooner, what doesn’t ship at all
Dependency impact: Which other teams are affected and how
Revenue impact: What does this mean for the top line, even if the connection is indirect

This takes work. But it’s the difference between a plan that survives a board meeting and one that gets torn apart by a non-executive who asks “what happens to the platform roadmap if you cut those three roles?“

3. Build the decision diff

Here’s the thing: executives don’t want to read three separate plans. They want to understand what’s different between them and what the trade-offs are.

The decision diff is a single artefact — ideally one slide or one page — that shows:

	Conservative	Moderate	Aggressive
Total engineering headcount	82	94	108
Annualised cost	£9.2M	£10.8M	£12.4M
Key project: Platform migration	Delayed 6 months	On track	Accelerated 3 months
Key project: Mobile app v2	Paused	Reduced scope	Full scope
Revenue at risk	£2.1M	None	None
Revenue upside enabled	None	None	£4.3M

This is the artefact that gets used in actual decisions. Not the 47-tab spreadsheet behind it.

4. Establish a cadence

Scenarios aren’t a one-off exercise. Build them into your operating rhythm:

Quarterly: Full scenario refresh aligned to business planning. Three scenarios, fully mapped cascade effects, decision diff presented to leadership.
Monthly: Lightweight scenario check. Have any assumptions changed enough to invalidate a scenario? Update the decision diff.
On-demand: When something material changes — a big client churns, an acquisition closes, a market shifts — you should be able to produce an updated scenario within 24 hours.

The on-demand capability is what separates good from great. And it’s only possible if your planning infrastructure supports it.

Every scenario should be versioned, timestamped, and shareable. When someone asks “what was the plan we discussed in the March board meeting?” you should be able to pull it up instantly, not reconstruct it from memory and email threads.

This sounds basic. I promise you, 90% of engineering organisations cannot do this.

The conversations

How you talk about scenarios matters as much as how you build them. Different audiences need different framing.

With your team

Trust-building: “I’ve modelled three versions of next quarter so we’re prepared regardless of what happens with the Q2 revenue numbers. Here’s what each one means for us.”

Trust-eroding: “There might be cuts coming. I don’t know the details yet. I’ll let you know when I know.”

Your team needs to know you’re thinking ahead and that you have a plan. They don’t need to see every scenario — that creates unnecessary anxiety. Share the moderate case as the working plan, and let them know you’ve got contingency plans if things change.

With your peers (other department heads)

Trust-building: “I’ve mapped out how our engineering scenarios affect your team’s roadmap. In the conservative case, the API integration you need slips to Q3. I wanted you to have that visibility now so we can plan around it.”

Trust-eroding: “We might not be able to do your project. Depends on budget.”

Cross-functional trust comes from proactive communication. When you can show a peer the cascade effects on their priorities before they have to ask, you become the most reliable partner in the organisation.

With leadership (CEO, CFO, board)

Trust-building: “Here are three options for engineering investment next year. Each one maps to a different revenue growth assumption. I’d recommend the moderate case, and here’s why — but the conservative plan is ready to activate if we need it.”

Trust-eroding: “We need 12 more engineers to hit roadmap. Can we get budget?”

Leadership wants options, not asks. They want to see that you’ve thought about the business holistically, not just your own empire. The engineering leader who presents three scenarios with a recommendation earns a fundamentally different level of trust than the one who presents a single wish list.

Common failure modes

Building scenarios nobody asked for. Scenario planning has to connect to actual decisions. If nobody’s choosing between your scenarios, you’re doing an academic exercise. Always anchor to a real decision: “We need to decide X. Here are three options.”

Over-engineering the model. Your first scenario model should take a day to build, not a month. Start with headcount, cost, and three or four key project impacts. You can add sophistication later. I’ve seen teams spend so long perfecting their model that the decision window closed before they finished.

Forgetting to update. A scenario from six months ago is worse than no scenario at all because it creates false confidence. If you can’t maintain it, simplify it until you can.

Modelling headcount without modelling capability. Cutting five engineers isn’t the same as cutting five engineers if three of them are your only people who understand the billing system. Scenarios need to account for skills and knowledge concentration, not just numbers.

Treating the moderate case as the plan. The moderate case is the most likely outcome, but it’s not a commitment. Make sure leadership understands that all three scenarios are tools for decision-making, not promises.

Getting started

If you’re not doing scenario planning today, here’s how to start this quarter.

Week 1: Build a simple three-scenario model for your current team. Use a spreadsheet. Three columns: conservative (cut 15%), moderate (stay flat), aggressive (grow 15%). For each, list the top five project impacts.

Week 2: Share the model with your finance partner. Ask them to validate the cost assumptions. This is also a trust-building exercise — you’re showing finance that you think in their language.

Week 3: Present the decision diff to your manager or leadership team. Not as a formal proposal — as a “here’s how I’m thinking about next quarter.” Gauge the reaction. Iterate.

Week 4: Establish the cadence. Put quarterly scenario refreshes in your calendar. Assign a DRI for maintaining the model.

You’ll be shocked how quickly this changes the quality of your budget conversations. Instead of defending a single plan, you’re facilitating a strategic discussion. That’s a bloody good place to be.

Downloads

The Scenario Planning Model is an Excel template pre-built with the three-scenario framework. It includes tabs for headcount modelling, cascade effect mapping, and a decision diff summary slide. Plug in your team data, adjust the assumptions, and you’ll have a working scenario model in a few hours rather than starting from scratch.

Capacity Planning — Your scenarios are only as good as your capacity assumptions. Get those right first.
Investment Framing — Once you’ve picked a scenario, frame the engineering work within it as investments with expected returns.
Building Long-term Credibility — Track how your scenarios compared to what actually happened. Calibrating over time is how you build trust.