Engineering strategy

Engineering strategy is the translation of business goals into technical direction that people can execute and reason about, and — the part v3.0 adds to the title — the act of writing it down so that it can be argued with, delegated against and checked. Strategy arrives in business language: grow revenue, reduce churn, enter a segment. Done badly, the translation becomes either a literal feature checklist with no theory of impact or a set of themes too abstract to act on. Done well, it becomes outcomes that tell people what success looks like and free them to find a cheaper path than the one first imagined, with a connecting thesis that says why these things and not others. It matters because an organisation without a written strategy is run by whoever spoke last, and because the test of a strategy is not whether it was announced but whether an engineer three levels down can say why their work is on the plan. The examinations test it through the roadmap that "doesn't add up to a strategy", the pivot that leaves dead work limping on, and the company plan that assumes capabilities engineering does not have.

1. Frame work as outcomes, not outputs. The change wanted in the world, not the thing to be built. Outcomes define success and free the path; outputs do neither.
2. Ask what would have to become true. For each goal, the conditions for success organise the work. When reality shifts, re-derive the work from the conditions instead of defending the list.
3. A strategy is a diagnosis and a set of choices, including what you will not do. A "strategy" that keeps every option open has decided nothing, and one that everybody instantly agrees with has usually decided nothing either.
4. Write it down. A strategy that exists in conversation cannot be argued with, delegated against or checked. The document is short, states the diagnosis, the choices and the reasoning, and is the thing that survives the offsite.
5. Communicate intent and boundaries, not solutions. A strategy has landed when teams can make good local decisions without asking. It is a campaign, repeated relentlessly and embedded in visible decisions — what gets funded, what gets stopped — not an announcement.
6. Translation runs both ways. Engineering strategy derives from company strategy, and engineering reality informs company strategy. When the company's plan assumes a capability the organisation does not have, saying so early is the job; absorbing it silently fails the company twice.

Strategy is a field with a large literature and thin controlled evidence; the models below are practitioner frameworks with clear provenance, graded as such.

Outcome versus output practice

Framing work as the change wanted in the world rather than the thing to be built. The core translation move of this unit, with no single author. Its test is the question a manager can put to any item on any plan: why is this here? If the answer ties to a business outcome, the translation worked. Its limit is that some work is legitimately output-shaped — a contractual deliverable, a compliance requirement — and that an outcome nobody can influence is a wish, not a goal.

Strategy, vision, and roadmap practice

The distinction, after Richard P. Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters (2011): a vision names the destination and why it matters; a strategy is a diagnosis of the situation, a guiding policy that responds to it, and a coherent set of actions — a set of choices, including what will not be done; a roadmap is merely the current sequence of bets that follows. Rumelt's diagnosis of bad strategy — fluff, failure to face the problem, goals mistaken for strategy, and a wish list of objectives — is the most useful checklist a manager has for reviewing a strategy document. The artifacts matter less than the choices; a brilliant strategy nobody can recite governs nothing.

Writing the strategy down practice

The practice, set out for engineering leaders in Will Larson, The Engineering Executive's Primer: Impactful Technical Leadership (2024), of producing a short written engineering strategy: the diagnosis of the current situation, the policies that follow, and the concrete actions, reviewed on a cadence and revised when the signals say so rather than when the calendar does. The written form is what makes a strategy resilient — outcomes and principles stable enough to survive change, with the means free to adapt — and what makes it checkable, because a written choice can be compared with what was actually funded.

The connecting thesis practice

Not a named model but the idea this unit treats as the difference between a strategy and a wish list: the statement of why these teams do these things, tying several teams' work to a few department-level outcomes. Its absence is the bottom-up roadmap — team wish lists stapled together — and the fix is never more detail in the list; it is defining the outcomes and re-deriving the list from them. The same idea sets the altitude of a manager's own goals: a manager of managers' objectives sit at department outcomes, not at a roll-up of team task lists.

The one-page strategy

A short document: the diagnosis in a paragraph, the three to five choices the organisation is making and the reasoning for each, what it is explicitly not doing, and how it will know whether the strategy is working. Reviewed quarterly against reality. If it cannot be written on a page, the choices have not been made.

The why test

At intervals, the manager picks an item from the current plan at random and asks the person doing it why it is there. If the answer connects to an outcome in the strategy, the translation is working; if it is "because it's on the roadmap", the strategy has not landed and the fix is communication, not the roadmap.

Re-deriving on a pivot

When the company changes direction mid-quarter, the strategy is re-derived from the new outcomes within days: what is now irrelevant is killed explicitly rather than left to limp on, what survives is re-justified, and the reasoning is over-communicated to the teams whose work just evaporated. Dead roadmap items that keep consuming capacity are the signature failure of a pivot handled badly.

Strategy as campaign

The written strategy is repeated in every planning conversation, embedded in funding and stopping decisions, and told as a memorable narrative until it survives retelling three levels down. The check is whether a team lead can recite it; if not, it has been announced, not communicated.

Surfacing the capability gap

When a company plan assumes something engineering cannot yet do — a scale, a security posture, a platform — the manager says so explicitly, early, with options: the strategy adjusts, or the capability is funded. Where the company has no clear product strategy, engineering brings options and evidence to force the conversation, while being explicit that it is contributing to product direction, not replacing it.

At team scope the object is a given strategy translated into one team's work: outcomes framed, features derived from a theory of impact, every engineer able to say why their work matters. At organisational scope the object becomes a department strategy with a connecting thesis, communicated as intent and boundaries so that decisions decentralise, and defended against churn and encroachment; the failure is the stapled wish list. At executive scope the manager authors the engineering strategy itself, argues it at the executive table, keeps it alive as the world changes, and recognises that the organisation — its structure, skills and architecture — is the strategy's implementation, which is SV-6 Organisational design and leading change. The pattern is in How Judgment Scales.

• Frames the team's work as outcomes and derives features from a theory of impact. team
• Ensures every engineer can say why their current work matters to the business. team
• Re-derives the plan when circumstances change rather than defending the original list. team
• Failure mode — strategy as a literal feature list. team
• Failure mode — themes too abstract to act on. team
• Failure mode — building things because they are on the roadmap. team
• Writes a department strategy with a connecting thesis that a team lead can recite. org
• Sets objectives at department-outcome altitude, not as a roll-up of team task lists. org
• Communicates intent, priorities and constraints so that teams decide locally without escalating. org
• Re-derives fast on a pivot, kills newly irrelevant work explicitly, and over-communicates the reasoning. org
• Failure mode — stapling team wish lists together and calling it strategy. org
• Failure mode — broadcasting the strategy once and assuming it landed. org
• Failure mode — letting dead roadmap items keep consuming capacity after a pivot. org
• Authors a written engineering strategy — diagnosis, choices, what it is not doing — and argues it at the executive table. exec
• Treats organisational design, skills and architecture as the strategy's implementation, and realigns them together. exec
• Tells the company what engineering cannot yet do before the plan depends on it, and forces the honest conversation. exec
• Fills a strategy vacuum with co-created options and evidence rather than silence or a silent takeover. exec
• Communicates strategy through decisions — what is funded, what is stopped — not only through decks. exec
• Keeps the strategy alive between planning cycles, revising on signals rather than on the calendar. exec
• Failure mode — new strategy, old organisation chart. exec
• Failure mode — nodding along to a company plan the organisation cannot execute. exec
• Failure mode — treating the absence of product strategy as someone else's problem. exec
• Failure mode — a strategy that exists only in the offsite slides. exec
• Failure mode — a strategy that keeps every option open in the name of flexibility. exec

Commitment versus flexibility. A strategy that commits will be wrong about some things; one that hedges is not a strategy. The resolution is structure: outcomes and principles held stable, means free to adapt, and a review cadence that changes the strategy on evidence rather than on nerves.

Direction versus autonomy. The more a strategy prescribes, the less teams can decide locally; the less it prescribes, the more they diverge. The line is intent and boundaries — the why, the priorities, what is not being done — with solutions left to teams.

Honesty upward versus standing. Telling the executive team that the plan assumes a capability engineering lacks can read as engineering saying no. Absorbing it silently reads as agreement and fails later. The framing that survives is options with costs, offered early.

Persistence versus responsiveness. Repeating the strategy relentlessly is how it lands, and a pivot that contradicts last month's repetition costs credibility. The resolution is to be explicit that the outcomes have changed and why, and to kill the old work visibly rather than let the contradiction stand.

Engineering preference versus business outcome. The best technical direction is not always the one the business needs, and the examinations consistently favour the option that ties the decision to an outcome. The judgment is in arguing engineering's case in the business's terms, and in accepting the answer when it goes the other way.

A head of engineering reads the company's new annual plan a week before it goes to the board. It commits the company to a platform strategy — opening the product to third parties within a year — and the plan assumes an engineering organisation that can do this. The organisation cannot. It was built around a single product: the architecture has no stable external interfaces, the teams are organised by product feature, and there is nobody with platform experience above the level of individual engineer. The chief executive is enthusiastic, and the plan has been socialised with the board as settled.

The pull is to nod along, take the plan as given, and try. That fails the company twice: the year will be lost, and the board will have been told something untrue. The opposite pull, to say that the plan is impossible, fails differently: it makes engineering the department of no, and it is not true either — the plan is possible if it is funded and sequenced.

The head of engineering does the translation both ways. Downward, they write the engineering strategy the company plan implies: the diagnosis (an organisation and an architecture built for one product), the choices (stable external interfaces first, a platform team, teams re-cut around capabilities rather than features, two senior platform hires), and what engineering will not do this year in order to do this. Upward, they take that document to the chief executive before the board meeting, with three options: the full platform in a year, which requires the re-cut, the hires, and stopping two committed product initiatives; a staged version that opens one capability to a small set of partners in the first year and the rest in the second; or the original plan, with engineering's honest assessment that it will miss.

The chief executive chooses the staged version and the board is told a plan the organisation can execute, with checkpoints. The head of engineering then treats the organisation as the implementation: the team re-cut and the platform team are announced with the strategy and not after it, because a new strategy over the old structure makes the old structure the real strategist.

What they do not do is either of the easy things: absorb an impossible plan and hope, or refuse it and be right in a year. The judgment is in bringing the honest picture early, with options, in the company's terms.

• SV-2 Communicating and partnering across functions — arguing the strategy to executives and the board, and disagreeing on the merits.
• SV-3 Roadmapping — the roadmap as the current sequence of bets that follows from the strategy.
• SV-6 Organisational design and leading change — the organisation as the strategy's implementation; realigning structure with direction.
• DE-1 Prioritisation under constraint — the portfolio the strategy governs, and stopping what no longer fits.
• TJ-1 Evaluating architectural decisions and their organisational consequences — the technical strategy as the architectural form of the same choices.

1. What question tests whether a goal has been translated well?
   Answer

   Pick any item on the plan and ask the person doing it why it is there. If the answer ties to a business outcome, the translation worked; if it is "because it's on the roadmap", the strategy has not landed.
2. What is the difference between an outcome and an output, and why does the difference free the path?
   Answer

   An outcome is the change wanted in the world; an output is the thing to be built. Stating the outcome tells people what success looks like and lets them find a cheaper way than the one first imagined.
3. The executive team says your department roadmap "doesn't add up to a strategy". What is missing, and why does more detail not fix it? org
   Answer

   A connecting thesis: a few department-level outcomes that explain why these teams do these things. More detail in a stapled wish list adds detail to the wish list. The fix is to define the outcomes and re-derive the roadmap from them.
4. Half your roadmap became irrelevant with a mid-quarter pivot. What is the discipline? org
   Answer

   Re-derive quickly from the new outcomes, kill the newly irrelevant work explicitly rather than letting it limp on, and over-communicate the reasoning to the teams whose work evaporated.
5. Name Rumelt's three parts of a good strategy, and the sign that a "strategy" has decided nothing.
   Answer

   A diagnosis, a guiding policy, and coherent action — a set of choices including what will not be done. A strategy that keeps every option open, or that everyone instantly agrees with, has decided nothing.
6. The company strategy assumes capabilities your organisation lacks. What is your responsibility, and what does silence cost? exec
   Answer

   Surface the misalignment explicitly and early, with options: the strategy adjusts or the capability is funded. Silence absorbs an impossible plan and fails the company twice — the year is lost and the board was told something untrue.
7. Why is announcing a new strategy over the old organisation chart a failure of strategy rather than of execution? exec
   Answer

   Because the organisation — structure, skills, architecture — is the strategy's implementation. Left unchanged, the old structure becomes the real strategist, and the new direction is a document.

• Richard P. Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters (2011) — diagnosis, guiding policy, coherent action; the anatomy of bad strategy.
• Will Larson, The Engineering Executive's Primer: Impactful Technical Leadership (2024) — writing an engineering strategy and keeping it alive.