At work, we switched from an architecture team to an architecture guild. We believed that a transition to a guild would enable us to spread design decision-making across the organization, gain transparency, and spread knowledge on designing our software.
The architecture guild is responsible for making important system design decisions, impacting multiple teams. It consists of engineers who rotate in and out of the guild. We follow a lightweight process, from RFC (Request for Comment) to ADR (Architecture Decision Record), after which they end up in product teams (permanent) or mission teams (temporary).
To make sure that decisions happen effectively, we use the DACI framework, a proven tool for making group decisions.
DACI stands for Driver, Approver, Contributor, and Informed.
The Driver is responsible for guaranteeing that everything in the decision-making process will get done. For example, ensuring that stakeholders are aware, we have all the information and complete all action items.
The Approver is the decision-maker and the person finally accountable for the decision.
The Contributor is a person or group knowledgeable enough to influence the decision-making process with their experience — the advice-givers.
Finally, the Informed are the people who need to know about the decision because it will impact them.
The DACI is a simple framework that clarifies the process and everyone's roles and responsibilities.
DACI and the Architecture Guild
The Driver of the Architecture Guild is the "Speaker of the Guild," a rotating member responsible for making sure we are following the process. Some of their responsibilities are identifying the DACI, ensuring the RFC is good quality and contributing to the conversation.
They also need to drive towards a decision. In the past, we have seen that RFCs did not receive the review they deserved, meaning we were not making decisions.
To prevent that from happening, we now have a default window of two weeks where RFCs need to be reviewed and either blocked or moved to the next phase.
The Approver of the RFC and ADR is the person closest to implementing the decision and most impacted by it. This person has the most facts. It could be the CTO if it's a decision affecting the future of the entire engineering organization, but usually, it is the team lead responsible for the most impacted domain.
To ensure that Contributors are involved, we ask teams to participate if we think it's part of their domain. We also do stuff like look at the code impacted and find previous contributors or ask around for people who have experience in this area in their earlier roles.
Finally, we inform the engineering organization by having a public #architecture-town-hall channel. We share meeting notes from the guild and notify them of any decisions in flight.
DACI and the Architecture Guild enable us to make design decisions with speed and clarity. Due to the guild's rotating membership, we disseminate the decision-making process and design our systems across the engineering teams. We encourage them to apply the same rigor at the team level, as they did on the guild.
Our move from the architecture team to the architecture guild was received well and is paying a dividend. We went from ivory tower to town hall without losing our ability to make decisions effectively. All while gaining transparency, inclusiveness, and buy-in.