Architecture decision logging
‘Drive Clarity in decision making’ explains the importance of ensuring that teams understand decisions being made and there is a DACI in place. A DACI ensures that the driver and the approver is known, and the team has the ability to participate in the decision making process.
A best practice is using a Jira/Kanban board for decision making. Anyone can propose a decision: Just like any other Jira backlog, it moves through states — proposed-open for feedback-accepted/rejected.
Each Engineering Decision backlog item has a very specific format. The proposer must follow the following format
Background: What is the backdrop that people need to understand?
Proposal: What is the author proposing we should do?
Rationale: Why does this decision make sense to the driver?
Black hat: What are the potential reasons to *not* make this decision? i.e. thinking through the downsides of the decision
Once a proposed decision has been opened, it is shared on the slack channel for all engineers (in some cases, we include other functions like product/marketing depending on the scope and impact of the decision). It is open for feedback for two weeks (typical) at which point the approver makes a decision.
The goal is not to say yes to everything: the goal is that (a) anyone can propose a change and (b) the entire team gets to participate in it asynchronously. The key value of this process is transparency and lack of surprises — decisions have not only been communicated, but enabled participation of the entire team.
At times, these decisions can be polarizing. But a polarizing decision in which everyone got a chance to participate is better than one in which they did not. The goal, as outlined in the decision making post in my blog is to ensure that everyone commits, even if they do not agree.
I solve for an egoless decision making process. I set an example by asking others to be approvers for what I am proposing: and show this in action by accepting the decision made by others. The only thing that matters in decisions are ‘are we doing the right thing for our customers and partners’. Ego has no place in this.
A huge added benefit is that the discussion and decisions are preserved. There have been times when we have thought ‘why the heck did we make this decision?’ — and you know what, we know exactly why. We have the decision logged, the rationale and the debate that lead to the decision as well as the decision maker.
Software development has parallels to archeology. The more you dig, the more layers of technology show up. The Architecture decision logging allows you to understand why a new layer formed, and a roadmap to the fossils within.
