Mastering Async Communication in a Remote World

This is one of my favorite posts/documents I have written. I wrote it during the pandemic (2020–21), when InfraCloud, the organization I work with, decided to go fully remote. It was published at infracloud.io on 11th April 2023: Mastering Async Communication in a Remote World.

As a remote first organization, we encourage everyone to follow asynchronous communication while working with our peers and customers at InfraCloud. This article about writing better messages is directly from our internal handbook. It was written for Slack, but the details should apply to any text-based communication platform. We think this will be beneficial to a wider audience, as more companies are adopting a hybrid or remote way of working.

When it comes to text-based communication, it is mostly about using Slack, Microsoft Teams, email, and other such tools. We use Slack as an instant messaging platform, so this section talks mostly about that. When used correctly, these tools help you to do asynchronous communication. Otherwise, these can be very distracting, and waste your time.

Asynchronous communication ensures that communication doesn’t get time-consuming leaving no or less time to code/design or problem-solving. Asynchronous communication is any type of communication that doesn’t happen in real-time and allows the recipient or recipients of the information to respond on their own time.

Like sending great emails or writing effective processes, asynchronous messages are something you have to learn to do over time.

The flow state (zone)

Before we talk more about text-based communication, let’s discuss a bit about focused work.

When you are focused on one thing and lose track of time, that phase is the flow state. It is the time where the person is most creative, and productive. This is widely known in the engineering organization, sometimes referred to as being in the zone.

The most important part of our work is problem-solving whether it is software engineering, marketing, sales, people operations, or any other function in the organization. And problem-solving is a creative endeavor hence the focused time is extremely important.

The Slack messages can create interrupts, which can get someone out of this zone. Too many interrupts can result in a distracted state, where the person is less productive, and less creative. One has to switch the context to and fro between what they were doing and what is being discussed/ asked in the message. So, whenever you want to send a message, always make sure you respect the other people’s time and their focused state. This does not mean you avoid sending messages to someone at all, we will see specific things with examples. You can read more about the flow state in the Google SRE book.

Slack basics

If you are new to Slack, don’t worry. Just take a look at a few of the videos from Slack video tutorials page. The videos are small, so go ahead and watch them quickly, we will wait for you here 😉

Add enough details to cover follow-up questions

The message should have enough context about the topic which you are talking about, or the question you are asking. This reduces the loop of question and answers. Whenever someone reads the message, they can reply right away with the solution or their thoughts instead of asking follow-up questions. That way they also have a clear picture if they want to reply to that message immediately or come to it later. As discussed earlier this reduces the to and fro context switches as well.

The following points will help you to write detailed messages:

• Try to specify why of the question Example:

  ❌	✅
  I don’t have access to the Google Document, can someone please provide me access?	I wanted access to the Google Document, because I wanted to add some comments/suggestions. Can someone please provide me the access? This is my email address: …

• Add more context and provide a TL;DR (Too Long Didn’t Read) at the beginning That way one can quickly read the problem/message. And look at the whole context if they need more information. This also helps them to decide whether they want to reply immediately or come back later.

  Example:

  TL;DR: Kubernetes 1.16 InitContainer SecurityContext issues: Y: operation not permitted- must be root

  I’ve added an initContainer to a pod running ABC application to do X but it returns error “Y: operation not permitted- must be root”.

• Don’t assume that people will have all the background information of the thing you are talking about Check if the group of people you are going to send the message to, has enough background/context about the question/topic you are going to talk about. Based on the targeted audience of the message, add more context. It is not possible for them to read your mind 🧙, so make sure to add the required context.

  A XKCD comic (1860) about communication

• Mention what do you want to get out of the communication? Is it an approval on a task? An asset of some kind? Be extremely clear. The intention of the ask should be crystal clear, so that the person responding knows what is expected from them next. Example:

  ❌	✅
  Hey vishal, I’m planning to take the day off next week.	Hey vishal, I’m planning to take the day off next week for some personal work, can you please approve my leave on the portal.

• Include a deadline Try to answer the following questions: When do you need a response by? How urgent is it? Which task is being blocked right now? Always mention the deadline on the question/information asked, so that the tasks can be prioritized accordingly. A deadline should be mentioned at the start of the message, rather than at the end. This is especially useful when the message is long.

Always use public channels

All the communication should happen over public channels where all employees/teammates are present, unless something is very private like salary-related, or confidential. This can be your team’s channel or an organization-wide channel.

• Having the discussion in public channels will help other teammates to get the context.
• They can pitch in if they have something to say about the topic.
• You will not have to explain the same thing to every teammate, and there will not be any miscommunication.

Be ruthless in avoiding private communication, if anyone sends you a private message which shouldn’t be private, copy-paste the message in the appropriate public channel and reply there. Private communication works against transparency and the more walls we build more time and effort will be spent in communicating than actual work.

Use Slack threads per topic

Each discussion in the channel should happen in the Slack threads. When replying to a message, make sure your reply is in the thread and not on the channel.

• That way all the conversation related to that issue/topic remains at one place.
• Only people involved in the discussion get notified.
• People can follow the threads (Slack feature), if they are interested in the discussion.

If the discussion is spread across the whole channel, it clutters other discussions and it is hard to read the discussion as a whole.

Take a look at the Slack’s Use threads to organise discussions document, if you are new to Slack.

❌ One reply is in the channel	✅ These are replies from the thread

Specific scenarios

This section covers more specific scenarios which you should take care of.

Avoid naked pings

As our aim is to reduce the number of interrupts, it is recommended to avoid doing naked pings. Naked pings are the messages which are just ‘Hi’, ‘Good morning’ etc without any other context with them.

• These messages result in a to and fro messaging loop, as well as waste time.
• The person who sees your message had to reply and then again wait for your reply.
• If you directly talk about the topic you want to discuss, the recipient of the message can see the message and decide if they want to reply immediately or respond after some time.

Won’t it be rude to just shoot message immediately? Not at all, rather you are respecting the recipient’s time and sending out a clear message with context.

Notice the timestamps in the following images.

❌	✅

Take a look at No Hello and Naked Pings for a more detailed explanation.

Use single message

Try to write the things you want to convey in a single message instead of posting a bunch of small messages one after another.

• This helps you to think more and consolidate your thoughts before sending the message.
• Reduces the number of interrupts.

Simply, reading your message one or two times before sending will help you to write it as a single message.

Asking for a call/meeting

Be it a request for a quick call or a long running meeting, make sure you add proper context to your request.

Include the following details:

• What it is about?
• What are your suitable time slots for the meeting/call.
• Provide a meeting link if it is a quick call.

That way, the context is clear and the message is actionable to the recipient. They can quickly reply with the time slot which is suitable for them based on your time slots.

For long running meetings: once all required participants agree upon a common time, make sure you send out a meeting invite with more details and an agenda.

❌	✅

If you receive a call request, and you can’t join it soon:

Ask the sender to add more details about the topic, so that you can take a look at it later. And decide whether to reply or have a call sometime later.

Sometimes you might not need a meeting at all!

Asking technical questions

Don’t ask to ask

No question is easy or silly. Don’t hesitate to post questions when you feel stuck or want to understand something in detail after doing your own research. Your question can help others as well.

A XKCD comic (1053) about asking questions

Post your question directly and avoid asking questions like “Has anyone worked with Terraform?”.

• Such questions are not actionable.
• They result in multiple to and fro messages.

If the question is posted directly, someone who has knowledge in that area will definitely reply to you. Someone who is willing to help might even try to figure out what is happening and then reply to you.

Take a look at Don’t ask to ask, just ask for a more detailed explanation.

How to ask the question

Once you have done your own research, searched on the internet, looked at the docs etc, follow this checklist to ask the question the right way.

• What are you trying to achieve?
• Which are the involved tools/libraries and their versions?
• Where/when do you get the error?
• What is the exact error message you get?
• What have you tried so far to solve this issue? Include those links in the message.
• Are there any documentation pages that you were following? Include those as well.

Use the code blocks when posting logs, code snippets on the channel. If you don’t know how to do that, no worries! Take a look at the ‘In-line code’ section from the Format your messages document.

❌	✅

It is highly recommended to read How To Ask Questions The Smart Way and How do I ask a good question? to understand this in a more detailed way.

Make sure you add the solution to the thread if you manage to solve it later with everyone’s help or on your own.

Other things

• Use most appropriate channel for your message. For instance, engineering related queries can go to #engineering, random conversations go to #random and all memes in #memes. At InfraCloud we use #engineering, #random and #giphy for the same.
• Avoid use of SMS language. For example use ‘you’ instead of ‘u’.
• Never use @here, @channel unless something is burning. Those mentions are very distracting.
• If there are too many people in the channel, then tag the specific people with whom you want to talk.
• If you want some information to persist over time, then use Confluence or Google Docs and share link on Slack/email.
• Never share credentials over Slack, use password managers, GPG etc to do that.

Congratulations! You now have learned the basics to have asynchronous communication over Slack. If you find someone not following these practices, send them link to a specific section and try to coach them about this.

I hope you found this post informative. Some parts of it are written by Girish Shilamkar, Sanket Sudake, and Anju Yadav. And it is based on many other articles and conference talks. If you find any reference missing, do let us know. I would like to hear your thoughts, feel free to DM me on Twitter.