Book Review: Crafting Engineering Strategy by Will Larson

Ask a room full of engineers whether their company has an engineering strategy and you’ll almost always get the same weary answer: no, not really. It’s one of those complaints that has become a kind of folk wisdom. The economy used to be better, children used to respect their parents, and engineering organisations used to have a strategy.

Will Larson’s new book, Crafting Engineering Strategy: How Thoughtful Decisions Solve Complex Problems, sets out to dismantle that complaint. Larson is the author of An Elegant Puzzle, Staff Engineer and The Engineering Executive’s Primer, and here he turns his attention to the one topic engineers most love to grumble about and least understand how to influence. His central claim is refreshingly unglamorous. Strategy, he writes, is “the art of reproducibly making good decisions.” Not visionary pronouncements from on high, not a glossy deck presented at the all-hands, but the boring, repeatable practice of deciding well and writing it down.

I found this to be one of the most immediately useful engineering books I’ve read in years, precisely because it strips away the mystique. This post walks through the ideas that stuck with me, and then looks at how the book can be applied by different roles across an engineering organisation, because one of Larson’s most encouraging arguments is that strategy is not the exclusive property of executives.

There is always a strategy

The book opens by refusing to accept the premise that a strategy is missing. Larson has “never worked somewhere where people didn’t claim there was no strategy,” and yet he’s also never found a company that genuinely lacked one. His point is that a strategy is embedded in the decisions an organisation actually makes, whether or not anyone has bothered to write it down. Borrowing William Gibson’s famous line about the future being unevenly distributed, he suggests the strategy is already there; it’s just visible only to a small group, and often quickly forgotten.

This reframing matters because it changes the question. Instead of asking “why don’t we have a strategy?”, Larson wants you to ask where the strategy lives if you can’t find it. When you go looking, you’ll usually discover an implicit set of rules that nobody has examined and nobody can therefore improve. His prescription is disarmingly simple, and it’s the thread running through the entire book:

The single biggest act you can take to further strategy in your organization is to write down strategy so it can be debated, agreed upon, and explicitly evolved.

Writing it down is what makes it possible to precisely disagree. He describes his time at Carta, where a written strategy meant new joiners could argue with decisions “from an informed place rather than coming across as attached to their prior company’s practices.” Oral history gives you a version of events that depends entirely on who you happened to ask. Written history lets an organisation agree at scale, which he argues is the prerequisite for growing at scale rather than trapping all the context inside a handful of senior heads.

The five steps

The backbone of the book is a repeatable, five-step structure for producing a strategy: explore, diagnose, refine, set policy, and operate. Larson is candid that this isn’t a magic formula, and that “strategies fail more often due to avoidable errors than from fundamentally unsound thinking. Busy people skip steps. Especially steps they dislike or have failed at before.” The structure exists to stop you skipping the awkward parts.

Exploration comes first, and it’s deliberately judgement-free. Before committing to an approach, you look at how other teams and companies have handled the same problem. His example is Uber’s 2014 service migration, where the team grounded themselves by reading the Google Borg and Berkeley Mesos papers before deciding anything. The discipline here is resisting the urge to reach for whatever worked at your last job.

Diagnosis is where the book earns its keep, and Larson calls it strategy’s foundation. This is the deliberate act of understanding your problem before reaching for a solution. He is blunt about the stakes:

Every strategy that I’ve seen fail, did so due to a lazy or inaccurate diagnoses. It’s very challenging to fail with a proper diagnosis, and almost impossible to succeed without one.

A good diagnosis, he argues, isn’t a statement of opinion you can easily dispute; it’s “a web of interconnected observations, facts, and data” that is hard to argue against even for people who dislike the conclusions. Two ideas from this chapter are especially worth highlighting. The first is that you should actively seek out the people most likely to disagree with you and represent their view faithfully, without letting your own bias show through. The second is his instruction to reframe blockers as part of the diagnosis rather than as reasons to give up. If your executives keep changing their minds, that isn’t proof that strategy is impossible; it’s a condition your strategy has to account for. As he puts it, “there are never reasons why strategy simply cannot succeed, only diagnoses you’ve failed to recognize.”

He’s also honest about organisational politics. Sometimes the true diagnosis is that a particular leader is the problem, and you cannot write that down. His advice is to “whisper the controversial parts”, finding a professional, factual framing. His example from a private equity transition simply notes that new ownership “will expect us to reduce R&D headcount costs” without editorialising about how anyone feels about it.

Refinement is the step most people skip. This is where you pressure test a raw diagnosis using one of three techniques: strategy testing, systems modelling, and Wardley mapping. Strategy testing is his antidote to what he calls the waterfall strategy trap: rather than perfecting a document in a vacuum, you run your proto-strategy against reality and iterate. His deeper point is that the biggest risk isn’t modelling too early or mapping too late, it’s doing neither, so he keeps the barrier to entry low.

Policy is where decisions finally get made. “Policy is interpreting your diagnosis into a concrete plan,” and he divides policies into four recurring kinds: approvals, allocations, direction, and guidance. Direction is unambiguous instruction, as in Calm’s blunt “all new code must be written in the monolith”, which removed a debate that individual judgement kept reopening. Guidance is for when you know the destination but can’t mandate the route. Allocations are the most concrete statement of priority an organisation makes; Uber’s decision to fix “one full time engineer on manual service provisioning tasks” and pour everyone else into automation is a policy that says more about priorities than any mission statement could. He offers two criteria for judging a policy: it must be applicable to real, messy situations, and it must be enforced. A policy such as “we only hire world-class engineers” fails both, because nobody can define or consistently apply it.

Operations is the step that separates strategies that change behaviour from strategies that “fade quietly into your organization’s history.” Policies don’t implement themselves. Larson’s memorable framing is that “effectively operating a policy is two thirds avoiding common practices that simply don’t work” such as top-down pronouncements, one-off training, and the vague hope that you’ll “just change the culture.” The remaining third is choosing concrete mechanisms: approval forums, inspection, automation, and above all nudges. He’s a strong advocate for the humble nudge, recalling how Stripe told teams when their cloud spend accelerated rather than forbidding all new spend outright, and concluding that “done well, I continue to believe they are the most effective operational mechanism.”

Putting it together: a worked example

Laid out one after another, the five steps can still feel abstract, so it’s worth walking a single problem all the way through them. The book leans on real case studies from Uber, Stripe and Calm to do this; what follows is my own illustrative scenario rather than one of Larson’s, but it’s the kind of situation many scale-ups will recognise.

Imagine a company that has grown from thirty engineers to a hundred and fifty in two years. New services are appearing faster than anyone can count, on-call rotas are miserable, and the small platform team is drowning in provisioning requests. Everyone agrees “something should be done”, but every attempt to fix it dissolves into an argument about microservices versus monoliths.

Exploration comes first, and it stays deliberately opinion-free. You read how comparable companies handled service sprawl, you dig out the internal design docs behind the three services that caused the most pain last year, and you note which patterns keep recurring. You resist the urge to announce a conclusion. The goal is simply to understand the shape of the problem space before committing to anything.

Diagnosis turns that reading into an honest, evidence-backed picture of your specific situation. Perhaps the data shows that the platform team of four hasn’t grown despite the engineering organisation tripling, that ninety per cent of new services were created to dodge a slow provisioning queue rather than for any architectural reason, and that most services have fewer than two committers. Following Larson’s advice, you deliberately sit down with the staff engineer who is convinced microservices are the future, and you capture their view faithfully. You also reframe the obvious blocker, “the platform team is understaffed and that won’t change this year”, not as a reason to give up but as a constraint the strategy must be built around. That single move, treating the immovable object as part of the diagnosis, is what stops the whole effort stalling.

Refinement pressure tests that picture before you commit. A quick systems model might reveal that adding services actually slows the organisation down once the platform team saturates, which is a far more persuasive argument than any assertion. Rather than perfecting a grand document, you run a small strategy test: for one month, route all new service requests through a lightweight review and see what actually happens. You learn cheaply, and you gather real evidence instead of speculation.

Policy is where the decisions finally land, and the diagnosis makes them feel almost inevitable. You might set a piece of direction (“new functionality is built in the existing service that owns that domain unless an exception is granted”), an allocation that fixes one platform engineer on manual provisioning while the rest build self-service tooling, and some guidance encouraging teams to fold thinly-staffed services back into their owning domain where it makes sense. Each policy maps to a specific line of the diagnosis, and each one is both applicable and enforceable, which is Larson’s bar for a policy worth having.

Operations is what makes any of that real. Instead of a launch email and a hopeful shrug, you add a nudge that pings a team the moment they try to create a new service, pointing them at the guidance and the exception process. You stand up a fortnightly inspection of new services and provisioning lead times on a shared dashboard that “cannot silently fail”, and you route exception requests through a single lightweight approval channel. None of this depends on a heroic mandate; it depends on mechanisms that keep working after the initial announcement has been forgotten.

Run end to end, the example shows why Larson insists the awkward early steps matter most. By the time you reach policy, the hard thinking is done and the decisions write themselves. Skip exploration and diagnosis, and you’d have jumped straight to “stop making so many microservices”, a decree that sounds decisive and changes nothing.

How different roles can apply the book

The reason I’d recommend this book widely is that it explicitly rejects the idea that you need a title before you’re allowed to think strategically. “You can work on strategy from anywhere in an organization,” Larson writes. “It just requires different tactics to do so.” Here’s how that plays out across the roles you’ll find in most engineering organisations.

Engineers

If you’re an individual contributor without formal authority, the book’s most valuable gift is a pair of low authority techniques. The first, borrowed from Staff Engineer, is “take five, then synthesize”: document how five recent, related decisions were actually made, then synthesise them into a diagnosis and policy. You’re not inventing a strategy so much as naming the one that already exists, which makes it very hard for anyone to argue you’re overstepping. The second, from An Elegant Puzzle, is “model, document, and share”: adopt the approach yourself, write down your reasoning, and let people copy your success. Neither requires anyone’s permission. For an engineer who has ever felt powerless watching a bad decision unfold on a team they don’t own, this is a practical route to influence.

Staff and principal engineers

Senior individual contributors sit at exactly the altitude the book is aimed at. Larson introduces the concept of strategy altitude, being deliberate about the level at which a policy should be set, and Staff-plus engineers are often the people who can see when a decision is being made at the wrong one. They’re also central to his idea of informational herd immunity. You don’t need every engineer to have read the strategy; you just need “enough people who know something that confusion doesn’t propagate too far.” In practice, that means every Staff-plus engineer and manager understanding the strategy well enough to keep their team on track. The refinement toolkit, particularly systems modelling and Wardley mapping, is squarely in this group’s wheelhouse and gives them a rigorous way to challenge or support a proposed direction with evidence rather than opinion.

Engineering managers

Managers are the connective tissue that keeps a written strategy alive, and the book’s chapter on operations reads almost like a manual for them. Larson is scathing about the mechanisms managers most often reach for by default, warning that “a couple of trainings will never change organizational behavior.” The more effective path is the unglamorous one: inspection mechanisms that “cannot silently fail”, nudges that bring context to people at the moment they need it, and a genuine curiosity about why some teams aren’t adopting a change rather than assuming they’re being difficult. His observation that people usually “want to do things the new way, but rarely take time to learn how to do it” is a healthier default assumption than most performance conversations start from.

Engineering executives

Executives get the book’s most bracing warning. Yes, they can mandate adherence in a way engineers can’t, but “mandates only matter if there are consequences”, and an executive unwilling to enforce them is issuing empty instructions. More pointedly, Larson notes that access and mandates “often create the appearance of progress” without improving the underlying diagnosis, which is “why executive strategies can fail so spectacularly and endure so long despite failure.” His conclusion is one every senior leader should sit with: executives “have an easier time doing strategy, but a much harder time learning how to do strategy well.” That’s the argument for practising the craft long before you reach the top, because “waiting to do strategy until you are an executive is a recipe for disaster.”

Product managers and other partners

Even outside engineering, the book insists you can contribute, though it will demand an even more influence driven approach. The examples where engineers themselves are on uncertain ground, such as the early adoption of large language models, are exactly the moments when an outside perspective is most valuable. The through-line is the same for everyone: diagnose honestly, write it down, and let the artefact do the persuading over time.

The good, and the caveats

What I appreciated most is how grounded the book is in real, named examples. The case studies aren’t sanitised. Larson revisits Digg’s catastrophic V4 rewrite, which he calls “the worst considered strategy I’ve personally participated in” and which “ensured we died fast rather than having an opportunity to dig our way out.” He’s careful, though, to relabel such strategies “inappropriate” rather than “bad”, because “the same strategy might well be very effective in a different set of circumstances.” That intellectual honesty runs throughout, and it’s a welcome corrective to the confident, context-free advice that dominates so much engineering leadership writing.

The book is not a light read. The five step scaffolding, the refinement techniques and the taxonomy of policies reward careful study rather than a quick skim, and readers hoping for a checklist to copy will be gently disappointed. That’s by design; Larson repeatedly reminds you that “the structure is not sacrosanct, it’s the thinking behind the sections that really matter.” The chapters on systems modelling and Wardley mapping in particular are enough to get you started but will send the curious off to other sources. And if you’ve read his earlier work, you’ll recognise a fair amount of the philosophy, albeit sharpened and far better organised here.

Crafting Engineering Strategy delivers on its subtitle by treating strategy as a learnable, teachable craft rather than an innate gift, and it does so with enough concrete examples that you can start applying it the same day. If you’ve ever complained that your organisation lacks a strategy, Larson’s response is both a challenge and an invitation: it’s already there, so go and write it down. As he reminds us, strategy is useful, and doing strategy can be simple, too.

You can find the book on Amazon or via O’Reilly, and much of the material is available to read on Larson’s companion site.