How is a strategy doc different from an OKR document?

An OKR document is a roadmap structured as objectives and key results. The strategy is upstream — it explains why these particular OKRs are the right ones given the situation, with alternatives explicitly considered and rejected. The OKR document is execution; the strategy is the argument. Most teams skip the strategy and write OKRs only; the OKRs drift over multi-quarter horizons because each quarterly OKR cycle is locally optimized rather than serving a coherent multi-quarter argument.

Should every engineering manager write strategy docs?

Line-managers (M1) typically don't write strategy docs at the multi-quarter scope; they execute against the strategy from above. Senior-managers (M2) sometimes write team-level strategy docs at the 6-month scope. M3+ definitely write strategy docs at the multi-quarter, multi-team scope. The pattern: strategy is an M3-and-above craft because the multi-team scope is what makes the constraints-on-choices framing useful. A line-manager's 'strategy' is usually a roadmap with strategic-sounding language.

How often should I refresh the engineering strategy?

Every 6 months is the modal cadence at most modern-tech-company orgs. Some companies refresh annually; some quarterly. The right cadence depends on the rate of change in the team's environment. A team navigating rapid market change or platform-strategy shifts may need 3-month refreshes; a team in a stable domain may need 12-month refreshes. The strategy should not be refreshed so often that it becomes performative; it should not be left so long that it becomes irrelevant.

How do I write the diagnosis section honestly?

The diagnosis is the hardest section to write because it requires honesty about the team's situation that may be uncomfortable — production-metric trends that are bad, hiring-funnel signals that are negative, retention concerns. Rumelt is explicit that most strategy documents fail at this step. The discipline: write the diagnosis first, share it with peers and your director before writing the policy and actions, take feedback that the diagnosis is incomplete or sanitized. The strategy doc that paper-overs uncomfortable diagnostic facts produces strategy that doesn't address the actual situation.

Should the strategy doc be shared with the team or kept at leadership level?

Shared with the senior-managers and line-managers underneath; sometimes shared with the broader team in summarized form. The full document is leadership-level (director, M3s, senior-managers); the summary or key sections are appropriate for broader sharing. The trade-off: full transparency builds team alignment and engagement, but some strategic content (acquisition discussions, leadership transitions, sensitive customer-specific work) can't be broadly shared. Pragmatic Engineer's coverage of how FAANG companies handle this varies by company; Larson's writing on transparency norms applies.

How do I get started writing my first strategy doc?

Read Rumelt's Good Strategy / Bad Strategy (full book, 30–40 hours) and Larson's An Elegant Puzzle 'Engineering strategy' chapter (1 hour). Then read 3–5 strategy docs that other engineering leaders have shared publicly (Larson has linked some on lethain.com; Stripe Press has some examples). Then write the diagnosis section first, share with peers, iterate. Write the policy and actions only after the diagnosis lands well. Total time: 20–40 hours for a first real strategy doc, less for subsequent ones.

What's the relationship between engineering strategy and product strategy?

The engineering strategy is downstream of the product strategy at most companies — the engineering strategy answers 'given the product strategy, what is the engineering organization's optimal posture and set of bets.' At companies where engineering is unusually central (developer-API platforms like Stripe, Databricks; ML-platform companies; AI labs), the engineering strategy is more upstream and influences the product strategy directly. Cross-functional alignment with PM and design at the strategy-document level is required at every company; the strategy doc surfaces disagreement before execution.

Engineering Manager Hub

Strategy and Roadmapping for Engineering Managers (2026 Field Guide)

By Blake Crosley · Last verified 2026-04-30

In short

Engineering strategy and roadmapping is the M3-and-above craft. Larson's 'Good engineering strategy is boring' essay (lethain.com) and the related An Elegant Puzzle 'Engineering strategy' chapter are the canonical practitioner references. Richard Rumelt's Good Strategy / Bad Strategy (Crown Business, 2011) is the underlying theory. The structural distinction the literature names: a strategy is a written argument about what to do given a situation, with alternatives named and rejected; a roadmap is a time-ordered list of features. Most documents that claim to be strategies are actually roadmaps. The M3+ deliverable that produces leverage is the strategy doc; the senior-managers and line-managers underneath produce the roadmap.

Key takeaways

Larson's 'Good engineering strategy is boring' (lethain.com) and the related An Elegant Puzzle 'Engineering strategy' chapter are the canonical practitioner references. Richard Rumelt's Good Strategy / Bad Strategy (Crown Business, 2011) is the underlying theory.
Rumelt's framework: a strategy has three components — diagnosis (what is the situation), guiding policy (what we optimize for), coherent actions (the 3–7 specific things we will do). Most documents that claim to be strategies skip the diagnosis and jump to action.
The structural distinction Larson names: a strategy is a written argument about what to do given a situation; a roadmap is a time-ordered list of features. Most engineering 'strategy' documents are actually roadmaps. The strategy is upstream; the roadmap is the M2-and-line-manager execution downstream.
Larson's most-cited line on this: 'a strategy that does not refute alternative strategies is not a strategy.' Rumelt's complement: 'most strategy is bullshit because it doesn't actually constrain choices.' Both name the same failure mode.
The engineering-strategy artifact is the primary M3+ deliverable. Typically 2–6 pages, refreshed every 6 months at most modern-tech-company orgs. Shared with the director, peer M3s, and senior-managers underneath.
Strategy at director+ tier requires explicit cross-functional alignment with PM, design, and senior leadership. The strategy doc is the artifact that surfaces disagreement before execution rather than during.
The roadmap is downstream of the strategy. M2s and line-managers produce the roadmap as quarterly OKRs or release plans within the strategic frame. Companies whose teams roadmap without an explicit upstream strategy produce drift over multi-quarter horizons.

Rumelt's framework: diagnosis, guiding policy, coherent actions

Richard Rumelt's Good Strategy / Bad Strategy (Crown Business, 2011) is the underlying theoretical reference for engineering strategy at the M3+ tier. The framework:

Diagnosis. What is the situation? What forces are acting on the team? What is changing in the company, the industry, or the technical landscape? Rumelt is explicit: most strategy documents fail at the diagnosis step because they jump to action without naming the situation honestly. A strong diagnosis surfaces the central challenge — the thing that must be addressed if the rest of the strategy is to make sense.
Guiding policy. Given the diagnosis, what is the policy that makes choices possible? Larson's framing: the guiding policy is what you optimize for, what you say no to. Examples from Stripe (per Patrick Collison's interviews) include 'optimize for new-developer time-to-first-charge' over alternative metrics. The guiding policy is typically half a page; if it is longer, it is not actually a policy but a list of preferences.
Coherent actions. The 3–7 specific actions or commitments that follow from the policy. These should be specific enough to refute (Rumelt's test for non-bullshit strategy) and concrete enough that the senior-managers underneath can execute. Typical: 'we will hire 2 senior ML engineers in Q2', 'we will deprecate the legacy authentication path by end of Q3', 'we will run an internal eval-tool sprint in Q1 producing a shippable artifact by week 6.'

Rumelt's central test: a strategy that does not constrain choices is not a strategy. If every action mentioned in the document is something you would have done anyway, the document is not articulating a strategy — it is describing the team's baseline activity. The strategy must rule out specific alternatives.

The complementary Larson test: 'a strategy that does not refute alternative strategies is not a strategy.' If the document does not name what other approaches were considered and explicitly rejected, it is not constraining choices. The most common failure mode: the strategy document describes the chosen approach in detail without naming the alternatives. The reader cannot evaluate whether the choice was the right one.

The engineering-strategy artifact: structure and length

The engineering-strategy artifact at the M3+ tier is typically 2–6 pages of written argument. Larson's 'Good engineering strategy is boring' essay names the structural pattern across modern-tech-company practice. The canonical structure:

Section 1: Diagnosis (1–2 pages). What is happening with the team and the company. References real data — production metrics, hiring funnel data, retention numbers, NPS or partner-feedback signal. Names the central challenge that the rest of the strategy must address. The diagnosis section is the hardest to write because it requires honesty about the team's situation that may be uncomfortable.
Section 2: Guiding policy (0.5–1 page). Given the diagnosis, what does the team optimize for in the next 6–12 months. What does the team explicitly say no to. Typical length: 3–5 sentences. The policy is restrictive — it rules out work that would otherwise be tempting.
Section 3: Coherent actions (1–2 pages). The 3–7 specific actions or commitments. Each action is concrete enough to be evaluated at a 6-month checkpoint. Each action serves the guiding policy. Typical: '2 senior hires in Q2', 'deprecate X by end of Q3', 'run internal eval sprint in Q1 with named artifact', 'rebuild Y service in Q2', 'sunset legacy data pipeline in Q4'.
Optional Section 4: Risks and dependencies (0.5–1 page). What could cause the strategy to fail. What external dependencies (other teams, leadership decisions, market changes) the strategy depends on.

The document is shared with the director, peer M3s, the senior-managers underneath, and (with appropriate context) the line-managers and senior ICs underneath them. Refresh cadence is typically every 6 months at most modern-tech-company orgs. The document is not a fire-and-forget — it is referenced in staff-meetings, in 1:1s when prioritization questions come up, and in cross-functional partnership conversations.

Strategy vs roadmap: the structural distinction

Larson's most-cited operational distinction: a strategy is a written argument about what to do given a situation, with alternatives named and rejected; a roadmap is a time-ordered list of features. Most documents that claim to be strategies are actually roadmaps. The structural difference:

Strategy	Roadmap
Argument with alternatives named and rejected	Time-ordered list of features
Constrains choices	Plans execution
2–6 pages, written prose	Spreadsheet, Gantt, or OKR document
Refreshed every 6–12 months	Refreshed quarterly or per-cycle
M3+ deliverable	M2 / line-manager deliverable
Audience: director, peer M3s, senior-managers underneath	Audience: team, cross-functional partners, leadership

The relationship between the two: the strategy is upstream of the roadmap. The strategy answers 'what should we do given the situation, and why these choices over alternatives.' The roadmap answers 'when will we do each thing, who owns it, what does done look like.' A team that roadmaps without an upstream strategy drifts over multi-quarter horizons because each quarterly roadmap is locally optimized rather than serving a coherent multi-quarter argument.

The most common failure mode at the M3+ tier: writing a 'strategy' that is actually a roadmap with strategic-sounding sentences pasted on top. The reader cannot distinguish what the team is choosing not to do; alternatives are not named; the document does not constrain choices. Rumelt's test fails. Larson's test fails.

Worked example: a 6-month engineering strategy at a senior-manager scope

A worked example of an engineering strategy at the senior-manager / M3 scope. Hypothetical: an authentication-and-identity sub-org of 35 engineers across 4 sub-teams, post-acquisition integration with a different identity stack.

Diagnosis (1.5 pages). The acquired company's identity stack uses a different protocol (OIDC vs SAML primary), serves 14 enterprise customers with bespoke configurations, and depends on a vendor whose contract expires in 18 months. The combined team has been operating in 'parallel-stack' mode for 9 months, with growing developer-experience friction. Production-incident frequency has increased 40% over the last 4 quarters. Hiring-funnel data shows declining acceptance rates from senior-IC candidates citing 'tech-debt visibility' in declining feedback. The central challenge: the parallel-stack cost is now exceeding the cost of consolidation; the team must commit to a consolidation path within 12 months or accept multi-year ongoing tech-debt drag.
Guiding policy (0.5 page). Optimize for engineer-time-to-productivity over feature-velocity for the next 12 months. Say no to new product surfaces that depend on identity work. Say no to additional vendor integrations. Say no to maintaining feature parity between the parallel stacks. Yes to consolidation work; yes to enterprise-customer migration support; yes to senior-IC hiring focused on identity-platform craft.
Coherent actions (2 pages). (a) Migrate the 14 enterprise customers off the acquired stack onto the consolidated stack by end of Q3, with named per-customer migration leads and explicit support cadence. (b) Hire 2 staff-level identity-platform engineers in Q1–Q2; promote 1 senior-IC to staff with the consolidation as named scope. (c) Stand up internal developer-experience metrics in Q1 with weekly publication; target 25% improvement in onboarding-to-first-PR by end of Q3. (d) Sunset the parallel-stack support contract by Q4 with a named exit plan. (e) Run a Q4 retrospective and re-evaluate the strategy for the next 6-month cycle.
Risks and dependencies (0.5 page). Customer migration could slip if we lose more than one of the named per-customer leads. Senior-IC hiring is the largest single risk; the strategy assumes we can land 2 staff-level identity-platform engineers in 6 months in a competitive market. The vendor-contract exit assumes the consolidated stack supports all current customer configurations, which depends on the v3 of the consolidation work landing on schedule.

The document is 4 pages of written prose. It rules out specific work (new product surfaces, additional vendor integrations, parallel-stack feature parity). It names the alternatives that were considered and rejected ('continue parallel-stack indefinitely' and 'rebuild from scratch on a third platform' both considered, both rejected with reasoning in the diagnosis section). It is concrete enough to be evaluated at a 6-month checkpoint. It is the kind of document Larson and Rumelt both name as a real strategy.

Frequently asked questions

How is a strategy doc different from an OKR document?: An OKR document is a roadmap structured as objectives and key results. The strategy is upstream — it explains why these particular OKRs are the right ones given the situation, with alternatives explicitly considered and rejected. The OKR document is execution; the strategy is the argument. Most teams skip the strategy and write OKRs only; the OKRs drift over multi-quarter horizons because each quarterly OKR cycle is locally optimized rather than serving a coherent multi-quarter argument.
Should every engineering manager write strategy docs?: Line-managers (M1) typically don't write strategy docs at the multi-quarter scope; they execute against the strategy from above. Senior-managers (M2) sometimes write team-level strategy docs at the 6-month scope. M3+ definitely write strategy docs at the multi-quarter, multi-team scope. The pattern: strategy is an M3-and-above craft because the multi-team scope is what makes the constraints-on-choices framing useful. A line-manager's 'strategy' is usually a roadmap with strategic-sounding language.
How often should I refresh the engineering strategy?: Every 6 months is the modal cadence at most modern-tech-company orgs. Some companies refresh annually; some quarterly. The right cadence depends on the rate of change in the team's environment. A team navigating rapid market change or platform-strategy shifts may need 3-month refreshes; a team in a stable domain may need 12-month refreshes. The strategy should not be refreshed so often that it becomes performative; it should not be left so long that it becomes irrelevant.
How do I write the diagnosis section honestly?: The diagnosis is the hardest section to write because it requires honesty about the team's situation that may be uncomfortable — production-metric trends that are bad, hiring-funnel signals that are negative, retention concerns. Rumelt is explicit that most strategy documents fail at this step. The discipline: write the diagnosis first, share it with peers and your director before writing the policy and actions, take feedback that the diagnosis is incomplete or sanitized. The strategy doc that paper-overs uncomfortable diagnostic facts produces strategy that doesn't address the actual situation.
Should the strategy doc be shared with the team or kept at leadership level?: Shared with the senior-managers and line-managers underneath; sometimes shared with the broader team in summarized form. The full document is leadership-level (director, M3s, senior-managers); the summary or key sections are appropriate for broader sharing. The trade-off: full transparency builds team alignment and engagement, but some strategic content (acquisition discussions, leadership transitions, sensitive customer-specific work) can't be broadly shared. Pragmatic Engineer's coverage of how FAANG companies handle this varies by company; Larson's writing on transparency norms applies.
How do I get started writing my first strategy doc?: Read Rumelt's Good Strategy / Bad Strategy (full book, 30–40 hours) and Larson's An Elegant Puzzle 'Engineering strategy' chapter (1 hour). Then read 3–5 strategy docs that other engineering leaders have shared publicly (Larson has linked some on lethain.com; Stripe Press has some examples). Then write the diagnosis section first, share with peers, iterate. Write the policy and actions only after the diagnosis lands well. Total time: 20–40 hours for a first real strategy doc, less for subsequent ones.
What's the relationship between engineering strategy and product strategy?: The engineering strategy is downstream of the product strategy at most companies — the engineering strategy answers 'given the product strategy, what is the engineering organization's optimal posture and set of bets.' At companies where engineering is unusually central (developer-API platforms like Stripe, Databricks; ML-platform companies; AI labs), the engineering strategy is more upstream and influences the product strategy directly. Cross-functional alignment with PM and design at the strategy-document level is required at every company; the strategy doc surfaces disagreement before execution.

Sources

About the author. Blake Crosley founded ResumeGeni and writes about engineering management, hiring technology, and ATS optimization. More writing at blakecrosley.com.