Writing Engineering Strategy
selt strategy engineering-leadership documentation
Status: Notes complete
Overview
Most engineering organizations have what they call a strategy but is actually a collection of vague principles — statements like “we value simplicity” or “we prefer boring technology.” These feel like guidance but fail the test of usefulness: they cannot help an engineer decide between two concrete options when both are consistent with the principle. This section addresses how to write engineering strategy that is actually specific enough to guide real decisions.
Larson argues that the creation of genuine engineering strategy is one of the highest-leverage activities available to Staff engineers, and one of the most consistently underdone. The pathway he describes is deliberately iterative and grounded: begin with individual design documents, synthesize patterns across them, and only then extract strategy. The approach resists the temptation to write strategy top-down from abstract ideals.
Core Concepts
Engineering Strategy — A specific, actionable set of decisions and constraints that guides future technical choices within an organization. A good strategy is grounded in current reality, makes trade-offs explicit, and is specific enough that reasonable people could disagree with it.
Engineering Vision — The long-horizon picture of where the organization wants to be technically in 3–5 years. Vision is less actionable than strategy; it provides direction without specifying the route. Strategy is what closes the gap between today and the vision.
Design Document — A written artifact that captures the technical context, decision, alternatives considered, trade-offs, and constraints for a specific engineering decision. Design docs are the raw material from which strategy is synthesized.
Principles — Statements of values that inform decisions without specifying them. “We prefer boring technology” is a principle. Principles are less actionable than strategy and more durable — they change more slowly. The failure mode is treating principles as if they were strategy.
Specificity heuristic / “Uncomfortably Specific” — Larson’s test for whether a strategy is real: if you can’t imagine reasonable people disagreeing with it, it is too vague to be useful. A real strategy names specific choices that exclude alternatives, and those exclusions might be wrong — which is what makes them meaningful.
Why Most “Strategies” Are Actually Just Principles
The default output of a strategy-writing exercise is a list of principles. This happens because:
- Principles are easier to agree on. Nobody disagrees with “we value reliability.”
- Principles feel authoritative without requiring the author to take a stance.
- The process of writing principles does not require the author to confront specific decisions.
The cost is that principles provide no guidance when it matters. An engineer choosing between two architectures both consistent with “we value simplicity” has learned nothing from reading the strategy. Real strategy makes the choice for them, or at least dramatically narrows it.
Example:
- Principle: “We value operational consistency across services.”
- Strategy: “All new backend services must be written in Go and deployed via our internal Kubernetes platform. Exceptions require written approval from the platform team.”
The strategy is operationally useful. The principle alone is not.
Larson’s Three-Step Process for Writing Strategy
Larson’s recommended approach inverts the typical strategy-writing process:
Step 1: Write Five Design Documents
Write (or collect) five or more design documents that represent real decisions your organization has made or is facing. These should:
- Cover a range of decision types: architecture, tooling, process, organizational structure.
- Include the context that shaped the decision, not just the decision itself.
- Capture the alternatives considered and why they were rejected.
- Document the constraints (team size, existing systems, timeline) that were real at the time.
The design documents are not the strategy. They are the evidence base.
Step 2: Synthesize Patterns Across the Documents
Read across the design documents and identify recurring patterns:
- What trade-offs come up repeatedly?
- What constraints appear in multiple contexts?
- Where did the organization consistently make similar choices, and why?
- Where did it make inconsistent choices, and what does that reveal about implicit values?
This synthesis is where genuine strategic insight emerges. The patterns are the strategy waiting to be named.
Step 3: Extract the Implied Strategy (and Test It)
Write the strategy as a set of specific, actionable decisions derived from the patterns. Then test each statement against the “uncomfortably specific” heuristic:
- Can a reasonable engineer use this to make a concrete decision without asking for further clarification?
- Could a reasonable person disagree with it?
- Does it exclude some options that would otherwise be considered?
If the answer to any of these is no, the statement is a principle, not a strategy element. Either make it more specific or move it to a separate “principles” section.
Properties of a Good Engineering Strategy
Specific enough to be wrong. A strategy that cannot be falsified — that no reasonable outcome would cause you to revise — is not actionable. Good strategies make claims that could turn out to be incorrect, which is what makes them testable and credible.
Grounded in current reality. Strategy that ignores actual constraints (team skill levels, existing systems, budget, current product priorities) is aspirational fiction. It will be ignored because engineers will recognize immediately that it does not apply to their actual situation.
Acknowledges constraints explicitly. Naming what you cannot change makes strategy more credible, not less. “Given that we cannot migrate away from our Oracle database in the next 18 months, all new services will…” is stronger than a strategy that ignores the Oracle database and gets ignored in return.
Makes trade-offs explicit. Every real strategic choice forecloses other options. A strategy that does not name what it trades away has probably not been thought through. “We will use a monolithic deployment model” implies “we are trading deployment flexibility for operational simplicity.”
Short enough to be read and remembered. Strategy documents that are too long are effectively no strategy at all. Aim for something an engineer can read in 20 minutes and recall the key decisions from without re-reading.
Engineering Vision vs. Engineering Strategy
| Dimension | Vision | Strategy |
|---|---|---|
| Time horizon | 3–5 years | 6–18 months |
| Actionability | Low — directional | High — decision-guiding |
| Specificity | Broad | Specific enough to be wrong |
| Frequency of revision | Rare | Regular |
| Primary audience | Leadership, org-wide orientation | Engineers making day-to-day decisions |
Vision and strategy are complementary, not competing. Vision tells you where you are going; strategy tells you what you will and will not do in order to get there. A common failure is to write a vision and call it a strategy.
Why Strategies Fail
Too abstract: The strategy consists of principles dressed up as decisions. “We will build for scale” is not a strategy.
Not grounded in current reality: The strategy describes an ideal architecture without accounting for the existing system, team capability, or timeline constraints. Engineers immediately see it as disconnected from their actual work.
Trade-offs not made explicit: The strategy avoids the hard choices — which approaches are out of scope, which existing patterns will be deprecated, which teams will need to change — because making them explicit creates conflict. As a result, the strategy does not resolve conflicts when they arise; it just defers them.
Written once, never revisited: Strategy has a shelf life. A strategy written for a 50-person engineering org may actively mislead a 500-person org. Without regular revision, strategy becomes archaeology rather than guidance.
Written by too few people: Strategy written in isolation by a single Staff engineer or CTO lacks the organizational buy-in needed for it to actually influence decisions. The synthesis step — drawing from real design documents written by many people — is also how buy-in is built.
The Role of Design Documents
Design documents serve two purposes simultaneously:
- Immediate: They record the reasoning for a specific decision, making it possible to revisit that reasoning later without relying on the memories of the people who were in the room.
- Strategic: Across a body of design documents, patterns become visible that reveal what the organization actually values versus what it claims to value.
A well-maintained corpus of design documents is one of the most valuable artifacts a maturing engineering organization can have. It is the substrate from which strategy is continuously synthesized.
For design docs to serve the strategic purpose, they need to include:
- Context: what was the situation when this decision was made?
- Alternatives: what else was considered?
- Constraints: what could not be changed?
- Decision: what was chosen?
- Rationale: why was this chosen over the alternatives?
The “Uncomfortably Specific” Heuristic in Practice
Applied examples:
| Statement | Assessment |
|---|---|
| ”We value simplicity in our systems.” | Principle — too vague to guide decisions |
| ”We will use Python for all new data pipeline services.” | Strategy — specific, excludable, potentially wrong |
| ”We prefer reliability over developer velocity.” | Principle — can’t make a concrete choice with this |
| ”New services must achieve 99.9% uptime SLA before GA; features cannot block service reliability work.” | Strategy — specific, creates real priority guidance |
| ”We believe in good engineering practices.” | Not even a principle — content-free |
| ”ADRs are required for any decision that changes our deployment model or adds a new programming language.” | Strategy — specific, actionable, enforceable |
Staff Engineer’s Role in Strategy
Writing strategy is explicitly Staff-level work because it requires:
- Cross-organizational visibility: you need to have seen enough design decisions across teams to synthesize patterns.
- Long time horizon: you need to have been around long enough to understand what has been tried, what failed, and why.
- Influence without authority: strategy is adopted through persuasion, not mandate. Staff engineers are well-positioned to build the broad coalition needed for strategy to stick.
- Willingness to be wrong: a real strategy is falsifiable. Writing one requires the courage to make claims that could turn out to be incorrect.
Strategy is not leadership’s job to dictate to engineers, nor is it something that can be crowdsourced from a committee. It emerges from the synthesis of real technical experience — which is precisely what Staff engineers are positioned to provide.
Key Takeaways
- Most engineering “strategies” are actually just lists of principles — too abstract to guide real decisions between concrete options.
- Larson’s three-step process: write five design documents → synthesize patterns across them → extract the implied strategy.
- The “uncomfortably specific” heuristic: if reasonable people can’t disagree with your strategy, it isn’t specific enough to be useful.
- Engineering vision (3–5 year horizon) and engineering strategy (6–18 months) are complementary, not the same thing.
- Good strategies make trade-offs explicit — they name what is out of scope, not just what is in scope.
- Constraints make strategy more credible: acknowledging what you cannot change grounds the strategy in reality.
- Design docs are the raw material: a well-maintained corpus of design documents is the substrate from which strategy is continuously synthesized.
- Strategy fails when it is too abstract, ignores constraints, avoids trade-offs, or is never revisited as the organization changes.
- Writing strategy is Staff-level work because it requires cross-organizational visibility, long time-horizon experience, and the courage to make falsifiable claims.
Related Resources
- sec02-work-on-what-matters — writing strategy is one of the highest-leverage activities to protect time for
- sec04-managing-technical-quality — technical quality decisions are a concrete domain where strategy applies
- sec05-staying-aligned-with-authority — strategy must align with organizational direction to be adopted
- ch04-communicating-as-a-staff-engineer — written strategy as a communication tool
- ch06-where-do-staff-engineers-sit — how organizational position affects access to design doc patterns
Last Updated: 2026-05-30