One of the key responsibilities of a tech lead or architect is to ensure there is a shared understanding of where the team is heading. A clear Technical Vision is really important so that everyone on the team pulls together in the same direction instead of moving in potentially different ways, or worse, pulling against each other. What follows are three tips I think about when focused on building a Technical Vision.
1. Use a visual
Although developers will often joke about the “whitebord architect”, I find diagrams are a powerful way of articulating ideas that cannot be succinctly expressed in code or words alone. I highly recommend Simon Brown’s The Art of Visualising Software Architecture which provides concrete advice to make your diagrams better.
Your first step in building a Technical Vision is to make sure you use some sort of visual model. Using words alone leads to unintentional misinterpretations or misunderstandings. Diagrams offer different perspectives and a shared model between two people. Use a number of visuals to model different perspectives but identify first what perspective you find adds the most to shared understanding.
TOGAF list a number of potential perspectives you might visualise. Remember however that more models does not lead to a better understanding. Diagrams are only a tool to aid communication, not to replace it. This leads nicely onto our second tip.
2. Discuss as a team
Successful architects and tech leads build a shared understanding of the Technical Vision by involving the entire team in its creation. Whiteboards are your best tool here to allow for real-time collaborative creation. A model is best built block by block with the same shared context and story.
Building a visual together is a much more effective way than printing off a PDF or asking people to view a static copy on a wiki. Beware your human sunk cost fallacy cognitive bias which my colleague Neal Ford calls the Irrational Artefact Attachment. Try not to invest too much time in any models or diagrams, or you’ll find yourself (irrationally) defending or preventing change to the model which leads us to the third and final tip.
3. Iterate – reflect and review
A real Technical Vision must incorporate feedback. Unlike the once-off architecture models written by true ivory tower architects, the Technical Vision should be revisited as the system evolves and as the team learn more about the domain and constraints of their environment.
Look to review the shared Technical Vision as a team on a frequent basis (once every three months is a good guideline for a long-lived system) to ensure the shared understanding is the same.
