Crafting Engineering Strategy — Will Larson (#Books)
I write about Will Larson's books regularly, and there is now a whole series of posts: “Staff Engineer” is about influence without a management title, “An Elegant Puzzle” treats the engineering organization as a system, and “The Engineering Executive's Primer” covers the work of a technology executive. The fourth book, Crafting Engineering Strategy, connects these levels through one question: how do you make difficult decisions and carry them through an organization? A Russian translation will be released soon; the English original appeared back in October 2025 (and I had already read many chapters as standalone posts on the author's blog).
The book itself covers engineering-organization strategy—from architecture and migrations to hiring, costs, and LLM adoption. The topic remains important even now, when many people are reluctant to declare a strategy and say they only plan for the short term. Even then, a company still has a strategy. If it is not written down, it lives in recurring decisions, verbal agreements, and long-serving employees' memories—with differing interpretations and lost context. In Larson's approach, a written strategy makes decisions visible, discussable, and improvable.
The book has five parts and 25 chapters. It starts with why strategy is needed, who can work on it, and when to document it. Then come five steps: исследование → диагностика → проработка → направляющая политика → операционные механизмы. Next are strategy testing, systems modeling, and Wardley maps; ten real cases involving migrations, LLMs, Private Equity, data, architecture, APIs, and acquisitions; and, finally, evaluating strategy and developing the skill.
What works particularly well in the book:
🔸 Diagnosis before the decision Start with data and opposing points of view, then choose a direction. Otherwise, a strategy becomes its author's favorite solution with a problem invented after the fact.
🔸 Dysfunction belongs in the diagnosis, not on a list of people to blame Larson handles this especially carefully. You cannot discard an unpleasant reality, but the document should not become an indictment. Frequent changes in leadership's position become a condition: show concrete progress quickly and retain support, or the strategy will probably fail. If people do not use a new tool, Larson suggests first looking for unnecessary friction and poor ergonomics. Your own past decisions also belong honestly in the diagnosis.
🔸 Start with a small bet that works The author recommends running one or two strategies at a time, testing a small element cheaply, and only then broadening the scope. At Uber, the team did not begin with a large program to decompose the Python monolith. It first made service deployment easier and tested that step in practice. Larson is not preaching slowness—he is accelerating learning and reducing the cost of error. It is almost a practical version of the saying “the slower you go, the farther you get,” but with feedback and metrics.
🔸 Policy must make it into practice You need an explicit choice and operating mechanisms suited to the context: exception rules, automation, metrics, or regular review, for example. Larson proposes evaluating strategy by the speed of the next iteration, its cost to the organization, and its actual impact.
The method grew primarily out of Larson's experience at Stripe, Uber, and Calm, and it will need adapting for other organizational cultures. The book is strongest for Staff+ engineers, architects, tech leads, and managers who need to drive changes across teams.
In his previous books, Larson examined the influence of Staff+ engineers, engineering-management systems, and the work of an executive. Here all three levels converge on one principle: a good direction can be tested cheaply, adjusted, and actually carried through an organization. I would call that calm approach the book's greatest strength.
#Books #Engineering #Management #Leadership #Architecture #Software