Introduction for Engineering Strategy.

This is a work-in-progress draft!

I’ve worked with people who spent years seeking a role where they could finally “do strategy.” This book hopes to convince you–and maybe even them–that there’s no need to wait. Strategy is no more than making decisions. It’s an accessible art form to everyone in an engineering role, including you. That doesn’t mean it’s easy: making good decisions is deceptively hard.

In this sense, how you commute to work is a strategy. Do you take the train, do you walk, or do you drive? How you commute probably changes if it snows, or if a member of your family needs help getting to an appointment that day. Day-to-day, your strategy is pretty consistent, but if your circumstances change–if the city decides to build a new bus stop nearby–you’d probably rethink your approach. A good strategy effectively navigates the circumstances, and a bad strategy does the opposite.

Engineering strategy is then making engineering decisions. This book defines “engineering” as both the discipline of writing software, and also concerns of the Engineering 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 it’s hopeless. My decision making has significantly improved over the course of my career, and this book’s core belief is that my improvement had very little to do with me, and a lot to do with learning to engage in structured thinking.

TODO: ^ transition in paragraph is rough/confusing

Over the past decade, I’ve slowly assembled a framework for working through engineering strategy problems. This is not a particularly novel framework, that aims to discredit 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 such as refining early strategy ideas into something that works. It also explains the attitude and the altitude you need to define strategy in your organization.

Grounded in my direct experience

This book attempts to sidestep the original sin of strategy books–generalizing in pursuit of a perfect ideal–by anchoring on my own personal experiences doing strategy. These experiences should allow you to evaluate my overall framework, and potentially come away with a better framework of your own. If you come away from this book convinced that my framework is wrong, and that you’ve identified a better framework, then I’m just as excited as I would be if you agreed with my synthesis.

As much as possible, I’ve explicitly recorded real strategies that I worked on in real companies, and have mentioned those companies 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. Those include Uber’s 2014 service migration, Stripe’s 2018 integration of the Index acquisition, and Calm’s 2020 focus on product engineering.

The other strategies I have abstracted away from specific companies because they are sensitive topics (e.g. how to work with private equity ownership), expose internal information that is better kept private (e.g. how to manage access to customer data), imagine a modern situation at a company I worked at years ago (e.g. how should a ride-sharing company adopt LLMs?), or discuss a problem I’ve encountered at every company I’ve worked at (e.g. whether to decompose a monolithic architecture).

TODO: explain my emphasis on case studies/specific stories as used in Staff Engineer, e.g. learning from SE’s success

TODO: rethink the following two paragraphs after the above reworking

These examples emphasize several core theme of this book. First, that effective strategy comes from refining decent ideas by exposing them to reality. Second, that the idea that strategy is only the domain of executives or Staff-plus engineers is self-defeating: every member of an engineering organization can do strategy, although their methods will certainly vary.

These examples also showcase how I’m navigating one of the challenges of writing about engineering strategy, which is that the publicly sharable versions of most engineering strategies tend to omit too much detail to be useful. Wherever possible, I have directly referenced the company and the team. In cases where that was impractical, I have generalized the account to make it possible to address the meaningful details where mentioning the company by name would have required omitting them.

end rethink todo

**TODO: note that I’ve tried to be positive on all of these strategies, if it seems that I’ve been too positive, it’s b/c all strategies age and some age poorly. But it’s most interesting to see strategies in the light they were intended/created, which explains the art of creation, as opposed to the art of evaluation.

Strategy of Richard Rumelt

Whenever I think about strategy, I start from Richard Rumelt’s Good Strategy, Bad Strategy, which describes three pillars of effective strategy:

1. Diagnosis - a theory describing the nature of the challenge. This is trying to identify 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
2. Guiding policy - a series of general policies which will be applied to grapple with the challenge. Guiding policies are typically going to be implicit or explicit tradeoffs. For example, a guiding policy might be “only hire for most urgent team, do not spread hires across all teams.” If a guiding policy doesn’t imply a tradeoff, you should be suspicious of it (e.g. “working harder to get it done” isn’t really a guiding policy, the relevant guiding policy there might be “work folks hard and expect high attrition”)
3. Coherent actions - a set of specific actions directed by guiding policy to address challenge. This is the most important part, and I think the most exciting part, 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, because it solved two problems I’ve been thinking about for a long time. First, how come when there is a written strategy, it’s almost always irrelevant to the situation at hand? Second, how come so many people talk about needing strategy, but there’s almost never anything written down?

The reason most written strategies don’t apply is because they’re actually visions of how things could ideally work, rather than accurate descriptions of how things work today. This means they don’t help you plot a course through today’s challenges to the desired state.

TODO: integrate following sentences into above paragraph

Rumelt provides the framework for strategy and the areas to avoid (good strategy, bad strategy). But even he acknowledges the core challenge in The Crux’s quote of Gary Hamel in

> The dirty little secret of the strategy industry is that it doesn’t have any theory of strategy creation.

However, if Rumelt’s work was trivial to apply to engineering, I think we’d see a lot more disciplined engineering strategy in practice. We’d also, one hopes, see a lot fewer obviously flawed strategies. This book aims to fill in that gap.

How Engineering Strategy differs from General Strategy

?

More than just financial and business goals

It’s more specific: it extends into the details in the mechanics of how engineering actually

It’s an ongoing activity in a living organization: not just a consultant’s document, needs mechanisms to set policy, enforce its usage, etc

*Challenge-based strategy* is reasoning forward from your current problems to identify actions that will address those challenges

*Constraint-based strategy* is defining guiding policies that help everyone within your organization to understand how to craft appropriate actions of their own that are in alignment with the other decisions being made concurrently by other individuals in the same organization

Extending for Engineering Strategy

TODO: these are just a jumble of raw notes to figure out

• “Extending Rumelt”
• Defining Engineering Strategy: Explore, Diagnose, Refine (Test, Map & Model), Policy, Operation
• covered in more detail in /components-of-eng-strategy/

As I’ve worked on this book, one of my lingering concerns is that the ideas in it are perhaps simply too obvious to write down.

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 some people would describe as quite obvious.

The belief that strategy is complex often gets people in trouble. It’s appealing to believe that strategies fail due to detailed errors in decision-making, or the unanticipated move of an adversary, and maybe that’s true when it comes to grand company strategies. However, my experience is that engineering strategies fail for very mundane reasons. The most common of these mundane reasons is that executives assume their strategy is good enough and move to rolling the strategy out before validating it works.

This book’s ambition

TODO: I hope as you read this, it’ll help you form your own theory of engineering strategy. Even if you don’t agree with mine!