Reading Notes

Will Larson on Engineering Strategy, Systems Thinking, and Writing Consistently

Source: Will Larson on Engineering Strategy, Systems Thinking, and Writing Consistently

Notes — Will Larson on Engineering Strategy, Systems Thinking, and Writing Consistently

Four questions [Adler frame]

Q1 — What is it about? A practitioner’s case for treating engineering strategy as a deliberate written artefact rather than an emergent organisational habit — and a broader argument that Rumelt’s strategy framework (diagnosis → guiding policies → actions) is the correct lens for any organisational strategy.

Q2 — How is it argued? From direct experience across four major engineering organisations (Stripe, Uber, Calm, Carta) and from sixteen years of writing and reflection. Will makes empirical claims from these cases; he is careful not to overgeneralise from individual examples while still drawing transferable conclusions.

Q3 — Is it true? The “boring strategies are good” claim is well-grounded: constraint-based strategies (standard kit, no cloud, Ruby monolith) demonstrably focus engineering energy. The “every company has a strategy, it’s just unwritten” insight is accurate and underappreciated. The “write it down to improve it” principle is a direct corollary of Rumelt. The limits: this framework is more applicable to large engineering organisations with existing technical debt and coordination overhead than to early-stage startups where the constraint set shifts monthly.

Q4 — What of it? The most actionable takeaway for an engineering leader: if the strategy is not written down, that is the first intervention — not a new strategy, just a written description of the one that currently exists. Then improve it iteratively.

Glossary

Engineering Strategy — the written set of principles that dictates how an engineering organisation allocates its limited capabilities toward the problems the company cares about. Always exists; rarely written down; improvable only once written.

Boring strategy — an engineering strategy characterised by deliberate constraint: we only use the tools we have, we do not use the cloud, we run one language. Frustrating to individual engineers; powerful for organisational focus.

Diagnosis — Rumelt’s first strategy component: an honest characterisation of the current situation and its constraints. Almost all bad strategies trace to a bad or dishonest diagnosis.

Guiding policies — Rumelt’s second component: the principles that govern how the organisation will address the diagnosed constraints.

Actions — Rumelt’s third component: the specific steps by which guiding policies are implemented. Rumelt’s concern: inert strategy, where guiding policies exist but no one implements them.

Stocks and flows — the core vocabulary of systems thinking (from Meadows, Thinking in Systems). Stocks are quantities that accumulate (headcount, code quality, technical debt). Flows are rates of change between stocks (hiring rate, attrition rate). Most engineering planning mistakes involve treating a flow problem as a stock problem.

DORA metrics — deployment frequency, lead time, change failure rate, time to restore service. Useful diagnostic tools; poor evaluation metrics. They reveal where to investigate, not whether to fire your engineers.

Engineering Strategy: the core argument [§ Strategy sections]

Everything already has a strategy

The complaint “we have no engineering strategy” is empirically wrong. A 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 exists. Writing it down is not creating something new; it is making something legible.

The diagnostic value of writing: once written, you can audit whether individuals are applying it correctly, whether it is coherent, whether it is appropriate for sub-units. Without a written document, every pathology looks like a people problem.

Boring strategies

Will’s three canonical examples:

  • Carta standard kit: no new programming languages, databases, or cloud providers. Frustrates engineers who want to use newer tools. Forces energy onto product problems rather than infrastructure proliferation.
  • Uber no-cloud policy (c. 2014): no AWS, own all data centres. Annoying operationally; enabled Uber to spin up China operations in three months (lifting rack in by crane) because they were not dependent on which geographies a cloud provider had built in.
  • Stripe Ruby monolith: frustrated polyglot engineers; focused the organisation on shipping features rather than maintaining cross-language tooling.

The pattern: boring strategies impose a cost on individual engineers (loss of option value, frustration) in exchange for an organisational benefit (focused capacity, consistent tooling, reduced coordination overhead). Good strategy is not about making engineers happy; it is about allocating limited capabilities toward the problems that matter.

Bad strategy traces to bad diagnosis

Rumelt’s framework predicts that bad guiding policies almost always trace to a bad diagnosis. The most common diagnostic failure: a willful belief that constraints are not real (“we can do all these projects at once”). Once the diagnosis is wrong, the guiding policies are internally coherent but externally incoherent — they solve a problem that does not exist while leaving the real problem unaddressed.

Systems thinking for engineering organisations [§ Stocks and flows]

Hiring pipeline as a stock/flow system:

  • Stock: engineers on team
  • Inflows: new hires
  • Outflows: attrition

A company that cuts hiring budget to improve velocity is manipulating the inflow. If the velocity problem is caused by high attrition creating instability, cutting inflow makes it worse. The stock/flow model makes this obvious; gut instinct often misses it.

Systems thinking is a discipline for accurate diagnosis. Will’s recommendation: Thinking in Systems by Donella Meadows.

On writing consistently [§ Writing]

Will has written approximately 1,000 posts across 16 years of engineering leadership roles. Key principles:

Write what gives you energy. Every piece written on assignment (for a magazine, for SEO, for what people want) is a drain. Every piece written from genuine current interest is sustainable. The risk to writers is not running out of ideas; it is quitting, which is more likely when writing is a chore.

Write what you are thinking about now. Not what is trending, not what your audience has requested. Staying in your lane produces more novel work than chasing trends, where everyone is saying the same thing.

Write the entire book before engaging a publisher. Reduces the risk of the publisher’s requirements diverging from the content you actually want to write. Applicable primarily to business/practitioner books where chapters do not depend on sequential technical build-up.