My personal notes on the book Crafting Engineering Strategy, by Will Larson.

1. Introduction

• Strategy is the practice of making thought-out decisions.
• Richard Rumelt’s “Good strategy, bad strategy” pillars:
  • Diagnosis: a theory describing the nature of the challenge.
  • Guiding policy: a series of general policies that will be applied to grapple with the challenge. Guiding policies are typically implicit or explicit tradeoffs.
  • Coherent actions: a set of specific actions to address the challenge, directed by guiding policy.
• Good strategies embrace change rather than fighting it.

2. Is engineering strategy useful?

• There is always a strategy, even if not written down.
• Written strategy drives organizational learning.
  • Tech radars come to mind as a visual strategy regarding technology adoption.
  • It should start with a small group of individuals, and then feedback from a wide group can be gathered.
• Making it possible to disagree more precisely is one of the benefits of having a written strategy.
• A written strategy contains context that can be used to understand the thinking that motivated past decisions.
• Unwritten strategy is
  • vulnerable to misinterpretation.
  • creates inconsistency across teams.
  • creates inconsistency over time.
  • poses a hazard to new leaders.
• Writing strategy supports personal learning: it supports situational awareness in new environments and serves as your personal archive.

3. Who gets to do strategy?

• As an engineer, you can document how past decisions have been made, and synthesize these documents into a diagnosis and a policy. You are then just naming the implicit strategy, and creating awareness.
• Model, document and share:
  • model the approach you want others to adopt;
  • document the approach, the thinking behind it, and how to adopt it;
  • share the document around.
• Executives have the advantage that they can mandate adherence to their strategy.

4. When should you write strategy, and how much?

• Before you start working on strategy, you have to decide whether now is the correct time. That depends on three criteria:
  • Current strategic state: even if not written down, it may be globally consistent; consistent within teams; or highly varied.
  • Trends in strategic state: how much the company is hiring; how frequently organizational changes happen; how effectively you document and communicate historical decisions.
  • Your context level: how well you understand the organization.
• How much strategy should you undertake?
  • Limit the work you have in progress at any time.
  • Start with small pieces of strategy before moving to something larger.
  • Have a point of view where you want to get over time.
• Strategy altitude lets you lay out a broad, comprehensive strategy quickly. Example:

5. Steps to build an engineering strategy

• Repeatable, structured approach to drafting strategy:
  1. Exploring: exploring the wider industry’s ideas and practices around the strategy you’re working on.
  2. Diagnosing: slow down to understand the details of your problem.
  3. Refining: take a raw, unproven set of ideas, and test them against reality. Techniques: strategy testing, systems modeling, and Wardley mapping.
  4. Setting policy: policy makes the tradeoffs and decisions to solve your diagnosis.
  5. Operations: are the concrete mechanisms that translate policy into an active force within your organization.
• Uber Service Migration Strategy is a good example of strategy.
• Diagnosis can be largely data driven, but also aimed at summarizing the problem.
• Discard every element of a strategy template that gets in your way as long as you can explain what that element was intended to accomplish.

6. Exploring

• Exploration is the antidote for early anchoring, it forces you to consider the problem widely before evaluating any of the possible paths forward.
• Exploration is about verifying your prior experience remains relevant.
• How to explore:
  1. Cast every resource you can think of related to the problem.
  2. Check with your current and prior colleagues about what topics and areas you may be missing.
  3. Separate the resources you want to explore from the ones worth mentioning.
  4. Work through the list and collect notes.
  5. Once you generally understand how others have approached this problem, stop.
• Always try to find internal precedent in your organization.
• Leverage your network.

7. Diagnosis

• It’s about understanding the nuances and constraints of the problem before jumping into solutions.
• A lazy or inaccurate diagnosis can cause the strategy to fail.
• Diagnosis is an organic rather than structured process, but we can follow some loose structure:
  1. Braindump: write down your best understanding of the circumstances and set it aside.
  2. In another piece of paper, review the context of your exploration. Set it aside.
  3. Devote another blank page to talking with different colleagues and stakeholders who you know are likely to disagree with your early thinking - your goal is to understand their views.
  4. Synthesize views into one internally consistent perspective. You will later evaluate your proposed approach against them.
  5. Test drafts against cross perspectives: sit down with the people that disagree most fervently and iterate until you have captured their perspectives accurately.
• The diagnosis is all about collecting information and setting the direction for the next phase (strategy refinement).
• Data backs up your perspective; however, accept that sometimes the data you need will be missing.
• Find a way to say things politely.
• Reframe blockers as part of your diagnosis: transform them into a condition your strategy needs to address.

8. Refining

• Strategy refinement identifies the narrow problems that matter the most, and validates that your solutions to those problems will be effective.
• Strategy Testing:
  1. Identify the narrowest, deepest slice of your strategy. Iterate on applying it until you’re endued its working.
  2. Identify metrics that help you verify your approach is working.
  3. Refine your strategy based on the results.
• Systems Modelling: can help make insights immediately visible.
• Wardley Mapping: it allows you to plot users and their needs, and then study how the solutions to those needs will shift over time.

9. Setting Policy

• Policy is interpreting your diagnosis as a complete plan.
• Faced with uncertainty, a policy acknowledges the ambiguity and commits to reconsidering when more information becomes available.
• Policy is a subset of strategy, not the entirety of strategy.
• Policy decides how trade-offs should be made.
• Steps to set policy:
  1. Review diagnosis.
  2. Select policies that address every diagnosis.
  3. Consolidate overlapping or adjoining policies.
  4. Backtest: test the policies against past decisions you made.
  5. Mine for conflict -> get feedback from people.
  6. Refine.
• A strategy may contain multiple policies.
• Kinds of Policies:
  • Approvals: define the process for making a recurring decision.
  • Allocations: describe how resources are split across multiple potential investments.
  • Direction: provides explicit instruction on how a decision must be made.
  • Guidance: provides a recommendation about how a decision should be made.
• Criteria for Effective Policies:
  • They ought to be applicable.
  • They should be enforced.
  • They should create leverage -> it solves part of the diagnosis.

10. Operations

• Operations are how a policy is implemented and reinforced.
• A rubric to evaluate mechanisms for operations:
  • Measurability
  • Adoption cost
  • User ease (or burden)
  • Provider ease (or burden)
  • Reliance on authority
  • Cultural alignment
• Effective Mechanisms and Patterns:
  • Approval and Advice forums
  • Inspection: lets you evaluate your policy success and if you need to make adjustments.
  • Nudges: means providing individuals with context about a better way they might do something. They pair well with inspection.
  • Documentation and Training.
  • Automation: it scales, and is impersonal.
  • Deferral to future work.
  • Meeting: they are expensive. Do not overuse them.
• Beware of cargo-culting.

11. Writing Readable Engineering Strategies

• Structure for presenting strategy:
  • Policy: what does the strategy require or allow?
  • Operations: how is the strategy enforced and carried out? How are exceptions granted?
  • Refining: what hard-bearing details informed the strategy?
  • Diagnosis: what general trends and observations steered the thinking?
  • Explore: what context we brought when crafting this strategy?
• Prioritize what readers will most likely care about.
• Ask for feedback from someone who’s not involved with the strategy, and ask them to point out areas which are difficult to understand.
• Written strategy should be reader oriented.

13. Strategy Testing for Iterative Refinement

• Prematurely rolling out a strategy prevents you from evaluating whether the strategy is effective.
• Strategy testing is ensuring that a strategy will accomplish its intended goal at a cost you are willing to pay. It should happen before the strategy is implemented.
• Test narrowly: e.g. apply a slice apply the strategy like a pilot program to a small slice of the problem.
• How to test: identify the narrowest, deepest available slice of your strategy; iterate on applying your strategy until you are confident the approach works well. Identify metrics that help you verify the approach is working: they should not measure adoption, but impact of the change.
• Meet every week to iterate on the metrics.
• Find a sponsor or a guide to pair.

14. Systems Modelling

• Systems modelling is useful when:
  • you are unsure where the leverage points might be in a complex system.
  • you have data to compare against.
  • when stakeholders’ disagreements are based on their unstated intuitions.
• Systems modelling often exposes counter-intuitive dimensions to the problem you are working on.
• When your model and reality conflict, reality is always right.

15. Wardley Maps

• Technique to ensure your strategy is grounded in reality.
• They map users, needs and capabilities.
• It looks like shit - I didn’t like it.