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.
Document control
| 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
| 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
1. Context
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
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
| 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
| 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
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
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
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
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
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
| 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
- 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
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.