Engineering strategy

Engineering strategy is the translation of business goals into technical direction that people can execute and reason about. It also covers the part v3.0 adds to the title: 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). A bad translation produces either a literal feature checklist with no theory of impact or a set of themes too abstract to act on. A good one produces outcomes that tell people what success looks like and leave them free to find a cheaper path than the one first imagined, joined by a thesis that explains why these things were chosen over others. An organisation without a written strategy is run by whoever spoke last. And a strategy is tested by whether an engineer three levels down can say why their work is on the plan, whatever was announced. The examinations test this 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. An outcome is the change wanted in the world; an output is the thing to be built. Outcomes define success and leave the path open. Outputs do neither.
2. Ask what would have to become true. For each goal, the conditions for success organise the work. When reality shifts, derive the work again from those 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. So, usually, has one that everybody agrees with at once.
4. Write it down. Nobody can argue with, delegate against or check a strategy that exists only in conversation. The document is short. It states the diagnosis, the choices and the reasoning, and it is what survives the offsite.
5. Communicate intent and boundaries, not solutions. A strategy has landed when teams can make good local decisions without asking. Getting there takes a campaign: the strategy is repeated relentlessly and shows up in visible decisions about what gets funded and what gets stopped. One announcement does not do it.
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, the manager's job is to say so early. Absorbing it in silence fails the company twice.

Strategy has a large literature and little controlled evidence. The models below are practitioner frameworks with clear provenance, and are graded accordingly.

Outcome versus output practice

This is the habit of framing work as the change wanted in the world instead of the thing to be built. It is the central translation move of this unit and has no single author. A manager can test it by asking of any item on any plan: why is this here? If the answer ties to a business outcome, the translation worked. It has two limits. Some work is legitimately shaped as output, such as a contractual deliverable or a compliance requirement. And an outcome nobody can influence is a wish rather than a goal.

Strategy, vision, and roadmap practice

The distinction follows 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; in other words, a set of choices, including what will not be done. A roadmap is merely the current sequence of bets that follows. Rumelt's account 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 choices matter more than the artifacts, and a brilliant strategy that nobody can recite governs nothing.

Writing the strategy down practice

Will Larson, The Engineering Executive's Primer: Impactful Technical Leadership (2024) sets out this practice for engineering leaders: a short written engineering strategy giving the diagnosis of the current situation, the policies that follow from it, and the concrete actions. It is reviewed on a cadence and revised when the signals call for it, whatever the calendar says. Writing it down makes the strategy resilient, because the outcomes and principles are stable enough to survive change while the means stay free to adapt. It also makes the strategy checkable, since a written choice can be compared with what was in fact funded.

The connecting thesis practice

This is an idea, not a named model, and this unit treats it as what separates a strategy from a wish list. The thesis states why these teams do these things, tying the work of several teams to a few department-level outcomes. Without it you get the bottom-up roadmap, which is team wish lists stapled together. Adding detail to the list never fixes that; the fix is to define the outcomes and derive the list again from them. The same idea sets the altitude of a manager's own goals. A manager of managers sets objectives at the level of department outcomes, and a roll-up of team task lists does not qualify.

The one-page strategy

A short document. It gives the diagnosis in a paragraph, the three to five choices the organisation is making with the reasoning for each, what it is explicitly not doing, and how it will know whether the strategy is working. It is reviewed against reality every quarter. If it will not fit on a page, the choices have not been made.

The why test

From time to time the manager picks an item from the current plan at random and asks the person doing it why it is there. An answer that connects to an outcome in the strategy means the translation is working. "Because it's on the roadmap" means the strategy has not landed, and the fix lies in communication rather than in the roadmap.

Re-deriving on a pivot

When the company changes direction mid-quarter, the strategy is derived again from the new outcomes within days. Work that is now irrelevant is killed explicitly instead of being left to limp on. Work that survives is justified afresh. The reasoning is over-communicated to the teams whose work has just evaporated. Dead roadmap items that go on consuming capacity are the signature of a badly handled pivot.

Strategy as campaign

The written strategy comes up in every planning conversation and is built into decisions about what to fund and what to stop. It is told as a memorable narrative, again and again, until it survives being retold three levels down. The check is whether a team lead can recite it. If they cannot, it has been announced without being 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 and early, and brings options: either 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. It also makes plain that it is contributing to product direction and has no intention of replacing it.

At team scope the manager takes a given strategy and translates it into one team's work, framing outcomes, deriving features from a theory of impact, and making sure every engineer can say why their work matters. At organisational scope the object becomes a department strategy with a connecting thesis. It is communicated as intent and boundaries so that decisions can be made locally, and it is defended against churn and encroachment. The characteristic failure here is the stapled wish list. At executive scope the manager writes the engineering strategy itself, argues for it at the executive table and keeps it alive as the world changes. They also recognise that the organisation, meaning its structure, skills and architecture, is how the strategy gets implemented, which is the subject of SV-6 Organisational design and leading change. The general pattern is described 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
• Works the plan out again when circumstances change instead of 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 the altitude of department outcomes, 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
• Writes an 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 options and evidence developed jointly, avoiding both silence and a silent takeover. exec
• Communicates strategy through decisions about what is funded and what is stopped, and not only through decks. exec
• Keeps the strategy alive between planning cycles, revising it when signals warrant and not by 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, and one that hedges is no strategy at all. The answer lies in structure. Hold the outcomes and principles steady, leave the means free to adapt, and review on a cadence that changes the strategy when evidence demands it and not when nerves fail.

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

Honesty upward versus standing. Telling the executive team that the plan assumes a capability engineering lacks can sound like engineering saying no. Absorbing it in silence sounds like agreement and fails later. What survives is a set of options with their costs, offered early.

Persistence versus responsiveness. A strategy lands through relentless repetition, and a pivot that contradicts last month's repetition costs credibility. The way through is to say plainly that the outcomes have changed and why, and to kill the old work visibly so the contradiction does not 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 lies in making 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 it assumes an engineering organisation that can deliver 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 nobody above the level of individual engineer has platform experience. The chief executive is enthusiastic, and the plan has been socialised with the board as settled.

The pull is to nod along, accept 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 is to declare the plan impossible. That fails in a different way. It makes engineering the department of no, and it is also untrue, because the plan is possible if it is funded and sequenced.

The head of engineering translates in both directions. Downward, they write the engineering strategy that the company plan implies. The diagnosis is an organisation and an architecture built for one product. The choices are stable external interfaces first, a platform team, teams re-cut around capabilities instead of features, and two senior platform hires. The document also says 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 first is the full platform in a year, which requires the re-cut, the hires, and stopping two committed product initiatives. The second is a staged version that opens one capability to a small set of partners in the first year and the rest in the second. The third is the original plan, with engineering's honest assessment that it will miss.

The chief executive chooses the staged version, and the board is told about 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 together with the strategy, not afterwards, because a new strategy laid over the old structure lets the old structure become the real strategist.

They avoid both of the easy options: absorbing an impossible plan and hoping, or refusing it and being proved right in a year. The judgment lies 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, and 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. Putting more detail into a stapled wish list only gives you a more detailed wish list. The fix is to define the outcomes and derive the roadmap again 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 instead of 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, which together form a set of choices that includes what will not be done. A strategy that keeps every option open, or that everyone agrees with at once, has decided nothing.
6. The company strategy assumes capabilities your organisation lacks. What is your responsibility, and what does silence cost? exec
   Answer

   Raise the misalignment explicitly and early, with options: the strategy adjusts or the capability is funded. Silence means absorbing an impossible plan, which 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 (its structure, skills and architecture) is the strategy's implementation. If it is left unchanged, the old structure becomes the real strategist and the new direction stays on paper.

• 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.