(This article is a follow up on Jason Fried Is group chat making you sweat? I suggest you read it before reading this one)
It’s funny to think that 7-8 years ago companies were banning MSN messenger because they were afraid employee’s were losing too much time chatting. Today companies have full blown messaging apps integrated into their processes with gifs and videos; they even pay for it. With the help of Clerk Chat communication with clients and customers can be made easy.
What would you call an all-day meeting with unknown participants and no agenda?
— Jason Fried (@jasonfried) February 18, 2016
When I first read this article from Jason Fried asking Is group chat making you sweat? I did not fully appreciate all the negatives points Jason was making. At the time being in a small team most issues Jason detailed were not a concern to me. Sure I could appreciate some arguments like the one about chasing messages all day long in channels, but I did not feel Slack was hindering too much my productivity.
Things changes, now that I have used Slack with multiple teams and with over 100 devs within the same organization, I can relate. Channels can kill productivity by moving your focus away from your work and more in your messaging app. Can you put in place guidelines on how to use a tool like Slack? Yes. However, the wrong tool for the job has a big chance to be used wrongly.
Example, a common pattern for me is to ask questions in one of the specialized channels; I am a member of that channel. However, I do not care about anything said in this channel beside what I am asking at that precise time. I still receive all @here notifications and sometimes even curious what is happening in there. In a channel you will have “core members” and people who just ride along. Those people riding along get the productivity potentially hindered all day long.
Group chat has to be used in specific cases, morning scrum, meetings with people outside the office, status update. Those are all good reasons to use group chat. What needs to be killed is the channels you are connected all day.
An alternative idea, notification channels
How can we keep the benefits of synchronous conversations over a large group of people without the drawback of conversation channels? I propose an alternative workflow. Using desktop and mobile notifications to handle channel messaging.
Kill the chat history, gifs, videos, endless messages, only important information distributed and then the conversations can continue in a one on one conversation or when the situation requires, a group chat. It looks like this:
- You have an organization.
- Groups within that organization
- You can be a member of a group, but you can also send notifications to any/all groups.
- Someone can respond to your notification with multiple actions
- open a group chat with all channel members + you
- open a group chat with you + opt-in
- open a one on one chat window
- All chat windows are killed once the conversation is done.
- In the same notification the channel members receive, the status should change if someone taken action.
Example: Taking back my earlier example and applying this workflow. Now I am not a member of the specialized group. However, I can easily contact them directly and get help. Nobody respond? Maybe they have something more important to do. I must use other asynchronous channels to get help (emails, Jira, etc.).
Example: In a red alert context, you can coordinate directly using the channels notifications and form a chat group on the fly to talk about the issue.
Example: You ask in a channel if anyone want to go to lunch, people wanting to go with you can click on the notification to join a group chat, then only the people interested can now decide where they want to go to lunch.
Using notifications is not perfect, but this solution significantly reduces the number of messages read in a day. No feeling of chasing messages, no implied consensus, no sense of urgency because you have a number on your slack icon, no new conversations in 5 different channels. Let’s kill the channels.