Writing Technical Strategy

Welcome to the advanced module. Everything so far — trade-offs, ADRs, SLOs, incident reviews — operated on one decision at a time. Strategy is the level above: a written stance that makes a hundred future decisions for you. It's also the most faked document in engineering. Most "strategy" docs are a slide of ambitions ("world-class platform!", "10x developer velocity!") that commit nobody to anything — what Richard Rumelt calls bad strategy, and it's not merely weak strategy but an active substitute for it.¹ This lesson gives you the test that separates the real thing from the fluff, and a method for writing the real thing.

The kernel: three parts, no substitutes

Rumelt's Good Strategy Bad Strategy — the foundational text everything in engineering strategy builds on — says every good strategy has the same logical skeleton, the kernel: a diagnosis, a guiding policy, and coherent action.¹ Miss any one and you don't have a strategy — you have a wish, a slogan, or a to-do list:

The diagnosis is the hard, honest part — and where most docs fail before they start. Rumelt calls the inability to face the challenge the core of bad strategy: if you haven't named the real problem, you can't evaluate any policy against it.¹ A real engineering diagnosis sounds uncomfortable and is backed by evidence: "we run four half-maintained ways to deploy, and the two production incidents last quarter both started in the least-maintained one." Not "we need to modernize our infrastructure" — that's a conclusion smuggled in as a diagnosis.

The guiding policy is where the choice lives — and choice means exclusion. "We will use the right tool for each job" forbids nothing, so it decides nothing: it's fluff wearing a strategy costume. Larson makes the same point in engineering terms: good policies guide trade-offs and explain the rationale; a policy every team already agrees with, that changes no behavior, wasn't worth writing down.² Here's the Principal-grade test in one sentence: a strategy doc nobody disagrees with is not a strategy — it must make a choice someone reasonable would contest.

Coherent action is what separates strategy from vision statements. Actions must be concrete (a named migration, a deprecation date, a hiring change, a rule with an enforcement mechanism) and they must be coherent — reinforcing each other rather than pulling in different directions.¹ Funding a platform team while also letting every product team keep its bespoke deploy pipeline is two actions that cancel out. If your action list reads like a backlog of unrelated good ideas, you have a to-do list, not a strategy.

The four tells of bad strategy

Rumelt names four hallmarks, and once you know them you'll see them in every slide deck: fluff (buzzwords restating the obvious — "our strategy is customer-centric excellence"), failure to face the challenge (no diagnosis, so no way to judge anything), mistaking goals for strategy ("reach 99.99% availability" is an ambition, not an approach), and bad objectives — action lists that are impracticable, or a grab-bag of unrelated wishes.¹ The printable strategy-kernel one-pager puts these tells next to the kernel tests — keep it beside you whenever you read or write a strategy doc.

Larson: good strategy is boring — and bottom-up

Will Larson — whose Crafting Engineering Strategy is the dedicated book-length treatment⁴ — adds the correction most engineers need: strategy is not visionary prose. "Good strategy is boring," specific, and often feels too obvious to bother writing down.³ And you don't write it top-down from a blank page. His method: write five design docs, then look for the repeated dilemmas and controversial decisions across them — synthesize those into a strategy. Write five strategies, then look at how their trade-offs interact over two to three years — synthesize those into a vision.³ Strategy is compressed experience from real decisions, not inspiration. This also means you, a Principal-track IC without executive authority, can start today: the raw material is design docs, and you already write those.

🧪 Lab: a one-page strategy memo for your actual area

This artifact is a centerpiece of your evidence trail — a real technical strategy for your actual team or area, one page, using the kernel headings verbatim. Open a doc titled "Technical Strategy: <your area>" with exactly three headings — Diagnosis / Guiding Policy / Coherent Action — and write:

1. Diagnosis (3–5 sentences): what is actually going on in your area? At least one sentence must be uncomfortable and evidenced — a number, an incident, a trend you can point to. If every sentence would survive a leadership review unchallenged, dig deeper.
2. Guiding Policy (2–3 sentences): the approach that addresses the diagnosis. It must explicitly name one thing your team will stop doing or will not do — an exclusion a reasonable colleague would push back on.
3. Coherent Action (3–5 bullets): concrete moves — each with an owner-shaped verb and ideally a date — that carry out the policy and reinforce each other. Check every bullet traces back to a sentence in the diagnosis; cut any that don't.
4. The skeptic pass: reread as your most contrarian peer. Mark the sentence they'd dispute. If you can't find one, the policy is fluff — sharpen the exclusion and repeat.

Feedback loop: bring the memo back to me in chat. I'll review it against a Principal-level rubric — would a skeptical peer genuinely dispute the guiding policy (if not, it's fluff), does every action trace to the diagnosis, and is it truly one page. This memo is prime promotion-packet material — Lesson 12 slots it in directly — and "walk me through a technical strategy you wrote" is a standard Principal interview question you'll now answer with a real document.

Check yourself — spot the bad strategy

Three scenarios. Apply the kernel and the four tells — don't scroll up. Wrong picks stay live.