Chapter 3 Flashcards — Creating the Big Picture
flashcards tsep technical-vision technical-strategy rumelt nemawashi
What is the difference between a technical vision and a technical strategy?
?
Technical vision describes the desired future state — what the technical landscape should look like in 3–5 years if all goes well. It answers: “What does good look like?” It is a destination, not a plan, and changes slowly.
Technical strategy is the actionable roadmap from current state to vision. It answers: “How do we get there?” It uses Rumelt’s kernel and updates regularly as conditions change.
What are the three components of Rumelt’s kernel for a good strategy?
?
- Diagnosis — a clear, specific description of the actual challenge (not a list of all problems, but the crux)
- Guiding policy — the constraint or approach governing how you’ll respond to the diagnosis; explicitly names trade-offs
- Coherent actions — specific, aligned steps that implement the guiding policy; every action points in the same direction
What makes a strategy “bad” vs. “good” in Rumelt’s framework?
?
Bad strategy:
- Diagnosis is a vague problem list without prioritization
- Guiding policy is “be excellent” — doesn’t name what you’re giving up
- Actions are a grab-bag of good ideas that don’t connect to each other
- Avoids trade-offs
Good strategy:
- Diagnosis names the specific, real challenge
- Guiding policy explicitly states what matters even over something else valuable
- Actions are coherent — they all reinforce the guiding policy
- Names what you’re not doing
What is an “even over” statement and why is it important?
?
An “even over” statement makes trade-offs explicit: “We value X even over Y” — where both X and Y are genuinely valuable things. When they conflict, X wins. Examples: “We value team autonomy even over shared infrastructure” or “We value data consistency even over availability.”
These statements are important because they convert a vague strategy (“be good at everything”) into a specific decision framework. They’re often controversial — that controversy is evidence that real trade-offs are being made.
What is nemawashi and why does it matter for technical strategy?
?
Nemawashi (根回し) is a Japanese concept meaning “going around the roots” — the practice of informally laying groundwork with key stakeholders before a formal decision. Named after the preparation of a tree for transplanting by loosening the soil around its roots.
It matters because formal reviews go faster when key influencers have already heard the idea, raised their concerns, and had them addressed informally. Without nemawashi, a formal review can surface objections that derail everything. With it, the formal review is largely a confirmation of already-reached informal consensus.
What is “rough consensus” and how does it differ from unanimity?
?
Rough consensus (from IETF engineering culture) means there is a prevailing view from a large portion of the group, and while some individuals disagree, the vast majority agrees the position is correct. It requires that all serious objections have been heard and addressed — not that everyone agrees.
It’s the practical standard for large technical decisions where unanimity is impossible. The alternative to rough consensus is either endless debate or a dictated decision that lacks buy-in.
What are the five setup steps before writing a technical vision or strategy?
?
- Start with boring ideas — the vision should be what experienced engineers would say “of course” to, not a novel invention. Novelty makes consensus harder.
- Join an existing expedition — if someone has started this work, join rather than compete.
- Get a sponsor — a leader who will support and protect the work. Without organizational backing, even excellent documents go nowhere.
- Choose a core group — small (5–8), diverse, trusted people who will do the drafting. Large committees don’t write.
- Set scope — be explicit about what the strategy covers and doesn’t.
What are the most common reasons a technical strategy fails after being written?
?
- No official endorsement — it lives in a wiki folder without organizational backing; teams ignore it
- No sponsor — nobody in a position of authority will defend it when challenged
- Stale content — conditions changed but the document wasn’t updated; now it sends teams in the wrong direction
- Vague guiding policy — doesn’t actually constrain anything; teams interpret it however they want
- Too many cooks — large committee negotiations produced a document that says nothing specific