Technical Strategy and Vision

“We need a technical strategy” is one of the most common things you’ll hear as you move up, and one of the most commonly botched. Most documents labelled “strategy” are a list of adjectives everyone already agrees with: we should be more scalable, more reliable, faster, more secure. Nobody disagrees, nothing changes, and three months later someone asks for a technical strategy again. This lesson is about writing the kind that actually sets direction, which turns out to require naming uncomfortable truths and saying no to things, which is exactly why it’s rare.

Strategy Is Not a Wish List

Here’s the test. If your “strategy” is a set of goals that no reasonable person would argue against (“improve reliability, reduce costs, increase velocity”), it’s not a strategy. It’s a wish list. A real strategy makes choices: it says we will do this and specifically not that, because of this diagnosis of our actual situation. A wish list offends no one and guides nothing. A strategy picks a side.

The clearest framework I know for this comes from Richard Rumelt’s Good Strategy / Bad Strategy, and it maps perfectly onto engineering.

The Kernel: Diagnosis, Policy, Actions

A real strategy has three parts, and they must connect:

1. Diagnosis. Name the actual problem, honestly, at the root. Not a solution in disguise. “We should migrate to Kubernetes” is not a diagnosis; it’s a pre-chosen answer. A diagnosis is: “Our deploys take two hours and fail 30% of the time, so teams batch up changes and ship slowly, which is why features take months.” That names the real problem (slow, unreliable deploys) and its consequence (slow delivery). Good diagnosis is often the hardest part, because it requires looking past the symptom everyone’s complaining about to the cause, and sometimes past the solution everyone’s already attached to.

2. Guiding policy. The overall approach you’ll take, and what you won’t. For the deploy problem: “Make deploys boring: one standard pipeline, under 15 minutes, owned centrally. No per-team snowflake pipelines.” Notice the “no” in there, that’s the policy making a choice. It rules out the appealing-but-fragmenting path of letting every team build their own thing. A guiding policy without a “no” is just an aspiration.

3. Coherent actions. Concrete steps that reinforce each other. “Build the standard pipeline. Migrate three pilot teams. Delete their old scripts. Make it the default for all new services.” These aren’t a random to-do list; each supports the policy and they build on one another. “Coherent” is the key word, the actions pull in the same direction.

The three parts are a chain: the diagnosis justifies the policy, and the policy drives the actions. If someone can’t see how your actions follow from a diagnosis, you have a list of projects, not a strategy.

Why Most “Strategy” Fails

Now you can see why the common failures fail:

• It’s a list of goals with no diagnosis. “Be scalable, reliable, fast.” No analysis of what’s actually wrong or why, so no real guidance. Everyone nods and nothing changes.
• It rules nothing out. A strategy that says yes to everything isn’t a strategy; it’s a wish. The power of a real strategy comes from what it says no to, because saying no is what focuses limited effort. If your strategy doesn’t make anyone slightly unhappy about something they wanted to do, it probably isn’t doing its job.
• It avoids the uncomfortable truth. Good strategy often names something people would rather not say out loud: “our architecture can’t support the roadmap,” “we’ve been investing in the wrong thing,” “this team’s approach doesn’t scale.” That discomfort is a feature. A strategy that only says pleasant things has no leverage.

As a staff engineer, writing a real strategy is partly an act of courage: you have to name the hard truth and pick a side, knowing some people won’t like it. That’s precisely where the value is.

Vision vs Strategy

People use these words interchangeably; they’re different, and both are useful:

• Vision is the destination: where we’re going, what good looks like in two or three years. “Any engineer can ship a change to production safely in under 30 minutes, with confidence.” It’s aspirational, directional, and meant to align and inspire. A vision answers where and why.
• Strategy is the route: how we’ll get from today’s mess to that destination, given our actual constraints. It answers how, and it makes the hard choices along the way.

You need both. A vision without a strategy is a nice poster nobody knows how to act on. A strategy without a vision is a set of moves with no clear destination, easy to lose the thread. As a staff engineer you’ll often write a short vision (a page: here’s where this area should be, and why) paired with a strategy (here’s the diagnosis and the path). The vision gets people pointed the same way; the strategy gets them moving.

Setting Direction Without Authority

Here’s the catch that makes technical strategy a staff skill rather than just a writing exercise: you usually can’t mandate any of it. You’re not the CTO. You can’t order teams to adopt your standard pipeline. So how does a strategy actually take hold?

• Write it down, clearly. A strategy that lives only in your head influences no one. The document is the artifact that travels, gets debated, and becomes shared (Lesson 4 is entirely about this writing).
• Make the case, repeatedly. You’ll present it, discuss it, and revise it many times. Influence is cumulative (Lesson 7). The first version is a draft for conversation, not a decree.
• Co-opt, don’t impose. Involve the teams who’ll be affected in shaping it, so it’s theirs too, not a thing done to them. A strategy with ten co-authors spreads itself.
• Make the right path the easy path. The most durable way to set direction is to make your approach the one with the least friction, a paved road (Lesson 10) that’s simply easier to use than rolling your own. People follow strategy far more reliably when following it is easier than not.
• Get air cover. Line up a senior sponsor (Lesson 9) who’ll back the direction in rooms you’re not in. A strategy with a director behind it carries weight yours alone can’t.

This is why strategy and influence are inseparable for a staff engineer. The best diagnosis in the world does nothing if you can’t get people to act on it, and you can’t make them, so you have to persuade them. The rest of this course is largely about how.

A Note on Scope: Don’t Over-Strategise

One caution: not everything needs a grand strategy. A single project needs a design doc (Lesson 4), not a three-year vision. Reserve strategy for genuinely cross-cutting, long-horizon questions, how should all our services handle X, what’s our approach to Y across the org, where is this domain going. Writing a sweeping “strategy” for a small, local, reversible decision is its own failure mode: it’s over-engineering applied to thinking. Match the weight of the document to the altitude of the question (Lesson 2).

Pitfalls to Avoid

1. Writing a wish list and calling it strategy. Goals everyone agrees with guide nothing. Make choices.
2. No diagnosis. Jumping to a solution (“use Kubernetes”) without naming the real problem it solves.
3. Ruling nothing out. A strategy with no “no” has no focus. If it makes no one slightly unhappy, it’s probably toothless.
4. Avoiding the uncomfortable truth. The hard thing nobody wants to say is usually where the leverage is.
5. Confusing vision and strategy. A destination without a route, or a route with no destination. You need both.
6. Expecting to mandate it. You can’t; you set direction by writing, persuading, co-opting, paving the road and getting air cover.
7. Over-strategising small decisions. A local, reversible choice needs a design doc, not a three-year strategy.

Quick Recap

• A real strategy = diagnosis (the honest problem) + guiding policy (the approach, and what you won’t do) + coherent actions (reinforcing steps).
• A wish list of agreeable goals is not a strategy; a strategy must say no to things.
• Vision is the destination (where and why); strategy is the route (how), given real constraints. You need both.
• Good strategy names an uncomfortable truth and picks a side, that’s the source of its power.
• You set direction without authority: write it, make the case, co-opt teams, make the right path easiest, and get a sponsor.

Next lesson: the medium through which all of this travels, writing. Design docs, writing for the actual reader, and getting your conclusion to the top.