Technical Strategy: Create One That Doesn't Gather Dust

I've written four technical strategy documents in my career. The first three are gathering dust in some Confluence graveyard. Nobody reads them. Nobody references them. They were dead within weeks of publication.

The fourth one is different. My team references it in ADRs, mentions it in planning meetings, and pushes back on requests that conflict with it. It's alive.

The difference isn't the content. It's the format, the process, and the operating model around it.

# Why Most Technical Strategies Fail

# Problem 1: They're Too Long

My first technical strategy was 28 pages. I was proud of it. I'd spent three weeks writing it. Nobody read past page 4. Not because they didn't care. Because 28 pages of strategy is a book, and engineers don't have time to read a book about the future when they're busy building the present.

# Problem 2: They're Too Abstract

"We will adopt a microservices architecture to improve scalability and team autonomy." Great. What does that mean for the engineer deciding on a database for a new feature this week? Nothing actionable. They can't connect the strategy to their daily decisions.

# Problem 3: They Don't Have Teeth

A strategy without consequences is a suggestion. If teams can ignore the strategy without any pushback, they will. Not out of malice. Out of pragmatism. The feature deadline is concrete. The strategy is theoretical.

# Problem 4: They Never Update

The strategy was written for the world as it existed in January. By July, the product strategy shifted, a key technology choice proved wrong, and two new constraints emerged. The strategy document doesn't reflect any of this. So people stop consulting it.

# The Contrarian Take: Strategy Is Saying No

Most technical strategies try to be everything. They describe the ideal architecture, the technology choices, the quality standards, the team structure implications, the migration plan, and the risk analysis. All in one document.

That's not a strategy. That's an encyclopedia.

A strategy is a small number of decisions that constrain future choices. Its primary purpose is to tell you what NOT to do. If your strategy doesn't help engineers say "no" to certain approaches, it isn't a strategy.

My current strategy document has exactly five decisions. That's it. Five sentences that constrain thousands of future choices.

# The Format That Works

I use a three-section format. Total length: 2-3 pages. That's a hard limit.

# Section 1: Context (Half a Page)

What's the business context that drives this strategy? Not the technical context. The business context.

Example: "We're targeting 10x user growth over the next 18 months. Our current architecture handles 50K concurrent users. We need to handle 500K without proportional infrastructure cost growth. Simultaneously, we're expanding into the EU, which introduces GDPR data residency requirements. These two constraints drive every decision below."

This section answers: why does this strategy exist? Every engineer who reads it should understand the business forces shaping the technical choices.

# Section 2: Strategic Decisions (One Page)

Five or fewer decisions. Each one follows this template:

Decision: One sentence stating the choice. What this means: Two to three sentences explaining the practical implications. What we're giving up: One to two sentences explaining the tradeoff.

Example:

Decision: All new services will be stateless and deployed as containers on Kubernetes.

What this means: No new services store session state locally. All state goes to Redis or Postgres. Every service must pass the "kill any instance at any time" test. New services use our standard Helm chart and deploy through the existing CI/CD pipeline.

What we're giving up: Some services would be simpler as stateful processes. We accept extra complexity in exchange for horizontal scalability and deployment uniformity.

Notice the "what we're giving up" section. This is the most important part. It shows you've thought about the tradeoffs, and it prevents people from relitigating the decision by raising the downside as if it's a surprise.

# Section 3: Decision Rights and Review Process (Half a Page)

Who enforces this strategy? When does it get reviewed? What's the process for requesting an exception?

Example: "The architecture guild owns this strategy. Exceptions require a written request with business justification, reviewed within one week. The strategy is reviewed and potentially updated every quarter, coinciding with business planning."

Without this section, the strategy has no enforcement mechanism, and it will be ignored.

# How to Create the Strategy

Don't write it alone in a room for three weeks. That's how you get a 28-page document nobody owns.

# Step 1: Gather Input (1 week)

Send a three-question survey to every senior engineer and engineering manager:

1. What's the biggest technical risk we face in the next 12 months?
2. What technical decision do we keep making inconsistently across teams?
3. If you could make one irreversible technical choice for the whole org, what would it be?

The responses will reveal common themes. My last survey had 14 responses and three themes emerged clearly: data consistency across services, deployment complexity, and observability gaps.

# Step 2: Draft Decisions (3 days)

Based on the input, draft 5-7 candidate decisions. More than you'll keep. Each one follows the template above.

# Step 3: Review and Debate (1 week)

Share the candidates with your senior engineers. Don't ask "what do you think?" Ask "which of these would you remove and why?" Forcing people to argue against specific decisions is more productive than asking for general feedback.

Cut to five or fewer decisions. If two decisions are closely related, merge them.

# Step 4: Announce and Activate (1 day)

Publish the strategy. Present it at an engineering all-hands. Walk through each decision and its tradeoffs. Take questions. Commit to the quarterly review cadence.

Then do the thing that matters most: reference it the following week. When a team proposes a stateful service, point to Decision #1. When someone wants to use a new database, route it through the exception process. The strategy becomes real through enforcement, not through publication.

# Keeping It Alive

A strategy that doesn't update is a strategy that dies. Here's my quarterly review process.

Two weeks before the review: Collect data. How many exceptions were requested? How many were approved? Were any decisions consistently problematic? Did the business context change?

Review meeting (2 hours, quarterly): The architecture guild reviews each decision. Three possible outcomes per decision:

1. Keep as-is. The decision is still sound.
2. Update. The business context changed, or we learned something. Revise the decision.
3. Retire. The decision is no longer relevant. Remove it and potentially replace it.

After the review: Publish the updated strategy with a changelog. Highlight what changed and why. Engineers should be able to see the evolution.

# The Stealable Framework: The 5-Decision Strategy

Your technical strategy should have exactly five or fewer decisions. Each decision:

1. Is one sentence long
2. Includes practical implications
3. Acknowledges what you're giving up
4. Has an enforcement mechanism
5. Gets reviewed quarterly

Total document length: 2-3 pages.

If you can't fit your strategy in 2-3 pages, you don't have a strategy. You have a wish list. Cut until it's sharp. Cut until every remaining decision actually constrains behavior. Cut until an engineer can read the whole thing in 10 minutes and know exactly how it affects their work.

That's a technical strategy that doesn't gather dust. Not because it's beautifully written, but because it's short enough to read, specific enough to follow, and enforced enough to matter.