How to Effectively Communicate on Slack
6 July, 2020
Slack is a wonderful communication tool but it does come with its downfalls. People use it to chit-chat, it can get a bit too noisy, not everyone is aligned on how to use it, and it has its limitations on what it can be used for. Even so, it’s a great resource for communication that can be used when your team is either collocated or distributed. After listening to other people’s conversations and receiving feedback around certain issues I decided to devise a framework for using Slack that I recommended company-wide.
1. Use public channels
We do not use direct messages (DMs) for any business related information exchange such as project-related topics. DMs should not be used unless for personal chats. Information needs to be shared on a public channel so that it is amplified and distributed throughout. This is especially true when everyone is working from home otherwise it’s difficult to keep tabs on what is going on, whether there are any blockers, and the progress that is being made. As a result, it's extremely useful to be transparent and accountable for followup steps. A Scrum Master like myself could jump in and push for certain folks/teams to unblock issues at hand, even if I had the day off and catching up the next day. Therefore, for every initiative and project we created a separate Slack channel that way everyone involved can stay in the loop.
2. Use threads
We started a thread on every question asked, rather than communicating about that topic in the Slack channel feed. Using a thread to discuss one topic or question (and follow up questions) reduced the noise for those who had no part in the conversation or were not interested in it. Especially when working asynchronously, this prevented individuals from waking up and having to go through hundreds of messages. Instead, using threads made the information easier for anyone to digest, organize and respond better. If it's not relevant, they can skip over it without scrolling over pages.
3. Standup notes
Our standups used to be very long meetings with meet and greets and post standup discussions. We then adopted standup notes where everyone could organize their thoughts. Each initiative had a channel on it’s own and we could create a new thread for standup notes. On a daily basis Slackbot would remind us to update our notes before the start of the standup. Each person entered that day’s thread and summarized what they were working on, if they had any blockers, and what they wanted to work on. Documenting these notes all in one place gave leaders visibility into what could be optimized.
We also had post-standup meetings that along with notes, had been by far an effective tool to break down complexity into workable pieces. We did not use a fancy workflow tool or a separate channel. Instead, it's a thread started by Slackbot like "Slackbot Reminder: Standup Notes @X @Y". We would create a thread and update status there in the format of "Yesterday's accomplishments" , "Today's tasks", and "Blockers".
- This framework was not enforced and instead recommended to all teams. We first wrote it down then distributed the information to everyone. Each team, realizing its potential, used it as guidance and tweaked it to fit their demands. These adjustments allowed for teams to optimize to the point where it became a habit for the teams in the States and in Berlin.
- Using the channels and thread feature allowed us to reduce the noise in Slack thereby letting individuals focus their attention on initiatives and priorities that were relevant only to them.
- Using Slack for standup notes gave us a centralized location to document what we were working on, our blockers, and the progress we were making. It created visibility within the team, across teams, and for leadership roles.
- Every company adopts tools for solving specific problems and with that comes a new set of problems. It's very important to get feedback from the users. As a leader, that is one of the skills you have to develop. These solutions arrived after iterating through 3 months of our time but are effective to our organization.
Matt Pillar, VP of Engineering at OneSignal, recalls how he helped merge two engineering teams at two different locations and how legal and cultural context made all the difference.
VP Engineering at OneSignal
Jackson Dowell, Engineering Manager at Asana, explains how he moved his project forward by coming up with a clear model of the system and problem that provided guidance to the team and helped communicate their efforts outward.
Engineering Manager at Asana
Toby Delamore, Product Manager at Xero, explains how skip-level conversations and maintaining an attentive relationship with engineers enabled him to keep a finger on the pulse of the team.
Product Manager at Xero
Michael Vanhoutte, Chief Architect at Aprimo, discusses why it is important to establish that a problem you are trying to solve is the right one and how the engineering obsession with ‘fixing the problems’ can lead us astray.
Chief Architect at Aprimo
Paulo Moncores, Senior Engineering Manager at Shopify, discusses why you shouldn’t avoid hard conversations and what role culture plays in handling them.
Senior Engineering Manager at Shopify
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.