A technical vision is sometimes called a “north star” or “shining city on the hill.” It doesn’t set out to make all of the decisions, but it should remove sources of conflict or ambiguity and empower everyone to choose their own path while being confident that they’ll end up at the right place. Resources for Writing a Technical Vision If you’re setting out to write a technology vision document, here are some resources I recommend: Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly) Chapter 4 of Making Things Happen by Scott Berkun (O’Reilly) “How to Set the Technical Direction for Your Team”, by James Hood of Amazon “Writing Our 3-Year Technical Vision”, by Daniel Micol of Eventbrite There’s no particular standard for what a vision looks like. It could be a pithy inspirational “vision statement” sentence, a 20-page essay, or a slide deck. It might include: A description of high-level values and goals A set of principles to use for making decisions A summary of decisions that have already been made An architectural diagram It could be very detailed and go into technology choices, or it could stay high-level and leave all of the details to whoever is implementing it. Whatever you create, it should be clear and opinionated, it should describe a realistic better future, and it should meet your organization’s needs. If you could wave a magic wand and be done, what would your architecture, processes, teams, culture, or capabilities be? That’s your vision.2070 ↱
The Staff Engineer's Path
Tanya Reilly