Slack: A distributed team’s good friend

Our collective shift to remote work has made clear, effective communication more important—and more challenging.

For many companies, Slack is the tool of choice for short, instant messages. But this application can be daunting to new users. Getting the most of it takes time, patience and effort on the part of the employee, and guidance from the organization in terms of when and how to use the channel.

Working for remote-first organizations, Slack has been part of my digital toolbelt for many years. Almost all of my coworkers work from home at least part of the time, which makes this application a critical part of our ability to communicate and coordinate across our decentralized team.

As more people join the Slack community, we built our internal code of conduct or “netiquette” for this application. By following these rules we ensure that communication is effective, efficient and useful:

🧵 Rule 1: Every conversation is a thread

One of our company’s first rules on Slack is that every conversation must be part of a thread. What’s a thread? It’s a list of comments that roll up to an initial or parent message. Anyone who wants to participate in a conversation needs to jump into the thread, not start a new one.

So what happens when people need to start a new thread? For the sake of clarity, all conversations must begin with a short, descriptive title. All details are then presented in the body. The first message ends with the ⤵ emoji, which signals to real-time readers that more information is forthcoming and that they should not yet answer the question until the query is complete. When the discussion in a thread comes to a conclusion, it should be “tl;dr-ed” at the end of the final message. Meanwhile, the initial message gets marked as resolved with this emoji ✅. This ensures that anyone scanning the channel or reviewing notifications after the fact can easily tell that the issue has been addressed.

Threaded messages help cut down on noise within the channel. It also creates a single, compact history of the issue, allowing people to review the thread and find answers without cross-referencing sources or following up with individuals. Over time, Slack threads can become an unofficial organizational FAQ, as each thread poses a question, discussion and answer. If and when the issue resurfaces, people can be directed to the thread instead of rehashing the conversation.

Bonus tips:

• Be specific. The #general channel by default has a lot of members, which can quickly become unmanageable if used inappropriately. Be sure to address the right group so as to reduce noise and distractions for others.
• Close the loop. If you, as the thread creator, find the answer to your own question, share the answer and mark the thread as resolved. Anything less is what we in the tech world call being a “DenverCoder9,” which is when a coder uses the help of forums to find answers, but never shares the knowledge.

🕵️ Rule 2: Minimize private conversations

One of the benefits of Slack is that it offers the ability to communicate quickly and casually. With messages constantly being posted within the thread, it may seem wise to take some conversations offline or have them privately, right? Wrong.

The equally important aspect of Slack is that it serves as a searchable digital archive of all conversations. When used and organized correctly, the messages are not a nuisance but a resource—a living, breathing record of what happened and why.

There are two types of private conversations that we tend to avoid:

Subchannels

Subchannels are a spin off of a main channel. They’re usually started by a user group with good intentions in that they don’t want to pollute the main channel with unrelated conversation.

For example, we create channels to support projects. Hypothetically speaking, there may come a point in the engagement that front-end engineers want to have a private conversation about design or another issue that doesn’t appear to involve the back-end team. So they may create a subchannel to work through these points on their own. That may seem like a great approach until they realize that the design they create can’t be supported on the back end. Equally concerning, the project manager can’t tell them that this idea isn’t feasible in terms of time or budget. If the conversation was part of a main thread, the issue would be caught. On a subchannel, it may not—costing the team valuable time and resources.

One could argue that this problem is a matter of proper reporting—and that may be true. But when working as a remote team, it’s far better to eliminate risk than to count on people to know when they need to take additional steps and what those steps are. Broader visibility often allows interested parties to step into the discussion earlier, making sure less time is wasted.

1on1 conversations

In many organizations, employees are encouraged to communicate directly through video meeting or email. It seems like the logical and polite thing to do, until you realize that it’s hardly the most efficient way to operate.

We never let one person be the sole source of information. That approach creates a bottleneck within the organization; it also may overwhelm one person with requests when others are equally capable of providing answers. Instead we make sure that information is properly distributed so that many people can quickly and accurately answer questions. This is especially important when your team is spread across many different time zones.

Thinking more broadly, private conversations can tend to exacerbate the very issue the person is trying to address: a lack of information. 1on1 conversations do not have publicly searchable history, which means that when the question comes up again, the conversation will need to happen again. Further, many of these conversations shift to a video call, leaving little chance for others to listen in. Participating as a spectator is a powerful learning tool, especially for new hires.

📚 Rule 3: Organize your channels

Slack can be overwhelming, especially for new users. That’s why it’s essential that a system is in place to make sure people can easily find the channel they are looking for.

We always follow the same signature for our team channels: team-[TEAM]-[TOPIC]. For example, the TEAM could be UX. The TOPIC is then limited to one of the following:

• eng - engineering related discussions
• design - all the artsy stuff belongs here
• qa - quality assurance
• writing - the channel for words
• resources - have some interesting learning resources to share?
• random-fun - let's face it, this is just cat-pictures, wooof and pictures of random alpacas combined
• consensus - used for Slack polls to discuss bigger topics

We also have project-specific channels, which are created when a new project starts. We use Jira epic to capture all the necessary work and the new Slack channel to facilitate the conversation. The name of the channel follows the format: project-[AB-XXXX] where AB-XXXX is the Jira epic number. This system makes it very easy to traverse from Jira ticket to the respective Epic and then to the corresponding Slack channel.

💬 Rule 4: All communication is asynchronous

Our workforce is based all over the world. Teams are not organized by time zone… quite the contrary, actually, as we find that having people in many different locations help improve the continuity of our work.

But while there are many benefits to working on a decentralized team, it is difficult to manage communication in a traditional "sync" way. As such, we discourage introductory and general messages, like: "hello", "may I ask something" or "does someone know about X" messages. Instead, if a team member needs something, they should create a message that includes: all the information they have; any corresponding links to relevant sources; and all questions that need to be answered. Then, the person just needs to wait. The nature of our workforce means that answers can come in a few minutes or the next day.

This seems counterproductive at first, but that is rarely the case. Because all communication is public (see Rule #2), there are more people who can chime in with answers. Assuming the person properly formulated the thread with all necessary questions, then they are likely to get answers in fewer cycles. In the meantime, the employee moves on. There should never be just one thing on each person’s bucket list.

⚡️ Bonus: Quick tips for power usage

1. Use emoji reactions when it makes sense. They create less noise than “I agree/will do/read it” messages while providing the same level of affirmation for the sender. Generally speaking it also spreads positivity with :party-parrot:, :parrot-conga:, :parrot-portal: and similar.
2. Markdown formatting. Learn it, use it. Everywhere. Always.
3. Memorize this: cmd+shift+enter for pasting longer snippets.
4. arrows + e for editing messages… and don't leave your “typoes.” wink
5. Don't have time to answer right now, but don't want to forget to get back to it? Right-click at any message -> Remind me at -> [select time]

With a relatively long experience working remotely, those are my best tips for Slack. As many of us get a crash course in working from home, what would you add?