Introduction for Engineering Strategy.

This is a work-in-progress draft!

Over the past decade, I’ve slowly assembled a comprehensive structure for working through engineering strategy problems. This is not a competitive framework, that aims to discredit other approach, but 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, as well as being explicit about what altitude you want strategy to happen at within your organization.

I’m going to open this book by talking about two very different strategies:

1. How a team of four engineers at Uber invented and implemented our strategy to migrate two thousand product engineers and their code to a new service platform rather than continuing to writing new code in the deprecated central monolith.

2. How a team drove adoption of a breaking-the-glass mechanism… despite the initial belief that it was impossible to improve adoption due to internal stakeholder pushback and lack of executive support.

   TODO: maybe focus on private equity strategy here for 2nd example? TODO: or the calm strategy?

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 to 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.

Uber’s service migration strategy

Uber’s service migration strategy

AnonFintech’s customer data access strategy

Maybe do this one instead?

…

Strategy of Richard Rumelt

Whenever I think about strategy, I start from Richard Rumelt’s Good Strategy, Bad Strategy, which 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 irrelevent 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.

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.

…etc

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 it’s 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

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

Perhaps too obvious?

these are just a jumble of raw notes to figure out

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 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.

Summary

…