Slack has announced a new feature called Threads, aimed at taking the clutter out of public channels. At first, you might think that Direct Messages already covered that, but it’s not so.
At Premium Minds, we switched from HipChat to Slack in the summer of 2016. There was much wailing and gnashing of teeth, but I was among those who loved the switch. One of the things I liked the most was the overall spirit of openness — the bias towards public channels instead of private ones, the fact that there is no channel administrator (giving everyone the power and responsibility of inviting people into the channels), etc. (Oh, and emoji reactions too, of course. 👌)
As a Product Owner within a team working on multiple products (each with lots of diversity), I like to take advantage of that openness to improve how the team shares a common vision and knowledge of what’s happening, of where the product and the team are heading. For that reason, for communication within the team (even if one to one) that both:
- doesn’t need immediate (urgent) attention, but can’t also wait for hours or days; and
- may impact (part of) the team (for instance, clarification on a user story);
I’m in favor of using the team’s Slack channel — with an @ mention if need be. That’s what I use when I need to communicate with the rest of the team, and that’s how I prefer to be reached out in this situation.
- Why Slack? Because it’s asynchronous, and has zero ambient noise (open space office, anyone?). Having a developer background, I understand the value of being in the zone (and covet it for myself too). If you work with a remote/distributed team, the reasons are different, but obvious. In my case, the team is not 100% co-located, so it’s a mix of both sets of reasons.
- Why not a Direct Message? Because both sides of the conversation are of interest to the whole team. Maybe a team mate is asking a question that denotes he might use the help of another team member. Maybe it’s question for which the answer is valuable. Maybe it’s something someone else would end up asking again later. This way, all the context is in plain sight and are searchable by anyone.
There are hurdles for this to become the norm, though. One of them is when multiple of these interactions are happening and/or one of them generates a little more follow-up than only an answer to a question — the channel becomes noisy. When the channel becomes noisy, people start paying less attention to what’s happening there and/or resorting to Direct Messages.
The Threads feature Slack now introduces brings a very interesting middle ground to this. A longer debate can be taken aside without being taken to private. Everyone can see the discussion is happening (or has happened) without it flooding the channel — they can take a sneak peek if they so want. Since this new feature includes the ability to bring messages from the thread back to the public arena of the channel, the team can then be exposed to the relevant outcome of the discussion without having to see the whole argument unfolding.
When coupling this with integrations, another potential use case comes to my mind: threads may trigger discussions that weren’t happening. I can imagine a thread starting from a Jenkins build failing, or from a story transitioning states in your project management tool of choice (Jira, Trello, Asana, …).
Summing up: if you lead a team into a common goal and Slack is a relevant part of your team’s communication, do default to using your team’s channel instead of Direct Messages. The newly introduced Threads feature brings a great way of separating your discussions without losing the value of having all information and context openly available within the team. This is particularly stringent for remote/distributed teams.
This post represents my personal opinion on this subject, not that of any company I work (or have worked) at/for on this subject area.