Chapter 3: Creating the Big Picture
tsep technical-vision technical-strategy rumelt nemawashi even-over direction-setting
Status: Notes complete
Overview
Chapter 3 is about how to create the organizational documents that give technical direction: vision and strategy. These are the “treasure map” from Chapter 2, made explicit and shared. Most organizations are either directionless (no shared understanding of where they’re heading technically) or stuck in analysis paralysis (endless debate about direction without resolution).
The chapter uses a running case study — SockMatcher, a fictional recommendation engine — to ground abstract concepts. SockMatcher illustrates what happens when a large codebase gets unwieldy and the org needs to define a technical direction. Every tool and technique in the chapter is demonstrated through this scenario.
The central argument: writing vision and strategy is a skill, not a magic talent. It follows a learnable process with concrete steps that any staff engineer can practice.
Core Concepts
Technical vision: A description of a desired future state — what the technical landscape should look like in 3–5 years if all goes well. Answers “what does good look like?” Not a plan; a destination.
Technical strategy: The actionable roadmap from current state to vision. Uses Rumelt’s kernel: diagnosis + guiding policy + coherent actions. Answers “how do we get there?”
Rumelt’s kernel (Richard Rumelt, Good Strategy/Bad Strategy): The three components of a good strategy:
- Diagnosis: A clear description of the challenge — what is actually wrong and why
- Guiding policy: The approach/constraint that governs how you’ll respond to the challenge
- Coherent actions: The specific, aligned actions that implement the guiding policy
“Even over” statements: A format for making trade-offs explicit. “We value X even over Y” — both X and Y are good things, but when they conflict, X wins. These statements define what the vision doesn’t include.
Nemawashi (根回し): A Japanese concept meaning “going around the roots” — the practice of laying informal groundwork with key stakeholders before a formal decision. Named after the process of preparing a tree for transplanting by loosening the soil around its roots first.
Rough consensus: A decision-making standard that doesn’t require unanimity but does require that all serious objections have been heard and addressed. From IETF’s engineering culture.
Vision vs. Strategy
These are different documents with different purposes:
| Technical Vision | Technical Strategy | |
|---|---|---|
| Question | What does good look like? | How do we get there? |
| Time horizon | 3–5 years | 1–2 years, specific |
| Contents | Aspirational state, principles | Problems to solve, approach, actions |
| Stability | Changes slowly (direction) | Updates regularly (plan) |
| Audience | Everyone in engineering | Teams doing the work |
Many organizations skip the vision and jump straight to strategy. This is a mistake — without a shared picture of the destination, different teams will interpret “good” differently and pull in different directions.
Rumelt’s Kernel in Practice
A strategy built on Rumelt’s kernel has these three components:
1. Diagnosis
- Names the specific challenge clearly
- Not “our architecture is messy” — that’s vague
- Good: “Our shared data store is a bottleneck that prevents teams from deploying independently and is the source of 60% of our production incidents”
2. Guiding Policy
- The constraint or approach that will govern responses to the diagnosis
- Sets the trade-offs: “we will prioritize team autonomy even over consistency guarantees”
- Not a list of all good things to do — it specifically rules things out
3. Coherent Actions
- Specific things teams will do
- Coherent means they all point in the same direction, not a grab-bag of good ideas
- Each action must be traceable to the guiding policy
Bad strategy (what to avoid):
- Diagnosis that’s a list of problems without prioritization
- Guiding policy that’s just “be excellent” (no trade-offs named)
- Incoherent actions that don’t connect to each other
The Process for Writing Vision and Strategy
Step 1: Set up for Success
- Start with boring ideas: The vision shouldn’t be a novel invention. It should be the thing that experienced engineers in your domain would say “of course, that’s what good looks like.” Novel = hard to get consensus.
- Join an existing expedition: If someone else has already started this work, join it rather than starting a competing effort.
- Get a sponsor: Find a leader who will support and protect the work. Without organizational backing, even excellent documents go nowhere.
- Choose a core group: Small, diverse, trusted group (5–8 people) who will do the actual drafting. Large committees don’t write good documents.
- Set scope: Be explicit about what the strategy covers and what it doesn’t.
Step 2: The Writing Loop
Interviews: Talk to stakeholders before writing. You need to understand: what are their biggest problems? What have they already tried? What do they need from the technical direction?
Thinking time: Staff engineers need protected time for deep work. Writing a good strategy requires sustained concentration — not something you can do between meetings.
Making decisions with “even over” statements: The hardest part of writing a strategy is making it say something specific. “Even over” statements force this:
- “We value consistency even over availability” (not both)
- “We will invest in team autonomy even over shared infrastructure”
- These are controversial; that’s the point. Discuss, revise, commit.
Building rough consensus: Don’t require everyone to agree; require that serious objections have been heard. Use the IETF definition: “rough consensus means that there is a prevailing view from a large portion of the working group, and that while some individuals disagree, the vast majority agrees the position is correct.”
Nemawashi: Before formal sign-off, have informal conversations with key influencers. “I’m thinking of proposing X — does that resonate with what you’re seeing?” This surfaces objections early, gives people a sense of ownership in the outcome, and makes the formal review faster.
Step 3: Launch and Maintain
Make it official: Get explicit organizational endorsement. A document that lives in a wiki folder without blessing is not a strategy — it’s a proposal. Get it formally adopted.
Keep it fresh: Strategies expire. Quarterly or biannually, review whether the diagnosis still applies, whether the guiding policy is still right, whether the coherent actions need updating. A stale strategy is worse than no strategy — it sends teams in the wrong direction.
Common Failure Modes
| Failure | Description |
|---|---|
| Scope creep | The vision becomes “everything should be good” with no real trade-offs |
| Analysis paralysis | Endless iteration, no decisions made, no document published |
| Too many authors | Large group debates every word; nothing gets written |
| No sponsor | Great document, no organizational support, nobody reads it |
| Stale strategy | Document exists but hasn’t been updated; teams ignore it |
| Vague guiding policy | Strategy doesn’t actually constrain anything |
Key Takeaways
- Technical vision answers “what does good look like?” — a destination, not a plan.
- Technical strategy answers “how do we get there?” using Rumelt’s kernel: diagnosis, guiding policy, coherent actions.
- “Even over” statements are how you make a strategy say something specific and actionable.
- The writing process matters: sponsor, core group, interviews, rough consensus, nemawashi.
- Nemawashi — informal groundwork before formal decisions — is essential for getting controversial documents accepted.
- Launch officially and maintain the strategy; stale or unofficial documents are worse than nothing.
- Bad strategy avoids trade-offs. Good strategy names what you’re giving up.
Related Resources
- ch02-three-maps — The treasure map that vision and strategy create
- ch05-leading-big-projects — How to anchor projects in an existing vision/strategy
- ch06-why-have-we-stopped — When a project stalls because direction is unclear