Syndication Icon
Published January 17, 2021 Updated October 23, 2021
Group Chat

We Alchemists are huge fans of asynchronous communication and the power of the written word, as seen in the syndication of this site, our 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 we’re not the only ones who think so. Doist has written several articles about asynchronous communication that bring up group chat and that we highly recommend:

💡 This article assumes knowledge of these Doist posts, which are worth reading in their entirety before we continue. Don’t worry, we’ll be here when you get back. 😉


To summarize some of the conclusions drawn by Doist:

  • Asynchronous communication, including via group chat, 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.

  • 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 to through past conversations in order not to repeat yourself is invaluable.


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.

  • 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.

  • 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.

  • 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. Microsoft is trying to make a big play in this space and failing miserably, and we highly recommend you avoid this service if you want to retain the engagement of 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.


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.


When using group chat, a core structure is helpful for new and old members finding access to information that might be of value. The following might be of interest as a starting point:

  • Conferences (mutable) - Information related to upcoming speaking engagements, planning, proposals, travel, etc.

  • Demos (mutable) - Share completed work and accomplishments that would be exciting for others to learn about, discuss, provide feedback on, etc.

  • Emergencies (non-mutable) - Production alerts/emergencies that must be addressed immediately. When using this channel, ensure staff only uses the channel for emergencies and keeps notifications turned on at all times. Any post in this channel requires everyone to drop what they are doing and pitch in as they are able. Discussion around each emergency should be done via threads.

  • Engineering (mutable) - Technical news, discussions, questions, etc. related to software engineering.

  • Events (mutable) - Information related to conferences, after hours gatherings, personal adventures, or anything of interest that others might want to participate in.

  • Health (mutable) - Information and discussions related to mental and physical health.

  • Kudos (mutable) - Praise for others who have done an excellent job or for being outstanding in general. Each post should detail what makes the praise exceptional. Supporting links are encouraged as well.

  • Learnings (mutable) - 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 (mutable) - Official company news and updates. Posts should be regulated to executives 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.

You’ll also notice that out of all the channels listed above, only one is required to be non-mutable: Emergencies. Production issues, while hopefully few and fare between, are important to address immediately. All other channels can be caught up on when one is able.


When using channels, keep the following conduct in mind:

  • Prefer channels that provide high signal to noise. Otherwise, leave, mute, or even archive these channels.

  • Mute channels that are of interest but don’t require constant attention. You’ll also want to move all of these channels into a Daily folder 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 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 it can be responded to in the appropriate channel instead. Encouraging public discussion allows participation from everyone and reinforces a culture of inclusion, transparency, and trust.

  • 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.

  • 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.

  • Avoid sending @all, @here, @everyone, etc. messages. A channel is meant for asynchronous communication and these types of messages defeat that purpose. 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 know they aren’t currently watching the channel, avoid using handles so individuals are not spammed with notifications. Remember, group chat shouldn’t require immediate attention.

  • 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 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.

  • 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 that have outlived their existence by archiving/deleting them as necessary.


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. /heimdall 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.


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, standard emoticons that have a consistent meaning avoid confusion. Here is a recommended list and the message each conveys:

  • ✅ (: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:) - Disbelief and 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 (:dancing_penguin:) - Pure joy.

  • 👀 (:eyes:) - Reading/reviewing the posted message and plan to respond shortly.

  • Nod (: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.


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:

  1. Avoids notifying the team of your status change so as not to disrupt everyone’s workflow.

  2. 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 collegue 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.


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 just needs practice. Over time, you’ll become a stellar communicator in group chat and be happy you did! 🎉