Creating a Reference Architecture
24 September, 2021
null null
null at A Startup
Problem
As a team grows and becomes more distributed, it becomes increasingly difficult to communicate the company vision across various teams. Not day-to-day work of every team would require thinking about the company product, the problem that is solved for customers, or how all of those pieces come together. Over time, teams get to specialize, become more siloed and fail to understand the bigger picture. We saw this happening when we moved from being US-centric to becoming a global business with a focus on Europe and APACand new products launched across those regions.
Actions taken
To mend the problem, we created a reference architecture for the company. It is a document that takes the form of several diagrams and a narrative around these diagrams and which serves as the North Star showcasing where the company is going. The document doesn’t state where the company and teams are today but is a representation of what we plan to make of the company and its products. It balances being too technical and burdened with technical terminology with being too high-level and resembling an executive-level presentation. It details how our products fit into the ecosystem, which teams fall under different big areas, and how the overall progression will look like.
It took us several weeks to do it. We brought together leaders from different teams to share their input on the diagramming side, and then one person took the lead on writing the narrative. The narrative should be communicated as a story, and help from marketing folks could be crucial in making that story compelling. If the whole process is run well, the final document should be something that will resonate with everyone in the company, from ICs to the CEO.
I think that identifying key individuals in every significant stakeholder’s group who will serve as a voice for that group is critical. The companies struggling with this problem are usually large, and different departments can have conflicting interests as well as visions of where the company should be heading. I would try to ensure representation across the board, which is best accomplished by forming a co-working group that would be willing to spend a couple of hours every week progressing this. The more unison achieved during the process should vouch for better adoption of the document.
Lessons learned
- We developed the reference architecture to point to teams not where we are now but where we are going. This is an evolving, not a static kind of document. Static documents can make people anxious and pessimistic because they look like everything is decided and set in stone. If you don’t speak about evolution, people will not be motivated to strive to get somewhere. Of course, the point is not to get there but to be on the road. But as long as you are moving forward, you are realizing the vision.
- You need to keep up-to-date on this document. Doing it for the first time takes a significant effort but once you did it, you will need a dedicated person to keep it up-to-date. A dedicated person can be a manager, senior manager, or chief architect, but you have to make sure that everyone knows who is responsible for refreshing the document every quarter.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
5 December
Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Jaroslav Pantsjoha
Google Cloud Practice lead at Contino
14 October
Teams have tremendous impact on the products on they build. T.E.A.M definition - Together Everybody Achieves More is true. A collaborative and empowered team builds great product versus the good ones.

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan
14 October
There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan
12 July
A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Ram Singh
Principal / Founder at id8 inc