Over the past two years, I’ve worked with ~20 companies as a contractor. Most used Slack. I’ve noticed 5 differences between the companies that use it well, and the ones that don’t.

One organization. Not multiple.

Not multiple. Create a channel per project. Not per team.

Not per team. Most conversations for a project go in that project’s channel. Not 1:1 chat.

Not 1:1 chat. Post your weekly meeting notes in the project channel.

Use Slack’s screenshare & call features.

First — why use Slack?

In short, if an email is responded to within an hour, it’s “fast”.

If a chat is responded to within an hour, it’s normal.

Which one do you want for your employees / team?

Here’s some specifics why Slack is better than e-mail:

Because “chat” is better than e-mail for conversations. (reading email threads sucks, reading chat histories is easy)

It’s also better for sharing files, finding files, and discussing files.

It’s also better for keeping a history of what’s been happening on a project.

It’s also better for onboarding new members of a project.

It’s also better for telling a team when your site is down, when new code has been changed, when a task deadline is coming up, when somebody is active / do not disturb, … the list goes on.

Ok here’s the tips.

Tip #1: One organization. Not multiple.

tl;dr If your company is “Awesome Corp”, then make awesome-corps.slack.com as your Slack organization. All employees are in it.

Do NOT break it out by team. Having awesome-qa.slack.com, awesome-eng.slack.com, awesome-sales.slack.com just ruined employees ability to easily chat cross-functionally. By splitting it up by team, you’re forcing your engineer to join awesome-sales.slack.com when they have a question relevant to sales. That’s annoying, and they probably won’t do it. Which means some important conversation isn’t happening, or it’s moving slowwww over email.

You can create channels that are private to specific members, like “exec team”, or “top-secret-pyramid scheme project”.

Tip #2: Create a channel per project. Not per team.

tl;dr Every time you start a new project, create a new channel and invite the relevant people to it.

If your company has a lot of projects, you will have a lot of channels. But people will only be in the ones that are relevant to them, so it’s fine.

Having project channels makes it SUPER easy to have people jump into a project just when they are relevant & easily read through a project’s history.

Projects end. That means channels will go dead. That’s fine — just archive them. And voila, now you have a history of what happened over the life of that project.

Do NOT create a channel for each team. There are a few reasons for this:

1. Team channels are too broad. Nobody will post except for “what are we getting for lunch” and “where is the team update meeting”.

2. Team channels are not encouraging cross-functional communication. Most of your employee’s projects are cross-functional. They need to communicate quickly with employees on other teams. Having a bunch of team channels doesn’t help this.

Tip #3: Most conversations for a project go in that project’s channel. Not in 1:1 chat.

tl;dr When two members on a project talk to eachother about something related to that project, in goes in the chat channel — not in 1:1 chat.

Why? Because now it is easy to reference conversations about a particular topic. Also you’ll be surprised how useful it is to know what 2 other people on your project are talking about today.

An added bonus is you get a really impressive project history. When you join a project channel where people have had most discussions in it, it is really easy to learn about the project / read through work that has been done.

Isn’t it annoying? Why would I discuss a bug in a channel if it only concerns one other person? No, it’s not annoying. You only get notified when your name / keywords come up in a channel. You’ll be surprised how much more aware of a project you are when you know your teammates have been discussing some bug for the past 4 hours.

Do NOT message other project members privately about an issue. You are not going to annoy team members by posting it in the project channel, but you will deprive them of awareness about what you are working on — and you will have a hard time referencing this knowledge to other people in the future.

Truth is, this is the tip that is the most “gray”. There are plenty of times to talk in 1:1, just most people will tend to talk in 1:1 when it would be useful for the project room. (e.g. discussing a design change, asking when they expect to have something complete, etc).

Tip #4: Post your weekly meeting notes in the project channel.

You probably have weekly update meetings for your project. You probably even take notes during it. Post those notes in the project’s channel.

You now have a summary of what’s being worked on each week that is easily searchable by you & your team. At the start of next week’s meeting or on Monday, people will look at the previous weeks notes.

The notes also act as a good marker for particular conversations — which is really useful when searching for a conversation a month or two later.

For example, if you remember a conversation about “UI refactor”, and find the meeting notes on 4/12/2017, then you scroll up a bit in the chat room and can see what was being talked about — even if the exact terms “ui refactor” were never used.

Tip #5: You can screen-share & talk over Slack.

That means when you’re chatting about a bug / design / document, you can screenshare mid-conversation if you need to.

It requires the paid plan which is $8 / employee, but considering what you’re probably paying your employees, the time they saved trying to get a Google Hangout set up just paid for itself.

Do NOT eat crackers in bed. Honestly, there’s not really a good “not” for this tip.

Alright hope that was helpful.

Again, these tips are obviously not universal truths. They are just patterns I’ve noticed that work well.

If you have other good advice for how your company uses Slack, you can comment here or msg me @whatsdonisdon.