Why your engineering strategy document is probably a wish list, not a strategy

Every quarter, engineering leaders write strategy documents. They list the desired outcomes for the next six months. Improve reliability. Reduce technical debt. Modernize the frontend. Migrate to microservices. Hire senior engineers. Improve developer experience. These documents get presented at leadership meetings, nodded at, and filed away.

They are not strategies. They are wish lists.

Generate a realistic engineering editorial image with monitors, architecture notes, and system artifacts, dark slate and blue palette, 16:9, no text, no clip art, no generic stock office look.

Most of the leadership posts in this phase are me compressing scar tissue into defaults. It also builds on what I learned earlier in “I mass-deleted our internal wiki and started over. Twice..” I am less interested in performative management language now and more interested in the boring mechanisms that keep teams aligned when nobody is in a heroic mood.

Editorial supporting image for the section "What a Strategy Actually Is" in the article "Why your engineering strategy document is probably a wish list, not a strategy". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "Why your engineering strategy document is probably a wish list, not a strategy". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: measured, confident, strategic, scarred enough to sound calm while saying hard things. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

What a Strategy Actually Is

Richard Rumelt’s definition of strategy in “Good Strategy Bad Strategy” is the clearest I have found. A strategy has three components:

1. A diagnosis. What is the specific challenge or constraint the organization faces right now? Not a list of challenges. The one challenge that matters most.
2. A guiding policy. What is the approach for addressing that challenge? This is the part most strategy documents skip entirely. The guiding policy is the one big decision that shapes all subsequent actions.
3. Coherent actions. What specific things will the team do, and equally important, what will the team explicitly not do? Actions must follow from the guiding policy. If they could be swapped out for different actions without changing the strategy, they are not coherent.

Most engineering strategy documents jump straight to actions without a diagnosis or guiding policy. “Migrate to microservices” is an action. What is the diagnosis that makes it necessary? “Our monolith is slowing us down” is not a diagnosis. It is a complaint. A diagnosis would be: “Our deployment frequency has dropped from daily to weekly because three teams share a single deployment pipeline, and any team’s failure blocks all teams.”

The FinanceOps Engineering Strategy

Here is the actual engineering strategy I wrote for FinanceOps last quarter. It is one page.

Diagnosis: Engineering throughput has plateaued despite headcount growth because our platform reliability tax consumes 30% of sprint capacity. Teams spend more time fighting infrastructure fires than building features. The root cause is insufficient investment in platform hardening over the last four quarters.

Guiding policy: For the next two quarters, platform reliability takes priority over new feature velocity. We will accept slower feature delivery in exchange for reducing the reliability tax to under 10% of sprint capacity. This means saying no to feature requests that do not directly improve reliability or reduce operational burden.

Coherent actions:

• Dedicate one full-time engineer to platform hardening for two quarters. This person does not take feature work.
• Implement SLO-based error budgets for all customer-facing services. When the error budget is exhausted, the team stops feature work and focuses on reliability.
• Eliminate the three most frequent sources of production incidents, measured by incident count over the last six months.
• Defer the API v3 migration, the frontend redesign, and the Kafka-to-SQS evaluation until the reliability tax is under 10%.

The last bullet is the most important. A strategy that does not say what you will not do is a wish list. The explicit deferrals are what make a strategy a strategy.

Why Most Strategy Documents Fail

Engineering strategy documents fail for three predictable reasons:

• No diagnosis. The document lists outcomes without identifying the constraint. “Improve developer experience” is an outcome. What is preventing good developer experience right now? If you cannot name it specifically, you do not have a strategy.
• No tradeoffs. The document lists everything the team wants to do without acknowledging that doing one thing means not doing another. A strategy that says “improve reliability AND accelerate feature delivery AND modernize the frontend AND hire more engineers” is not a strategy. It is a to-do list with no prioritization.
• No coherent policy. The actions could be rearranged, swapped, or replaced without changing the document’s meaning. If the actions are not tightly connected to a single guiding policy, they are independent initiatives, not a strategy.

How to Test Your Strategy Document

Before you present an engineering strategy, run these three tests:

1. Can you state the diagnosis in two sentences? If you need a paragraph, you have not identified the core constraint.
2. Does the guiding policy explicitly exclude something the team wants to do? If nothing is deferred or deprioritized, you do not have a strategy.
3. Would someone reading only the actions understand why those actions and not others? If the actions do not obviously follow from the policy, the strategy lacks coherence.

Create a realistic engineering leadership editorial image with a cleaner desk, refined system notes, calmer lighting, 4:3, no cliché teamwork stock imagery.

This is the phase where individual scars finally turned into repeatable operating principles. I cared less about sounding clever and more about leaving behind a system that stayed sane without me in the room. That is how I build portfolio, pipeline-sdk, and dotfiles too.

A strategy that does not say no to something is just a roadmap with a fancy title. Real strategy requires sacrifice, and the sacrifice is what makes it useful.

I rewrite our engineering strategy every two quarters. Not because circumstances change that fast, but because my diagnosis improves as I understand the organization’s constraints more precisely. The first strategy I wrote at FinanceOps was a wish list. I know because it tried to do everything. The current one tries to do one thing well. That is progress.

The distinction between strategy and wish list is falsifiability. A real strategy document includes constraints, tradeoffs, and explicit decisions about what the team will not do. A wish list includes everything the team hopes to accomplish without acknowledging the resource constraints that make prioritization necessary. After rewriting our strategy document with explicit constraints and anti-goals, the team made faster decisions because the boundaries were clear.