Building Effective Engineering Strategy Frameworks

Engineering strategy isn't "technical roadmap with business words." It's not vision disguised as strategy ("We'll be the most scalable platform!").

Strategy is the framework that helps your team make good decisions when you're not in the room.

Most teams have execution plans, sprint goals, roadmaps. What they don't have: a coherent framework connecting technical choices to business outcomes. So they ship fast in the wrong direction.

I learned this managing multiple teams across payments infrastructure. Strategy doc gets written, everyone nods. Three weeks later, teams are making decisions that directly contradict it. Not because they disagreed. Because the strategy never translated into actionable guidance.

This post builds on Will Larson's Crafting Engineering Strategy, Donella Meadows' Thinking in Systems, and Richard Rumelt's Good Strategy Bad Strategy / The Crux. These books changed how I think about technical decisions.

Why Most Strategy Fails

Most engineering "strategies" don't change how teams make decisions.

The cycle: Leadership asks for strategy. Someone writes a doc. Gets approved. Nobody reads it again. Teams keep making choices the same way. Whoever argues loudest wins.

Strategy works when it shows up in daily decisions: picking a database, debating build vs buy, questioning an architecture approach.

If your strategy doesn't guide those moments, it's just a document.

Diagnosis, Policy, Actions

Richard Rumelt's Good Strategy Bad Strategy breaks strategy into three parts:

Diagnosis: What's the situation and core challenge?
Guiding Policy: What's our approach to solving it?
Coherent Actions: What specific steps will we take?

Most "strategies" skip diagnosis and jump straight to actions. "We need a new integration approach" without explaining why the current one blocks deals.

We saw this on a merchant hardware integration project. POS devices connecting to billing machines using 3 physical wires. Wired and wireless integrations were completely separate. Different codebases, different processes, different support playbooks. This created two problems: enterprise customers rejected the 3-wire complexity (too hard to deploy at 500+ locations), and every new feature had to be built twice.

Product wanted a unified single-wire integration that would work for both wired and wireless. Great vision. The plan was to hire external consultants to build custom drivers over 3 months. The assumption: our team couldn't handle this level of complexity.

I challenged that assumption. Do we actually need driver-level changes, or can we solve this at the application layer? Nobody had validated the technical approach. We were about to spend 3 months and significant budget without diagnosing what's actually hard.

We proposed a 2-week POC with one engineer: build an app-level integration using single USB, abstract away the wired/wireless differences at the application layer. If it works, we save months and prove in-house capability. If it doesn't, we have data on what's hard.

The POC worked. Single wire, app-level abstraction, no driver changes needed. Wired and wireless integrations now shared 90% of the codebase. We demoed it to the enterprise customer who had rejected our 3-wire approach. They accepted immediately.

More importantly, we now had a unified architecture that would support the next 2 years of product development. One codebase, one setup process, one support playbook. That 2-week POC unblocked the enterprise business and set the product direction.

Will Larson extends this into 5 steps for creating strategy:

Explore: What have others done?
Diagnose: What's our situation?
Refine: Test with models
Policy: Make tradeoffs explicit
Operation: How we execute

Key insight: Write in reverse order for readers.

Write for Readers, Not Thinkers

When you create strategy, you work through: Explore → Diagnose → Refine → Policy → Operation.

When you present strategy, reverse it: Policy → Operation → Refine → Diagnose → Explore.

Why reverse the order? Because readers want to know what we're doing first. If they need more context, they'll read Operation (how we execute). If they want the rationale, they'll read Refine and Diagnose. Almost nobody reads Explore.

Strategy docs written in "thinking order" (five pages of problem analysis before stating the decision) don't get read past page two.

Write for readers, not thinkers:

1. Policy: What We're Doing

Policy describes how tradeoffs should be made. Not what you'll do, but how you'll decide when choices come up.

Good policies often feel boring. They should feel inevitable given your diagnosis. A policy isn't good because it's novel. It's good because it's effective.

Most strategies need 3-5 policies to address the diagnosis fully. Each policy should include:

The directive (what must or should happen)
The reasoning (why this matters, linked to the diagnosis)
The tradeoff (what you're accepting as a cost)

Bad policy: "Improve developer productivity"
Good policy: "Reduce commit-to-production from 2h to 30min by Q3. This means deprioritizing new CI features to focus on pipeline speed. We accept slower feature rollout to enable 10x deployment frequency."

For the integration project:

Validate with POC before committing to consultants. Build 2-week proof-of-concept with one engineer to prove app-level solution works. We cannot commit to a 3-month consultant engagement for driver-level solution based on untested assumptions. If the POC fails, we have data on what's actually hard. If it succeeds, we save months and prove we can do this in-house.

Unify wired and wireless codebases, accept temporary feature gaps. Wired and wireless integrations must share 90%+ of codebase through application-layer abstraction. This means some features from the separate implementations won't work immediately in the unified version. We accept this to eliminate the long-term tax of maintaining two codebases, two setup processes, and two support playbooks.

Optimize for 2-year product evolution, not immediate deployment. Single-wire solution must enable both enterprise deals (simple deployment at 500+ locations) and future product capabilities (seamless switching between wired/wireless). We will accept hardware constraints that simplify the architecture rather than building every possible configuration upfront.

2. Operation: Making Policy Work

Operations are the concrete mechanisms that ensure policies actually happen. Even the best policy fails if teams don't adopt it. A one-time announcement doesn't change behavior.

Good operational mechanisms answer:

How will this policy be enforced?
Who handles exceptions?
How do we measure if it's working?

For the integration project:

Week 1-2: Single engineer builds POC. Success criteria: single-wire connection works, wired/wireless abstraction validates.
Week 3: Principal Engineers review architecture. Approval required before proceeding.
Week 4-6: Refine based on feedback. Demo to enterprise customer. Get written acceptance before broader rollout.
Q2: Enterprise deployment. Ops tracks setup time vs 3-wire baseline. Customer support monitors integration issues.

Operations turn "we should do this" into "here's exactly how we'll know if we're doing it."

3. Refine: Validate Before You Commit

Refinement validates your approach actually works before you bet the organization on it. Tools include systems modeling, Wardley mapping, and strategy testing (POCs, pilots, experiments).

The biggest risk isn't modeling too early or too late. It's skipping refinement entirely. Most strategies fail because they never validated the approach would work.

What the POC revealed:

App-level abstraction worked (single USB wire, hide wired/wireless complexity)
Unified codebase possible (90% code sharing between wired and wireless)
No driver-level changes needed (leverage existing USB infrastructure)
Customer validated it: enterprise customer who rejected 3-wire immediately accepted single-wire demo
Strategic insight: Not just enterprise sales. This unified architecture would support the next 2 years of product development.

The POC created alignment. Product saw it work. Engineering proved capability. Customer accepted it. Everyone aligned around the same evidence.

4. Diagnose: The Challenge

Diagnosis describes the nature of the challenge. Not symptoms. The root cause. This is for readers who want to understand why you're doing this, not just what you're doing.

Good diagnosis identifies the crux: the specific challenge that, if solved, makes everything else easier.

For the integration:

Current State: 3-wire integration (POS device to billing machine) works for small merchants. Wired and wireless are separate implementations. Different codebases, different processes.

The Challenge:

Enterprise rejecting 3-wire (too complex to deploy at 500+ locations)
Every feature built twice (wired and wireless)
Product leadership believes we need external consultants for driver-level solution

The Crux: We don't actually know if driver-level changes are needed. Nobody validated the technical approach. We're about to spend 3 months and significant budget based on untested assumptions about complexity.

Why This Matters: Losing enterprise pipeline. Continued dual-codebase tax on every product feature. External dependency for core capability.

Customer Signal: "We can't deploy 3-wire at 800 locations. Show us something simpler or we're evaluating competitors."

5. Explore: Alternatives Considered

Exploration shows what's possible. Study what others have done. Understand industry patterns. Identify options you haven't considered.

This builds trust. Readers see you've thought it through, not just jumped to the obvious answer.

For the integration, we explored:

Option 1: Hire external consultants for driver-level solution
Industry pattern for complex hardware integrations. Months-long timeline, high cost, knowledge doesn't stay in-house. Assumes driver-level changes are required.

Option 2: Build driver-level solution in-house
Complex, risky, unproven feasibility. Team capability questioned by product leadership. Would take months to validate if we even can do this.

Option 3: Test if app-level solution works (chosen)
2-week POC to validate assumptions before committing. If app-level works, we save months and prove in-house capability. If it doesn't, we have data on what's actually hard and can revisit options 1 or 2 with evidence.

Model Your Bets

The biggest shift came from learning systems modeling. Instead of debating which approach is better, model the scenarios.

Models Beat Debates

Relying on "engineering judgment" for major decisions creates endless debates because everyone's judgment points in different directions.

Instead, sketch the system: what accumulates (stocks), what flows in and out, what feedback loops exist. Model 2-3 scenarios in a spreadsheet. Takes about an hour and often reveals counterintuitive insights.

Here's a simple example of modeling device observability:

Building observability from zero:

We had a supply chain problem. Thousands of hardware devices moving between warehouses, merchants, and repair centers. Device loss was showing up in monthly P&L reviews. Not huge numbers, but trending upward. We had manual spreadsheet tracking, but no systematic observability into where and why devices were disappearing.

We mapped out the entire device lifecycle on Excalidraw. Every state (Vendor Portal, Portal Verification, Stock Preparation, Dispatch, Merchant Location, Repair Center, etc.) and every transition between them. The map revealed 15+ handoff points across vendor operations, business operations, SCM operations, field service, and logistics.

The systems model came from studying this flow. Key stocks: devices in each state (warehouse inventory, devices at merchants, devices in repair, devices in transit between states). Key flows: transition rates between states (deployment rate, return rate, repair rate). The constraint: we only had visibility into stable states, not transitions.

Here's the problem. Manual spreadsheets captured daily inventory: "500 devices in warehouse, 1200 at merchants, 80 in repair." But devices spend most of their time in stable states and brief periods in transition. When a device disappeared, we couldn't tell if it was lost during warehouse-to-merchant deployment, merchant-to-warehouse return, or merchant-to-repair handoff.

We modeled what would happen if we only tracked state snapshots versus tracking every transition. Snapshot-only approach meant we'd always have blind spots during handoffs. To hit 99%+ observability, we needed to instrument the transitions themselves.

We built it. Instrumented every state change: "device ID 1234 moved from Stock Preparation to Dispatch at timestamp," "device ID 1234 signed off by field service at timestamp," "device ID 1234 entered repair queue at timestamp." Result: 99.3% observability versus 97% target.

More importantly, the data revealed patterns. Merchant-to-repair-center transitions had 10x higher loss rate than other handoffs. That workflow used a different system we'd missed in the original mapping. We fixed it, loss rate on that transition dropped 40%.

The data also revealed dwell states. Devices sitting in "Stock Preparation" for 7+ days. Devices stuck in "Repair Queue" for 14+ days. These weren't losses, but they showed up as operational inefficiencies. Long dwell times meant capital locked up, inventory bloat, delayed deployments. Operations used this to optimize workflow timing and resource allocation.

Now we had the feedback loop: transition data leads to pattern detection, which drives workflow fixes, which improves operations.

Loading diagram...

The system: Blue boxes are stocks (what we could measure via daily snapshots). Solid arrows are flows we tracked. Dotted arrows to the red box show losses during handoffs, invisible until we instrumented the transitions themselves. The merchant-to-repair flow had 10x higher loss rate because it used a different workflow system we'd missed.

How to Model

The process is straightforward:

Sketch stocks (things that accumulate) and flows (rates of change)
Identify feedback loops (how stocks affect flows)
Model 2-3 scenarios in a spreadsheet (takes about an hour)
Look for counterintuitive insights
Document the key insight in your strategy doc

You don't need fancy tools. Excalidraw and Google Sheets are enough.

For a deeper understanding of systems modeling, Thinking in Systems by Donella Meadows is excellent (not software-specific, but the mental models translate perfectly to engineering). Will Larson's introduction to systems thinking is more software-focused.

Pick Your Tool

Different problems need different refinement approaches:

Systems Modeling: Use when you understand the problem but need to find leverage points

Unsure where to focus efforts for largest impact
Have significant data to validate against
Stakeholders disagree based on unstated intuitions
Example: Where does device loss actually happen? Model the flows to find the bottleneck.

Wardley Mapping: Use when the ecosystem around you is evolving

Industry dynamics shifting rapidly
Understanding how capabilities will commoditize
Build vs buy decisions in changing markets
Example: Is metrics collection still a competitive advantage, or is it commodity infrastructure now?

Strategy Testing: Use when reality is deeply ambiguous

No agreement on the nature of the problem
Need to validate if a solution is viable before committing
Already have a strategy, need to refine the details
Example: Will teams actually adopt this new pattern? Run a small test first.

Strategy testing deserves its own post. POCs, pilots, experiments all have different risk profiles and learning goals. For now: two weeks of proof beats two months of debate.

Wardley Mapping for Build vs Buy

Wardley mapping shows evolution of components on two axes:

Wardley Map Example

Y-axis: Value chain. User-visible capabilities at top, underlying components below.
X-axis: Evolution. Genesis (novel) → Custom-built → Product → Commodity (utility).

The strategic insight: Don't build custom solutions for commoditized capabilities. Don't buy products for your competitive advantages.

For the observability system, a Wardley map would show:

Commodity (right side): Metrics collection, time-series database, alerting infrastructure. Use existing tools.
Custom (left-center): Supply chain state modeling, transition tracking logic, device loss detection. Build this ourselves because it's specific to our workflow.

This cuts through "not invented here" syndrome and vendor lock-in debates. Map where capabilities sit on the evolution axis, then decide build vs buy based on strategic value and maturity.

Wardley mapping deserves its own deep dive. For now: Will Larson's refining strategy with Wardley mapping and the case studies in his book.

Strategy Means Saying No

Every strategy is saying NO to something.

The integration example: We said NO to driver-level complexity for app-level abstraction. We said NO to maintaining dual codebases (wired and wireless). We accepted proving feasibility first via POC instead of committing to full build upfront. We accepted single-wire constraint to unify the architecture.

The observability example: We said NO to perfect 100% coverage to hit 99%+ faster with less complexity.

That's the tradeoff. Most strategies hide this. They present the decision without showing what you're giving up.

Good strategy makes tradeoffs explicit:

What are we NOT doing?
What are we accepting as a cost?
What risks are we taking?

When everyone sees the tradeoffs, they can make better local decisions that align with the strategy.

Who Should Write Strategy?

Don't wait for permission. Start writing.

The Uber service migration story from Will's book illustrates this well. A 4-person infrastructure team was supporting 2000+ product engineers. Product engineering was doubling every 6 months, and provisioning requests were projected to go from 2-3 per week to 8-12 per week. Their first instinct was to hire more infrastructure engineers. But when they modeled it, they discovered that new product engineers would generate more provisioning requests than new infrastructure hires could handle. Only automation would scale. They had no executive sponsor, but they wrote the strategy, modeled it, proved it worked incrementally, and eventually got org-wide adoption.

Small teams often write the best strategy because they can't force adoption. They have to refine it until it works.

We saw this with the integration project. Started by challenging an assumption, built a POC, proved it with one customer, then got broader buy-in. The strategy was already working before formal approval.

The key is matching scope to altitude. Staff Engineers and EMs should write strategy for service or team-level decisions (integration approaches, architecture evolution). Senior EMs and Directors handle multi-team coordination (shared infrastructure, cross-team standards). Directors and VPs set org-wide strategy (build vs buy, platform investments).

A VP shouldn't be writing detailed integration plans, and a Staff Engineer shouldn't be setting org-wide platform strategy. But an EM shouldn't hesitate to write strategy for their scope. Start small, prove it works, build adoption.

Make It Testable

"Improve developer productivity" isn't testable. "Reduce commit-to-production from 2h to 30min by Q3" is.

Every strategic bet needs:

A way to prove it wrong
A timeline for checking
Decision criteria for pivoting

Set review cadences:

Weekly: Tactical metrics (deployment velocity, incident rate, observability %)
Monthly: Strategic metrics (overall quality, team satisfaction, customer adoption)
Quarterly: Strategy validity (did our assumptions hold? should we pivot?)

Without cadences, metrics become vanity dashboards. With cadences, they drive decisions.

OpEx Framework

We built an operational excellence framework that makes strategy execution visible:

Operational Excellence Framework

Process Quality (top-left):

SDA & velocity trends (are we shipping faster?)
PR throughput & cycle time P90 (dev experience)
Deployment frequency & lead time for changes (DORA)
% effort towards roadmap vs unplanned (are we strategic or reactive?)

Code Quality (top-right):

Code coverage (test health)
Tech debt reduction (are we paying it down?)
Build success rate & CI execution time (CI/CD health)
PR review & merge delays (collaboration bottlenecks)

Production Quality (bottom-left):

P0/P1 incidents & hotfix/revert rate (production stability)
PSE tickets escalated to dev teams (support load)
MTTR & incident RCA completion (recovery speed, learning)

Innovation & Adoption (bottom-right):

AI adoption & productivity gains (are we experimenting?)
Engineering experimentation & POCs (exploration)
Automation & tooling (dev experience improvements)

Every EM reports weekly on these metrics. We review monthly, adjust quarterly.

This framework does three things:

Makes strategy visible: If your strategy is "reduce technical debt," it shows up in Code Quality quadrant
Reveals tradeoffs: Shipping too fast (Process Quality up) while Production Quality drops? That's a signal.
Drives decisions: When metrics shift, we ask "why?" and adjust

For observability, we tracked:

Weekly: Device state transitions captured (%), data pipeline uptime, transition events processed, dwell time P90 by state
Monthly: Overall observability %, loss incident count, high-risk transition points, states with excessive dwell times
Quarterly: P&L impact from device loss, operational process improvements implemented, inventory efficiency gains

This caught issues early. Week 6, observability stalled at 98% for two weeks straight. We dug in.

Found the issue: merchant-to-repair-center transitions weren't being captured. That specific handoff used a different workflow system. We'd missed it in initial implementation.

Fixed it in 3 days. Observability jumped to 99.3%. More importantly, we discovered that repair-center returns had the highest loss rate. Operations team changed the process. Loss rate dropped 40%.

The framework isn't just measurement. It's a conversation tool. When everyone sees the same data, strategic adjustments become obvious.

Common Traps

Perfect Framework Trap: Spent months building templates nobody used. Lightweight beats comprehensive.

Annual Planning Trap: Strategy once a year doesn't work. Do quarterly reviews. Adjust based on what you learned.

Model-Free Decisions: Don't debate for weeks. Build a POC or model it in a spreadsheet. Takes hours, not weeks. Makes assumptions explicit.

Strategy as Project Plan: If your doc is just a list of projects with dates, it's not strategy. It's a project plan. Strategy explains why these projects and not others.

Skipping Exploration: Don't just solve today's pain. Explore what others have done. What's changed in the industry? You might be solving the wrong problem.

What Good Looks Like

Strategy works when teams make consistent decisions without escalation. Engineers explain WHY, not just WHAT. Everyone knows what we're NOT doing and why.

Best feedback I got on the integration strategy: "I finally understand why we're doing a POC first instead of committing to the full solution upfront."

Second best: "We disagreed on the app-level approach, but I get the tradeoff. Prove it works fast vs build everything we think we need."

That's when you know it's working.

Review and Adjust

Most teams define strategy, measure it, then ignore the data.

The discipline is in weekly/monthly/quarterly reviews:

Look at the data
Ask what we learned
Adjust based on evidence
Communicate changes

Strategy isn't static. It's a framework that evolves as you learn.

The OpEx framework makes this visible. Every EM reports weekly on metrics across all four quadrants. Monthly reviews ask: what patterns emerged? Which quadrant is trending wrong? What needs attention? Quarterly reviews ask: is our strategy still valid? Should we pivot? What did we learn?

Strategy changes show up in the data before they show up in complaints.