Vision & Strategy

Vision — What It Is and What It Is Not

A vision is a vivid, concrete description of the future state you are building toward. It is not a mission statement, not a list of OKRs, and not a strategy.

Element	Vision	Not Vision
Time horizon	2-5 years	This quarter’s goals
Specificity	Concrete enough to test decisions against	Vague aspirational statement
Emotional resonance	People can feel why it matters	Corporate jargon no one remembers
Stability	Changes rarely (direction, not details)	Shifts every quarter
Example	“Every customer interaction is resolved in under 2 minutes through AI-assisted agents, with human handoff only for edge cases”	“Be the best AI platform”

The North Star Test

A good engineering vision passes three tests:

1. Decision filter: When two smart people disagree on a technical approach, does the vision resolve it? If your vision is “build a world-class platform,” it resolves nothing. If it is “zero-downtime, sub-100ms response time for all customer-facing interactions,” it resolves many architecture debates immediately.

2. Motivation test: When an engineer is slogging through the third week of a migration, can they connect their work to the vision? If not, either the vision is too abstract or you have failed to draw the connection.

3. Falsifiability test: Can you imagine a future where you clearly achieved or clearly failed to achieve this vision? “Be innovative” is unfalsifiable. “Every deploy goes to production within 30 minutes of merge with zero manual steps” is falsifiable.

Crafting Vision — The Practical Process

Most leadership books describe vision as something that arrives through inspiration. In practice, good engineering vision emerges from:

1. Understanding constraints deeply — What are the real technical, organizational, and market constraints? Vision that ignores constraints is fantasy.
2. Extrapolating trends — Where is the technology/market/org heading in 3 years? Not prediction — directional understanding.
3. Identifying the gap — What is the biggest gap between current state and where the trends point? The vision fills that gap.
4. Making it concrete — Describe a day-in-the-life in the future state. What does the engineer, the customer, the ops team experience? This is what Jeff Bezos calls the “working backwards” approach — Amazon’s PR/FAQ method forces you to describe the end state before designing the solution.

---

Strategy — The Sequence of Choices

Strategy is not a plan. A plan is a sequence of steps. A strategy is a coherent set of choices about where to play and how to win — Roger Martin’s framing from “Playing to Win” (2013).

The Strategy Stack

Most organizations conflate layers that should be distinct:

Mission (Why we exist)
    |
Vision (Where we are going)
    |
Strategy (How we will get there — the choices)
    |
Objectives & Key Results (How we measure progress)
    |
Roadmap / Initiatives (What we will do this quarter)
    |
Tasks (What we do this week)

The most common dysfunction: Organizations jump from Vision directly to Tasks, skipping Strategy entirely. The result is a team that is busy but not making progress — lots of motion, little movement.

What Makes Strategy Hard

Strategy is fundamentally about what you will NOT do. This is why most engineering orgs struggle with it — engineers are problem-solvers who want to tackle everything. A strategy that says “we will do X, Y, and Z” is not a strategy. A strategy that says “we will do X, which means we explicitly will NOT do Y and Z for now” is a strategy.

Michael Porter’s essential insight: The essence of strategy is choosing what not to do. If your strategy does not make someone uncomfortable about what you are giving up, it is not a strategy.

Strategy Frameworks for Engineering Leaders

Playing to Win (Roger Martin & A.G. Lafley)

Five cascading choices:

Choice	Question	Engineering Example
Winning Aspiration	What does winning look like?	“Fastest time-to-market in our category”
Where to Play	Which markets, segments, channels?	“Enterprise customers, API-first, EMEA focus”
How to Win	What is our competitive advantage?	“Superior developer experience through self-serve tooling”
Capabilities	What must we be great at?	“CI/CD automation, API design, observability”
Management Systems	What processes/metrics support the choices?	“Deploy frequency as KPI, internal DX NPS, platform adoption rate”

The power is in the cascade: each choice constrains the next. If you choose “enterprise customers” as where to play, your “how to win” cannot be “move fast and break things.”

Wardley Mapping

Simon Wardley’s approach is particularly powerful for technology strategy because it makes the evolution of components explicit.

The key insight: every technology component moves through stages — Genesis (novel) to Custom (built for you) to Product (buy it) to Commodity (utility). Your strategy should:

• Build where you have genesis/custom advantage (your differentiator)
• Buy what has become product/commodity (do not waste engineering on solved problems)
• Anticipate what is about to commoditize and stop investing there before your competitors do

Application: When deciding whether to build vs. buy an AI framework, map the components. LLM inference is becoming commodity (use APIs). Prompt engineering is still custom. Evaluation/guardrails are genesis. Your strategic investment should be in eval and guardrails, not in running your own models.

---

OKR Cascading — Making Strategy Real

OKRs (Objectives and Key Results) are the most common mechanism for translating strategy into measurable progress. They are also the most commonly butchered.

The OKR Stack Done Right

Company Objective: "Become the #1 AI-powered customer service platform in EMEA"
  |
  |- KR1: Achieve 50% AI resolution rate (from 20%)
  |- KR2: Reduce average handle time to < 90 seconds
  |- KR3: Onboard 15 enterprise customers
  |
  |-- Team Objective (AI Platform): "Ship production-ready AI agent framework"
        |
        |- KR1: 3 customer-facing agents in production with < 200ms P95 latency
        |- KR2: Guardrail framework catches 99% of policy violations in eval suite
        |- KR3: Agent creation time < 2 days for a new use case (from 3 weeks)

Common OKR Dysfunctions

Dysfunction	What Happens	The Fix
Task masquerading as KR	“KR: Launch feature X” — this is an output, not an outcome	Ask “what would change if we launched X?” That change is the KR.
Sandbagged OKRs	Team consistently hits 100%. They are not stretching.	OKRs should have ~70% expected attainment. 100% means you aimed too low.
OKR-strategy disconnect	Team OKRs do not trace back to company strategy	Every team OKR should answer: “which company KR does this serve?” If it does not, why are we doing it?
Too many OKRs	5 objectives with 4 KRs each = 20 things to track = tracking nothing	Max 3 objectives, 3-4 KRs each. Ruthlessly cut.
Quarterly churn	OKRs change completely every quarter	Strategy-level OKRs should be stable for 2-4 quarters. Only initiative-level OKRs change quarterly.
OKRs as performance reviews	KR attainment = bonus/rating	This guarantees sandbagging. OKRs measure direction, not individual performance.

The Missing Layer: Bets and Initiatives

Between OKRs and tasks, most organizations need an explicit bets layer:

• Bet: A hypothesis about how to move a KR. “We believe that if we add real-time agent coaching, AI resolution rate will increase by 15%.”
• Initiative: The work required to test the bet. “Build coaching module, run A/B test on 3 customer accounts over 6 weeks.”
• Success criteria: How you will know the bet paid off. “AI resolution rate on test accounts exceeds control by 10+ percentage points.”

This framing is powerful because it makes explicit that strategy execution is experimentation, not certainty. Some bets will fail. That is expected. The strategy is the portfolio of bets, not any single one.

---

Communicating Strategy — The Hardest Part

Most leaders spend 90% of their time crafting strategy and 10% communicating it. The ratio should be reversed. Strategy that lives in a slide deck is not strategy — it is a document.

The Repetition Problem

Research (Kotter, 1996) suggests leaders need to communicate a change vision 7-12 times through multiple channels before it sticks. Most leaders say it once in an all-hands, put it in Confluence, and assume everyone got it.

Practical cadence:

• Weekly: Reference the strategy connection in standups and sprint planning. “This ticket matters because [strategy link].”
• Monthly: Dedicated strategy update in team meetings. What has changed? What have we learned? What are we doubling down on?
• Quarterly: Full strategy review with the team. Are we still making the right choices? What should we stop doing?

The Translation Problem

Different audiences need different framings of the same strategy:

Audience	They Care About	Frame Strategy As
Senior ICs / Staff Engineers	Technical direction, architecture implications	“Here is how this changes what we build and how we build it”
Mid-level Engineers	What they will work on, growth opportunities	“Here is what this means for your work and your career”
Product Managers	Customer outcomes, competitive positioning	“Here is how this changes what we ship and why customers will care”
Executive stakeholders	Business impact, risk, timeline, investment	“Here is the ROI, the risk profile, and what we need from you”
Cross-functional peers	Dependencies, collaboration, shared goals	“Here is where we need each other and how we can help”

The Narrative Structure

The most effective strategy communications follow a three-act structure:

1. Context (Why now): What has changed in the market, technology, or organization that makes this strategy necessary? Do not assume people see what you see.
2. Choice (What we are doing and not doing): State the strategy clearly. Be explicit about tradeoffs. Name what you are saying no to.
3. Consequence (What this means for you): Make it personal. What changes for each audience? What stays the same? What do they need to do differently starting Monday?

---

Strategic Thinking as a Daily Practice

Strategy is not an annual offsite activity. It is a daily thinking discipline.

Questions to Ask Regularly

• “What are we optimizing for?” — If the team cannot answer this in one sentence, you have a strategy problem.
• “What would we stop doing if we took our strategy seriously?” — The gap between stated strategy and actual work allocation is your real strategy.
• “Where are we spending effort on commodity problems?” — Build vs. buy should be revisited quarterly.
• “What are our competitors doing that we are choosing not to do, and why?” — Explicit non-choices are as important as choices.
• “If we only had half the team, what would we cut?” — Forces prioritization honesty.

The Strategy Tax

Every strategic choice creates a tax — ongoing costs that are worth paying as long as the strategy holds, but that compound if the strategy shifts and you do not clean up.

Examples:

• Choosing microservices creates an operational tax (service mesh, distributed tracing, deployment complexity)
• Choosing AWS creates a vendor tax (AWS-specific patterns, certifications, cost management)
• Choosing to support multiple AI model providers creates an abstraction tax (adapter layers, testing matrix)

The discipline: Regularly audit your strategy taxes. When the strategy that justified them changes, the taxes need to be retired. Most technical debt is actually strategy tax from decisions whose underlying strategy is no longer valid.

---

Anti-Patterns

Anti-Pattern	Description	Consequence
Vision without strategy	Inspiring destination, no choices about how to get there	Diffused effort, no progress
Strategy without communication	Great strategy in a slide deck no one reads	Team executes based on local optimization, not strategic alignment
Annual strategy	Strategy set once per year, never revisited	Strategy is stale by Q2, team learns to ignore it
Strategy by committee	Everyone must agree before choices are made	Lowest-common-denominator strategy that differentiates nothing
Copy-paste strategy	Adopting another company’s strategy wholesale	Their context is not your context; what works for Spotify does not work for a 50-person startup
OKR theater	OKRs exist on paper but do not drive decisions	Teams learn that stated priorities and real priorities diverge
Strategy-execution gap	Clear strategy, but day-to-day decisions contradict it	“We say AI-first but every new project is a CRUD app”

---

References

• Martin, R. & Lafley, A.G. (2013). Playing to Win: How Strategy Really Works. Harvard Business Review Press. — The five choices framework; the best accessible strategy book.
• Porter, M.E. (1996). “What Is Strategy?” Harvard Business Review. — The seminal argument that strategy is about tradeoffs and choosing what not to do.
• Wardley, S. (2020). Wardley Maps. Available free at learnwardleymapping.com. — Component evolution and situational awareness for tech strategy.
• Doerr, J. (2018). Measure What Matters. Portfolio. — The OKR bible, with case studies from Google, Intel, and others.
• Kotter, J.P. (1996). Leading Change. Harvard Business School Press. — The communication repetition research and the urgency/vision framework.
• Rumelt, R. (2011). Good Strategy Bad Strategy. Crown Business. — The “kernel” of strategy: diagnosis, guiding policy, coherent actions.
• Grove, A.S. (1996). Only the Paranoid Survive. Currency Doubleday. — Strategic inflection points and how to recognize them.
• Bezos, J. (various). Amazon shareholder letters. — Working backwards, two-pizza teams, Day 1 thinking as strategic discipline.
• Larson, W. (2019). An Elegant Puzzle. Stripe Press. — Engineering strategy in practice (sizing teams, migrations, technical quality).
• Fournier, C. (2017). The Manager’s Path. O’Reilly. — Strategy communication at different management levels.