The Boring Engineering Strategy
Write the strategy down, get the diagnosis honest, then constrain options so energy goes to what matters.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 93%
Larson's claim is that every company already has an engineering strategy — it's just unwritten, so it can't be debugged. Writing it down turns an unfalsifiable complaint ('there's no strategy here') into a document you can improve. The good ones are almost always boring constraints ('we only use the tools we have today'), because a constraint is what focuses limited engineering capacity onto the problems the company actually values. Bad strategy is nearly always a dishonest diagnosis.
Origin
The three-part definition of strategy — diagnosis, guiding policies, actions — is Richard Rumelt's, from 'Good Strategy Bad Strategy' (Larson also cites 'The Crux'). Larson adapts it for engineering: where Rumelt worries most about inert strategy that never gets implemented, Larson finds the engineering value sits in the guiding policies, because their job is to clarify how future decisions get made. The examples are his own from Uber, Stripe and Carta.
Core principles
- 01There is always a strategy. Sometimes it's bad, but it's never absent — it's just unwritten.
- 02Writing it down is what makes it debuggable: is the doc unclear, is this person misapplying it, or is the strategy wrong for this unit?
- 03Good strategy is often boring, and boring is the point.
- 04The goal of strategy is not to appease everyone; it is to dictate how limited capacity gets invested.
- 05Constraint is the mechanism. Deliberately narrowing options is what buys speed and focus.
- 06Almost all bad strategy traces to a willful disbelief about the real diagnosis.
How to run it
- 1
Write down the diagnosis honestly
State the current status quo — what is actually true today, including the constraints you don't like. Larson: bad strategy is usually people exerting what they want to be true onto the constraints, e.g. insisting all these projects can be done at once when they can't.
Pro tip The hardest diagnoses to write are the ones a committed CEO or exec doesn't want to hear. Write it anyway; an incoherent diagnosis makes every downstream policy incoherent.
Watch out If the diagnosis is wishful, the guiding policies are incoherent before you've written a word of them.
- 2
Set guiding policies as constraints
Based on the diagnosis, state how you will address it — usually as a narrowing of options. Examples Larson names: 'we only use the standard kit we already have today' (Carta, written by engineer Eric Vogel), 'we run everything in our own data centers, no cloud' (Uber, 2014 era), 'we run a Ruby monolith' (Stripe).
Pro tip Look for the boring constraint before the ambitious initiative. A rule about what you won't adopt does more work than a rule about what you will.
- 3
Name the actions that implement the policies
Specify how the guiding policies actually get implemented. Rumelt's concern is inert strategy — deciding to deprecate the old features nobody uses, then never deprecating any of them.
Watch out A guiding policy with no actions attached is decoration. On the engineering side you get more leverage from clarity about future decisions than from a fresh action list, but zero actions is still a failed strategy.
- 4
Accept that engineers will hate it, and hold the line
Larson is explicit that engineers hated both the Uber no-cloud policy and the Stripe Ruby monolith. Coming into alignment is painful if you're slightly misaligned, and it can feel like losing control. Hold the constraint anyway if it aims capacity at what the company values.
Pro tip Explain the constraint as an investment thesis about limited capacity, not as a taste preference. It converts 'we won't let you' into 'here's what we're buying with the focus'.
Watch out Do not soften a good constraint just to reduce complaints. Appeasement is not the goal of strategy.
- 5
Debug the written strategy over time
With a document in hand, diagnose failures precisely: the head of product should improve the clarity of this doc; this PM isn't applying it correctly; this strategy isn't appropriate for this business unit even though it works for the others.
Pro tip Treat these three failure modes as your triage categories any time someone says 'the strategy isn't working'.
In the wild
In the 2014 era Uber ran a strict no-cloud policy — everything in its own data centers. It was annoying: they had to invent or run copies of everything themselves. But when Uber needed China, they spun up in roughly three months, including taking the roof off a data center and craning racks in because they wouldn't fit through the door.
→ Uber could move in and out of geopolitical constraints in months. Cloud-dependent competitors are limited to wherever AWS, Google Cloud or Azure have built out. Uber later exited China with a substantial stake in Didi.
Stripe's policy was simply that they ran a Ruby monolith. Many engineers hated it and wanted to introduce new languages. The policy has since loosened (more Java in 2023 Stripe than 2016 Stripe), but during the constrained era it held.
→ Engineering energy went into innovative features for users rather than into building and maintaining tooling to support multiple programming languages.
Common mistakes
Believing you have no strategy because there's no template
People wait for a forkable product-strategy template and conclude that its absence means no strategy exists. The strategy exists; it's just unarticulated and therefore applied inconsistently down the reporting chain. Write the bad version down — you can only improve what's written.
A wishful diagnosis
Almost all bad strategies come from willful disbelief about what an accurate diagnosis is — most commonly the belief that all these projects can be done at once. Every guiding policy built on that is incoherent from the start.
Value-statement strategy
'We build the highest quality products' is not a strategy. It gives no one any basis for a decision. If a reader can't tell what to stop doing after reading it, it isn't guiding anything.
Is it for you?
Best for
Engineering leaders, CTOs and heads of product at companies where teams complain there's 'no strategy', or where every new database, language or cloud gets adopted by whoever argued hardest.
Not ideal for
Genuine R&D or exploratory orgs whose whole purpose is to test unfamiliar tools, and very early startups still searching for a diagnosis worth constraining around.
From the transcript
“the the first rule of strategy is that if you write it down then you can like improve it”
“often good strategy is so boring it's a hard hard to talk about”
“the goal of good strategy is to dictate how we invest The Limited capacities we have or The Limited capabilities we have into the problems…”
“usually because people are are sort of exerting what they want to be true on on constraints”
“there's a diagnosis like what is the current status quo like what are the things that are real today”
From the episode
The engineering mindset
Will Larson (Carta, Stripe, Uber, Calm, Digg)