Crafting Engineering Strategy How Thoughtful Decisions Solve Complex Problems (Will Larson) (z-library.sk, 1lib.sk, z-lib.sk)

📄 File Format: PDF

💾 File Size: 7.4 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

Crafting Engineering Strategy HOW THOUGHTFUL DECISIONS SOLVE COMPLEX PROBLEMS WILL LARSON

📄 Page 2

v Many engineers assume their organization doesn’t have an engineering strategy—when in fact, they often do. It just may not be working. In Crafting Engineering Strategy, Will Larson (author of An Elegant Puzzle, Staff Engineer, and The Engineering Executive’s Primer) offers a practical, example-rich guide to navigating technical and organizational complexity through structured, intentional strategy. Written for senior engineers, engineering leaders, architects, and curious collaborators, this book lays out a repeatable process for building effective, actionable strategies—from early diagnosis to rollout. With lessons drawn from real-world case studies at companies like Stripe, Uber, and Calm, Larson provides a framework for shaping critical decisions around system migrations, API deprecations, platform investments, and more. Along the way, you’ll learn to augment technical planning with communication, governance, and systems thinking. Whether you’re shaping your team’s direction or leading a company-wide initiative, Crafting Engineering Strategy will help you make thoughtful decisions that stick. • Build durable engineering strategies from first principles • Apply methods like Wardley mapping and systems modeling • Lead strategy as a staff+ engineer or executive • Learn from detailed case studies across industries • Improve your strategic fluency and influence over time Will Larson serves as chief technology officer at Imprint and has previously held senior engineering leadership roles at Stripe, Carta, Calm, and Uber. He’s the author of four books and regularly writes on his blog, Irrational Exuberance. TECHNOLOGY STR ATEGY Crafting Engineering Strategy HOW THOUGHTFUL DECISIONS SOLVE COMPLEX PROBLEMS ISBN: 979-8-341-64552-3 US $39.99 CAN $49.99

📄 Page 3

Crafting Engineering Strategy How Thoughtful Decisions Solve Complex Problems Will Larson

📄 Page 4

979-8-341-64552-3 [LSI] Crafting Engineering Strategy by Will Larson Copyright © 2026 Will Larson. All rights reserved. Published by O’Reilly Media, Inc., 141 Stony Circle, Suite 195, Santa Rosa, CA 95401. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://oreilly.com). For more information, contact our corporate/institutional sales department: 800-998-9938 or corporate@oreilly.com. Acquisition Editor: David Michelson Development Editor: Sarah Grey Production Editor: Kristen Brown Copyeditor: Piper Content Partners Proofreader: Krsta Technology Solutions Indexer: Ellen Troutman-Zaig Cover Designer: Susan Thompson Cover Illustrator: Susan Thompson Interior Designer: Monica Kamsvaag Interior Illustrator: Kate Dullea October 2025: First Edition Revision History for the First Edition 2025-10-14: First Release See http://oreilly.com/catalog/errata.csp?isbn=9798341645523 for release details. The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Crafting Engineering Strategy, the cover image, and related trade dress are trademarks of O’Reilly Media, Inc. The views expressed in this work are those of the author and do not represent the publisher’s views. While the publisher and the author have used good faith efforts to ensure that the information and instructions contained in this work are accurate, the publisher and the author disclaim all responsibility for errors or omissions, including without limitation responsibility for damages resulting from the use of or reliance on this work. Use of the information and instructions contained in this work is at your own risk. If any code samples or other technology this work contains or describes is subject to open source licenses or the intellectual property rights of others, it is your responsibility to ensure that your use thereof complies with such licenses and/or rights.

📄 Page 5

Contents | Preface v PART I | Introducing Engineering Strategy 1 | Introduction 3 2 | Is Engineering Strategy Useful? 7 3 | Who Gets to Do Strategy? 17 4 | When Should You Write Strategy–and How Much? 23 PART II | Steps for Building Engineering Strategies 5 | Steps to Build an Engineering Strategy 33 6 | Exploring 41 7 | Diagnosis 47 8 | Refining 55 9 | Setting Policy 63 10 | Operations 77 11 | Writing Readable Engineering Strategies 91 12 | Bridging Theory and Practice 97 iii

📄 Page 6

PART III | Refinement Tools 13 | Strategy Testing for Iterative Refinement 105 14 | Systems Modeling 113 15 | Wardley Maps 123 PART IV | Case Studies 16 | Service Migration Strategy 137 17 | LLM Adoption Strategy 161 18 | Private Equity Ownership Strategy 199 19 | Customer Data Access Strategy 217 20 | Service Architecture Strategy 225 21 | Product Engineering Strategy 231 22 | Developer, API, and Acquisition Strategy at Stripe 241 PART V | Going Forward 23 | Is This Strategy Any Good? 263 24 | How to Get Better at Strategy 271 25 | Strategy Resources 279 | Index 283 iv | CONTENTS

📄 Page 7

Preface In 2015, the Mini Sky City skyscraper, with 57 floors, was built in Changsha, China, in 19 days. Driving my son to school over the past few years, I’ve watched a nine-story building in San Francisco get built over three years. There’s some argument that Mini Sky City’s record isn’t legitimate because it relied heavily on modular, prebuilt architecture, but I can assure you that the three-years-and- counting building in San Francisco is similarly being built from modular compo- nents. Why did one of these projects build three floors per day, and the other three floors per year? How Big Things Get Done by Bent Flyvbjerg and Dan Gardner (Crown Cur- rency, 2023) explores how strategy impacts the successful creation of complex buildings. The authors’ foundational observation is that you go fast by making most of your mistakes where it’s cheapest—for example, in simulation—and fewer where it’s difficult to fix—for example, after you’ve built most of a physical building. In my experience, their observation applies equally well to software engineering strategy. However, the problem in software engineering goes further. You’ll never meet an architect who hasn’t seen a building plan, but the majority of software engineers and even software executives will tell you that they’ve never seen a clear, written engineering strategy. There’s a widespread belief that engineering strategy doesn’t exist—but if you ask the right questions, you’ll find that almost every engineer has a strong instinctive understanding of their current company’s engineering strategy. Even if that strategy isn’t particularly good, they’ll know what it is. I want this book to reshape the conversation around software engineering strategy in two ways. First, I hope to establish a sufficiently clear, shared defi- nition of engineering strategy so that we agree on what we’re talking about. With that definition, we can discuss how to improve our strategies, rather than v

📄 Page 8

debating whether they exist. My second goal is to make it easier for all of us to write down our companies’ engineering strategies. If this book is particularly successful, a few years from now the ideas in this book will be obsolete through their own ubiquity. They’ll be so obvious that they’re not worth discussing—and that would be a triumph. Strategy is often viewed as the domain of Staff-plus engineers and execu- tives. I hope those folks think a lot about strategy, but I believe that everyone in an engineering organization can apply strategy. If you work within or even adjacent to an engineering organization, then this book wants to help you understand and improve on your company’s engineering strategy. Certainly, different roles require different approaches, but you can contribute to improvement. Finally, I believe a bit of rigor in our thinking can change our lives, our colleagues’ lives, and the lives of the people who use the software that we create. Engineering organizations today routinely waste dozens or hundreds of years of their teams’ lives by refusing to engage with the reality of their problems. Far from an abstract and aspirational endeavor, strategy invests our scarce time wisely—and that’s the bare minimum we owe ourselves, our colleagues, and our users. What This Book Is Not This book is intended to be widely accessible, particularly for anyone working in or adjacent to software engineering. However, it certainly won’t be everything to everyone, and I want to acknowledge some of its limitations. First, the examples in this book are rooted in my personal experiences. I’ve done many things in my career, like starting a small iOS gaming startup in 2008, growing Calm’s engineering organization, and contributing to Stripe’s and Uber’s periods of rapid growth. However, my experience has its gaps: I worked at Yahoo! when it was quite large, with a massive codebase, but I was there in a junior role, so I have an incomplete view of working at a company of that size. I’ve also never worked in government. Indeed, the list of things I haven’t done is endless. Second, this book is an opinionated introduction to engineering strategy, and it’s intended to serve as your first introduction to that hopelessly broad topic. If you’re looking for a more general book on strategy, particularly if you don’t work in a software engineering–adjacent field, I’d probably suggest you instead start with Richard Rumelt’s Good Strategy, Bad Strategy (Crown Currency, 2011). vi | PREFACE

📄 Page 9

Finally, this book touches on software architecture a number of times, as it’s a common topic within engineering strategies. However, it is not a book about software architecture. Where one strategy focuses on software architecture, the next might focus just as heavily on managerial mechanisms, like approving headcount backfills. For a book on architecture, I might suggest Fundamentals of Software Architecture: A Modern Engineering Approach by Mark Richards and Neal Ford, now in its second edition (O’Reilly, 2025). Navigating This Book The default way to read this book is to start at the beginning and read through to the end. If you do that, you’ll work through the book’s five parts in order: • Part I, “Introducing Engineering Strategy”, introduces this book’s overall thesis. • Part II, “Steps for Building Engineering Strategies”, breaks down the steps to craft, implement, and operate an engineering strategy into step-by-step instructions. • Part III, “Refinement Tools”, goes into further detail about refining strat- egy, which I believe is the most valuable and most neglected element of engineering strategy. • Part IV, “Case Studies”, provides 10 concrete engineering strategies, all of which are based on concrete work I’ve done in my career (although some are lightly anonymized). • Part V, “Going Forward”, wraps up the book with advice for evaluating strategies and improving your own strategy work. If you want a more focused dive into the topic, I’d encourage you to start by reading the case studies, and then selectively read the chapters to understand any parts of the case studies that you find interesting or surprising. Reading this way will leave you without some of the relevant definitions, but it should still be a coherent read, and there’s always the index to find anything you want to look up. PREFACE | vii

📄 Page 10

Using Code Examples Supplemental material (code examples, exercises, etc.) is available for download at https://craftingengstrategy.com. If you have a technical question or a problem using the code examples, please send email to support@oreilly.com. This book is here to help you get your job done. In general, if example code is offered with this book, you may use it in your programs and documenta- tion. You do not need to contact us for permission unless you’re reproducing a significant portion of the code. For example, writing a program that uses several chunks of code from this book does not require permission. Selling or distributing examples from O’Reilly books does require permission. Answering a question by citing this book and quoting example code does not require permis- sion. Incorporating a significant amount of example code from this book into your product’s documentation does require permission. We appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN. For example: “Crafting Engineering Strategy by Will Larson (O’Reilly). Copyright 2026 Will Larson, 979-8-341-64552-3.” If you feel your use of code examples falls outside fair use or the permission given above, feel free to contact us at permissions@oreilly.com. O’Reilly Online Learning For more than 40 years, O’Reilly Media has provided tech- nology and business training, knowledge, and insight to help companies succeed. Our unique network of experts and innovators share their knowledge and expertise through books, articles, and our online learning platform. O’Reilly’s online learning platform gives you on-demand access to live training courses, in-depth learning paths, interactive coding environments, and a vast collection of text and video from O’Reilly and 200+ other publishers. For more information, visit https://oreilly.com. viii | PREFACE

📄 Page 11

How to Contact Us Please address comments and questions concerning this book to the publisher: O’Reilly Media, Inc. 141 Stony Circle, Suite 195 Santa Rosa, CA 95401 800-889-8969 (in the United States or Canada) 707-827-7019 (international or local) 707-829-0104 (fax) support@oreilly.com https://oreilly.com/about/contact.html We have a web page for this book, where we list errata and any additional information. You can access this page at https://oreil.ly/craftingEngStrategy. For news and information about our books and courses, visit https:// oreilly.com. Find us on LinkedIn: https://linkedin.com/company/oreilly-media. Watch us on YouTube: https://youtube.com/oreillymedia. Acknowledgments Each book is the culmination of the prior writing I have done, the people I have had the chance to collaborate with, and the work itself that has educated me despite my best efforts. Thank you to each person who has helped me with this book itself, and with the work it stands on. I owe a particular deep debt to Sarah, Adi, Bobby, and David for their help in refining this book. Above all else, I owe endless thanks to my wife, Laurel, and my son, Emer- son. Thank you both for being part of this book’s journey, and the much larger journey where this book is only a very small chapter. PREFACE | ix

📄 Page 12

(This page has no text content)

📄 Page 13

Introducing Engineering Strategy Strategy is a very broad topic, and the first part of this book surveys that breadth while landing the foundation to dive into the details in the four following parts. It will establish the core definitions that we’ll take through this book, and connect this book’s ideas to the tradition they originated in. It will also address the three most frequent concerns I hear from would-be strategy practitioners. First, is engineering strategy actually useful? (Yes.) Who gets to do it? (You do.) How much strategy is actually useful? (It depends on the altitude you’re writing at.) PART | I

📄 Page 14

(This page has no text content)

📄 Page 15

Introduction I’ve worked alongside many talented people who spent years waiting for a chance to finally “do strategy.” My hope is that this book convinces you—and maybe them—that waiting is optional. Strategy isn’t reserved for executives. It’s the practice of making thoughtful decisions, and it’s accessible to everyone—includ- ing you. Even if you’d prefer to avoid strategy, it’s still happening all around you. My first big dose of strategy came when I was managing the team responsible for Uber’s service migration (Document 16-1) while we desperately tried to survive an accelerating avalanche of inbound support requests. Since then, I’ve seen strategy everywhere I worked, from Stripe’s acquisition of Index (Document 22-4) to Calm’s focus on being a product engineering company (Document 21-1). There are even some strategy problems that I’ve encountered again and again at every company I’ve joined, such as deciding how to decompose monolithic codebases (Document 20-1). This book is focused on engineering strategy—in other words, making thoughtful decisions about engineering. Engineering is defined both as the dis- cipline of writing software, and also as the concerns of the Engineering depart- ment or organization within your company. If this seems like a hopelessly broad topic, then we agree on the scope of my definition. However, I would never agree that it’s hopeless. My decision making has significantly improved over the course of my career. I believe very strongly that my improvement had very little to do with my intrin- sic ability and a lot to do with my learning to engage in structured thinking. I also believe the lessons that I learned slowly are eminently teachable in the next few hundred pages. 3 | 1

📄 Page 16

Grounded in My Direct Experience Strategy is a broad topic, and many strategy books become awkwardly abstract. To avoid falling into that trap, I’ve anchored this book in my personal experien- ces doing strategy and the strategy work of colleagues that I had the opportunity to witness directly. As much as possible, I’ve used examples that I worked on in real companies, which I mention by name. That’s true for more than half the strategies included in this book, which describe strategies I collaborated on during my time at Stripe, Uber, and Calm. For the other half of the strategies, I have abstracted away from naming specific companies because they cover sensitive topics, such as how to work with private equity ownership (Document 18-1), or expose internal information better kept private, as in how to manage access to customer data (Document 19-1). In both sorts of examples, I’ve worked hard to remain honest, even when I’ve had to omit some details, out of respect for the companies and individuals involved. You’ll also notice that I try to be positive about all of these strategies. If I seem too positive at times, it’s because all strategies age. Even the best eventually turn sour. It’s most interesting to understand strategies in the context they were originally conceived. Of course, evaluation matters too, which I’ll cover in Chapter 23. Adapting Rumelt for Engineering In addition to my own experience, the second-largest influence on this book is Richard Rumelt’s Good Strategy, Bad Strategy. It’s a quick read, and it was a life- changing discovery for me. Rumelt describes three pillars of effective strategy, which I’ll paraphrase here: Diagnosis A theory describing the nature of the challenge. This involves identifying the root cause(s) at play: for example, “high work-in-progress is preventing us from finishing any tasks, so we are increasingly behind each sprint” might be a good diagnosis. Guiding policy A series of general policies which will be applied to grapple with the challenge. Guiding policies are typically implicit or explicit tradeoffs. For example, a guiding policy might be “only hire for the most urgent team; do not spread hires across all teams.” If a guiding policy doesn’t imply a 4 | CRAFTING ENGINEERING STRATEGY

📄 Page 17

tradeoff, you should be suspicious of it. “Working harder to get it done” isn’t really a guiding policy, for instance; the relevant guiding policy there might be “work folks hard and expect high attrition.” Coherent actions A set of specific actions to address the challenge, directed by guiding policy. This is the most important part, and I think the most exciting, because it clarifies that a strategy is only meaningful if it leads to aligned action. The first time I read this definition was eye-opening: it answered so many strategy questions I’d had for such a long time. However, although I was grate- ful to Rumelt for giving me my first framework for thinking about strategy, I continued noticing how little deliberate strategy existed in the engineering organizations I’d joined. Eventually, I recognized that if applying Rumelt’s work to engineering was trivial, we’d see a lot more disciplined engineering strategy in practice. We’d also, one hopes, see fewer obviously flawed engineering strategies. This book is the culmination of a decade spent understanding how to adapt Rumelt’s approach to something that not only could work, but concretely has worked in the organiza- tions that I’ve joined. Iterative, Intellectual, and Mechanical In addition to being anchored in my personal experience and building on Rumelt’s approach, this book takes an iterative approach and embraces both the intellectual and the mechanical aspects of strategy. Even my proudest strategy work eventually becomes obsolete. For some time, I was embarrassed by this realization. Eventually, I came to recognize that entropy is natural in strategy work; good strategy embraces change rather than fighting it. This solidified for me into the concept of strategy refinement (Chapter 8), where ideas are deliberately validated and improved rather than being treated as immutable. If you’ve ever participated in executive hiring, you’ve probably interviewed someone who described strategic thinking as a personal strength. Those candi- dates often draw a distinction between directing how work should be done and being in the weeds of doing the work itself. It happens enough that you start to appreciate that many people view strategy as a fundamentally intellectual endeavor about how things ought to work, rather than a mechanical endeavor that studies how things actually do work in practice. INTRODUCTION | 5

📄 Page 18

While strategy does indeed have intellectual elements, effective strategy is at least as dependent on the mechanical nuances of reality as it is on intellectual frameworks. Even the best policies will fail without attention to whether the team is actually adopting the policy’s guidance. Similarly, very effective operational mechanisms to roll out a strategy won’t help your company if the policy being rolled out is a bad one (see Chapter 10). As obvious as these ideas seem, many organizations expect their strategies to manifest perfectly into existence from the very beginning. This book discusses how to bridge the gap between that pressing expectation of perfection and the reality that effective strategy development is grounded in iterative work that is both intellectual and mechanical. This Book’s Ambition As I’ve worked on this book, one of my lingering concerns is that the ideas in it are perhaps too obvious to write down. But each time I’ve been tempted to set the project aside, I see a new example, or am reminded of an old experience, where some of the smartest people I’ve ever known have struggled unsuccessfully with a strategy problem that others would describe as quite simple. The belief that strategy is complex often gets people in trouble. It’s appealing to believe that strategies fail due to intricate errors in decision making or the unanticipated moves of an adversary. Maybe that is common when it comes to grand strategy. However, my experience is that engineering strategies fail for very mundane reasons—the most common of which is that executives assume their strategy will roll itself out. The second most common reason is forgetting to spend time validating the details. Both are avoidable with a bit of structure. This book’s framework is not an attempt to discredit all other approaches. Rather, it’s a synthesis of the various approaches I’ve encountered, along with a few dimensions that I’ve not seen addressed in much detail elsewhere. Even if you don’t agree with my framework, I hope it helps you refine your own framework. Either way, our industry will be much better for it. 6 | CRAFTING ENGINEERING STRATEGY

📄 Page 19

Is Engineering Strategy Useful? While I frequently hear engineers bemoan a missing strategy, their complaints rarely articulate why the missing strategy matters. Instead, it serves as more of a truism: the economy used to be better, children used to respect their parents, and engineering organizations used to have an engineering strategy. This chapter starts by exploring something I believe quite strongly: there’s always an engineering strategy, even if there’s nothing written down. From there, we’ll discuss why strategy, especially written strategy, is such a valuable opportu- nity for organizations that take it seriously. We’ll dig into: • Why there’s always a strategy, even when people say there isn’t • How strategies have changed companies I’ve encountered • How inappropriate strategies create significant organizational pain without much compensating benefit • How written strategy drives organizational learning • The costs of not writing strategy down • How strategy supports personal learning and development, even when you’re not empowered to “do strategy” yourself By this chapter’s end, I hope you will agree with me that strategy is an undertaking worth investing your time—and your organization’s. 7 | 2

📄 Page 20

There’s Always a Strategy Every company I’ve worked in has had at least one engineer who felt the com- pany didn’t have an engineering strategy. Once I became an executive and could document and distribute an engineering strategy myself, complaints about miss- ing strategy didn’t go away; they just shifted to focus on a missing product or company strategy. This even happened at companies that definitively had engineering strate- gies, like the payment provider Stripe. When I joined in 2016, it had a clear engineering strategy with numerous guiding policies, including: • Maintain backwards API compatibility, at almost any cost. (For example, force an upgrade from TLS 1.2 to TLS 1.3 to retain PCI compliance, but don’t force upgrades from the /v1/charges endpoint to the /v1/pay ment_intents endpoint.) • Work in Ruby within a monorepo, unless it’s the PCI environment, data processing, or data science work. • Engineers are fully responsible for the usability of their work, even when product or engineering managers are involved. I found it to be generally clear what the company’s engineering strategy was on any given topic—even if finding it sometimes required asking around. Over time, certain decisions became sufficiently contentious that it became hard to definitively answer what the strategy was. For example, the question of whether to adopt Ruby or Java became contentious enough that I distributed a strategy document attempting to mediate the disagreement. It wasn’t a particularly suc- cessful effort, for reasons that are obvious in hindsight—particularly the lack of any enforcement mechanism. William Gibson has said, “The future is already here—it’s just not very evenly distributed.” In the same sense, there is always a strategy embedded into an organization’s decisions—even if that strategy is only visible to a small group and is quickly forgotten. I’ve simply never found an organization with no engineering strategy at all. If you ever find yourself thinking that your organization doesn’t have one, I’d encourage you to seek out where the strategy might live in practice, even if it isn’t codified in documentation. Whatever you find practitioners doing is their strategy. Repeated decisions are always made according to some rule or set of rules, even if the only rule is a powerful disregard for prior decisions. 8 | CRAFTING ENGINEERING STRATEGY