At the core of asynchronous communication is a messaging system that allows teams to communicate (and work) continuously in public. The necessary features for an effective messaging tool are:
- channel based communication, to gather discussions by team, project or interest. Just be careful to make the channels broad enough to avoid creating new silos.
- threaded discussions, so that notifications are only delivered to the people who showed interest in a particular subject.
- external tools integration (and messaging), to give more visibility on the work being done outside of the messaging system. It is also a way to unify the communication and the notification systems.
Slack was the precursor in this field and is the obvious choice. Microsoft Teams is still an inferior choice IMHO but it can still get the job done, and I heard some companies used Discord successfully in this context. But as per usual, the tool itself is less important than the way we use it as a team.
Over the years, I have found a handful of rules that have helped our teams get the most out of asynchronous communication. None of them are absolute (YMMV), and every team can adapt them differently, but they have served me well over the years:
General principles
- The messaging system is essentially an asynchronous communication tool (except for meetings of course 😅).
- A message never expects an immediate response or reaction.
- You can disable your notifications and focus on your work.
- Take some time multiple times a day to communicate and check on active discussions. Asynchronous means the team is giving you time to react on your own terms, but it does not mean others should have to wait for days for a reply.
- In case of an emergency (if production goes down for example), it will always be beneficial to share the information with as many people as possible on the messaging system, but dedicated urgent communication methods must still be activated to alert the individuals concerned by the emergency.
- Do not wait for a meeting to share a question, a suggestion or even a simple thought:
- communication should be asynchronous and continuous. Share your information now and do not risk forgetting to share it later.
- if no one seems interested in what you have to say, then no big deal. 😉
- if you feel like introducing all your messages with “Hello” or “Hi”, it means that you are probably not communicating continuously enough.
- Be considerate and provide context: do not assume everyone knows what you are talking about. Take time to provide links for people who want to know more about what you are writing about.
- No FOMO: if the messaging system is used properly, it will be impossible for everyone to follow all discussions.
- Every piece of information you receive this way is valuable.
- Every piece missed would have probably been missed as well in a synchronous organization because it would have happened in another silo (ie a meeting, planned or improvised, you were not part of).
- Always try to initiate an exchange asynchronously first (async first). If written communication fails (if it is too difficult to understand each other, for instance), then a synchronous exchange with the stakeholders can be scheduled.
- Following a synchronous coordination, do not forget to report the conclusion of the exchanges in writing so that everyone can follow up on the matter (async last).
Chat based communication
Chats are by nature communication silos which are only accessible to people who have been invited. Except in rare cases where confidentiality is imperative, every discussion, including those between two people, should take place in a public channel instead of a chat.
In any case, Just remember that chats are asynchronous as well.
Channel based communication
- Channels can be created to allow specialized discussions by project, team, or theme. To maximize visibility it is better to start by discussing openly in an existing channel and then decide to redirect an overflow of information to a new dedicated one.
- Automated bot notifications (JIRA notifications, for example) should not be mixed with human discussions in the same channel.
- Everyone is free to subscribe or not to notifications from a channel. But it will obviously be more difficult to communicate effectively if everyone does not subscribe at least to the topics that concern them directly.
- When creating a new channel, it should be promoted in the main channel so that everyone has the chance to subscribe.
- Let people decide what they care about: it is better to broadcast information that interests few people in a general channel than to risk broadcasting important information in a hidden channel that only a few people have subscribed to.
- Avoid systematically mentioning people you want to specifically address in a discussion:
- subscribers to the channel will receive a notification of a new message anyway.
- people already participating in a discussion (reply or reaction) will also receive a notification.
- one of the benefits of open discussion is the passive ability to include people who might unexpectedly have useful insights to contribute.
- Mentioning allows attracting the attention of a specific person who may not be subscribed to the channel (who is outside the team, for example), or to send a (kind) reminder to someone from whom a response is expected.
- Always answer in thread.
- Keep threads focused. Side discussions should be quickly promoted to their own thread.
- Don't keep threads active for too long. Long-running discussions tend to become difficult to follow, and starting a fresh thread can provide a useful reset and summary point. It also shows all the observers the subject is still being discussed.
Microsoft Teams specific rules
Teams requires a few additional conventions because its channel model differs from Slack:
- Channels are a way to organize discussions within a team. The notion of team should be considered very broadly to avoid communication silos.
- Within a team, all _channel_s must allow threaded display mode. This limits notifications to those who are interested in the discussion (those who reacted or replied).
- Within a team, there is always a general discussion channel that interests (at least) the entire_team_.
- It is possible to mark a message as important in a channel. Use this feature sparingly and with discernment: if everything is important, nothing really is.
- Channels are also a way to share resources (documents, files…) accessible to an entire team, present and future.
None of these rules are revolutionary. Their purpose is simply to make communication visible, searchable, and respectful of everyone's attention. The exact tools may change, but the underlying principles remain the same: communicate in the open, write things down, and give people the freedom to respond on their own terms.
Top comments (0)