How to use Slack at work

I started using Slack back in November 2013. It had just launched into closed beta and we were one of their first media customers. Back then the choices for my team were slim: chat apps hadn't really made it to corporates yet, but the team needed to share links, code snippets, and handle projects outside the mess of repeated email chains which were driving us mad¹.

In finding Slack we found a new superpower. We had bridged the gap between the longevity of email and the speed of instant messaging; sharing information in a natural way that suited how we communicated elsewhere. And as a team of around 8 people, Slack worked across just a few channels for us.

But as the rest of the organisation slowly got on board, we found the growing pains of Slack to be hard to handle. As our colleagues joined, they didn't understand the benefit we had accidentally created for ourselves in the ways we'd found to work. We were flooded with direct messages, hold outs responding in email, and people who had decided emojis were not for the office. Old habits die hard, and Slack doesn't do much to help you out of them.

Since then I've seen countless teams have the same kinds of growing pains with Slack, and those pains often reflect organisational pain points that need to be addressed. And if you can get past it there's a wealth of new value to be unlocked.

You can maximise your value from Slack just by getting your team to have a shared understanding of three things: notifications, channels, and search.

Notifications🔗

Slack has a very powerful tool in 'mentions': when you tag another user with their @handle. Mentioning people I think should always be through a shared understanding of what it means to do so, and it's this disjointed view that most often trips teams up on how to best utilise Slack.

Mentions are best described in the framing of the tool that came before: email. Where email has "to" and "cc", so effectively does Slack in the way it incorporates its communication stack.

When you mention someone in a message it should be thought of writing a message "to" them in an email, or where they are specifically copied because you want their visibility. They need to see, read, and potentially take action from whatever you have sent.

When you would cc someone only to keep them aware of something -- maybe it doesn't need their attention right now, or they need a log of it somewhere -- then make sure you put the message in a channel. Pick one that suits the topic of discussion and has the right people.

This helps publicise useful information, and potentially help others you might have otherwise been unaware of. For example, if you have a #product-support channel, you might post in there tagging the product owner about something they should address. By virtue of posting your request in the channel, other users might also jump in to agree with you, or thumbs up your message, signalling that they would also like it addressed.

CC'ing in Slack is also so much better than email, in that it doesn't flood your inbox by default. When people complain of notification overload in Slack, I can't understand how, when using it this way, you wouldn't get less noise than your email inbox.

Never direct message someone about something that might of interest to more than one person and isn't urgent. Direct messaging someone, even without mentioning them, forces a notification onto their device that it is not possible to mute (in single person direct messages), and permanently locks that knowledge between the two of you. Leadership private channels, or one-to-one private channels are significantly better than this (as they offer the ability to choose whether to mention someone or not).

Do not expect notifying someone to mean you are deserved of their attention immediately. Though Slack enables a chatroom style discourse, it should not force such a structure on your team. Allow people to respond at their own speed.

If you do need time without notifications, consider setting 'do not disturb' (DND) instead of turning them off entirely. This still allows you to work distraction free, and Slack will actually tell those who try to direct message you that you have DND on. If it is important and urgent, they can still force a notification through this way.²

Channels🔗

When you use channels right, these can function as your typical email list or cc group. As is common at a lot of organisations, email lists are built as a way to contact teams, or areas of responsibility in the company. You might have sales@ for the entire sales team, or everyone@ for the entire business. These map quite well to your possible #sales channel and your #general channel.

Whenever you would create an email list, you can create a channel, and because channels are typically much easier to create for the average employee than an email group, you can choose to have a few more of them. It is much better, however, to have broad channels than narrow channels. Until a channel is busy, there's really little reason to split it up.

Ideally you want to keep your channels public. This is the biggest mentality shift that will improve your experience with Slack. A enormous amount of Slack's capability becomes locked away if your team defaults to private channels. Slack's search, and machine learning systems to point you towards knowledgeable users and useful channels only works if Slack knows you should be aware of them. If all your useful discussion happens in private channels, or worse, direct messages, then your team mates have to get added to those channels to even be aware of them.³

It is not possible to turn private channels into public channels, so working in private is a habit that is hard to break out of once you've built up some foundations. Try as much as possible to get this right early.

If you do work in private channels you'll soon work in hundreds of them. Leaving private channels becomes something nobody ever does. Because if you do you can't easily get back in without remembering it exists and knowing who to ask. Public channels make this more manageable. Join a channel to ask a question, and then leave it once you've got what you need. Keeping your channel count as low as possible is a good habit, so public by default is a great assistance to that aim.

If you must have private channels for projects, consider opening them up with a tool like The Operator, which I built for this purpose. The Operator adds selected private channels to a directory where users outside of them can see a little blurb about them and ask to be let in.

Search🔗

If that wasn't enough reason to work in public channels, search will be. Search is Slack's quiet superpower, and if you've ever had to grapple with other workplace search engines (eg. Google Docs), you'll be relieved whenever a discussion happened in Slack instead.

Slack is really fast at returning results, which makes iterating on your search something you can do without wasting much effort. A wealth of search operators help narrow your search step by step until you find what you need.

Some key operators: from: to denote who sent the message, in: to mean in a channel or direct message, has: typically to search has:link for messages with links, and is: to find your threads (is:thread), saved messages (is:saved) and direct messages (is:dm).

You can combine these in any order to create really advanced searches. Typically I'll set my results to Newest message as I'm usually after something recent, but if I'm after long lost knowledge or decisions from the past, I'll use Slack's most relevant to help boost messages with good signal.

Before you ask a message, it's always worth trying a search (particularly in the ubiquitous #help channels).

And don't forget the other tabs: search defaults to messages, but you can also find relevant channels and people by Slack's search. Slack is often a better company directory than anything else available, so search for titles and departments and find relevant people in Slack.

And that's it. Those are my main three. Do you have any other tips that you think are essential to good Slack usage? Tweet/message me.

Extra credit🔗

• Threads. Threads are very useful if you use them well, and a pain if you don't. Use threads liberally in larger channels of more than a few people. Never use them in direct messages if you can avoid it. They are absolutely essential for channels over a few dozen people, where otherwise noise reigns.
• Emoji reactions are for work. Common and easy patterns I've seen are 👀 to indicate you've seen something and 👍 or ✅ to show it's actioned. You can base entire workflows for service desk channels from reactions, and it stops users who need to recap from going down solved problems unless they're interested.
• Star or group important channels. Create your own signal by keeping your team and project channels at the top. Mute or leave high bandwidth channels where you need to post but rarely need to read.

---

Footnotes🔗

1. Our alternatives: Google Hangouts which our organisation had placed a 24hr limit on, or setting up an IRC server -- a chat technology from the 1980s with no persistence. ↩

2. Quill, a Slack competitor that got bought by Twitter who then did nothing with it, had a really great solution to this and I'm sad that Slack hasn't adopted it. You had tow kinds of mention, one that forced a notification !!@name and one that just tagged someone in a conversation for them to review later. See here for a bunch of great ideas Slack should adopt. ↩

3. Stripe has a fascinating article on how pre-Slack they unlocked everyone's inboxes by CCing lists. This is a tremendous example of the benefit working in public can have. ↩