# Engineering Strategy: [Organisation or engineering group], [YYYY to YYYY]

> Engineering strategy document built on the strategy kernel described by
> Richard P. Rumelt in *Good Strategy Bad Strategy* (2011): a diagnosis of
> the critical challenge, guiding policies that set the approach, and
> coherent actions that carry it out. It adds context, evidence, explicit
> trade-offs, metrics (including the DORA software delivery metrics),
> risks and a review cadence, and links to the technical vision and
> architecture principles. Replace every `[bracketed]` value and every row
> marked *Example*.

<!--
Guidance: How to use this template
- Write the diagnosis first and spend most of your effort there. A
  strategy that skips diagnosis becomes a list of goals, which Rumelt
  calls a hallmark of bad strategy.
- Keep the document short enough to be read: three to five guiding
  policies, each backed by a few coherent actions. If everything is a
  priority, nothing is.
- Section 5 (what we will not do) is where a strategy shows it is real.
  If no one objects to it, it is probably not saying anything.
- The worked example is a fictional product engineering group of about
  120 engineers. Delete it once your rows exist.
-->

## Document control

<!-- Guidance: Identify the strategy, its time horizon and who is accountable. Strategies without a named owner and a review date are rarely revisited. -->

| Field | Value |
|---|---|
| Document ID | [ENG-STRAT-001] |
| Scope | [Engineering group, product line or whole technology organisation] |
| Horizon | [YYYY-MM to YYYY-MM, typically 12 to 24 months] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@vp-engineering] |
| Contributors | [@principal-engineers, @engineering-managers, @product-lead] |
| Approvers / reviewers | [@cto, @cpo, @cfo-delegate] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Chief technology officer | [@name] | [Approved / Approved with comments / Rejected] | YYYY-MM-DD |
| Chief product officer | [@name] | [Decision] | YYYY-MM-DD |
| Finance partner | [@name] | [Decision] | YYYY-MM-DD |
| Staff and principal engineer group | [@names] | [Endorsed / Comments] | YYYY-MM-DD |

## Revision history

<!-- Guidance: Record when the diagnosis changed, not only when wording changed. A changed diagnosis usually means policies and actions must change too. -->

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft of diagnosis and policies |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Evidence added from incident review and developer survey |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved by the leadership team |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Half-year review; action CA-05 closed, CA-07 added |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Context](#1-context)
2. [Diagnosis](#2-diagnosis)
3. [Guiding policies](#3-guiding-policies)
4. [Coherent actions](#4-coherent-actions)
5. [Trade-offs and what we will not do](#5-trade-offs-and-what-we-will-not-do)
6. [Metrics](#6-metrics)
7. [Risks and assumptions](#7-risks-and-assumptions)
8. [Review cadence and decision log](#8-review-cadence-and-decision-log)
9. [Links to vision, principles and plans](#9-links-to-vision-principles-and-plans)
10. [Communication and adoption](#10-communication-and-adoption)
11. [Glossary and references](#11-glossary-and-references)

## 1. Context

<!-- Guidance: Give readers the facts they need to judge the diagnosis: what the business is trying to achieve, what engineering looks like today, and what constraints are fixed. Keep opinions for section 2. -->

### 1.1 Business strategy and goals

[Summarise the business strategy this engineering strategy serves, in
three to five sentences, and link the source document. For example: the
company aims to grow recurring revenue by expanding into two new markets
and moving mid-sized customers to self-service, while holding
engineering cost flat as a share of revenue.]

| Business goal | Source | Engineering relevance |
|---|---|---|
| *Example:* Enter two new markets by YYYY-QN | Company strategy YYYY | Localisation, data residency, regional deployments |
| *Example:* Self-service onboarding for mid-sized customers | Product strategy | Product velocity, reliability of signup flows |
| *Example:* Engineering cost flat as a share of revenue | Finance plan | Productivity, cloud cost |
| [Goal] | [Source] | [Relevance] |

### 1.2 Current state of engineering

| Aspect | Current state |
|---|---|
| Teams and size | [*Example:* 14 product teams, 2 platform teams, about 120 engineers] |
| Architecture | [*Example:* one large monolith plus 25 services; shared database] |
| Delivery | [*Example:* weekly release train for the monolith; services deploy independently] |
| Operations | [*Example:* follow-the-sun on-call for tier 1 services only] |
| Technology landscape | [Link to Technology Radar (`architecture/tech-radar`)] |
| Known debt | [Link to Technical Debt Register (`architecture/tech-debt-register`)] |

### 1.3 Fixed constraints

- [*Example:* headcount growth limited to 10 percent in the horizon.]
- [*Example:* the cloud provider contract runs until YYYY-MM.]
- [*Example:* regulatory deadline for data residency in market B on
  YYYY-MM-DD.]

## 2. Diagnosis

<!-- Guidance: Name the critical challenge, explain why it is hard, and show evidence. Identify the crux: the part of the problem that, if solved, unlocks most of the rest. Avoid listing every problem; choose. -->

### 2.1 The challenge

[One paragraph. *Example:* Our ability to deliver the business goals is
limited less by the number of engineers than by coupling. Most product
changes touch the monolith and its shared database, so teams queue
behind one release train, incidents in one area affect all customers,
and adding engineers adds coordination rather than throughput. At the
same time, entering new markets requires regional deployments that the
current architecture cannot support without duplicating the whole
system.]

### 2.2 Evidence

| ID | Observation | Evidence | Source and date |
|---|---|---|---|
| EV-01 *(Example)* | Most change lead time is waiting, not working | Median change lead time [N] days, of which [M] days waiting for the release train | Delivery metrics, YYYY-QN |
| EV-02 *(Example)* | Incidents cluster in the shared database | [N] of [M] severity 1 incidents in the last year traced to shared schema changes | Postmortems (`dev/postmortem`) |
| EV-03 *(Example)* | Engineers report coordination as the top blocker | Developer survey: [percentage] rank cross-team coordination first | Survey YYYY-MM |
| EV-04 *(Example)* | Unplanned work is high | Deployment rework rate [percentage] | Delivery metrics, YYYY-QN |
| EV-05 *(Example)* | Regional deployment is not possible today | Architecture review finding AR-[nn] | Architecture review YYYY-MM-DD |
| [EV-nn] | [Observation] | [Data] | [Source] |

### 2.3 The crux

[One or two sentences naming the pivot point. *Example:* The crux is the
shared database: as long as teams share one schema, they cannot release,
scale or deploy regionally on their own.]

### 2.4 What the diagnosis is not

[State the explanations you considered and rejected, with the reason.
*Example:* we considered "not enough engineers" and rejected it because
EV-01 and EV-03 show the constraint is waiting and coordination, which
more engineers would worsen.]

## 3. Guiding policies

<!-- Guidance: A guiding policy is the chosen method of attack: it steers effort and excludes options. It is neither a goal ("be faster") nor an action ("hire an SRE"). Test each policy by asking what it forbids. -->

| ID | Guiding policy | Addresses | What it rules out |
|---|---|---|---|
| GP-01 *(Example)* | Decouple by data ownership: every domain owns its data and exposes it only through interfaces | Crux, EV-02 | New features that read or write another domain's tables |
| GP-02 *(Example)* | Make independent release the default path; the release train becomes the exception | EV-01, EV-04 | New code paths that can only ship with the monolith release |
| GP-03 *(Example)* | Concentrate platform investment on the paved road that teams need to deploy regionally | EV-05, regional market goal | Bespoke per-team infrastructure; new platforms outside the paved road |
| GP-04 *(Example)* | Measure delivery outcomes, not activity | EV-01, EV-04 | Targets on story points, lines of code or individual output |
| [GP-nn] | [Policy] | [EV IDs or crux] | [What it forbids] |

### 3.1 How the policies fit together

[Explain in a short paragraph why these policies reinforce each other.
*Example:* GP-01 creates the boundaries that make GP-02 possible; GP-03
gives teams the means to operate independently once they are decoupled;
GP-04 tells us whether the combination is working.]

## 4. Coherent actions

<!-- Guidance: Actions implement the policies and must reinforce each other. Give each one an owner, dates and a deliverable. Drop any action that does not follow from a policy, however attractive. -->

| ID | Action | Implements | Owner | Start | End | Deliverable | Status |
|---|---|---|---|---|---|---|---|
| CA-01 *(Example)* | Define domain boundaries and assign data ownership for the top 10 tables by change frequency | GP-01 | [@principal-architect] | YYYY-MM | YYYY-MM | Context map and ownership table | [Not started / In progress / Done] |
| CA-02 *(Example)* | Extract billing and identity domains from the shared database | GP-01 | [@em-billing], [@em-identity] | YYYY-MM | YYYY-MM | Two domains with own stores | [Status] |
| CA-03 *(Example)* | Give every service an independent deployment pipeline on the paved road | GP-02, GP-03 | [@platform-lead] | YYYY-MM | YYYY-MM | Pipeline template, adoption report | [Status] |
| CA-04 *(Example)* | Introduce feature flags and progressive delivery for the monolith | GP-02 | [@em-core] | YYYY-MM | YYYY-MM | Flag service, rollout runbook | [Status] |
| CA-05 *(Example)* | Deliver a regional deployment capability on the platform | GP-03 | [@platform-lead] | YYYY-MM | YYYY-MM | Second region live for two services | [Status] |
| CA-06 *(Example)* | Publish delivery metrics per team and review them monthly | GP-04 | [@vp-engineering] | YYYY-MM | YYYY-MM | Dashboard, review ritual | [Status] |
| CA-07 *(Example)* | Fund debt work on the shared schema at [20 percent] of capacity in affected teams | GP-01 | [@engineering-managers] | YYYY-MM | YYYY-MM | Debt items closed | [Status] |
| [CA-nn] | [Action] | [GP IDs] | [@owner] | YYYY-MM | YYYY-MM | [Deliverable] | [Status] |

### 4.1 Sequencing

```mermaid
flowchart LR
  ca1[CA-01 Domain boundaries] --> ca2[CA-02 Extract billing and identity]
  ca3[CA-03 Independent pipelines] --> ca2
  ca3 --> ca5[CA-05 Regional deployment]
  ca2 --> ca5
  ca4[CA-04 Flags and progressive delivery] --> ca6[CA-06 Metrics reviews]
  ca7[CA-07 Funded schema debt] --> ca2
```

The diagram shows dependencies: domain boundaries and pipelines come
before extraction, and regional deployment needs both extracted domains
and the paved road.

### 4.2 Resource commitment

| Action | Teams involved | Capacity committed | Funding source |
|---|---|---|---|
| CA-02 *(Example)* | Billing, Identity | [2 teams for 2 quarters] | Product roadmap allocation |
| CA-05 *(Example)* | Platform | [60 percent of platform capacity] | Platform budget |
| [CA-nn] | [Teams] | [Capacity] | [Source] |

## 5. Trade-offs and what we will not do

<!-- Guidance: Say what you are giving up. Name concrete initiatives, technologies or requests that will be declined or deferred because of this strategy, and who agreed. -->

### 5.1 Trade-offs accepted

| ID | We choose | Over | Consequence we accept |
|---|---|---|---|
| TO-01 *(Example)* | Decoupling the data layer | Shipping more features in the next two quarters | Feature throughput of affected teams drops by an estimated [percentage] during CA-02 |
| TO-02 *(Example)* | One paved road | Team freedom to choose any infrastructure | Some teams migrate off tools they prefer |
| TO-03 *(Example)* | Regional deployment for two services first | A full regional copy of the product | Market B launches with a reduced feature set |
| [TO-nn] | [Choice] | [Alternative] | [Consequence] |

### 5.2 What we will not do

- [*Example:* We will not start a full rewrite of the monolith; we
  extract domains incrementally.]
- [*Example:* We will not adopt a second cloud provider during this
  horizon.]
- [*Example:* We will not set targets on individual developer output
  metrics.]
- [*Example:* We will not add new services that share the monolith
  database.]

## 6. Metrics

<!-- Guidance: Choose a few measures that tell you whether the guiding policies are working. Pair each lagging outcome with a leading indicator you can move within weeks. Never use these metrics to rank individuals. -->

### 6.1 Software delivery performance

DORA, the research programme behind the State of DevOps reports,
describes five software delivery performance metrics, grouped as
throughput and instability. Use the definitions published at dora.dev
and record any local adaptation.

| ID | Metric | Group | Baseline | Target | Policy |
|---|---|---|---|---|---|
| MET-01 | Change lead time | Throughput | [*Example:* median N days] | [Target] | GP-02 |
| MET-02 | Deployment frequency | Throughput | [Baseline] | [Target] | GP-02 |
| MET-03 | Failed deployment recovery time | Throughput | [Baseline] | [Target] | GP-02, GP-03 |
| MET-04 | Change fail rate | Instability | [Baseline] | [Target] | GP-01 |
| MET-05 | Deployment rework rate | Instability | [Baseline] | [Target] | GP-01, GP-02 |

The 2025 DORA report, *State of AI-assisted Software Development*
(published September 2025), describes seven team profiles derived from
cluster analysis that combine delivery performance with team well-being
and product outcomes, instead of presenting the earlier elite, high,
medium and low performance tiers. If you use the profiles, use them to
diagnose a team's situation, not as a ranking, and check the current
report at dora.dev for their names and definitions.

### 6.2 Strategy-specific indicators

| ID | Indicator | Type | Baseline | Target | Policy or action |
|---|---|---|---|---|---|
| MET-06 *(Example)* | Share of changes deployed outside the release train | Leading | [percentage] | [percentage] | GP-02, CA-03 |
| MET-07 *(Example)* | Tables with more than one writing domain | Leading | [N] | 0 for the top 10 | GP-01, CA-01, CA-02 |
| MET-08 *(Example)* | Services deployable to the second region | Leading | 0 | [N] | GP-03, CA-05 |
| MET-09 *(Example)* | Developer survey: coordination as top blocker | Lagging | [percentage] | [percentage] | GP-01, GP-02 |
| MET-10 *(Example)* | Cloud cost as a share of revenue | Guardrail | [percentage] | Not above baseline | Constraint 1.3 |
| [MET-nn] | [Indicator] | [Leading / Lagging / Guardrail] | [Baseline] | [Target] | [GP or CA IDs] |

## 7. Risks and assumptions

<!-- Guidance: List the beliefs that, if wrong, would invalidate the diagnosis or the policies. Assign an owner to watch each one and say what you would do if it turned out false. -->

### 7.1 Assumptions

| ID | Assumption | How we will know it is wrong | Owner |
|---|---|---|---|
| AS-01 *(Example)* | Data coupling, not skills, is the main constraint | MET-06 rises but MET-01 does not improve | [@vp-engineering] |
| AS-02 *(Example)* | Market B requires regional hosting by YYYY-MM-DD | Legal review concludes otherwise | [@legal-partner] |
| [AS-nn] | [Assumption] | [Signal] | [@owner] |

### 7.2 Risks

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| RSK-01 *(Example)* | Product pressure pulls teams off CA-02 | High | High | Capacity commitment in 4.2 agreed with product leadership; reviewed monthly | [@cpo] |
| RSK-02 *(Example)* | Extraction introduces data consistency defects | Medium | High | Dual-write period with reconciliation checks | [@principal-architect] |
| RSK-03 *(Example)* | Platform team becomes a bottleneck for CA-03 and CA-05 | Medium | Medium | Self-service templates first; embedded platform engineers | [@platform-lead] |
| [RSK-nn] | [Risk] | [Low / Medium / High] | [Low / Medium / High] | [Mitigation] | [@owner] |

## 8. Review cadence and decision log

<!-- Guidance: Decide when the strategy is checked and when it is rewritten. Review progress often; revisit the diagnosis less often, but always when the evidence changes. -->

### 8.1 Cadence

| Review | Frequency | Participants | Output |
|---|---|---|---|
| Action progress | Monthly | Action owners, VP engineering | Status updates in section 4 |
| Metrics review | Monthly | Engineering leadership | Trends for section 6, escalations |
| Strategy review | Every six months | Leadership team, principal engineers | Revised policies and actions, new version |
| Diagnosis refresh | Annually, or when an assumption in 7.1 fails | Leadership team | New diagnosis or confirmation |

### 8.2 Decision log

| ID | Date | Decision | Reason | Effect on strategy |
|---|---|---|---|---|
| DEC-01 *(Example)* | YYYY-MM-DD | Defer CA-05 by one quarter | Market B launch moved | TO-03 unchanged; MET-08 target date moved |
| [DEC-nn] | YYYY-MM-DD | [Decision] | [Reason] | [Effect] |

## 9. Links to vision, principles and plans

<!-- Guidance: Show how this strategy sits between the long-term technical vision and the day-to-day plans. The vision says where we want to be; the strategy says how we will overcome what stands in the way. -->

| Artefact | Relationship to this strategy | Location |
|---|---|---|
| Technical vision | Describes the target state in [3 to 5] years; this strategy addresses the obstacles to it | [Link] |
| Architecture principles | Constrain how actions are designed; GP-01 relies on the data ownership principle | Architecture Principles Catalogue (`architecture/architecture-principles`) |
| Reference architecture | The paved road in GP-03 is specified there | Reference Architecture (`architecture/reference-architecture`) |
| Architecture roadmap | Places CA-02 and CA-05 on the enterprise roadmap | Architecture Roadmap and Transition Architectures (`architecture/architecture-roadmap-transition`) |
| OKRs | Quarterly key results derived from MET-01 to MET-10 | OKRs (`business/okr`) |
| RFCs and ADRs | Detailed decisions for each action | RFC (`dev/rfc`), ADR (`architecture/adr-full`) |
| Technology choices | Technology selection for new building blocks | Technology Selection (`architecture/technology-selection`) |
| Debt backlog | Work funded by CA-07 | Technical Debt Register (`architecture/tech-debt-register`) |

## 10. Communication and adoption

<!-- Guidance: A strategy only works if engineers can explain it. Plan how it will be shared, how teams translate it into their own plans, and how feedback reaches the owner. -->

- **Launch**: present the diagnosis, policies and the "will not do" list
  at an all-hands; publish this document where every engineer can read
  and comment on it.
- **Translation**: each team writes [one paragraph] on how the guiding
  policies change its roadmap for the next two quarters.
- **Decision test**: teams use the guiding policies to settle design
  disagreements; unresolved conflicts go to the decision log.
- **Feedback**: comments and challenges go to [channel or forum]; the
  owner answers them before each strategy review.

### 10.1 Summary for one slide

| Kernel element | One-line summary |
|---|---|
| Diagnosis | [*Example:* Shared data couples all teams; coordination, not headcount, limits delivery] |
| Guiding policies | [*Example:* Own your data; release independently; one paved road; measure outcomes] |
| Coherent actions | [*Example:* Draw boundaries, extract two domains, independent pipelines, second region, monthly metrics] |

## 11. Glossary and references

<!-- Guidance: Define the terms in the way this document uses them and cite the sources the method relies on. -->

### 11.1 Glossary

| Term | Meaning in this document |
|---|---|
| Strategy kernel | The three linked parts of a strategy: diagnosis, guiding policy and coherent action |
| Diagnosis | A judgement about what is really going on and which part of it matters most, simple enough to act on |
| Crux | The part of the challenge that is both critical and addressable |
| Guiding policy | The general method chosen for tackling the challenge, which narrows the options teams consider |
| Coherent actions | Mutually reinforcing steps, with people and money attached, that put the guiding policies into practice |
| Leading indicator | A measure that moves early and predicts an outcome |
| Guardrail metric | A measure that must not get worse while pursuing the targets |

### 11.2 References

- Richard P. Rumelt, *Good Strategy Bad Strategy: The Difference and Why
  It Matters*, Crown Business, 2011: the strategy kernel.
- DORA, software delivery performance metrics, dora.dev (guide page
  updated January 2026); DORA, *State of AI-assisted Software
  Development* (2025 report, September 2025).
- Related templates: Architecture Principles Catalogue
  (`architecture/architecture-principles`), Technology Radar
  (`architecture/tech-radar`), Technical Debt Register
  (`architecture/tech-debt-register`), OKRs (`business/okr`), RFC
  (`dev/rfc`), Reference Architecture (`architecture/reference-architecture`).

## Standard and licence note

Structure aligned with the strategy kernel (diagnosis, guiding policy,
coherent actions) described by Richard P. Rumelt in *Good Strategy Bad
Strategy* (Crown Business, 2011), and with the software delivery
performance metrics published by DORA at dora.dev. The book is
copyrighted; this template quotes none of it, and all wording,
structure beyond the three kernel elements, and examples are original.
Check the current DORA guidance and report for metric definitions.
Template licence: MIT.