Slack Etiquette: Unwritten Rules for Teams

I have been running a remote team since April 2023, and the thing that surprised me most is how much of our communication friction came from unspoken expectations. People were getting frustrated, feeling ignored, or feeling overwhelmed, and none of it was intentional. One person thought @channel was appropriate for lunch recommendations. Another thought not replying within five minutes was rude. A third was having entire project discussions in DMs that the rest of the team needed to see.

The problem was not that anyone was communicating badly. The problem was that nobody had ever explicitly agreed on how to communicate. Slack etiquette is the set of norms that bridge this gap. It is the difference between a Slack workspace that feels like a productive office and one that feels like a crowded train station where everyone is shouting.

These fifteen rules are not arbitrary. Each one comes from a real conflict I have either experienced or seen on other teams. They are the rules I wish someone had handed me on day one of running a remote team. If your team adopts even half of them, your Slack experience will improve dramatically.

Rule 1: Thread Everything That Gets a Reply

This is the single most important slack etiquette rule and the one that is violated most often. If you are replying to someone's message, reply in a thread, not in the main channel. Threading keeps the channel readable. Without threads, a busy channel becomes an incomprehensible wall of interleaved conversations where you cannot tell who is responding to what.

The real conflict. On my team, a developer posted a question about an API endpoint in our engineering channel. Three people replied in the channel, not in a thread. Meanwhile, someone else posted a deployment update. Within ten minutes, the API discussion and the deployment update were interleaved into a mess that required scrolling back and forth to follow either conversation. The deployment update contained a critical warning that was missed because it was buried between API discussion messages. We nearly shipped a broken build.

The rule. If a message has received or will receive more than one reply, use a thread. If you are the second person replying to something, reply in the thread even if the first person replied in the channel. Threads can be created retroactively. I discussed the broader problem of losing information in threads in [stop using Slack threads as a todo list](/blog/stop-using-slack-threads-as-todo-list), but the inverse problem, not threading at all, is equally destructive.

Rules 2-4: Mentions, Channels, and DMs

Rule 2: @channel is for emergencies only. The @channel mention notifies every single person in the channel, including people in different timezones who might be asleep. It is the Slack equivalent of pulling the fire alarm. Use it only when the entire channel genuinely needs to see your message immediately. Examples of appropriate @channel use: the production site is down, a critical deadline has changed, or a security incident is in progress. Examples of inappropriate @channel use: reminding people about a meeting, asking a general question, or sharing a funny article.

The real conflict. A product manager on a team I advised used @channel in a 200-person company-wide channel to ask if anyone had a restaurant recommendation for a client dinner. Two hundred people received a notification. Twelve of them were in different timezones and had their sleep interrupted. The PM received a mix of restaurant suggestions and angry messages about notification abuse. One senior engineer who was on-call and sleeping was woken up and lost two hours of critical rest before a production shift.

Rule 3: @here is for the present audience. Unlike @channel, @here only notifies people who are currently active in Slack. This is appropriate for time-sensitive messages that only matter to people who are online right now. Examples: anyone available for a quick sync in 10 minutes, the office kitchen is closing early today, or I am heading to lunch if anyone wants to join. @here respects timezone boundaries because it only reaches people who are actually working.

Rule 4: Default to channels over DMs. This is counterintuitive for people who come from email culture, where private communication is the default. In Slack, public channels should be the default. When you discuss something in a DM, that information is invisible to everyone else on the team. If the topic is relevant to anyone beyond the two of you, it belongs in a channel. DMs are appropriate for personal matters, sensitive HR topics, one-on-one feedback, and genuinely private conversations. Everything else should be in a channel where the team can see it, search it later, and learn from it.

Rules 5-7: Response Time and Acknowledgment

Rule 5: Set explicit response time expectations. The biggest source of Slack anxiety is not knowing whether or how fast someone will respond. Different people have wildly different expectations. Some think 5 minutes is normal. Others think 4 hours is fine. Without explicit norms, the person who expects 5 minutes and gets 4 hours thinks they are being ignored. Slack response time expectations should be agreed upon as a team and documented somewhere visible.

My team's response time norms. We agreed on a tiered system. DMs: respond within 2 hours during work hours. Channel messages where you are mentioned: respond within 4 hours. General channel messages without a mention: respond within 24 hours or not at all. Urgent items: use the word URGENT in the message and expect a response within 30 minutes. This tiered approach removed all ambiguity. Nobody worries about response speed because the expectations are clear.

Rule 6: Use emoji reactions as acknowledgment. Not every message needs a typed reply. A thumbs up, a checkmark, or an eyes emoji tells the sender I saw this and I acknowledge it without creating a thread of one-word responses. Emoji reactions are especially valuable in asynchronous communication slack workflows where people might not be able to write a full response immediately. A quick reaction within minutes buys you time to respond thoughtfully within hours.

The real conflict. A designer shared a mockup in a channel and asked for feedback. Nobody reacted or replied for 6 hours. The designer spent those 6 hours anxious, wondering if the design was so bad that people did not know what to say. In reality, everyone was in back-to-back meetings. A simple eyes emoji from one person early on would have communicated I saw it, I will review it later and saved the designer hours of unnecessary stress.

Rule 7: If it takes more than 3 messages to resolve, move to a call. Text-based communication is great for quick exchanges but terrible for complex discussions. If you find yourself writing paragraph-length messages and going back and forth more than three times, suggest a quick call. A five-minute voice conversation resolves what would take thirty minutes of typing. I have seen teams waste entire afternoons on Slack debates that a ten-minute huddle would have settled instantly. Knowing when to use slack vs email and when to use neither is a critical skill.

Rules 8-11: Message Craft and Formatting

Rule 8: Front-load your message with the ask. Do not bury the question or request at the end of a long message. Start with what you need, then provide context. Your teammates are scanning messages quickly. If the first line is background context, they might not read far enough to find the actual ask. Bad format: I was looking at the metrics dashboard yesterday and noticed that the conversion rate dropped by 12 percent which might be related to the change we shipped on Friday, can someone look into this? Good format: Can someone investigate the 12 percent conversion drop? I think it might be related to Friday's deploy. Here is what I noticed in the metrics dashboard.

Rule 9: Keep messages under 5 sentences for channel posts. Long messages in channels get skipped. If you need to communicate something complex, write a concise summary in the channel and link to a longer document, a Loom video, or a thread with details. The channel message is the headline. The detail goes elsewhere. This is a core slack best practices principle that most people learn the hard way after writing a ten-paragraph message that nobody reads.

Rule 10: Do not send hello then wait. This is sometimes called no hello culture. Do not send a message that just says Hi or Hey, are you free? and then wait for a response before stating what you need. This forces the recipient into a synchronous conversation and wastes their time waiting for your actual question. Instead, send the complete message in one go: Hey Sarah, when you get a chance, could you review the login page PR? No rush, just before EOD if possible. This lets the recipient respond on their own schedule with full context.

The real conflict. A team member would message me Hey, got a minute? multiple times per day. Each time, I would stop what I was doing to respond, only to find out the actual question was something trivial that could have been sent as a complete async message. After three months, I was losing 30-40 minutes daily just to the overhead of these hello-first exchanges. When I brought it up, the team member had no idea it was a problem. They thought they were being polite by checking availability first. This perfectly illustrates why communication norms need to be explicit.

Rule 11: Use voice messages for nuance. Slack huddles and voice messages are underused tools for situations where tone matters. Text strips out tone, sarcasm, warmth, and urgency in ways that create misunderstandings. If you are giving feedback, discussing a sensitive topic, or explaining something complex, a 60-second voice message conveys more than 500 words of text. It is faster to create, faster to consume, and less likely to be misinterpreted.

Rules 12-14: Timezone and Culture Awareness

Rule 12: Never expect instant responses from different timezones. This seems obvious but is violated constantly. If your colleague is in a timezone 8 hours ahead and you message them at your 3 PM (their 11 PM), do not follow up the next morning with did you see my message? They saw it. They were asleep. Build timezone awareness into your Slack habits by checking people's local time before messaging and structuring requests so they can be addressed during the recipient's next work day.

Rule 13: Schedule messages for the recipient's work hours. Slack's scheduled send feature lets you write a message now and deliver it when the recipient is online. This is a game-changer for distributed teams. Instead of sending a message at the recipient's midnight, schedule it for their 9 AM. They start their day with your message at the top of their feed instead of buried under 8 hours of other messages. This small act of timezone respect pays enormous dividends in response rates and team goodwill.

Rule 14: Be explicit about deadlines across timezones. When you say end of day in a global team, whose end of day do you mean? Always include a specific time with a timezone: Please review by 5 PM EST on Thursday. Vague time references cause confusion and missed deadlines when team members are spread across the globe. This applies to slack response time expectations too. Within 4 hours means 4 hours of their work time, not 4 clock hours regardless of timezone.

The real conflict. A US-based manager sent a message to a London-based engineer at 5 PM EST (10 PM London time) saying this needs to be done by tomorrow morning. The engineer woke up at 8 AM London time (3 AM EST), completed the work by 11 AM London time, and the manager did not see it until 6 AM EST because they expected it by their morning. The engineer thought they had delivered early. The manager thought they had delivered late. Both were frustrated, and neither was wrong. Timezone ambiguity had created a phantom conflict.

Rule 15: Channel Naming and Hygiene

Rule 15: Follow a consistent channel naming convention. Channel names are the navigation system of your Slack workspace. Without a convention, you end up with channels named engineering, eng-team, dev-discussion, and devs that all serve the same purpose. This is the slack best practices equivalent of having five junk drawers in your kitchen.

A naming convention that works. Use prefixes to categorize channels. Team channels start with team- (team-engineering, team-design, team-marketing). Project channels start with proj- (proj-redesign, proj-q2-launch). Social channels start with fun- (fun-music, fun-pets, fun-food). Announcement channels start with announce- (announce-company, announce-engineering). This convention lets anyone find the right channel by browsing the prefix category, even if they do not know the exact channel name.

Archive dead channels. Every quarter, review your channel list and archive channels that have had no activity in 60 days. Dead channels clutter the sidebar, confuse new team members, and sometimes contain outdated information that people mistakenly trust. Archiving does not delete the channel. It just hides it from active view while preserving all the messages. You can unarchive it later if needed.

Every channel needs a purpose statement. When you create a channel, fill in the channel topic and description with what the channel is for and what should not be posted there. A channel called team-engineering should have a topic like Engineering team discussions, code reviews, and technical decisions. Not for social chat (use fun-random) or company announcements (use announce-company). This prevents channel drift where a focused channel gradually becomes a general-purpose dumping ground.

Implementing These Norms Without Being the Fun Police

The biggest objection to communication rules is that they feel controlling. Nobody wants to be the person who sends a document titled Communication Rules for the Slack Workspace to the whole company. That feels bureaucratic and kills the casual, conversational culture that makes Slack enjoyable.

Here is how I introduced these norms without making it feel heavy. First, I did not frame them as rules. I framed them as how we work. During a team retrospective, I asked what frustrates you about Slack? The team brought up most of these issues themselves: too many @channel pings, hello-first messages, lost information in DMs, timezone confusion. The rules emerged from the team's own pain points, which meant they had immediate buy-in.

Second, I started with just three norms: thread replies, no bare hellos, and emoji reactions for acknowledgment. We practiced those for a month before adding more. Trying to implement fifteen rules at once would have overwhelmed everyone and triggered rebellion. A gradual rollout lets each norm become a habit before the next one is introduced.

Third, I modeled the behavior I wanted. I threaded every reply. I always included context with my questions. I reacted with emoji immediately and responded with text later. When the team lead consistently follows the norms, the team follows without needing to be told. Behavior spreads through observation, not documentation.

Fourth, I made it safe to call out violations gently. When someone sends a bare hello, anyone can respond with the nohello.com link with a smiley face. When someone uses @channel inappropriately, anyone can point it out without it being a confrontation. The key word is gently. If calling out a norm violation feels hostile, people will stop doing it, and the norms will erode.

Good slack etiquette is not about perfection. It is about establishing shared expectations so that communication works for everyone on the team. Every rule in this guide exists because I watched its absence cause real problems: missed information, hurt feelings, wasted hours, and preventable conflicts.

Start with the three rules that address your team's biggest pain points. Practice them for a month. Then add more. Within three months, your Slack workspace will feel fundamentally different. Less noisy, more organized, and significantly less stressful for everyone involved.

Of course, even the best slack etiquette cannot solve the problem of action items getting lost in conversations. When your team communicates well but nobody captures the tasks that emerge from those conversations, good communication still leads to dropped balls. That is the gap Mursa fills. It captures tasks from Slack conversations so that well-communicated decisions actually turn into completed work. Because the point of good communication is not just to talk better. It is to get more done. And Mursa makes sure the getting done part does not fall through the cracks.