Engineering Strategy
The written set of principles that governs how an engineering organisation allocates its limited capabilities toward the problems the company cares about. As articulated by Will Larson: always exists, rarely written down, and improvable only once written.
The core insight
Complaints that “we have no engineering strategy” are empirically wrong. An engineering strategy exists whenever an organisation makes consistent choices — about tools, architecture, hiring, prioritisation. The strategy may be inconsistent, poorly articulated, or applied differently across reporting layers; but it is never absent. Writing it down is not creating something new. It is making something legible.
The diagnostic value of writing: once documented, you can audit whether individuals apply it correctly, whether it is internally coherent, and whether it is appropriate for sub-units. Without a written document, every pathology looks like a people problem.
Will’s first rule: “If you write it down, then you can improve it.”
Boring strategies
Good engineering strategies are often deliberately boring: we only use the tools we already have, we run one programming language, we own our own data centres. These constraints frustrate individual engineers while focusing organisational energy on the problems that matter.
Will’s canonical examples:
- Carta standard kit — no new programming languages, databases, or cloud providers; energy stays on product problems rather than infrastructure proliferation.
- Uber no-cloud policy (c. 2014) — all data centres owned; enabled spinning up China operations in three months because no dependency on cloud provider geography.
- Stripe Ruby monolith — frustrated polyglot engineers; focused the organisation on shipping features rather than cross-language tooling.
The pattern: boring strategies impose a cost on individual engineers (loss of option value) in exchange for an organisational benefit (focused capacity, reduced coordination overhead).
Rumelt’s framework
Will Larson applies Richard Rumelt’s three-part definition to engineering strategy:
- Diagnosis — an honest characterisation of the current situation and its constraints. Almost all bad strategies trace to a bad or dishonest diagnosis; the most common failure is willfully believing that constraints are not real.
- Guiding policies — principles that govern how the organisation addresses the diagnosed constraints.
- Actions — specific steps implementing the guiding policies. Rumelt’s concern: inert strategy, where guiding policies exist but no one implements them.
Source
Introduced in Will Larson on Engineering Strategy, Systems Thinking, and Writing Consistently.