Technical Strategy

Most documents labeled "technical strategy" are not strategy. They are a wishlist ("we should adopt event sourcing"), a tech-stack inventory ("we use Go, Postgres, Kafka"), or a list of projects with quarters next to them. None of these tell you what to do when reality pushes back, which is the only time strategy earns its keep.

Strategy is for the hard case: limited people, conflicting priorities, several teams pulling in different directions, and a business that wants outcomes, not architecture. If your document doesn't help in that case, it isn't strategy — it's decoration.

What Technical Strategy Actually Is

Richard Rumelt, in Good Strategy / Bad Strategy, calls the core of any real strategy the kernel, made of three parts:

• Diagnosis. What is actually going on? Name the central challenge. "Our deploy pipeline takes 40 minutes and blocks 30 engineers" is a diagnosis. "We need to be more agile" is not.
• Guiding policy. The overall approach to the challenge — the constraint you impose on yourself to make the problem tractable. "We will invest in build speed before adding any new services" is a guiding policy.
• Coherent actions. A set of steps that reinforce each other and follow from the policy. Not a laundry list — actions that point the same direction.

The test of a strategy is whether the three parts hang together. A diagnosis with no policy is an observation. A policy with no diagnosis is a slogan. Actions with neither are a backlog.

What It Is Not

• A wishlist. "Adopt service mesh, move to Kubernetes, rewrite the monolith" — desirable things, but desire is not strategy. Strategy says which of these, why, in what order, and at the cost of what else.
• A tech-stack list. Your stack is an input to strategy, not the strategy. Listing what you run tells nobody where you're going.
• A budget. Money allocated is not direction chosen.
• Everything at once. A strategy that pursues every good idea has chosen nothing. Rumelt's word for this is "bad strategy" — it fails to choose.

Vision vs Strategy vs Roadmap

These three get conflated constantly. Keep them distinct:

The vision is the destination. The strategy is the route chosen given the terrain — the mountains, the budget, the team you actually have. The roadmap is the turn-by-turn directions, which you re-plan every time the road is closed.

A common failure: a team writes a roadmap and calls it strategy. When the roadmap slips — and it will — they have nothing underneath to fall back on, because the reasoning was never written down.

Writing a Technical Vision

A vision document describes what "good" looks like far enough out that today's constraints don't dominate. Prompt questions that produce a real one:

• If we got everything right over the next three years, what would an engineer's day feel like? What would they no longer fight?
• What would we be able to build that we can't build today?
• What does the system look like to a customer? To on-call? To a new hire in week one?
• What are we deliberately not going to be good at?

Make it concrete and falsifiable. "World-class developer experience" is unfalsifiable and therefore useless. "Any engineer can ship a change to production in under an hour, on their first day, without asking anyone" is concrete — you can tell whether you got there.

On time horizon: 2–3 years is the sweet spot. Shorter and it's just a roadmap. Longer and it's science fiction nobody can act on.

On buy-in: a vision written alone and announced is a vision nobody owns. Draft with input from the people who'll execute it, circulate it as an RFC or design doc, and let the teams poke holes. The version that survives that gauntlet is the one people will actually pull toward. You usually can't mandate a vision into existence — see influence without authority.

Roadmaps That Survive Reality

A roadmap is a plan, and all plans are wrong. The goal isn't a roadmap that's right — it's one that degrades gracefully when it's wrong.

• Sequence by dependency, not by wish. If A unblocks three other things, A goes first, even if it's boring. Map the dependency graph before you map the calendar.
• Themes over dated Gantt charts. "This half: cut deploy time and stabilize the data layer" survives reality better than a 14-bar Gantt chart with precise dates that everyone knows are fiction by week two. Dated bars create false precision and invite blame when they slip.
• Leave slack. A roadmap planned to 100% capacity has zero room for the incident, the attrition, the thing you didn't know about. Plan to ~70%. The slack is not waste; it's where reality goes.
• Make dependencies explicit, including external ones. "Blocked on the platform team's auth migration" is a real roadmap item. Pretending it isn't doesn't make it go away.
• Revisit on a cadence. Monthly or quarterly, re-examine the roadmap against what's actually happened. A roadmap nobody revisits is a wish you wrote down once.

The difference between a roadmap and a fantasy is that a roadmap has a feedback loop.

Tying It to Business Strategy

Nobody funds a technical strategy that doesn't connect to something the business cares about. The three currencies that always land:

• Outcomes. "This lets us ship features to enterprise customers we currently turn away."
• Cost. "This cuts our compute bill by 40% as we scale, or avoids hiring three engineers to do manual work."
• Risk. "Our current auth system is one CVE away from a breach we can't patch quickly."

Translate every strategic bet into at least one of these. If you can't, either you don't understand the bet, or it shouldn't be a priority. "It's better engineering" is not a business case — it's an assertion the business has no reason to trust.

This translation is also how you defend the strategy in a budget cut. The bets tied to revenue or risk survive; the ones justified only by elegance get cut first, and rightly.

Strategic Tech Debt

Tech debt is usually framed as a cleanup chore. At the strategy level, it's a lever you pull on purpose.

Debt is a loan against future velocity. Sometimes taking the loan is correct: ship the hacky version to validate the market, then pay it down once you know the bet paid off. Sometimes paying it down is the highest-leverage thing you can do, because it unblocks everything downstream.

Decide deliberately:

• Debt to take on. Time-to-market matters more than cleanliness for unproven bets. Take the shortcut, but write down that you took it and what it'll cost to undo. Undocumented shortcuts become folklore.
• Debt to pay down. Pay the debt that sits on the critical path of the strategy — the slow build, the brittle module everyone has to touch, the schema that blocks the next three features. Ignore the ugly-but-isolated corner nobody goes near.
• Debt to leave alone. Not all debt is worth paying. A gnarly module that hasn't changed in three years and isn't on the roadmap is not a priority, however much it offends you.

The strategic question is never "is this clean?" It's "is this debt on the path, and is the interest rate rising?" See technical decisions for how to weigh an individual call.

Driving Alignment Across Teams

A strategy that lives in one head, or one doc nobody opens, isn't driving anything. Making it a living thing:

• Write it down, then socialize it relentlessly. The doc is necessary but not sufficient. You'll explain it more times than feels reasonable. That repetition is the work, not a sign you wrote it badly.
• Make local decisions traceable to it. When a team makes a call, they should be able to point at the strategy and say "this follows from the guiding policy." If they can't, either the decision is off-strategy or the strategy is too vague to guide anything.
• Use it as a decision filter. The value of a strategy is the projects it lets you say no to. "That's a good idea but it's not on the path this year" is the strategy working.
• Review it openly. When the diagnosis changes — new competitor, new scale, new constraint — change the strategy out loud, with the teams, so they see it adapt rather than discovering it's stale.
• Connect it to the tech radar. The radar is where the strategy's stance on specific technologies becomes legible to everyone — what's adopt, what's hold, what's being retired.

Alignment is not a one-time broadcast. It's a standing practice of keeping the doc, the decisions, and the reality in sync.

Anti-Patterns

• Strategy as a list of projects. A roadmap with no diagnosis or guiding policy underneath. When priorities collide, there's nothing to adjudicate with.
• The rewrite-everything plan. "We'll fix it all in the v2 rewrite." Big-bang rewrites overrun, the business keeps moving, and you end up maintaining two systems. Strategy strangles the old system incrementally; it doesn't bet the company on a rewrite.
• Strategy nobody read. A beautiful 40-page doc, written once, linked never. If you can't state the kernel in three sentences, nobody will carry it.
• Resume-driven architecture. Adopting the trendy technology because it looks good to have done, not because the diagnosis called for it. The tell: the technology was chosen before the problem was named.
• Premature standardization. Mandating one framework, one database, one pattern across all teams before you've learned what works. Standardize what's proven and load-bearing; let the rest vary until the pattern is clear. Standardizing on the wrong thing is more expensive than not standardizing at all.

Self-Check

Before you call a document a technical strategy:

Can you state the diagnosis, the guiding policy, and one thing you're choosing NOT to do — in three sentences, from memory?

If yes, it's a strategy and people can carry it. If it takes a 40-page deck, you have a wishlist with good production values.