Project Anatomy: Wishful Thinking Is Not a Strategy

TL;DR: Outcome = Strategy × Tactics. It’s a product, not a sum - so one zero is fatal. Wishful thinking is quietly setting the strategy term to zero and betting tactical brilliance covers for it. It can’t. This post is how to tell a strategy from a wish, and what to do when you catch one in the wild.

The Question #

Somebody new joins - a director, a staff engineer, doesn’t matter who - and in their first week they ask the question that’s supposed to be easy. “So what’s the strategy here?”

And someone pulls up the roadmap.

You know the one. Four columns, Q1 through Q4 - or four rows of Gantt bars, if your tool of the month leans that way. Thirty-odd line items in tidy pastel. Auth revamp. Mobile parity. The Migration. AI-powered something. Performance. Each one owned, each one tagged, each one with a quarter beside it like a promise. It looks like months of thinking. It probably was.

It’s also not a strategy.

It’s a list. A list of what we’ll build and roughly when - genuinely useful, and a completely different object from a strategy. A roadmap answers what. It says nothing about why these thirty things and not the three hundred others on the table. It doesn’t name the one problem that’s actually bleeding you. It doesn’t say what you’re choosing not to do. No diagnosis, no choice, no edge - just motion, scheduled.

Hand someone the roadmap when they asked for the strategy and you’ve answered a different question, very confidently, and felt productive doing it.

Here’s the part that should keep you up: a team can run that roadmap flawlessly - every item shipped, every quarter green, burndown gorgeous - and a year on, nothing has actually moved. Because shipping a wishlist on time is still just shipping a wishlist.

This post is about that gap. About why strong teams keep mistaking a list for a plan, and a plan for a strategy - and what that mix-up quietly costs.

Strategy & Tactics, the 60-second 101 #

Both words get thrown around so loosely that “strategy meeting” and “tactical plan” can refer to literally the same artefact. Let’s sharpen.

Tactics are the how. Concrete moves - pick the queue over the cron, add the index, cache here, rewrite that service, run the spike. Near-term, legible, measurable. The question: “what do we do next, and how?”

Strategy is the why-this-not-that. A diagnosis of the one obstacle that actually matters, a choice of where to aim, and what you’re explicitly giving up to aim there. The question: “what’s actually in our way, and what’s our coherent approach to beating it?”

The split is older than software. Stratēgia in Greek meant generalship - the whole campaign, the job of the stratēgos. Taktikē meant the arrangement of forces in a single engagement. The general picks which war and where; the soldiers pick how to take the next hill. We borrowed the words and then forgot they meant different things.

One line for the back pocket: strategy is direction; tactics are motion. Huge motion in the wrong direction is most death marches. Knowing exactly where to go and never moving is most architecture decks.

And the meeting-ready litmus: if you can’t say what you’re not doing, you’re describing tactics, not strategy. Strategy implies sacrifice. A plan with no sacrifice is a to-do list with ambition attached.

The multiplication, not the sum #

The shape of the model matters more than the formula. Why a product, and not a sum?

Because addition would let a heroic tactical team add their way out of a missing strategy. Pour enough velocity in and the total still climbs - that’s what addition does. Multiplication is honest about the dependency. One term goes to zero and the whole thing collapses, no matter how huge the other gets. There is no amount of “execute better” that recovers from “we picked the wrong problem.”

The thing to notice about the first two rows: from the inside, they feel completely different. The death march feels like failure. The architecture deck feels like winning. Look at the actual output and they’re the same number. Zero.

The well-run death march is the more dangerous of the two, because the team’s instruments all light up green. Velocity holds, burndowns drop, every demo goes well. A team can ship constantly and nothing moves - and it can stay that way for years, because shipping is legible and outcome is not.

What wishful thinking actually is #

The most useful thing Richard Rumelt did in Good Strategy / Bad Strategy was refuse the symmetric framing. Bad strategy is not the absence of strategy. It’s a specific thing - a recognisable set of moves that look like strategy from across the room. It wears strategy’s costume. Once you can see the costume, you can’t unsee it. Four patterns, translated to engineering.

Fluff. “We’ll leverage best-in-class cloud-native architecture to delight users.” Notice what the sentence does and doesn’t do: words that sound like commitment, committing to nothing. Try Roger Martin’s opposite test - if the opposite of your statement is obviously idiotic (“we’ll build a slow product users hate”), then it isn’t a choice. It’s a platitude that happened to get formatted in a slide.

No diagnosis. The team announces “we need to move to microservices” and the room nods. Nobody has named, in a sentence, what’s actually slow, what’s actually fragile, or what users are actually leaving over. The solution sprinted past the problem. Rumelt is blunt: weak diagnosis is the single most common cause of bad strategy - and engineering organisations are unusually good at it. So much tooling, so many patterns, so much pattern-matching reflex that we can supply a solution before we’ve finished reading the symptoms.

Goals dressed as strategy. “Reliability to 99.99% by year-end” is a fine goal. It is also not a strategy. A strategy is the how and, more importantly, what you’ll stop doing to fund the how. A number with a deadline stapled on tells the team where to land without telling them which runway to use or which other flights to cancel. They will pick locally-sensible runways. They will not converge.

Urgency mistaken for direction. The CEO who wants everything today is supplying pressure, not direction. Rumelt is careful here: strategy is not ambition, determination, or inspirational leadership. Those are inputs the strategy uses. They are not substitutes for it. A team running on pure urgency does what any team would - it grabs the nearest legible task and ships it. That’s tactics doing its job. The strategy term, meanwhile, is quietly equal to zero.

Run a real 2026 example through this. “We’re rolling out AI coding assistants across every team by Q3” - does it pass? It’s not pure fluff; it commits to something specific. But there’s no diagnosis (what’s actually bottlenecking us?), the goal is wearing the strategy’s costume (the rollout is the goal, not the how), and the energy behind it is mostly urgency - everyone else is doing it, we should too. Three out of four tells, scored in under a minute. That’s the cost of skipping the diagnosis: a capability you couldn’t aim if you tried.

Wishful thinking isn’t the opposite of strategy. It’s the counterfeit of it.

Why engineers fall for it hardest #

The problem isn’t ego or short-sightedness. It’s structural: tactics are legible, strategy is not.

Velocity is a number. Merged PRs are a number. A clean CI/CD graph is a number. None of them tell you whether you picked the right problem - and there is no dashboard for “did we aim at the thing that actually matters.” So we over-invest where the instruments work, under-invest where they don’t, and the term we neglect is the multiplicative one.

Which is why the same small bestiary of engineering-shaped wishes keeps showing up. The Rewrite - once we rebuild it, everything gets faster, with no diagnosis of why it’s slow. The Migration - adopt the thing and hope the thing is the strategy. “We’ll add tests, observability, docs later” - later is where wishes go to die. CI/CD and Kubernetes as a strategy - a capability you can’t aim is just expensive motion. Each one is the strategy term going to zero, in a way that feels like progress from the inside.

The honest counterargument #

Here’s the version that gets thrown back at me when I make this argument out loud, and it’s good enough that I should make it for you first.

Sometimes “strategy first” is itself the wish. Sometimes the information you’d need to diagnose the actual problem doesn’t exist yet. You don’t know which workflow is leaking activation. You don’t know whether the latency is a database, a client, or a cache problem. You don’t know which segment is the right segment to chase. In that state, demanding a clean diagnosis before any action is its own kind of wishful thinking - “if we just plan harder, the answer will appear” - dressed up in strategist’s glasses.

The honest move in that state isn’t to keep planning. It’s to run a small, time-boxed bet, fully aware that the bet is how you buy the diagnosis. The two-week spike, the cheap A/B, the smallest customer pilot - these aren’t substitutes for strategy. They’re how you generate the data a real strategy requires. The failure mode isn’t acting before you’re certain. The failure mode is acting and then refusing to read the result - shipping the spike, declaring victory, and absorbing the result into the roadmap without ever returning to the diagnosis the spike was supposed to produce. That’s the actual line. The discipline isn’t strategy-before-action. It’s never letting an action escape without a diagnosis attached.

The test: wish or strategy? #

Six questions. Apply them to anything that’s been called a strategy in your last quarter.

1. Diagnosis - Can you name the single biggest obstacle in one sentence? If not, it’s a wish.
2. Sacrifice - What are you explicitly not doing? If “nothing,” you haven’t chosen - and strategy is choice.
3. Opposite test - Is the opposite of your plan obviously stupid? If yes, it’s a platitude, not a decision.
4. Coherence - Do the actions point the same way, or is it a laundry list of locally-sensible tickets?
5. Matched pair - Does your how actually serve the one outcome that matters, or is it busywork that just happens to be reasonable?
6. Falsifiability - “What would have to be true for this to work?” Have you checked the least likely one?

If a plan can’t survive these, the strategy term is going to zero - and you’re about to multiply your whole team by it.

Worked example: same team, two numbers #

A demanding CEO. “Win the market by Q3.” (Whether that aspiration is winnable at all isn’t the team’s call to make - they work with what they’re given.) Run the same team through six months twice.

Run one - wishful thinking. The team reaches for tactics. A microservices migration because the monolith feels slow. Three new hires because more engineers is more output. A rewrite of the checkout flow because the rewrite feels like progress. No diagnosis - nobody asks, in a sentence, what’s actually preventing wins. Six months of motion. Every item ships on its calendar. The CEO asks how we’re doing; someone pulls up the roadmap. Burndown gorgeous. The market knows none of it happened. Outcome: 0.

Run two - strategy. Same week one. The team spends it on the funnel instead. They find one core flow whose intermittent failures are killing 60% of activations - and that flow is upstream of everything else. That’s the diagnosis. Where to play: one workflow, one segment, this quarter. How: fix the flow, instrument it, stop everything else that doesn’t serve it. What gets dropped: the rewrite, two of three hires, the microservices migration. The sacrifice is the proof there’s a strategy at all. Six months later: the funnel is fixed, the segment is converting, the company has the data to make a real next bet. The strategy term wasn’t zero. Outcome: a multiple.

Same engineers. Same calendar. Same CEO, same pressure, same talent. The only variable that changed was whether the strategy term was zero.

Go back to that roadmap - the one someone pulls up when you ask for the strategy. Every line answers what and when. Not one answers why these, and not the hundred others. That answer is the strategy. It was never on the board. Zero times anything is still zero.