‘Glass heart’ is probably the biggest obstacle to participating in open source, which has a lot to do with one’s psychological maturity and daily upbringing. People with super empathy will adapt quickly, while those who lack it will find it hard to accept. The global collaboration model brought by the internet, exemplified by the success of open source software projects like Linux, confirms this. So we need to rationally overcome this, especially when adapting to remote work.
Summary
Reducing the number of meetings while improving communication quality is no longer just talk. This article shows you how asynchronous decision-making can achieve the desired results.
Asynchronous decision-making has become a common decision-making strategy to some extent, especially for distributed software teams from around the world. Asynchronous decision-making is particularly critical for this type of team. In the following discussion, I will try to discuss and explain how asynchronous decision-making can become a tool for remote teams, as well as some useful principles.
I believe everyone is very familiar with synchronous decision-making, whose obvious advantage is that participants can interact in real-time. Paul Graham, author of “Hackers & Painters”, wrote a blog post: Maker’s Schedule. When we interrupt what these makers are doing, the cost is quite expensive. Of course, for remote teams, synchronous decision-making is almost impossible. I believe those with similar experience must realize the pain of trying to achieve synchronous meetings - all kinds of waiting, wasting time, inefficiency, constant confirmation, etc.
In contrast, we must accept reality and use asynchronous decision-making for communication. This is also a strategy often adopted by many large open source projects. Take a classic example: at the Apache Software Foundation (ASF, as I will refer to it throughout), where I am most active, meetings are minimized as much as possible, and the team maintains an effective way to move forward. Many projects under the Apache Software Foundation only hold a few meetings per year (or even no meetings at all), but the development teams can consistently produce high-quality open source software.
So how does asynchronous decision-making work?
Essential Tools
Centralized Asynchronous Communication Channels
To implement asynchronous decision-making, the first problem to solve is to have a centralized communication channel. Regardless of the implementation, there are some required features, such as all team members getting the same information, supporting threaded discussions, where relevant people discuss on one thread while ignoring other topics discussed in the same channel. I don’t know if you’re familiar with marine radio, but it works by using broadcast to the maximum extent to attract the attention of specific groups, and then entering corresponding sub-channels for further discussion.
Many open source projects still use mailing lists as centralized communication channels. Of course, the younger generation of software developers today might think this method is outdated and clumsy. Mailing lists do require a certain amount of restraint and discipline to effectively manage busy, high-traffic content, especially when it comes to interesting items. Each thread must stick to one topic and ensure topics don’t repeat. Even so, so far, with correct use and combined with indexed archives, mailing lists are still the perfect centralized asynchronous communication channel.
Enterprise teams may benefit from more modern collaboration tools that are easier to use and provide more powerful multimedia features. Regardless of the tool used, the key is to create a channel where large numbers of people can communicate efficiently and asynchronously on various topics. Based on actual observations, to create a consistent, highly engaged community, one busy channel is better than many scattered channels.
Consensus Building Mechanism
Second, it’s not actually a tool, but a spiritual content, that is, reaching consensus. Only with consensus can we avoid deadlocks and move things forward. Everyone thinks unanimous decisions among many people is the ideal situation, but this is often wishful thinking. As a second best option, we hope to reach consensus: “forming effective broad consensus among those with decision-making power.” We know that requiring unanimous agreement or vetoing decisions will hinder progress. Therefore, at ASF, the use of veto power is limited to certain situations. ASF’s voting mechanism has developed effectively over the years and has been recognized by the world and often imitated. If certain teams are similar to ASF, such as not having a boss with centralized power, then building consensus in such loosely coupled teams is very helpful. Of course, another situation is when consensus doesn’t naturally emerge, it’s also a very effective method.
Case Management System
Consensus is often reached in the project’s centralized communication channel, which we described earlier. But for very complex situations, some third-party tools may be needed to complete this. This tool is: Case Management System. This way, everyone can use the central communication channel for informal discussions and brainstorming. When certain content that needs decision-making gradually emerges, the Case Management System can be introduced.
Case Management Systems can more accurately organize decisions. For smaller teams with relatively few decisions, there’s no need for such a system. But when things get complex, saving details of discussions about specific decisions and related information in a specific place is of great help to the team.
Actually, a Case Management System doesn’t necessarily have to be a complex software system. ASF uses the simplest issue tracking, originally designed for web-based problem tracking and bug management. Each Case is discussed and handled on the same page, including all comments and all operation records. This is very useful for tracking decisions and all the paths taken for such decisions. For example, some non-urgent or complex decisions may take a long time to reach completion. Having historical records in one place is of great benefit. Especially for new members, they can read these issues to understand what decisions have been made recently, which decisions are still under discussion, who participated in these decisions, and the background behind each decision, so they can quickly integrate into the team.
Success Stories
The ASF board has nine members who make many decisions during regular monthly phone meetings, but the meetings don’t exceed two hours. The reason for such efficiency is that we did very detailed work in the early stage, and of course, all this work was done asynchronously. The benefit of this is that we can focus the meeting on complex or uncertain matters, rather than focusing on those trivial full/partial consensus issues.
In fact, similar meetings are not uncommon outside the software industry. For example, the weekly meetings of the Swiss Federal Council. Their approach is very similar to ASF. The team also uses asynchronous decision-making to build consensus, thus making full preparations for meetings. The meeting agenda consists of a set of color-coded lists that indicate which items can be quickly approved, which need more discussion, and which items are expected to be more complex. In this way, a committee of only 7 people can handle over 5,000 decisions per year. Calculating carefully, there are only about 50 weeks in a year, and they only meet for a few hours each week. This is a very remarkable achievement.
Based on my personal experience, I can responsibly say that asynchronous decision-making mechanisms are worth investing in. The tools are ready-made, and of course, they need to be verified by time. It can also bring the benefit of happy work to team members, and this is the key to the success of anything.
About the Author
Bertrand Delacretaz is a principal scientist at Adobe’s research team in Basel, Switzerland. He devotes a lot of time to advocating and implementing open development, providing his colleagues with more efficient, interesting, geographically dispersed, and efficient teams. Bertrand is also an active member of the Apache Software Foundation. At the time of writing this article (2017), he served as a director of the ASF Foundation, one of nine members.
This article was published by Bertrand Delacretaz on Opensource.com: Asynchronous decision-making: Helping remote teams succeed.
Reprinted with permission: Developer Relations »
