Actually, Slack really sucks

But this is where the OP totally lost me:

> In the olden days, you’d send around a group email. As things progressed, relevant people would be added to the email chain and irrelevant people removed. It wasn’t on trend and it might have been clunky but it served its purpose. If a person needed information from one specific person, they could contact them individually in the chain. Everyone could input ideas and get the issue solved. When the issue was out of the way, the whole thing could be shut down with a press of the delete key.

Those are some seriously rose-tinted lenses. Again, I haven't used Slack for work, but unless Slack is significantly clunkier than HipChat/Gchat, and the Slack client sends an electrical shock upon each message sent/received, I'm having a hard time believing that Slack is overall less pleasant than the email-chain-discussions of the past.

Ignoring the fact that the OP describes the most idyllic discussion-by-email-chain situation in this history of the universe when arguing why Slack chat is so inferior, the main flaw in his argument is that maybe his company has cultural communication problems overall that are exacerbated by features of Slack that are helpful to others?

Here's his main complaint:

Now try this in Slack. Remember, it’s one of 10 issues you’ll have in a day, so you start with creating a group chat instead of a dedicated channel. Now add someone. Yup. You’ve now just started an entirely different group chat. All the context of the conversation has gone and you’ve found yourself starting over, having to re-explain the whole situation for each new person added. You’ve also suddenly got a shitload of group chat windows open. Oh, and they aren’t named like channels, so which one of those four group chat windows you’ve now got open was it again? Oh shit. You got it right, but someone else didn’t. They’ve responded in the chat you were all using previously before you realised someone needed adding.

Sure, it's annoying to have to bring someone up to speed when inviting them into an ongoing conversation. Has the OP considered how fucking annoying it is to the person you've just forcefully invited into your conversation to read through several paragraphs/pages of pre-existing chatter to get themselves up to speed? It sounds like there are issues in Slack's interface that could be cleaned up, but the problem of new people being added into a group chat without being able to see the history is a feature that compels a few good practices:

1. Don't start a group chat for something that could be sussed out in a channel.

2. Don't start an important group chat without thinking of all the relevant stakeholders who might have input on the issue. Is it possible in Slack to invite someone into a group chat even if they're AFAIK (which would allow them to see the history of the conversation without having had to actively participate)?

3. For those situations in which you need to invite someone ad-hoc, make sure you can sum up the issue in a couple of sentences (e.g. "Hey Jane, Bob tells me you know about this [URL to Github issue]"). For situations in which the new person needs to know all of what you've discussed before and behind her back before you decided to rudely invite her to your chat, see Point 2.

I tried it with my team about a year ago, and all of the OP criticisms resonate with me. We don't use Slack anymore.

> 1. Don't start a group chat for something that could be sussed out in a channel.

I've made a point to direct folks who direct message me with a lot of side discussion to try and keep in in the channels, if at all possible. The capture of side-bar conversations in an easily sharable form is the main reason that we adopted Slack.

Now try this in Slack. Remember, it’s one of 10 issues you’ll have in a day, so you start with creating a group chat instead of a dedicated channel.

Stop. All of the problems that follow this statement are a result of creating a group chat instead of a channel. If you're creating a group chat, you're most likely doing it wrong. You should have long-running specialized channels by topic that includes the relevant people. For example, if you're discussing a bug in XYZ analytics, post in #xyz-analytics. If you're discussing something specialized and short-lived, create a channel anyway. For example, #xyz-1.1-release. This helps in allowing engineers to focus on channels that are relevant to them.

Go through all the channels with notifications showing, reading through each channel. Realise most of the content wasn’t relevant to me. Sometimes miss content that was that had shot too far up the page overnight.

Unless that communication simply wasn't happening (in which case, Slack is a making a positive impact), that communication existed in some form elsewhere. It might have been email or in person, but either way, if the volume increased for you it's probably because you are simply privy to it now where you weren't before. Perhaps it's not relevant for you. That's fine, because at some point it will be, whereas you would have been excluded before. That means being able to head off bad decisions before they've had much time to gestate.

I've established a guideline for my group that all (non-sensitive) communication should happen in public, and that means on Slack. That alone has made a big difference in making sure people are in the loop and that bad decisions are visible to everyone. Slack isn't my ideal vehicle for this (I'd prefer something behind a firewall), but if it gets people talking out loud, then sure.