Preface (Engineering Strategy Book).

In 2015, the Mini Sky City skyscraper, with 57 floors, was built in Changsha, China, in 19 days. Driving to work 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, pre-built architecture, but I can assure you that the three-years-and-counting building in San Francisco is similarly being built from modular components. 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 explores how strategy impacts the successful creation of complex buildings, and their 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.

This book wants to reshape the conversation around software engineering strategy in two ways. First, I hope to establish a sufficiently clear, shared definition of engineering strategy so that we agree on what we’re talking about. With that definition, we can start the discussion examining how to improve our strategies, rather than debating whether they exist. My second goal is to make it easier for all of us to take up the pen 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–that would be a triumph

Strategy is often viewed as the dominion of Staff-plus engineers and executives. I hope those folks think a lot about strategy, but this book believes that strategy is applicable–and improvable–by everyone within an engineering organization. If you work within an engineering organization, 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 is the bare minimum we owe ourselves, our colleagues and our users to invest our scarce time wisely.

What This Book is Not

This book is intended to be widely accessible, particularly so for anyone working in, or adjacent, to software engineering. However, this book 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, from starting a small iOS gaming startup in 2008, to growing Calm’s engineering organization, to contributing to Stripe and Uber’s periods of rapid growth. Of course, 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, and I consequently 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 is 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 Rumelt’s Good Strategy, Bad Strategy.

Finally, this book touches on software architecture a number of times, as software architecture is a common topic within engineering strategies. However, it is not a book about software architecture. Where one strategy will focus on software architecture, the next will focus just as heavily on managerial mechanisms like approving headcount backfills. For a book on architecture, I might suggest Fundamentals of Software Architecture: An Engineering Approach by Mark Richards and Neal Ford.

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 1: Introducing engineering strategy introduces this book’s overall thesis
• Part 2: Steps for building engineering strategies breaks down step-by-step instructions for following each of the steps to craft, implement and operate an engineering strategy
• Part 3: Refine strategy: test, model & map goes into further detail on the topic of strategy refinement, which I believe is the most valuable and most neglected element of engineering strategy
• Part 4: Strategy case studies provides ten concrete engineering strategies, all of which are based on concrete work I’ve done in my career (although some are lightly anonymized)
• Part 5: Going forward wraps up the book with advice for evaluating strategy, and improving your own strategy work

If you want a more focused dive into the book, I’d encourage you to start by reading the case studies, and then selectively reading the chapters to understand any parts that you find interesting or surprising. Reading this way will mean that you’re left without some of the relevant definitions, but realistically most strategy readers are working without those definitions as well, so hopefully it’s still a coherent read.

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 the work it stands on.

Above all else, I owe indefinite thanks to my wife, Laurel, and my son, Emerson. 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.