I am a huge fan of asynchronous communication and the power of the written word, as seen in the syndication of this site, devotion to journaling, the Git rebase workflow for empowering quality code, interviewing practices, performance reviews, and so much more. Used effectively, group chat is one of the most powerful tools for asynchronous collaboration, and I’m not the only ones who thinks so. Doist has written several articles about asynchronous communication that bring up group chat and that I highly recommend:
๐ก This article assumes knowledge of these Doist posts, which are worth reading in their entirety before we continue. Don’t worry, I’ll be here when you get back. ๐
Advantages
To summarize some of the conclusions drawn by Doist:
-
Asynchronous communication empowers distributed staff to work wherever they want and whenever they like. As long as progress is being made and communication is transparent, the sky is the limit to what a team can accomplish together.
-
Transparent communication means anyone can be involved in decisions, democratizing the team.
-
Counteracts presenteeism which is more insidious and costly than most organizations/teams realize.
-
Having a historic record of all conversations gives people new to the team a chance to catch up and understand the long tail of how the team got to where they are today. Additionally, the ability to quickly search through past conversations in order not to repeat yourself is invaluable.
Services
Several services support group chat. Briefly, here are the ones you’ll want to consider or avoid entirely:
-
Twist - Built with the sole purpose of being asynchronous from the start. Twist is the leader in this space right now and best choice.
-
Yac - Yac is a nice compliment to Twist with a strong focus on asynchronous communication. The difference is Twist is focused on asynchronous written communication while Yac is focused on audio. The audio is transcribed to text but the primary focus is audio. There is also support for screen sharing and other tooling as well.
-
Slack - Slack is a dominant player in this space but isn’t the best at asynchronous communication — unless the team culture is very diligent about ensuring Slack is used asynchronously. By nature, Slack tries to get your immediate attention through notifications and create a fear of missing out when that doesn’t need to be the case at all.
-
Discord - Originally built for gamers but has now become a place for general group collaboration complete with voice integration. I suppose you could say Discord is the hipper version of Slack but both Discord and Slack fall into the same realm of instant, notification based group chat which isn’t great when it comes to good tooling for asynchronous communication.
-
Signal - Signal is our favorite tool for secure instant messaging and even group chat to some extent. That said, Signal excels at secure ephemeral messages rather than the long tail of messages.
-
Telegram - Another major player in this space with a strong focus on being fast and security (although their track record on security has been questionable).
-
Microsoft Teams - One of the worst and abysmally awful services out there. I highly recommend you avoid this service if you want to retain your staff.
When using any of the services above, it can be beneficial to download the desktop and/or mobile apps for convenience and improved coverage.
Channels
Use channels to keep information organized around major topics. I’ll break this down further through basic starting structure and guidelines for keeping channels organized but also not overwhelming.
Structure
When using group chat, a core structure is helpful for new and old members finding access to information that might be of value. Consider the following as a starting point:
-
Conferences - Information related to upcoming speaking engagements, planning, proposals, travel, etc.
-
Demos - Share completed accomplishments that would be exciting for others to learn about, discuss, provide feedback on, and so forth. This channel, and all sub-channels, should be focused on screencast presentations only. Threaded discussion is always encouraged but, for full written discourse, that goes in the top level Engineering or Learnings channels. You’ll need to establish two channels — at a minimum — because the target audiences are important:
-
Engineering - Share technical details, ideas, learnings, tools, tips, tricks, etc. which are valuable for fellow engineers but too much noise for product staff and/or stakeholders. This has some overlap with the Learnings channel in that these demos can be about what you are learning but — more importantly — also about delving into the more technical implementation details of what people are working on.
-
Product - Share demos of completed work. This is a great way to allow product owners and stakeholders to get excited about what’s about to be released (i.e. in the Stage environment) or what is deployed in Production. The work you demo in this channel should always be live and immediately available for those who might want to make use of what you are talking about. This also improves the feedback loop which is important to encourage as often as possible.
-
-
Engineering - Technical news, discussions, questions, etc. related to the entire software engineering team. If a single channel is too broad, breaking down channels by specialized team is recommended as well. Examples:
#eng-ruby
,#eng-backend
,#eng-devops
, etc. -
Events - Information related to conferences, after hours gatherings, personal adventures, or anything of interest that others might want to participate in.
-
Health - Information and discussions related to mental and physical health.
-
Kudos - Praise for others who have done an excellent job or being outstanding in general. Each post should detail what makes the praise exceptional including any supporting links to additional material.
-
Learnings - Share links, lessons learned, tips, tricks, etc. Posts should also explain why the learning was valuable or any additional insight which might be valuable for fostering further discussion.
-
News - Official company news and updates. Posts should be regulated to executive staff where threads can be used for deeper discussion.
When new members are added to your organization, you’ll want to ensure they are added to the above channels automatically. Each individual can then organize and manage notifications for these channels within their local client as they see fit.
Guidelines
When using channels, keep the following conduct in mind:
-
Prefer channels that provide high signal to noise. Otherwise, leave, mute, or archive these channels.
-
Mute channels that are of interest but don’t require constant attention. Move all of these channels into a Daily checkup folder, for example, which you can schedule a reminder via your task manager to catch up on once daily.
-
When creating channels, ensure there is a topic which is a brief sentence on what the channel is about. Also, ensure the channel’s purpose is defined. This generally appears in the information/details section of the channel and explains why the channel exists. The purpose is meant to support the topic and should be a brief paragraph (or two) which further explains why the channel is important. Supporting links, references, etc. can be included in the topic and purpose descriptions as necessary.
-
Use channel prefixes to group related channels and to improve search-ability via alphabetic sorting. For example, consider the following specialized engineering channels:
eng-ruby
,eng-elm
,eng-rust
, etc. -
Use channels instead of direct messages. Lead by example and initiate or respond to direct messages in channels so others are encouraged to do the same. Even if you are composing the message to a single person or part of the team, it’s still useful for others to know what is going on. If receiving a direct message, ask if you can respond to the message in the appropriate public channel instead. Encouraging public discussion allows participation from everyone and reinforces a culture of inclusion, transparency, and trust.
-
Avoid sending
@all
,@here
,@everyone
, etc. messages. A channel is meant for asynchronous communication and these types of messages defeat that purpose entirely. If a channel doesn’t have these messages disabled by default, ensure notifications of this type are disabled by manually editing the channel notification settings. -
Avoid heavy use of individual’s handles (i.e.
@jane
,@joe
, etc.) when messaging others. Unless it is truly urgent or they are not in the current channel, avoid using handles so individuals are not spammed with notifications. Remember: Group chat shouldn’t require immediate attention. -
Use threads when responding to messages in a channel. This allows for detailed discussions to form around a topic which anyone can follow for further updates if necessary. Doing this also prevents the channel from being interspersed with multiple discussions going on at once which are confusing to read and/or follow.
-
Avoid posting a message with the ๐งต (thread) emoticon or even creating a message with the intent of starting a thread. Instead, let the thread happen dynamically rather than assume everyone will be interested. If you need to pull people into the conversation later, you can but — even better — it’s more helpful to summarize the discussion after the fact which puts the emphasis back on valuing everyone’s time more.
-
Avoid forwarding a threaded response back into the main channel. This makes a big presumption that people — who didn’t choose to follow the thread in the first place — want to be alerted about the thread again. Instead, you can respect people’s time and attention by letting them choose to follow or join a thread on their own accord.
-
Avoid using an individual’s handle within the same threaded conversation. Threads, like any unread message, will display as part of the individual’s unread count by default. There is no need to alert them further as they’ll respond back when they pop up for air. In other words, a threaded conversation should be a civil discourse. Using their handle, to force a notification, is akin to yelling at them when you are standing right next to them.
-
Avoid creating random channels. Be judicious in what justifies bringing a new channel into existence by identifying information that might be too noisy for one channel but could benefit from having its own channel.
-
Avoid maintaining channels with low activity or have outlived their existence by archiving/deleting them as necessary.
-
Avoid leaving messages unanswered because not only is it rude but can discourage others from feeling the channel is a safe place to ask questions or gather feedback. Even if you don’t know the answer to the question, use a reaction to at least show that the individual was heard. A small gesture such as using a thought balloon (๐ญ) reaction can have a huge impact from leaving the original poster from feeling rejected.
Integrations
Many group chat services support some form of integrated automation through the use of robots or, more commonly known as, bots. Most of these integrations can be found within the Slack Apps Marketplace and installed accordingly.
When integrations are added, make sure to devote a dedicated channel for each and allow staff to
optionally tune into them as desired. In some cases, the updates and notifications from several
related integrations can be grouped together in the same channel. In other cases, the integrations
serve as useful tools — accessible from any channel — which augment people’s workflows in
unobtrusive ways, including updating your status (i.e. /status At Lunch
), disabling notifications
for focused work (i.e. /dnd 2 hours
), or deploying software (i.e. /janus deploy shield
1.0.0
).
Whatever your configuration, please ensure these channels do not require mandatory attendance. Also, avoid mixing robotic notifications with human discussion since mixed channels can get unwieldy, decimating thoughtful discussion and productive work. Loud, unwieldy channels reduce your staff to the lowest common denominator by forcing everyone to pay attention to every message. Many of your staff — some of whom have their own specialized workflows — will already be on top of these alerts in some form or fashion that isn’t group chat-based.
Messages
The following details how to compose, manage, and respond to messages in manner that reduces notifications while improving readability.
Prefixes
Prefixing messages with an emoticon is a great way to inform readers about the kind of the message you are sharing. There are several advantages to this approach which overlaps with Reactions (explained later in this article):
-
Clearly identifies and calls attention to new information which avoids having to use a
@<group>
notification. -
Allows you to share information with the team that might not elicit or even require feedback.
Here is a recommended list of emoticons you can use to prefix a message you want to share with your team:
-
๐ฃ (
:mega:
) - Announces information that is important to the team to be aware of. -
โน๏ธ (
:information_source:
) - Useful when needing to share information that isn’t an announcement or learning but still useful to be aware of. -
๐ (
:reminder_ribbon:
) - Reminds the team of an upcoming event, task, and so forth. -
๐ก (
:bulb:
) - Shares new learnings, cool tips, etc. that the team might enjoy diving deeper into later. You don’t need to use this prefix if you have a dedicated#learnings
channel but is handy when all you have is a single team channel.
For all other messages, you can avoid using prefixes entirely since they are not needed for normal team chatter. As with any message you post, use sparingly and be clear.
Reactions
Reactions are emoticons that can be applied to messages posted by team members, several of which are very useful in order to:
-
Convey emotion when text isn’t enough.
-
Say a lot with little — An image is worth a 1,000 words.
-
Provide feedback without alerting others. This is especially handy in keeping channel notifications to a minimum so others are not constantly distracted.
-
Let others know their voice was heard, even if someone didn’t have anything to say in direct response to your message.
While the list of emoticons is vast, imbuing consistency helps reduce confusion. Here is a recommended list along with the reasons why they are important:
-
โ (
:white_check_mark:
) - Approval, the task requested of you has been completed, or the task is already done. -
๐ (
:bookmark:
) - You can’t read the document immediately but will soon or you’ve read, liked, and bookmarked the document for future reference. -
๐ (
:cool:
) - The message is…well…cool. -
(
:disbelief:
) - Disbelief or a slight bemused disappointment. -
๐ (
:tada:
) - Enthusiasm and/or excitement. -
โ๏ธ (
:sparkle:
) - Favorite or like. -
๐ป (
:sunflower:
) - A gesture of condolence by giving of virtual flowers to someone you wish will heal up and feel better soon. -
๐ญ (
:thought_balloon
) - Find the feedback interesting, are thinking about what was said, and/or are considering responding. -
(
:dancing_penguin:
) - Pure joy. -
๐ (
:eyes:
) - Reading/reviewing the posted message and plan to respond shortly. -
(
:nod:
) - Agreement. -
๐ (
:ok:
) - Acknowledgement. -
๐ (
:rocket:
) - Enthusiastic progress, and/or forward traction. -
๐ (
:bow:
) - Thankfulness and/or gratefulness. -
๐ (
:sweat_smile:
) - Positive worry, nervousness, embarrassment, or hesitation. -
โฌ๏ธ (
:arrow_up:
) - Emphasis and/or importance of what was said.
Statuses
While it is tempting to post a message regarding your status in asynchronous group chat, it’s
unnecessary since you can update your status via the /status
slash command. This accomplishes two
important aspects of communication:
-
Avoids notifying the team of your status change so as not to disrupt everyone’s workflow.
-
Provides a visual indication to others of your status. They can hover over your name to learn of your status, see the status change in current discussions, and/or see your status via search.
Emoji’s can help too. Examples:
-
โ๏ธ Focusing (
/status :alembic: Focusing
) - Deep thought and intense work. It is often best to couple this status with disabled notifications. With Slack, this can be done via the Do Not Disturb slash command:/dnd <number> hours
. -
๐ Learning (
/status :books: Learning
) - Learning and/or training. Depending on the situation, this can also be coupled with Do Not Disturb status. -
๐ Lunch (
/status :rice: Lunch
) - Out to lunch and will be back soon. -
โ๏ธ Meeting (
/status :phone: Meeting
) - In a meeting and might not be able to respond immediately. -
๐ฅ Pairing (
/status :busts_in_silhouette: Pairing
) - Pairing with a colleague and might be indisposed for a while. -
๐ Traveling (
/status :racing_motorcycle: Traveling
) - Traveling or in transit and might not be able to respond to any messages for a while.
Be creative but brief. Using a word or two is best.
Conclusion
Hopefully all of this information about using group chat as a tool of asynchronous communication helps you be a better communicator and improve your organization’s culture. Be diligent in adhering to these principals in order to empower your staff — and be proactive about it! A lot of organizations don’t know how to communicate well, most people don’t understand how to leverage the power of the written word, and this is especially true in software engineering. All of that said, the guidelines in this article can help. Like anything, being able to write well is a mental muscle that needs practice. In time, you’ll become a stellar communicator while influencing others! ๐