#25 Ten Unspoken Rules in Slack

After working at five different companies that use Slack, I’ve realised that within an engineering culture, there’s also a Slack culture. A culture that reflects how effective and communicative a team can be. How they communicate ideas, progress, blockers, solutions, etc.

This is not research-backed, but here’s a thought experiment:

What if you could measure a team’s performance by observing their Slack channels?

Over time, they’ll develop some unspoken rules for communication to increase their team’s productivity. I believe you can spot a productive engineer by their written communication and how they use Slack.

So, here are 10 rules for efficient Slack communication.

---

#1 - Don’t overuse @here

When I worked at Dell, I was responsible for coordinating tech talks for engineering teams and regularly posted announcements for upcoming talks. A rookie mistake I made was pinging the channel with every announcement and inviting discussions, which ended up pinging every member for every reply. This created a noisy update, one I’d even mute myself.

Unless there’s an urgent update or a need for the team’s attention, using @here more than necessary will interrupt their deep focus time. A conversation thread that starts with @here generates lots of notifications, making it difficult for non-relevant participants to concentrate.

Be mindful of using @here. Only use if the entire group should engage.

#2 - Use threads for new conversations

Some people tend to go back and forth on a specific point, which ends up cluttering the channel. For example, my team once had a debate on Docker vs Podman (50+ messages). A good rule is to create a thread, tag the relevant people, and start the conversation there.

This provides a bird’s-eye view of all current and past nested conversations within the main channel. It’s super convenient for people who want to zoom in or out of any conversation they find relevant or interesting.

If Alice, Bob, and Charlie want to follow up on the $feature release, they know where to find it.

#3 - Add context to new messages

This rule is simple but essential. Messaging individuals without context creates awkward ambiguity and leads to longer discussions before issues are resolved. Receiving multiple “Hi”s from teammates makes it harder to distinguish what’s urgent, important, or easy to resolve.

So, instead of posting

❌ Hey there
❌ I have a question
❌ Are you free?

Take the time to write out your question or request:

✅ Hey, can we catch up on the new roadmap this week? I have a few questions about the second milestone.

#4 - Separate channel for a recurring topic

Having an all-in-one channel for all discussions can hurt the team’s productivity, making it harder to search for key details and organise conversations by category. If a topic keeps coming up with specific individuals, create a dedicated channel for it.

For example,

• Asking a team about backend services → #ask-backend

• Requesting support from QA engineers → #support-qa

• Discussing key details of a project → #project-awesome

#5 - Format links with bookmarklets

Over time, teams develop their own habits and tools for communicating over Slack. Sharing PRs, posting release notes, recording demos, etc.

A common one I found in previous companies, is using bookmarklets for PR reviews.

A bookmarklet is a JavaScript code snippet stored as a bookmark in a browser.

A bookmarklet is a small piece of code that runs on a web page to perform a specific action. For example, I can have a bookmarklet that copies the page URL and formats it into an [emoji][page title] for fun. Here is an example:

🌟 A concrete example of a bookmarklet is copy-pasting PRs to the team channel.

A good solution is to have a bookmarklet that generates a standard message with a PR link, including its state (open or draft) and diffs. Here are two examples: (1) GitLab and (2) GitHub.

Check out the repo below for using a bookmarklet for PRs:

🔗 https://github.com/shehab-as/bookmarklets

#6 - Cut down on previews

This is a biased opinion, but from experience, I’ve found that message previews create a lot of clutter. This is true in busy channels where important conversations are happening.

My colleagues and I have this unspoken rule of removing “visual noise” as much as possible when posting in the main channel. This includes previews from PRs, Notion, Shortcut, Jira, etc.

Try to minimise previews when posting links, especially if there are many.

#7 - Use Slackbot for reminders

Individuals with busy calendars tend to set reminders in Gmail or Outlook to keep things on track. Teams do the same with Slackbot, using it to set reminders and automate repeated tasks. This helps everyone stay organised and make sure nothing is overlooked.

Here are examples:

• 🔔 /remind #channel to share team updates every Friday at 3PM

• 🔔 /remind #channel to review open PRs every weekday at 9AM

• 🔔 /remind #channel to accept new interviews every Thursday at 3PM

• 🔔 /remind #channel to schedule a retro on the first Monday of every month at 1PM

#8 - Avoid lengthy channel names

This may seem like an obvious rule, but I still come across channels with long names that add little value. Naming channels shouldn’t be a big deal, but take a moment to trim down any unnecessary words.

Here are examples:

• ❌ #engineering-team-technical-discussions
  ✅ #eng-discuss

• ❌ #customer-bug-reports-and-tracking
  ✅ #bug-reports

• ❌ #hiring-and-referral-process-updates
  ✅ #hiring

There are only two hard things in Computer Science: cache invalidation and naming things.— Phil Karlton

I would also add—naming Slack channels—as another hard thing. 😬

#9 - Use tmp- for short-lived channels

Some projects require temporary collaboration from adjacent teams or individuals. These channels are short-lived, meant for only a few days or weeks. A good convention is to signal the liveness through the channel’s name.

tmp- channels are expected to be archived within days or weeks.

#10 - Use prefix for consistency

Channels with a common prefix can help visualise an engineering function and highlight relevant channels for engineers. This is especially useful for new joiners, who may find themselves lost in many channels without knowing which are most important.

Technical program managers (TPMs) or individuals working with multiple teams also find this valuable for coordinating and managing cross-team communication.

Using a prefix for all channels is not mandatory, but try to find a balance between convenience and clarity.

Bonus: #11 - Leverage Slack’s marketplace

🔗 https://slack.com/marketplace

Slack is more than just a messaging app. It’s a platform with many supported integrations and a marketplace full of apps for collaboration and productivity.

Take the time to explore the apps that work best for you and your team.

Some ideas for inspiration:

• Loom — Record demos or quick updates.

• Jira — Create and track team sprints.

• GitLab — Track CI/CD statuses and new MRs.

• Polly — Create quick polls for teams.

• Clockwise — Manage a busy calendar.

• Coffee & Donut Chat — Randomise coffee chats with the team.

---

One last thing: Posting a direct message to someone vs. in a channel can be seen as synchronous vs. asynchronous communication. If you need an urgent response, message that person directly (sync). If it’s not urgent, post it in the channel (async).

Or for clarity, you can signal this at the beginning of your message, like this:

✅ “(Non-urgent) Can someone look into the error logs?”
✅ “(Urgent) Can someone look into the deployment failure?”

---

Wrap Up

Teams love using Slack for day-to-day communication. They find new ways to boost productivity through app integrations, Slackbot, formatted links, and more. They have fun with emojis, GIFs, and memes. They pin announcements and links for quick access, and generally make everything easy to search.

To recap:

Fun fact: Did you know that Slack is an acronym for “Searchable Log of All Conversation and Knowledge”?

💬 Quick Note:

I recently launched a testimonial page (also known as Wall of Love) for readers to share their thoughts about the newsletter. I would love to feature yours! You can add one through this link 🙌

Special thanks to Kenny, Nim, Karim, Roxana, and Mark for their beautiful words!