At Degreed, we recently switched from an architecture team to an architecture guild. We believed that a transition to the architecture 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, which can impact multiple teams. It consists of engineers across the organization 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 gets done. Making sure that stakeholders are aware, information is gathered and action items are being completed.
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, providing clarity in 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 who is responsible for making sure we are following the process. Some of their responsibilities are identifying the DACI, making sure the RFC is of good quality, and contributors are involved in 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 make sure to 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 which are 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 also disseminate the decision-making process and how we 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.