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
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.
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
|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
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.
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.
|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
- 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
- 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
This section covers more specific scenarios which you should take care
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
- 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
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
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
- 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.
- 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
@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.