Engineering Strategy: Frequently Asked Questions

Is engineering strategy a real thing?

Yes, engineering strategy absolutely exists in every engineering organization. One of the key insights from the book is that there’s always an engineering strategy, even if there’s nothing written down. The strategy may be implicit rather than explicit—embedded in decisions, behaviors, and organizational structures rather than documented in a comprehensive strategy document.

The challenge isn’t that engineering organizations lack strategies; it’s that those strategies are often unspoken, inconsistently understood across the organization, or not deliberately created. This leads to situations where engineers claim their company has no strategy while simultaneously understanding “how things work around here.”

By documenting your strategy, you make it possible to deliberately improve it rather than having it evolve haphazardly.

Learn more in Is engineering strategy useful?

How is engineering strategy different from strategy in general?

Engineering strategy applies general strategic principles to the specific domain of software engineering. The book adapts Richard Rumelt’s framework from Good Strategy, Bad Strategy (diagnosis, guiding policy, coherent actions) to focus on engineering contexts, challenges, and decisions.

What makes engineering strategy distinct is its focus on technical decisions like architecture choices, technology adoption, quality standards, and engineering processes—all within the context of delivering value through software. Engineering strategy deals with topics like monolith decomposition, managing technical debt, adopting new technologies, API design and lifecycle, and optimizing developer experience.

While general business strategy might focus on market positioning, competitive advantage, and business models, engineering strategy focuses on how to organize and execute technical work effectively in service of those broader business goals.

Learn more in Introduction

What are examples of engineering strategy?

The book provides numerous real-world engineering strategy examples including:

Uber’s service migration strategy (2014): How a small infrastructure team successfully migrated 1,000+ services to a new service platform by focusing on self-service tooling
Stripe’s Sorbet strategy (2017): The decision to build a custom static type checker for Ruby rather than decomposing their monolith
Calm’s product engineering strategy: Focusing on product development over infrastructure innovation with policies like writing all code in the monolith
Stripe’s API deprecation strategy: Never deprecating APIs without an unavoidable requirement to do so
Private equity ownership strategy: How to manage engineering costs and team structure after acquisition
Monolith decomposition strategy: Deciding whether and how to break up a monolithic codebase
Large Language Model adoption strategy: A structured approach to introducing LLMs into a company’s products and processes

These case studies demonstrate how engineering strategies address specific technical and organizational challenges within different contexts.

Learn more in the Case Studies section

What template should I use to create an engineering strategy?

The book recommends a template with five key components:

Explore: Research how others have approached similar problems
Diagnose: Define the specific challenges you’re trying to solve
Refine: Test and validate your understanding with tools like systems modeling
Policy: Make concrete decisions and tradeoffs
Operations: Establish mechanisms to implement and enforce your strategy

However, this template is meant for creating a strategy. When presenting a strategy, it’s often better to invert the structure (Policy first, then Operations, Refine, Diagnose, Explore) to make it more readable.

The book emphasizes that this template isn’t sacrosanct—you should adapt it to your needs. What matters is that you’re deliberately covering each component, even if you merge or reorder sections.

Learn more in Steps to build an engineering strategy and Making engineering strategies more readable

Can engineers do engineering strategy? Is engineering strategy only for executives?

Engineering strategy is absolutely not limited to executives. The book explicitly states that strategy is accessible to everyone in an engineering organization, though the approaches differ based on role and authority.

Individual engineers can use techniques like “Take five, then synthesize” (documenting how similar decisions have been made, then synthesizing a policy) or “model, document, and share” (demonstrating a better approach through example). These bottom-up methods can be highly effective even without executive authority.

While executives can mandate adoption of strategies, they often lack the detailed context that engineers have. The most effective strategies typically come from collaboration across multiple levels of the organization, combining executive support with deep technical understanding.

Learn more in Who gets to do strategy?

How to get better at engineering strategy?

To improve your engineering strategy skills, the book recommends:

Study existing strategies: Read public resources on engineering blogs, ask peers about their experiences, and build a collection of strategies to learn from
Join or create a learning circle: Form a community with peers to discuss strategy challenges and approaches
Evaluate strategies using a structured rubric: Analyze how quickly strategies are refined, how expensive refinement is, and how well they solve their diagnosed problems
Practice at appropriate altitude: If you can’t work on organization-wide strategies, focus on team-level or personal strategies
Track your progress: Maintain a record of strategies you’ve implemented, refined, or studied, and review it quarterly
Seek feedback: Review your strategy work with trusted peers who can provide honest assessment

The key is consistent practice—even if it’s just one strategy every six months—coupled with deliberate learning from each attempt.

Learn more in How to get better at strategy?

Are there jobs in engineering strategy?

While “Strategy Engineer” isn’t typically a standalone job title, engineering strategy work is embedded in many roles throughout engineering organizations. Senior and Staff-plus engineers, engineering managers, technical program managers, and engineering executives all regularly engage in strategy work as part of their responsibilities.

Some larger organizations do have dedicated teams focused on engineering strategy, often under names like “Engineering Effectiveness,” “Developer Experience,” or “Technical Strategy.” These teams help shape and implement strategies that affect the broader engineering organization.

Even without a dedicated strategy role, you can incorporate strategy work into your current position. The book emphasizes that everyone in engineering can contribute to strategy, and developing this skill can be valuable for career advancement toward senior technical leadership roles.

Learn more in Who gets to do strategy?

What are other engineering strategy resources?

The book recommends several resources for learning more about engineering strategy:

Books:

Good Strategy, Bad Strategy by Richard Rumelt
Technology Strategy Patterns by Eben Hewitt
The Value Flywheel Effect by Anderson, McCann, and O’Reilly
Architecture Modernization by Nick Tune with Jean-Georges Perrin
Thinking in Systems: A Primer by Donella Meadows
How Big Things Get Done by Bent Flyvbjerg and Dan Gardner

Articles and case studies:

“Magnitudes of exploration” (Stripe’s Engineering strategy)
“Run less software” by Rich Archbold (Intercom)
“How Big Technical Changes Happen at Slack”
“The difficult teenage years: Setting tech strategy after a launch” (Financial Times)

Other resources:

BoringTechnology.club by Dan McKinley
Wardley Maps by Simon Wardley
Public engineering blogs from companies like Slack, Stripe, and Netflix

Learn more in Strategy resources

What are the five steps to build an engineering strategy?

The book outlines five essential steps for building an effective engineering strategy:

Explore: Research how other organizations have approached similar challenges. This includes reading industry literature, speaking with peers at other companies, and investigating existing solutions within your own organization. This step helps prevent early anchoring on one approach.
Diagnose: Clearly define the problem you’re trying to solve before jumping to solutions. This includes understanding the technical, social, and business constraints you’re operating within. A good diagnosis forms the foundation for effective policy.
Refine: Use techniques like systems modeling, Wardley mapping, or strategy testing to validate and improve your understanding of the problem. This step helps identify which elements of your strategy are most important.
Policy: Make concrete decisions and tradeoffs that address the diagnosed challenges. These can range from specific technical approaches to organizational processes.
Operations: Create mechanisms to implement and enforce your strategy, ensuring it doesn’t just remain a document but becomes an active force in your organization.

Learn more in Steps to build an engineering strategy

How do I evaluate if a strategy is any good?

The book provides a three-part rubric for evaluating strategy quality:

How quickly is the strategy refined? Good strategies evolve based on new information and changing circumstances. A strategy that improves quickly is better than one that remains static despite evidence it’s not working.
How expensive is the strategy’s refinement? Effective strategies can be validated and improved cheaply. If testing a strategy requires massive investment before you know if it works, that’s a red flag.
How well does the current iteration solve its diagnosis? Ultimately, a strategy must address the problems it set out to solve.

The book also emphasizes the concept of strategy phases. As a strategy is implemented, new information emerges that may invalidate parts of the original diagnosis. Good strategists recognize these phase transitions and adjust accordingly.

It’s worth noting that it’s very difficult to accurately evaluate other companies’ strategies from the outside because you’re missing critical context about their circumstances and constraints.

Learn more in Is this strategy any good?

Strategy refinement is the process of validating and improving your strategy through deliberate testing and feedback. It’s perhaps the most critical yet often neglected aspect of engineering strategy.

The book describes refinement as “a toolkit of methods to identify which parts of your diagnosis are most important, and verify that your approach to solving the diagnosis actually works.” Three key refinement techniques covered are:

Strategy testing: Identifying the narrowest slice of your strategy to implement, then iterating until you have evidence it works
Systems modeling: Creating models to understand complex systems and identify leverage points
Wardley mapping: Plotting the evolution of capabilities to understand how the ecosystem is changing

Refinement matters because even the best initial strategy is based on incomplete information and untested assumptions. Without refinement, strategies frequently fail due to unexpected obstacles or changing circumstances.

Effective strategy isn’t a one-time exercise but an iterative process. Organizations that skip refinement often push forward with flawed approaches, leading to expensive failures that could have been avoided with early, cheap tests.

Learn more in Refining strategy

How do I navigate ambiguity and uncertainty in strategy?

Ambiguity and uncertainty are inherent in strategy work, and the book provides several approaches to navigate them effectively:

Accept ambiguity as part of the diagnosis: Rather than getting blocked by missing information, acknowledge it explicitly in your strategy. For example, the private equity strategy acknowledges uncertainty about reduction targets but still provides guidance on what to do in the meantime.
Use refinement techniques: Systems modeling, Wardley mapping, and strategy testing can help reduce uncertainty by providing structured ways to explore complex problems and test assumptions.
Don’t wait for missing strategies: If you’re waiting for strategies from other teams or executives before creating your own, you’ll never make progress. Instead, incorporate the absence of those strategies into your diagnosis and move forward.
Adopt provisional policies: When perfect information isn’t available, create policies that work with what you know and explicitly plan to revisit them when more information becomes available.
Focus on operational mechanisms: In highly ambiguous situations, focus on creating mechanisms that help you learn faster, rather than trying to get the perfect policy immediately.

The book emphasizes that strategy is iterative, and uncertainty isn’t a reason to avoid strategy—it’s precisely why strategy is valuable.

Learn more in Setting policy and Bridging theory and practice

What’s the difference between policy and operations in strategy?

Policy and operations are two distinct but complementary components of strategy:

Policy is the set of decisions, tradeoffs, and approaches that address your diagnosed challenges. Policies can take several forms:

Approvals: Defining processes for making recurring decisions
Allocations: Determining how to split resources across investments
Direction: Providing explicit instructions on how decisions must be made
Guidance: Offering recommendations on how decisions should be made

Operations are the concrete mechanisms that implement and enforce your policies. These include:

Approval forums: Committees or individuals who review exceptions
Inspection mechanisms: Ways to check if policies are being followed
Nudges: Context-aware reminders that guide better decisions
Documentation: Clear guidance on how to follow policies
Automation: Technical systems that enforce policies
Meetings: Regular forums to review progress and address issues

The key distinction is that policy describes what should happen, while operations ensure it actually happens. Even the best policy will fail without effective operational mechanisms to support it.

In practice, when writing a strategy for readers, these sections are often merged to improve readability, but when creating a strategy, it’s valuable to think about them separately.

Learn more in Setting policy and Operations for strategy

What is Wardley mapping and when should I use it?

Wardley mapping is a technique for visualizing the evolution of components in a value chain, created by Simon Wardley. A Wardley map plots components along two axes:

Visibility to user (vertical axis): How aware users are of a component
Evolution (horizontal axis): How mature a component is, from genesis to commodity

The book identifies several scenarios where Wardley mapping is particularly valuable:

When you need to understand how a technology ecosystem is evolving (like the LLM ecosystem example)
When your strategy needs to account for industry-wide changes
When you want to identify opportunities for strategic advantage based on component evolution
When your strategy needs to span multiple years and accommodate changing circumstances

Wardley mapping helps you zoom out to see broader patterns and anticipate changes, which makes it complementary to techniques like systems modeling (which zooms in on specific dynamics).

The book provides a step-by-step approach to creating Wardley maps, starting with identifying users and needs, establishing value chains, plotting them on the map, and then predicting evolution.

Learn more in Refining strategy with Wardley Mapping

What is systems modeling and how does it help with strategy?

Systems modeling is representing interconnected components as stocks (accumulations) and flows (changes to stocks) to understand complex behaviors and identify leverage points. The book describes it as “an effective, flexible tool for debugging complex problems.”

Systems modeling helps with strategy in several key ways:

Identifying leverage points: Models reveal which interventions will have the most impact. For example, the rider onboarding model showed that reengaging departed drivers was more valuable than improving onboarding speed.
Testing ideas cheaply: Models let you experiment with different approaches without real-world risks. The API deprecation model demonstrated how reducing both baseline churn and deprecation-related churn together created the biggest impact.
Revealing counter-intuitive insights: Models often show unexpected behaviors. The developer experience model revealed that implementing LLMs might increase time writing and testing code, not decrease it.
Mediating stakeholder disagreements: When stakeholders have conflicting intuitions about what will work, models provide a structured way to explore those intuitions.

The book provides multiple examples of applying systems modeling to engineering strategies, including service provisioning, driver onboarding, and API deprecation.

Learn more in Using systems modeling to refine strategy

When should I write strategy, and how much is too much?

The book provides clear guidance on timing and volume for strategy work:

When to write strategy:

When your organization is not globally consistent in approach (different teams give different answers)
When you’re experiencing significant hiring growth (which can dilute cultural knowledge)
When you have new external leadership who may drive inconsistent approaches
When you have significant organizational changes like reorganizations

How much strategy:

Limit yourself to one or two strategies at a time to ensure quality and focus
Use strategy altitude to manage volume:
- Higher altitude (organization-wide) strategies should be more permissive
- Lower altitude (team-level) strategies can be more prescriptive
- Permissive strategies create less overhead than prescriptive ones

Signs you’re doing too much:

Your prior strategy work isn’t impacting subsequent decisions
Teams feel overwhelmed by changes in approach
You’re spending more time on strategy than on implementation

The book recommends focusing on one strategy until it works before moving to the next one. This approach may seem unambitious, but it’s typically more effective than attempting many strategies simultaneously.

Learn more in When to write strategy, and how much?

How should I format my strategy document to maximize readability?

The book emphasizes that the order for writing a strategy is different from the order for reading it. For maximum readability:

Invert the structure: Put the most immediately useful information first:
- Policy: What does the strategy require or allow?
- Operation: How is the strategy enforced?
- Refine: What were the key insights that informed the strategy?
- Diagnose: What challenges is the strategy addressing?
- Explore: What broader context informed the thinking?
Consider refactoring: Feel free to merge sections (like combining Policy and Operations) or embed one section in another when it makes the document more readable.
Additional readability tips:
- Test with uninvolved readers before wide release
- Include a clear commenting period and office hours for questions
- Disable in-document commenting after release to avoid distraction
- Include consistent metadata (creation date, approval status, where to ask questions)
- Create a template specific to your organization

Remember that most readers just want to know what to do, not the full thinking behind it. The inverted structure serves those readers first while still providing context for those who want to understand the rationale.

Learn more in Making engineering strategies more readable

What is strategy altitude and why does it matter?

Strategy altitude refers to the organizational level at which a strategy operates and how permissive or prescriptive it is. The book identifies this concept as a key tool for managing the volume and impact of strategies.

Altitude levels include:

Company-wide strategies
Engineering organization strategies
Team-level strategies
Individual strategies

Permissiveness spectrum:

Prescriptive strategies mandate specific approaches with little flexibility
Permissive strategies provide guidance but allow for local customization

Strategy altitude matters because:

It affects adoption costs: Higher-altitude, prescriptive strategies create more organizational overhead
It impacts effectiveness: The right altitude ensures the strategy can be properly enforced
It enables managing multiple strategies: Using different altitudes allows you to address more challenges without overwhelming the organization

The book recommends deliberately choosing your strategy’s altitude based on your context. If you lack authority for a high-altitude strategy, operate at a lower altitude. If you need to cover many topics quickly, use more permissive approaches at higher altitudes.

Examples include Calm’s product engineering strategy (high-altitude, relatively prescriptive) versus Uber’s service migration strategy (lower-altitude, more permissive).

Learn more in When to write strategy, and how much?

How do operational mechanisms make or break a strategy?

Operational mechanisms are the concrete ways a strategy is implemented and enforced. The book emphasizes that even the best policies fail without effective operational mechanisms, calling them “two-thirds avoiding common practices that simply don’t work.”

Effective operational mechanisms:

Make policies real: They translate abstract decisions into concrete actions
Provide feedback: They help identify when policies aren’t working
Create accountability: They ensure teams actually follow the policy
Reduce friction: They make following the policy easier than ignoring it

The book identifies common effective mechanisms:

Approval and advice forums
Inspection mechanisms to evaluate compliance
Nudges that provide timely guidance
Documentation of how to follow the policy
Automation that enforces the policy
Meetings to review progress and address issues

It also highlights mechanisms that typically fail:

Top-down pronouncements without enforcement
One-time educational announcements
Mandatory recurring trainings that no one pays attention to
Vague cultural expectations without concrete steps

Effective mechanisms differ based on your role—executives have more leverage through mandates, while individual engineers may rely more on nudges and documentation. However, the book notes that mandates often don’t work as well as expected, while lightweight mechanisms can be surprisingly effective.

Learn more in Operations for strategy

How do I handle strategy when my organization is undergoing rapid change?

The book specifically addresses doing strategy in chaotic environments, emphasizing that strategy doesn’t require stable environments—it requires awareness of the environment you’re operating in.

Key approaches for handling rapid change include:

Explicitly acknowledge uncertainty in your diagnosis: Rather than waiting for perfect information, incorporate the uncertainty into your strategy. For example, the private equity strategy acknowledged unknown reduction targets but still provided guidance.
Focus on shorter timeframes: In dynamic environments, your strategy might only project forward a few weeks or months instead of years.
Use Wardley mapping to anticipate evolution and build adaptability into your strategy.
Emphasize operational mechanisms that provide frequent feedback, allowing you to detect when circumstances have changed.
Focus on policies that create options rather than those that commit to specific long-term approaches.
Layer permissive, high-altitude strategies that provide guidance without constraining teams from adapting to changing circumstances.

The book emphasizes that strategies don’t fail because of chaotic environments—they fail because they don’t diagnose those environments accurately. A good strategy in a rapidly changing context will explicitly account for that change.

Learn more in Bridging theory and practice

What are the most common ways strategies fail?

The book identifies several recurring patterns of strategy failure:

Skipping refinement: Many strategies fail because they aren’t tested before being fully implemented. Strategy testing is particularly valuable for avoiding this failure mode.
Poor diagnosis: Strategies that misunderstand the core problem or ignore critical constraints are doomed from the start. Often this happens when strategies anchor too quickly on one solution.
Neglecting operational mechanisms: Even sound policies fail without effective mechanisms to ensure adoption. This is especially common with executive-driven strategies that assume announcement equals adoption.
Overly ambitious scope: Attempting to change too much at once often leads to failure. The book recommends working on one strategy at a time.
Mismatched altitude: Strategies that are too prescriptive for their altitude create too much overhead and resistance.
Manufactured consent: Creating the illusion of agreement without actual alignment leads to surface-level compliance but ultimate failure.
Optimizing for side goals: When strategies prioritize secondary objectives (like learning a new technology) over the primary goal, they often fail to solve the core problem.
Disregarding constraints: Ignoring real limitations (like available resources) leads to strategies that cannot be implemented.

The book emphasizes that many of these failure modes can be detected early through proper refinement techniques and then corrected before significant resources are wasted.

Learn more in Refining strategy and Is this strategy any good?

How do I get buy-in for my strategy?

While the book doesn’t dedicate a specific chapter to getting buy-in, it provides several approaches across different chapters:

Start with solid exploration and diagnosis: When your strategy is grounded in a thorough understanding of the problem and existing approaches, it’s more compelling to stakeholders.
Use refinement techniques to build evidence: Systems modeling, Wardley mapping, and strategy testing provide concrete evidence that builds confidence in your approach.
Match your strategy’s altitude to your influence: If you’re not an executive, focus on team-level strategies or use influence-based approaches like “model, document, and share.”
Focus on solving urgent, recognized problems: Strategies addressing widely acknowledged pain points get more traction than those solving theoretical issues.
Format for readability: Structure your strategy document with policy first so stakeholders immediately understand what you’re proposing.
Acknowledge constraints: Strategies that work within recognized constraints rather than fighting them are more likely to be adopted.
Use a hybrid rollout: Start with a permissive approach that allows teams to customize implementation, then gradually move to more prescriptive policies as you demonstrate value.
Target “strategy archaeologists”: Identify long-tenured employees who understand the organization’s history and get their support first.

The book notes that different approaches work better in different organizations, so understanding your company’s culture is essential to effective buy-in strategies.

Learn more in Who gets to do strategy? and Bridging theory and practice

Previous chapter: Drafting Strategy