Senior engineering leaders are regularly asked for "the technical strategy", and most of what gets written in response is not a strategy. It's a list of aspirations (modernize the platform, improve reliability, accelerate delivery) with a roadmap attached. Executives skim it, nod, and nothing changes, because nothing in it forces a choice. This post shows how to write a strategy that fits on one page, makes real trade-offs and asks for a decision.
What a strategy actually is
Richard Rumelt's Good Strategy Bad Strategy gives the most useful definition. A good strategy has a kernel with three parts:
- Diagnosis: what's really going on. It names the critical challenge and simplifies a messy situation into something you can act on.
- Guiding policy: the overall approach to that challenge. It rules some options in and, just as importantly, rules others out.
- Coherent actions: specific steps that carry out the policy and reinforce each other.
Rumelt also describes what he calls bad strategy: fluff (impressive-sounding language with little meaning), failure to face the actual challenge, mistaking goals for strategy, and objectives that are either a jumble of unrelated items or simply out of reach. Hold a draft up against that list and most engineering strategies fail on at least two counts.
The quickest test: could a reasonable person disagree with your guiding policy? "We will prioritize reliability" can't be disagreed with, so it doesn't guide anything. "We will freeze new product integrations for two quarters to pay down the deployment pipeline" can, and that's why it's useful.
Write it bottom-up
Will Larson, in his writing on engineering strategy, suggests an approach that avoids the blank page: look at the recent design documents and decisions your organization has made, find what they have in common, and write that down as strategy. Strategies grounded in real decisions are more credible and easier to follow than ones invented from above, and they surface the trade-offs you're already making implicitly.
Practically, before drafting:
- Collect the last ten or so significant technical decisions: design docs, incident follow-ups, build-vs-buy calls, reorganizations.
- Note the recurring tension in them. It's usually one or two things: speed versus safety, platform versus product work, one legacy system everything depends on.
- Gather three to five numbers that show the situation plainly. Executives will ask "how do you know?" and a number answers faster than a paragraph.
The one-page format
One page forces prioritization. If it doesn't fit, you haven't chosen yet.
Title: the decision in plain words
1. The ask (2–3 lines)
What you need from this audience, and by when.
2. Diagnosis (one short paragraph + 3–5 numbers)
The single most important challenge, and why now.
3. Guiding policy (3–5 bullets)
The choices you're making. Include at least one thing you will NOT do.
4. Actions (3–5 items, each with an owner and a date)
What happens in the next two quarters.
5. How we'll know (2–4 measures)
Leading indicators you'll report on, with today's baseline.
6. Risks and what we're giving up (2–4 bullets)
Lead with the ask. Executives read from the top and often stop early. If the decision you need is at the bottom, it won't get made.
A worked example
A hypothetical, to show the level of specificity to aim for.
Title: Pause new integrations for two quarters to fix how we ship
The ask: Approve a two-quarter pause on new partner integrations, starting next quarter, and move two engineers from the integrations team to the platform team for that period.
Diagnosis: Our delivery speed is limited by the release process, not by headcount. Median time from merge to production is 9 days. 40% of last quarter's incidents started with a deployment. Each team spends roughly a day a week on release coordination. Adding engineers adds more changes to the same queue.
Guiding policy: Invest in the deployment path before new product surface. Automate first, then decouple: every service deployable on its own. We will not start the planned rewrite of the billing service; it stays as is until deploys are routine.
Actions: Automated deploy pipeline for the ten highest-traffic services (Platform, end of Q1). Feature flags as the default for risky changes (Platform + two product teams, Q1). Retire the weekly release train (Engineering leads, Q2).
How we'll know: Merge-to-production time (baseline 9 days, target under 1). Share of incidents caused by deploys (baseline 40%). Deploys per week.
Risks and what we give up: Two partner integrations slip to the second half of the year; Sales has been consulted. Morale risk on the integrations team; mitigated by rotating people rather than moving them permanently.
Note what it doesn't contain: architecture diagrams, a list of every initiative, or the word "modernize". The detail lives in linked design documents for those who want it.
The measures lean on the kind of delivery metrics the DORA research program popularized (deployment frequency, lead time for changes, change failure rate, time to restore service). They're widely understood, which saves you explaining why they matter.
Writing for executives
- Translate into their currency. Not "reduce deploy friction" but "ship the roadmap you already approved without adding headcount". Tie at least one measure to something the business already tracks.
- One number per claim. A diagnosis full of adjectives invites debate; a diagnosis with a baseline invites a decision.
- Name the trade-off yourself. If you don't say what's being given up, someone in the room will, and it will look like you missed it.
- Prefer prose to slides for the thinking. Amazon's well-known practice of starting leadership meetings by silently reading a written narrative exists because full sentences expose weak reasoning that bullet points hide. Even if you present with slides, write the page first.
- No surprises in the meeting. Walk the most affected peers and your own manager through it beforehand. The meeting should confirm a decision, not start the argument.
Keep it alive
A strategy that's written once and filed is a document, not a strategy. Put a review date on the page (quarterly works for most organizations), report on the measures in your regular updates, and refer back to the guiding policy when new requests arrive: "That's an integration; we agreed to pause those until Q3." When the diagnosis changes, rewrite the page rather than appending to it.
Before you send it
- The ask is in the first three lines.
- The diagnosis names one challenge, with numbers.
- At least one thing is explicitly not being done.
- Every action has an owner and a date.
- Each measure has a baseline.
- Someone reasonable could disagree with the guiding policy.
- It fits on one page.
Setting multi-year technical direction and communicating it to executives are core areas of the PTME study guide, which covers organizational transformation and technical architecture decisions in more depth.