📖 Business
Technical Vision and Strategy
Two distinct documents that staff engineers own and maintain, often conflated but serving fundamentally different purposes. The **technical vision** describes where your systems are going — a north star that paints a picture of the future state 2-5 years out. The **technical strategy** describes how you get there — the concrete plan with steps, trade-offs, and dependencies. Reilly argues that most organizations skip the vision and go straight to strategy, which means teams are executing plans without agreeing on the destination. The result: local optimizations that conflict with each other, architectural decisions that age poorly, and recurring debates about direction that should have been settled once.
2
Minutes
2
Concepts
+45
XP
1
How It Works
Technical Vision (the destination):
- Not a plan — a description of the end state
- Should be exciting enough to motivate and clear enough to evaluate proposals against
- Written so that anyone can ask "does this move us toward or away from the vision?" and get an unambiguous answer
- Rarely changes — major pivots might update it yearly, but the vision should be stable
- Example: "All data flows through a unified event bus. Services are independently deployable. A new engineer can ship to production on their first day."
Technical Strategy (the plan):
- Concrete steps, milestones, migration paths, dependency ordering
- Includes trade-offs — what you're choosing NOT to do and why
- Specific enough that teams can make autonomous decisions by checking against it
- Updates frequently — quarterly at minimum, or whenever the landscape shifts
- Example: "Q1: Extract auth into a shared service. Q2: Migrate user-facing APIs to the new gateway. Q3: Deprecate the monolith's auth module."
The relationship between them:
- Vision sets direction; strategy plots the course
- You can change strategy without changing vision (different route, same destination)
- Changing vision is a big deal — it means the destination moved
- Both must be written down and socialized. A vision in your head helps nobody.
How to write them:
- Start with the vision. Get buy-in from leadership and key engineers before writing strategy.
- The vision should fit on one page. If it's longer, it's not clear enough.
- The strategy should be detailed enough to act on but not so detailed it's a project plan.
- Socialize both broadly. Present at all-hands, link from wikis, reference in design reviews.