Slack hygiene at a fully-remote company

On the left, text reads: "Slack hygiene at a fully-remote company." On the right is the Slack logo, surrounded by suds.

We’re fully remote, we rarely (if ever) send emails internally, and we hold as few meetings as humanly possible. So that leaves us with Slack and Notion as our primary means of communication. 

We already wrote something up about how we use docs. Here, we’re going to talk about how we use Slack. 

We want to thank Zapier for their post, “Slack etiquette at Zapier.” We based our approach directly off their guide. 

Check out their article for a complete list of simple rules that will keep your channels uncluttered and useful. We’ve found it extremely helpful. 

But there’s a couple additional things we do to further simplify communication.

We’re going to run through some basic rules about:

  • Channel naming conventions

  • Managing your attention in Slack

  • Requesting that another colleague do some task 

  • Acknowledging requests

Why Slack hygiene matters

We’re a company of about 75 people, and we’re growing steadily. Reducing noise pollution, traffic, and collisions in the miniature crowded city of our internal comms tool keeps people productive, efficient, and informed. 

  • A poorly-disciplined Slack channel can quickly become overrun with unnecessary comments, banter, and redundancy. This isn’t helpful for anyone. 

  • And while it may not be that annoying at first, poor Slack hygiene eventually gets in the way of people’s workflows. It gets harder for people to find the information they need, which makes it harder for them to do their jobs.

Text reads, "Why Slack hygiene matters." Then, a list reads: it keeps Slack from becoming overrun with unnecessary comments, and it ensures people can find the information they need, when they need it."

How we use Slack

We use Slack for the same reasons Zapier uses Slack. Namely:

For almost-synchronous, fast-moving information

Slack is the company newsfeed. Not everyone will catch what you say in Slack. It’s likely your message will get buried within a couple hours. If you need the information to stick, or if it’s important that everyone reads it, create a document in Notion or an Asana ticket. You can link to those artifacts in Slack. 

For public conversations

Err on the side of using public channels for work-related discussions. DMs are private between two or a few people. DMs should only be used for private conversations. 

A private conversation can include anything that deals with sensitive topics or information, a new idea that’s underdeveloped and not ready for public discourse, or private notes.

If you find someone DM-ing you about something that should be in a public channel for visibility, ask that person to repost in a relevant channel so you can reply there. Or offer to do so on their behalf. 

Public by default means that intra-team communications are public and visible to anyone in the company by default. 

When you’re opening up a channel of communication or a new document, assume it should be public, and find specific reasons for why it should be private, rather than the other way around.

Public by default makes our team more effective by:

  • Making it easy to access a project state. Anyone working on a project adjacency can look at a Slack channel or a set of docs and see what’s going on. 

  • Enabling serendipitous interactions. Someone not in the original discussion may have context or expertise related to some project or idea.\

  • Helping onboard new employees. Less asking and meeting, more self-service knowledge-gathering.  

  • Improving searchability. When info is public, people can find it. This reduces how often you have to interrupt colleagues or ask about information that’s already documented.

Text reads: "Public by default helps team members: Easily access project states, enable serendipitous interactions, and help onboard new employees."

What Slack is not for

Non-ephemeral task discussion

If there’s a task in Asana, a doc in Notion, a PR in Github, or a mockup in Figma, best to keep the discussion in comments in the tool of origin. (In fact, we have many bots that post tasks, comments, etc. from these platforms directly into Slack too, so you can keep in sync.)

High-bandwidth collaboration

If you’re stuck on something complicated, it’s going to be much faster to hop on a call with 1-2 collaborators and iron out the kinks. Async has its limits. Complex projects that would be stalled in async workflows often get moving quickly once there’s a live discussion. 

Topics where non-verbal communication matters

Conversations that require the human element (delivering feedback, building rapport, ironing out a conflict) are best done live. 

Channel naming conventions

Like Zapier, we use a standardized naming convention to keep things organized. This is done largely through prefixes. 

  • #tremendous- - company-wide content (#tremendous-announcements, #tremendous-banter, #tremendous-praise, #tremendous-people)

  • #team- - each team has a dedicated channel (#team-sales, etc). These channels are open to all, to increase transparency and communications between teams. (For instance, If a salesperson has a question for support, they can post it in #team-support.) If there's regular content that's valuable exclusively to the team, consider creating a separate channel (see below).

  • -internal - is a smaller team channel, typically consisting of active team members (e.g. #marketing-internal). These stay public, but they tend to have more day-to-day chatter.

  • #sales-, #mkt-, #product-, #ops-, etc - team channels about specific topics (#sales-outbound, #mkt-blog, #product-ux-research)

  • #project- - ongoing projects. Archive upon conclusion of the project.

  • #bot- - automated posts / webhooks from other services (#bot-metrics, #bot-front-end-exceptions)

  • #offsite- - offsite discussion channels

  • #interview- - interview channels, where external candidates are invited and can collaborate with us

  • #c-internal- - private channels for logistics and discussion of individual job candidates

  • #random- - whimsy! catchall for anything that doesn’t fit into other prefixes (#random-music, #random-podcasts)

A screenshot of Slack channels.

Managing notifications (and your attention)

We have access to basically every channel as a team. This can be overwhelming. Blocking off large chunks of time for deep work is a core tenet of our culture. So it’s key that each individual is a responsible arbiter of their own attention

Some tips on how to do this:

  • Set up Do Not Disturb. It turns off notifications so you can focus, and still permits people to override and notify you if something is urgent.

A screenshot of the Slack UI, including an option to set "Do Not Disturb."
  • Mute channels that are noisy (particularly useful for bot channels).

A screenshot of channel options, including an option to "Mute Channel."
  • Save messages in Slack so that you get to them later, even though they’ve been read. Advanced users will route saved messages to their todo lists.

A screenshot of Slack message options, including the option to "Add to saved items."
  • Clean up your sidebar so new messages don’t get lost in channel clutter.

Asking someone to do something

In lieu of meetings, we primarily use digital comms channels to discuss initiatives, projects, tasks, and requests. Slack is one avenue for talking about all the stuff we want to get done. 

But a lot of information flows through Slack, at all hours of the day. Especially at Tremendous, where we’re scattered across time zones. It’s easy to miss stuff. So if you want to request that a colleague helps you out with a task, it’s important to take extra steps to make sure they actually see it. 

First, see if there’s a process to follow in a project management tool. (We use Asana.) 

Even better: pair a task in a project management tool with a nudge in Slack.

If you only want to use Slack, use mentions.

Slack mentions (e.g. @here, @nick) come with additional notification properties. This is useful, because many team members have notifications for certain channels muted or off.

Type of messageWhen to useExpectations
Message posted in channel, without a mentionGeneral FYI to channel.Most will see sometime.
CC (cc @nick)General FYI, expectation that cc’d parties will see at some point.Most will see sometime, cc’d will see soon, but may not respond.
Direct mention (e.g. @nick)Requesting a specific action or response from someone.Most will see sometime. Tagged will see soon, expected to respond.
@hereFor important / urgent announcements, where visibility is important or specific action required.All online will see immediately. Someone will usually respond soon.
@channelFor urgent, action required. Notifies teammates not at their computer.All will see immediately, including those not at comp. Many will respond.

A note on cross-posting

Would the information or suggestion you just made be helpful to people who may not have access to the channel you posted in? 

No worries. This is where cross-posting comes in. 

Simply click ‘copy link’ to paste your comment into another channel. 

Few channels contain every person across the company. 

So if you posted something in #team-marketing that an engineer may find helpful, it’s best practice to repost the comment in #team-engineering to make sure the information gets in front of the right people. 

Contextualize your messages

Make sure to add context to your message, so team members have a little more information about what exactly you need from them. 

Prepend these to messages when they have specific expectations on responses.

A couple examples of time-specific expectations:

  • (no reply required)

  • (not time sensitive)

  • (needs reply by Tuesday EOD)

Screenshot of a Slack message.

Acknowledging requests

There are no read receipts in Slack. So acknowledging a message is a valuable way to tell the sender that it was seen and processed. 

Even more so if you’re a fully remote company that holds very few meetings. We rarely propose initiatives over Zoom, so we can’t verify that people have seen our ideas or suggestions unless they somehow acknowledge it in writing. 

We do this in two ways:

  • Emoji response - this gesture acknowledges silently.

    • Assume the sender won’t see these unless they look at the original message.

      • 👀 - seen

      • 👍 - acknowledged

      • Literally any other emoji (even goofy ones that obliquely refer to the topic) can be a lightweight way to note your engagement with the discussion

  • In-thread response - this notifies the sender loudly.

    • Use in-thread responses for when you want to loudly acknowledge receipt. These will be akin to a DM. If you aren’t sure, prefer this to an emoji response, since it’s more likely to be seen.

    • It doesn’t have to be lengthy - just reply with 👍.

A note on emojis at a fully-remote company

Every interaction matters - especially when you’re remote. Recognizing coworkers’ comments, jokes, suggestions, and arguments with affirmative or even silly emojis helps everyone feel seen, heard, and acknowledged. 

Written communication, notoriously, is devoid of the subtle, illuminating inflections of tone of voice, facial expression, body language, etc. 

Emojis add some color to what readers are feeling and how they’re receiving information. If someone makes a joke on Slack, and you reply with a laughing emoji, they can rest assured their playful tone landed. And giving helpful emotional context to someone’s comment, joke, or idea fosters a more friendly, less-sterile workplace. 

The bottom line

Slack is extremely effective at making instant messaging convenient, fast, easy, and sortable. But it’s also really good at distracting you from your most important work, and it can quickly become cluttered with unnecessary messages, unproductive banter, and off-topic digressions. 

Using Slack as one of our few primary modes of sharing information comes with a responsibility to be clear, concise, and unobtrusive in our communications. These simple rules help us keep things organized.

Share this article

Facebook
Twitter
LinkedIn