I had the chance to attend Devoxx France this year in Paris. Here is the most important lesson I learned :
How to avoid unnecessary meetings with asynchronous decision making
Bertrand Delacretaz, a member of the Apache foundation. He gave a great talk about how the open source community handles decision taking. Open source developers are often all over the world, often in different timezones. Meetings are not an option for them. Still, they manage to make great decisions !
Even if you don’t work remotely, avoiding unnecessary meetings is always a great thing !
- You’ll have more time to do productive and interesting stuff
- You’ll avoid interruptions and be even more productive
- If you are an introvert, it’s going to be easier to contribute to the decision
- As people have more time to think through the decision, the result is usually better
💡 Even if you don’t work remotely, avoiding unnecessary meetings is always a great thing !
For the hasty folks among you, here is a summary. The decision making follows 4 stages :
- Open discussion and brainstorming. People discuss openly and suggest ideas in a free form manner.
- Emergence of options. After enough discussion, a few options will start to make more sense than others.
- Coming to a consensus. Someone will draft a formal proposal. People will discuss and amend this proposal until they reach consensus. Consensus is not unanimity !
- Decision. After consensus, the benevolent decision owner validates the decision once and for all.
Until the decision is taken, the process can move forward but also backward.
We need only two tools to make this possible :
- For discussion, brainstorming and emergence of options, use a very open and chatty tool. The speaker called this a “shared asynchronous communication channel”. This can be an online chat, a mailing list or Github issues (ex). It could even be a real life whiteboard if you all had access to it.
- From drafting the proposal to the end, prefer a structured and chronological tool. The speaker suggests using a “shared case management tool”. Draft the proposal in this tool, and use comments to log the latest steps of the decision taking. He had examples using Jira issues (ex) or Github pull requests (ex). To confirm the decision, close the case. The tool will record which version of the decision was exactly taken.
Architecture Decision Record
ADR is the practice of documenting architecture decisions. It makes sure we remember why we took a decision. This can be very useful to know how to deal with the existing software. A widespread practice for ADRs is to use simple text files in git. There are even tools for that. This looks like a perfect fit for decision making using git pull requests ! I’ll write a post about that when I get the chance to try.
💡 Git pull requests based asynchronous decision making is a perfect fit for Architecture Decision Records.
I am currently trying this whole decision making technique at work. We are still in the brainstorming phase. We are using our internal chat app for that. Options are starting to emerge, but we did not move to the consensus part yet. I’ll write a return on experience post when we reach the end.