The RFC process is well-understood at most engineering organizations. You have a problem, you have a proposed solution, you write it up, you get feedback, and you either proceed or revise. RFCs are structured around a decision: should we do X, and if so, how?
Strategy documents are different — and the difference matters. A strategy document is not asking “should we do X.” It is answering the question “why are we doing what we’re doing, and how does it connect to everything else we care about?” It is less about proposing a specific solution and more about establishing a shared understanding of the problem space, the constraints, and the reasoning that should govern future decisions in a domain.
Staff engineers are increasingly expected to write strategy documents as they take on more cross-team and cross-functional scope. This post is about how to write one that actually does the job.
Why Most Strategy Documents Fail
The most common failure mode is that a strategy document is written to be seen, not to be used.
The author spends two weeks writing a thorough document that covers the history of the problem, the technical landscape, three options they evaluated, and a conclusion. It gets reviewed, gets minor comments, gets approved, and gets filed somewhere in the wiki. Six months later, a new engineer joins and makes a decision that contradicts the strategy. Nobody remembers the document exists. The decision is made again from scratch in the next planning cycle.
The document failed not because it was poorly written but because it was never designed for reuse. It documented a decision rather than establishing a framework for making future decisions in the domain.
The second common failure is the opposite: a document so abstract that it cannot be applied. Strategy documents written at the “north star” level — “we want scalable, maintainable systems that enable rapid iteration” — give engineers nothing they can use when a specific decision needs to be made. Everyone agrees with the north star. No one knows whether it implies using Kafka for this particular use case or not.
A strategy document that works operates in the middle: concrete enough to constrain decisions, abstract enough to survive the decisions that change below it.
What a Strategy Document Is For
Before writing, be precise about the purpose. A strategy document should answer a specific question about a domain — security posture, data architecture, platform boundaries, build-vs-buy for infrastructure, team API design principles, etc.
The test for whether your document is appropriately scoped is: can an engineer reading it determine whether a specific decision they face is in-scope for this strategy, and if so, can they derive guidance from it?
If the answer is no, the scope is wrong. Either too broad (“we’re documenting our engineering philosophy”) or too narrow (“we’re documenting why we chose PostgreSQL over MySQL in 2023”).
The Structure That Works
There is no canonical format for strategy documents, but the following structure covers the components that most consistently make them useful.
Problem Space
Start with the problem, not the solution. Describe the domain: what decisions repeatedly arise here, what has gone wrong in the past without explicit strategy, and why this domain merits explicit treatment rather than ad-hoc case-by-case decisions.
This section earns the document’s existence. If you cannot articulate why this domain needs a strategy, you may not actually need a strategy document — you may need an RFC about a specific decision, or just better documentation of an existing convention.
Context and Constraints
The most underwritten section in most strategy documents. Strategy is always contextual: what is right for a 15-person startup is wrong for a 500-person engineering organization. Strategy that ignores team size, skill distribution, existing systems, and timeline constraints produces recommendations that are correct in the abstract and unimplementable in practice.
Write down the constraints that bound the strategy: budget, timeline, team topology, existing architecture commitments, regulatory requirements, organizational constraints. Make them explicit. This serves two purposes: it helps readers understand why the strategy makes the choices it does, and it documents the conditions under which the strategy should be revisited.
Principles
This is the core of a strategy document: a small number of guiding principles that define how decisions should be made in this domain. “Small” means 3–7 principles. More than that, and you have a document, not a strategy — you have no way of resolving conflicts between principles and no prioritization.
Principles need to be specific enough to be falsifiable. “Prefer simplicity” is not a principle — it is a value statement everyone agrees with. “Prefer solutions that can be operated by a 2-person team without specialized expertise” is a principle. It has implications. It rules things out. It can be applied to a specific decision.
Each principle should state the rule and the reasoning behind it. The reasoning is what survives when the rule seems to conflict with a specific case. If you only document the rule, engineers will apply it mechanically or ignore it when it seems wrong. If you document the reasoning, engineers can reason from it.
Implications and Non-Goals
Explicitly state what the strategy implies — what it rules in and what it rules out. Then separately state what it explicitly does not govern.
Non-goals are particularly important. A strategy document that does not state its scope will get applied to decisions it was not meant to govern. Teams will cite it as justification for decisions it has no bearing on. Non-goals prevent this by setting clear boundaries.
How to Apply This
The section most commonly omitted. Tell engineers how to use the document when they face a real decision. This means: what questions should they ask to determine whether this strategy applies, what does “following this strategy” look like in practice, and what is the process when a decision seems to conflict with the strategy.
This section acknowledges that strategies are not algorithms. They require judgment. The job of the strategy document is to inform that judgment, not replace it.
The Writing Process
The writing process for a strategy document is different from an RFC, and the difference is often where they go wrong.
An RFC is largely synchronous: you write a proposal, you get feedback, you revise it, and you ship or reject it. The feedback process is focused on a specific decision.
A strategy document requires more upstream investment in listening. Before writing, you need to understand the landscape: what decisions have been made in this domain, what has gone wrong, what different parts of the organization believe the right approach is, and where the genuine disagreements are. You cannot write a useful strategy document without knowing where the tensions are.
This means the most important work happens before you open a doc. Talk to the engineers who have been in this domain longest. Talk to the people who will be most affected by the strategy. Understand what each group cares about and why. Then write the document.
The document itself should be reviewed before it is published, but the review should be about whether it accurately captures the problem space and whether the principles hold up — not about whether reviewers agree with every implication. If you are trying to build consensus in the review process on a strategy document, the document is doing work it was not designed to do. Consensus belongs upstream.
The Hardest Part: Saying No
A strategy document that cannot say no to anything is not a strategy. It is a list of preferences.
The most useful and most difficult part of writing a strategy document is identifying which approaches, tools, or patterns the strategy explicitly discourages or prohibits — and writing that down. This will create disagreement. That disagreement is the point. If there is no disagreement, the strategy is not specific enough to be useful.
When documenting something the strategy rules out, be precise about the reasoning. “We are not using X because Y” is more durable than “we prefer alternatives to X.” The first explains the decision in terms that can be revisited when Y no longer holds. The second just creates a soft preference with no context for re-evaluation.
Keeping It Current
A strategy document that is never updated is unreliable. Engineers will stop trusting it, stop citing it, and eventually stop knowing it exists.
Build a review cadence into the document itself: “This strategy should be reviewed when [trigger]” — for example, when the team doubles in size, when a new architectural category becomes available, when a major system in the domain reaches end-of-life. Naming the triggers is more useful than setting a calendar review, because it ties the review to the conditions that should actually change the strategy.
When conditions change, either update the strategy or explicitly document that the strategy was reviewed and still holds. Either action keeps the document alive. Silence kills it.
What a Good Strategy Document Produces
When a strategy document is working, you see specific behaviors in the organization. Engineers cite it when making decisions. New team members can read it and orient themselves in the domain without ad-hoc explanation. Disagreements about decisions in the domain are resolved by reasoning from the principles rather than by re-litigating the entire landscape. The same decision does not get made twice.
When a strategy document is not working, you see the inverse. Nobody remembers it. People making decisions in the domain have not read it. The same questions come up in every planning cycle. Engineers cite “the strategy” to support contradictory positions because the document is vague enough to justify anything.
The difference is almost always in the specificity of the principles and the concreteness of the implications section. That is the work. The framing and structure support it, but they do not replace it.