We're Sharing Our Slack Guidelines and How They're Helping in an All-Remote Culture

Until last year, I found Slack frustrating, but tolerable. It was a nice place to send all our alerts, and facilitate open conversation and collaboration—two things that matter a lot, and that email does poorly. But as we crossed the 100-employee mark, Slack started to feel noisy and slow. It was difficult to follow conversations, and many complained that they spent too much of their days just clearing notifications. Hearing my long-held sentiment echoed across the company pushed me to action.

So I led a committee to make some guidelines for how we use Slack. We released them to the company in January and they had a profound impact on our communication, even before we were all sheltered in place. Now that we are all working from home, our online communication is absolutely critical—I can’t imagine how much slower we would move without structure in our communication.

If you’re just here for the guidelines, jump ahead with the links. They are shared here in almost-complete form, with a few examples redacted to protect our employees’ privacy.

• Goals and methodology

• What we decided not to include

• The impact

• Mode’s Slack Guidelines

But first, a bit about how we arrived at these guidelines, and some things you may want to consider that aren’t in the guidelines themselves.

Goals and methodology

We started this project to address communication norms broadly but quickly honed in on Slack as the place where we would be able to have the most dramatic and immediate impact. Even in the broader context of communication at the company, many of our goals were Slack-specific:

• Treat Slack messages a little less like instant messages and a little more like email—we want people to think before posting, and to communicate in a way that will be searchable/discoverable in the future.

• Provide guidance on when to use Slack as opposed to making a document or sending an email.

• Clarify expectations around response times in Slack and allow communication to become less synchronous on the whole.

• Improve onboarding for new employees by clarifying how they should be using our communication tools.

We also wanted to focus on convention over configuration. There are certainly tools out there that are better suited than Slack to accomplish some of these goals (I spent a lot of time looking at Threads, in particular). Ultimately, we made a deliberate decision to solve the problem by changing social norms rather than by throwing another SaaS app at the problem, with the expectation that it would be harder to accomplish but stickier in the long run.

There were several concepts that, while not goals per se, I felt were important to include to make sure our Slack use reflects Mode’s broader cultural values:

• Treating each other well: It’s easy to misconstrue someone’s intent (or to misrepresent your own intent). We all need to be mindful of this when using Slack or any other medium.

• Kind enforcement: Adjusting social norms is difficult and requires us all to keep one another on track. We should politely correct one another when we see behavior that falls outside the norms we’ve outlined.

• Unplugging: As at many startups, people at Mode work a lot. So it’s important to make time away from work feel as restful as we can make it. The guidelines below address expectations and techniques to help make this possible.

Once we honed in on these goals, I started speaking with folks at Mode internally about what was working and what wasn’t. I put together a small committee to brainstorm and collect feedback, then circulated a couple drafts more broadly for input.

As a leadership team, we often find ourselves questioning how applicable our own experience (too many meetings!) is to that of a manager or an individual contributor on a given team. To avoid this bias, the committee sought input from folks at all levels of the company. This was an especially valuable process, as it led us to a lot of examples—good and bad—of things to address in the guidelines themselves. I also spoke with several people outside the company who had developed similar training materials (special shoutout to Kirill at Enki).

What we decided not to include

While our Slack Guidelines introduce a variety of tools and suggest use cases for them, they don’t cover expected behavior. We do most of our document collaboration in Quip, but there are pockets of the company that use Google Suite, Notion, Coda, and Airtable. At some point, we will consolidate a bit and provide some guidance on where to store things (a key step on the way to knowing where to find things). As an extension of this, we considered guidelines around how to make and record decisions—when to seek input from others, who is required to make decisions, etc. We’ve thought about building an internal handbook along the lines of Valve’s well-known example and we may get there eventually, but decided that there was a lot of value in the piecemeal approach. Based on the initial reception of our Slack Guidelines, this was definitely the right call.

One of the big questions that came up in this process was when to have a meeting instead of using Slack. Daily standups, for example, can be done either way. As we dug in, we found that teams had different preferences, and concluded that it was probably best to let each team figure it out themselves. The other places where this felt most controversial were for quick tap-on-the-shoulder types of “meetings” to answer a specific question, and with misunderstandings resulting from the difficulty of expressing sentiment in text-only communication.

Since moving to 100%-remote in the COVID-19 era, we’ve found that the Zoom integration with Slack is especially good for resolving issues like this. Need to resolve an issue quickly? Just /zoom and figure it out. This didn’t make its way into our first draft of the Slack Guidelines, but has proven incredibly useful and will undoubtedly be in the first revision.

There are a bunch of Slack-specific things we didn’t cover in the interest of shipping something quickly. The biggest outstanding item is a set of best practices for using or adding integrations: who can/should enable new integrations, navigating our vendor security process, etc. We also don’t cover which channels to join, but our IT admin put together a Slack channel directory, which has helped quite a bit with onboarding (and also exposed a ridiculous proliferation of channels). Finally, we decided to omit a bunch of tactical things to keep the document from getting crazy-long. For example, using emojis to react to a message in a DM does not send a notification, so if the goal is just to give a 👍 to let the other person know you’ve received their message, the best practice is to send it as a message. That’s nice to know, but probably not worth adding to our guidelines document at the risk of detracting from the more important behaviors that we want everyone to internalize.

The impact

I was worried that this would feel heavy-handed, and anticipated mixed responses ranging from “I’m already a good communicator, why do I need this?” to “Okay, I guess I’ll try this if you really want me to.”

Instead, the reception was overwhelmingly positive. I saw an immediate and pervasive behavior change, and got a lot of direct positive feedback from employees in all departments. Other department heads reported seeing the same reactions.

We’re several months into these new guidelines and a couple of things have stuck more than others. So far, the team has:

• Used Slack threads much more extensively. Now it’s much easier to follow conversations, though Slack’s notification system can make it difficult to follow updates to threads. On the whole, this has been a big improvement.

• Applied better structure and formatting to their Slack posts. Many new threads now have bold subject lines at the beginning, and arrange information in ways that make them easy to read. This is the most noticeable difference—each post is much higher-quality than it might have been sans-guidelines.

Overall, I’d say everyone got the gist, and some folks got the details. The results are good, and we have already built on them successfully—the /zoom convention is a great example. Our Slack Guidelines have also been enough of a success that we went on to add Meeting Guidelines, but that’s a topic for another post entirely.

After rolling out the guidelines below, we’ve seen a lot more posts that look like this example below and it’s helped us move faster.

Here’s our Slack Guidelines.

Note: The examples that we included in these published guidelines were approved with employee consent. We removed some examples that were originally linked in this document to protect confidential information, but encourage those of you who adapt these guidelines to link to examples at your own companies.

Mode’s Slack Guidelines

The summary

Following these guidelines will make us more consistent, predictable, and effective in our communication.

• Make your availability clear.

  • Use status updates to let others know when you are away or when they should expect a delayed response.

  • When you’re not working, consider logging out or setting *Do Not Disturb *so that you can get out of “work mode” and recharge.

• Assume best intent. Sometimes tone and context are lost in text.

• Communicate using threads. In general, your message in slack should be either:

  • a response to an existing message, in the thread below that message.

  • a new thread, in which case you should put the most important information or action items first, use bold text to highlight important pieces, and use line breaks or bullets to break up content.

• Default to posting in public channels. Use private groups and DMs for sensitive material or for coordinating to avoid spamming public channels.

• Abide by the conventions for @mentions, particularly when mentioning groups or in large or reserved channels like #announcements and #general (listed at the bottom of this doc).

• We’re all responsible for our adherence to these guidelines, so:

  • re-read your message before you hit send.

  • when you think someone has strayed a bit too far from these guidelines, respond and politely let them know how they can communicate better.

Why do we have guidelines?

The best thing we can do to move faster as individuals and collectively as a company is to communicate effectively. Used right, Slack makes it easier for information to reach the right people. Used poorly, Slack can interrupt focus and become an enormous time suck. At its worst, it can derail decisions that are on the path to great outcomes.

These are guidelines, not hard rules. Ultimately, we rely on our judgment to determine how to communicate. In places where these guidelines aren’t practical or effective, do what you feel is best (and notify the People team so that we can potentially modify the guidelines).

We are all responsible for making Slack work for Mode. If you see something that doesn’t fit these guidelines, DM the person responsible and politely suggest they change their post.

What Slack is for

We use a variety of internal communication tools at Mode including Zoom, Quip, Google Suite, and other domain-specific tools with their own notifications and inboxes like GitHub.

We use Slack for:

• Asking questions, even (especially) when you don’t know who is the best person to answer

  • Here’s an example of a question that is directed to a group rather than an individual.

• In cases like the one below, Slack can make questions visible to many experts at once, and can lead to several solution options.

• Discussions that can reach a resolution quickly. For example:

  • Confirming a detail of a decision that has already been made

  • Coordinating responsibilities on a project (though the result should be recorded in the appropriate project tracking software)

• Direct messages between employees or groups of employees

• Posting and responding to one-to-many updates

  • Here’s a good example of an update with more context than we would have gotten through automation, and a resolution in the same thread so that anyone following would know that the problem is resolved.

• Automated notifications/alerts that should live in a publicly accessible place

  • The #nps-responses channel is a good example

• Daily standups on a team-by-team basis (some functional or project teams do these on Slack, others do it in other ways)

For the following things, you should use other applications:

• Zoom for real-time meetings with multiple individuals:

• Text or call in emergency (link to internal phone directory). You can always try Slack first, of course.

• Email when including people outside Mode in communications (sales, partnership, recruiting, etc.)

As a supplement to any of the above:

• Quip or Google Suite for materials that require review or revision. Use and add comments there. (You can link to the appropriate Slack channel)

• Asana/GitHub Issues/The relevant ticketing system to assign items for follow-up

  • This will typically accompany some other type of communication in Slack or otherwise.

Honest words, kindly delivered

Trust is fundamental to good long-term collaboration and communication. In order to maintain that trust, we need to be careful about the words we use on Slack. It can be difficult to infer the tone of a written message—the best intent can produce a terrible outcome with just a little carelessness. Avoiding this pitfall requires two things:

• Take care to re-read your messages before sending, especially when controversial or challenging.

• When you are offended or confused by a message, assume best intent. Address the sender directly and seek to clarify.

Expectations for presence and responsiveness

The following is expected of everybody, on days when you are working:

• Check Slack periodically throughout the day.

  • This will vary from person to person. Use your judgment to determine the right balance of responsiveness vs. focus time or, when in doubt, consult the people you work with regularly or your manager.

• Participate in conversations as you have time—we do not expect instant responses

• Read direct messages within 24h and respond, if appropriate

• Keep your status up to date with details about your availability. The easiest way to do this is to add the Google Calendar integration, which will draw from your calendar. When you have PTO, you should mark it on your calendar so that it is reflected in your Slack status.

  • You should still notify your manager and immediate collaborators, and log your PTO in BambooHR.

  • Slack automatically assumes you are active if you are at your computer typing (even outside of Slack). If you would like not to be disturbed, manually set your status to “Away.”

  • Here’s Slack’s complete guide on how to manage your status.

If you need to get a hold of someone immediately, try Slack first. If they are not responsive, check their calendar and, if necessary, text them (link to phone directory).

Unplugging

When you’re done with work for the day, consider setting Do Not Disturb or logging out of Slack entirely. It’s important to get out of “work Mode” and to recharge — if you’re needed for anything critical at off hours, someone will call or text you. This goes for weekends and vacation as well.

Communicating effectively on Slack

Our Slack posts should generally strive to get information across as quickly as possible, allow people to consume necessary info quickly (and drop out when not necessary), and prevent valuable threads from being drowned out by chatter. We achieve these primarily by posting quality content in the right places.

Threads vs. chat

When posting in a public channel, you should always think of your post as starting a new thread. If your post is a response to another message, post it in a thread attached to the relevant post.

Messages should be written in a way that invites constructive conversation from the right people. Some tips for doing this:

• Start with a subject line (in bold or caps) that denotes what you expect of the reader (e.g. “ACTION:” or “DECISION”).

• When starting a thread, put most important information first.

  • This is almost always the “bottom line” — the request you are making, the decision you want to discuss, etc.

  • Any reader should be able to decide quickly whether it’s relevant to them and then keep reading or move on.

• Use line breaks (Shift + Enter) and bullets (*) to break up paragraphs and make your post more easily readable.

• Use bold text to highlight important information (action items, etc.).

• Avoid long (200+ word) posts. If you need to include this much information, put some of it in a 2nd post in a thread, or consider a Quip or Google Doc instead.

• Several of these guidelines came from this HBR article. Check it out for examples and more in-depth explanations.

• Here’s an example of how to do this effectively, posted in the channel for the ReportCapture project referenced in the post:

Public vs Private vs DM

Most communication should take place in public channels, for a few reasons:

• People can easily follow or abandon conversations when they are in the open without creating a bunch of branches of the conversation—it remains easy to keep track of what is happening and to loop in relevant people. This is one of the primary reasons we use Slack instead of email.

• People who are having parallel conversations can see that they are happening and merge them.

• The organization of public conversations into channels with good naming convention helps us find prior conversations when we want to revisit them.

Private channels present a number of challenges. Files and posts shared in private channels can’t be shared to public ones. None of the public channel benefits apply. We should use private channels for circumstances where privacy is absolutely critical:

• Discussing candidates who are interviewing (these channels begin with the prefix “int-”)

• Sensitive HR issues

• Collaborating on draft work that is not yet ready for public consumption

• Situations in which you regularly DM the same group of people such that it’s easier to find the conversation if you name it

DMs have all the same challenges as private channels, and should thus be used for one-off communications that are sensitive or don’t merit contribution from others at the company:

• Providing sensitive feedback

• Coordinating logistics for a meeting

@Mentioning individuals

Posting primarily in public channels has an easily-solvable drawback: you need to explicitly @mention anyone whom you’d like to notify about your post.

• It can be helpful to @mention people in a message, even when you don’t expect a specific action from them, like this example below:

@Mentioning a group of people

In general, you should avoid @mentioning entire channels at once, as this is equivalent to notifying the entire company in many cases. For example, nearly all employees are in the #cs-general channel. If you want to notify all members of the success team, use @csms instead of @channel or @here.

• @channel: When you want to make an announcement, using @channel will send a push notification to all members in that channel. This should be reserved for company-wide announcements and extremely urgent matters (e.g., posting in #eng-fire that Mode is down).

• @here When you need a quick answer and the request is urgent enough that it is acceptable to interrupt everyone in the channel who is currently active in Slack. You should see how many people are members of the channel before doing this, and consider mentioning a specific collection of people instead (e.g., @frontend

  eng or @backend eng instead of @here in the #eng channel).

Channels and Channel Policies

Reserved Channels

• #announcements: This channel is only to be used by managers to announce significant updates that are important enough to interrupt everyone at the company’s work. Posts in this channel should always mention @channel and should be relevant to everyone (e.g., administrative announcements, key hires, event notifications, etc.)

• #general: This channel is only to be used for work-related content that is relevant to the entire company, but less urgent than announcements (e.g., continued discussion from our weekly all-hands meeting)

Additional Resources

• Slack help on channels, sending messages, and other basics

• Slack tips and tricks