Effective team communication in Slack

Disclaimer: The goal of this article is to share my experience of working with Slack. Everything below is just my opinion. This is not a paid ad, and I am not affiliated with Slack in any way.

Even though Slack has become one of the most popular messaging platforms used by tech companies all over the world, I was surprised to find out that lots of teams are still relying on emails, Skype, and other conventional communications tools. I understand that Slack is not a silver bullet and won’t solve all the communication issues in your team, but I still encourage you to try it.

At my previous workplace, we initially used Skype. But as the company grew, we quickly transitioned to Slack. Not everything was convenient at first, we had to restructure our chats several times and introduce some rules to make it work for us. But over 5 years there were no major problems and, in my opinion, moving all communications to slack has only benefited us.

In this article, I will try to give some tips on how to organize your Slack to make it work for your growing company. It might be useful for:

• Growing teams who are still using conventional messenger apps.
• Teams that are already using Slack but want to improve their communications.

Problems of private groups and direct messaging

I see a lot of problems that are caused by inefficiencies in internal communication in my current workplace. The company is split into teams by platform and functions (i.e. backend, web, Android, iOS, etc). Even though we have Slack in our company, many teams mostly interact over Skype through private groups and direct messages. In some situations, it takes much more time than it should to find answers or get help, especially for new employees.

Below I will try to outline some problems that we have and how can we organize communications in the company to help mitigate them.

Problem: Too many redirects

Many times I have a question about the API, but I don’t know exactly whom should I address it. Ideally, I just need to address my question to the backend team and don’t care who will reply. But because there is no public group where I can do it (email doesn’t count), I have to ask individual members of the backend team in direct messages. This sometimes leads to redirects and I have to write the same thing to several people before I can get my answer. I hope the example bellow will better illustrate the situation.

Example 1: “Communication redirects”. It’s Thursday afternoon, AD (Android) has a few questions about the API. He asks his team lead AH about it, who remembers, a month ago, similar functionality was done by IK on the server-side. Anton then writes to IK, but he is currently working on a high-priority task, and replies with a short delay. IK tells that it was not him who implemented this API, it’s better to ask YS. Anton forwards the question to YS, who came to work earlier today and is already off duty. Later turns out YS has a day off on Friday. On Monday early morning, YS replies. Because they both realized there is some problem, YS adjusted the API a bit. AD finishes his task and opens PR. After code review, the build is ready for testing on Tuesday morning.

This example is quite extreme but it has happened before. We can see that we’ve wasted quite some time on redirects here. But if Anton wrote to Yuriy first, he would have had a higher chance to get his answer on Thursday speeding up the release of the feature by at least 1 day. But how would he know whom to write?

Direct chats (and lack of public groups) cause wasted time through redirects.

One of the solutions would be to have a public chat for backend team where anyone could ask question. Other people who are also interested in the topic, can see it and will be aware of what’s going on.

Problem: No knowledge sharing

Because a lot of cross-team communication is done in direct messages, other team members are unaware of conversations (and the decisions that happened during these conversations). If there is someone else involved (e.g., iOS), we have to tell them about it later – probably in yet another direct chat. This might come up as a bug in iOS or can be completely overlooked.

We have many platform teams working on same projects, sometimes almost in parallel, sometimes with a substantial delay in time. Discussions with the UX designer can happen 1:1 and can result in some changes in the mockups. It is very easy to forget to notify other platform about the change. Let’s take a look at the following example.

Example 2. “Changes in requirements are not always propagated”. PE (Android) started working on the project first. He has implemented some features and sent them to QA for testing. iOS developer AB started a bit later and found an edge case that was not covered by the mockup. He asked designer about it, and after a discussion they have updated the mockup. Unfortunately they forgot to notify PE about it (which can happen to anyone). As QA started testing Android, they found out that it doesn’t look exactly like the mockup and returned it as an implementation bug.

Although, no matter how hard we try to collaborate and discuss questions our peers from other platform, we can sometimes forget to do it. As a result, we have to waste some time on fixing more bugs and testing them. This problem is especially prominent in distributed teams.

Direct messages slow down knowledge sharing

If all the communications with designer were conducted in a public channel, all interested parties would have been notified about the updated requirements automatically.

Problem: Ineffective onboarding

A growing company needs an effective onboarding process. And that’s not very easy to do, especially when you don’t have enough resources. If a new employee needs help, there should be a way for them to get it.

When nobody is maintaining plublic channels and just texts to each other directly, a newcomer doesn’t even know whom to ask, except their team lead. This puts a huge load on the team lead and makes onboarding process painfully slow.

Direct messages slow down onboarding

Onboarding problem must be solved on a process level, but this will be never. What you can do now, is encourage discussions of work issues in public channels. This will bring a lot of benefits to onoarding of new employees.

• Public channels will let new employees learn what is happening in the company.
• In the team’s public channel, newcomers will be able to see how their team mates answer questions – next time they will know the answers themselves.
• Having access to the entire public communication history of the company will enabled them find some answers without bothering their peers.

Comparison of Slack with conventional messaging apps

Before I go into how exactly we organized Slack communications in my previous workplace, I would like to compare Slack with personal messaging apps. Let’s first look at “conventional” messengers.

Pros and cons of conventional messengers

There are many reasons why using one of the conventional messaging platforms (like Skype) for company internal communications might be appealing:

• You don’t have to pay for it.
• It is popular and everyone has an account.
• It provides UX that everybody knows.
• It is well established and unlikely to stop working.

All these points make popular personal messaging apps perfect tools for online communications in smaller teams. It is very easy to make group chats there. In the beginning, it would be sufficient for a company to keep communications there. However, as the company grows, the problems of these messengers will become obvious.

• Eventually, there will be just too many groups.
• It will be hard to search in the message history.
• You need to manually add new employees to all relevant groups.
• When an employee leaves the company, you need to manually remove them from all groups.
• If you want to keep personal chats separate, you might need to create a separate account for work.
• You cannot control user accounts (e.g., if they have weak passwords, your organization’s communication is at risk).

This list is not exhaustive, but it is quite obvious, that personal messengers are not a scalable solution for growing companies. That’s why big messengers out there all came up with products for organizations. I have never used them, so cannot comment on how good they are. I assume they all provide the same feature set as Slack and can be a good fit for a growing company.

Why Slack is better for growing teams

The advantages of Slack compared to conventional messengers are:

• Each “Organization” in Slack manages its users.
• There are public and private “channels”.
• In the channel, conversations may be organized by threads.
• Slack supports many plugins, chatbots, and integrations with 3rd-party apps.
• It has a good global search tool.
• You can customize notifications based on mentions and keywords.

Disadvantages of Slack

Slack is not for every company, as it has its disadvantages (compared to conventional messengers). Here are the ones I could think of:

• Slack is quite expensive (with pricing per active user).
• It has a limit of 15 people in video calls (e.g. Telegram supports more).
• It doesn’t show delivered/read flags for messages (but is it really necessary?).
• It doesn’t fully support offline mode (but neither does Skype).
• It sometimes (quite rarely) can be down.

How to use Slack effectively

If you are convinced to use Slack in your team, I have a few tips to make communication more efficient. Keep in mind, this is just my experience, which might not work for your organization.

Introducing Slack to your company

1. Test on a small team. If you don’t have Slack in your company yet, test it on a small team first (you can even start with a free plan). Ensure that it works before forcing all employees to use it. At my previous workplace, my team was the pioneer and started using Slack first in the company.

2. Make Slack a single place to chat. As you roll out Slack to all the teams in your organization, make sure they use it for all their internal communications. They should not keep using both old and new ways, as it will ruin the transition. If all company is using Slack, completely stop using the other communication app.

3. Teach the team how to use Slack. You need to make sure people understand how to use Slack to their advantage. Public channels, threads, mentions, reactions, search, etc. More on that below.

Users and groups

To facilitate more effective communications in Slack I recommend:

• Use the same user names as in emails.
• Ask employees to fill out their profiles (avatar, full name, and what they do).
• Create user groups based on department.
• Update user groups when adding new users or when organization structure changes.

Public and private channels

Here is how I propose Slack channels should be organized.

1. #general is a channel with all company employees. Use it for company announcements or if you have a question that you don’t know who should answer.

2. Each team must have a PRIVATE channel. Private channel is used by the team for its private communications. Just like in plain old Skype, a team may want to create other private channels for CI notifications or other things if they need to.

3. Each team must have a PUBLIC channel. This is how they interface with other teams of the company. Anyone in the company must know (or be able to quickly find) a public channel of any team, read it or ask questions.

4. Theme channels. It might be a good idea to create theme channels devoted to a particular topic. For example, #office (discussing office issues), #vacations – to announce days off, #jokes – channel for fun memes.

5. Temporary channels for big projects. You may want to create temporary channels for big projects (that last for months).

All public channels must have a meaningful name and description, should be easily discovered.

Example:

Public channels:

#general
#android
#ios
#frontend
#backend
#qa
#product
#design
#accounting
#operations
#sales
#it-infrastructure
...

Private channels:

#android-private
#backend-private
#ios-private
#qa-private
...

How to maintain a public channel

To make communications in Slack more efficient, it is important to follow certain rules when chatting in public channels.

1. Keep questions on the topic. Make sure people don’t ask backend questions in #product channel. Add some guidelines to description. When question is asked in a wrong place, redirect them immediately to the right channel.

2. Reply in a thread. When a question is asked in a public channel, reply in a thread. This will ensure other external members will not be notified.

3. Moderate conversations. Make sure conversations are on a topic and professional (jokes and sarcasm must be redirected to appropriate channel). Don’t blame people for problems, suggest solutions and preventative measures.

4. Ensure quick reaction. It will all work better if questions are answered. Try to answer questions asap. If you don’t know the answer, but you know the person who does, reply to the question by mentioning that person. The team can also arrange a schedule for team members to answer questions.

5. Mark questions as resolved. Usually the one who asked should mark their question as resolved. If there are multiple questions, the channel owner team will not which questions are still waiting for an answer.

6. Collect common questions and answers.. You might see that questions repeat. Ask people to search before they ask, pin useful conversation threads/resources or put common answers to a Confluence page and place a link to the topic of the chat.

How to stay responsive on Slack

Here is how I would work with Slack to make sure it doesn’t distract me too much and I am still responsive.

1. Star important chats. To be in close communication with people and teams that I work with, I will add them to favorites (“star” them). This way, they are displayed on top of the list and there is less chance to miss an important message.

2. Setup notifications. I might set all notifications for important channels, set keyword notifications / direct mentions in some channels. Experiment and find what works for you and what doesn’t.

3. Mute all unimportant channels. I will mute channels that are not important (if I haven’t left them) to reduce distraction.

4. Reply in threads. When replying to messages in public channels, I will always do it in a thread.

5. Sort out messages in the morning. I will check Slack in the morning and try to reply to all messages.

6. Check Slack periodically. I will react on direct mentions asap. In other cases, I will check my Slack periodically to see what’s going on.

7. Mark my status. I will try to keep my Slack status up-to-date. If I’m on vacation I set the corresponding status icon and vacation dates, so that everybody knows I’m unavailable.

How to follow public channels

You don’t need to be subscribed to all the channels. In fact, what channels you follow and how often you check them depend on where you work, what you are currently working on, as well as on your personality.

Slack allows you to configure notifications for each channel individually. You may choose to be notified about any message, direct mention and/or based on a keyword. You may also choose to completely mute the channel. Use notification settings to minimize distraction and maximize your responsiveness.

Here is how I would organize my channel notifications.

• As a regular employee of the company, I should be a member of #general. I will probably mute it though and only enable direct mentions and some keywords.
• As an Android developer, I should be a member of a public channel #android and #android-private channels. I need to watch them regularly to be able to help my team and answer questions from other teams.
• Because I often need to work with the iOS team on the same tasks and interact with the server APIs, I would also join, mute and occasionally read #ios and #backend public channels, just to be aware of what’s going on (people ask questions I might be interested to know the answer). I would probably also let Slack notify me of any mentions of the word “android” in these channels.
• Depending on my current tasks, I might sometimes need to join other public channels to ask questions.
• I would Leave channels that I haven’t read for a while (Slack has reminders for that).

Conclusion

If you decided to use Slack, I recommend placing this article in your company’s public knowledge base, such as Confluence. Ensure that everyone on your team is on the same page by letting them read the guidelines. Monitor how it works and listen to the feedback. Experiment and adjust the rules to suit your needs.

The presented structure of Slack channels may not work for every company. Some of the points may seem too obvious, but it is still useful to be aware of them. I hope someone will find this useful and improve their communication.

Thanks for reading.