Slack and Chat

Learning outcomes

You already write a careful email. Chat feels like it should be easier, because it is short and fast, and yet it is where good communicators quietly waste the most of everyone’s time. The medium rewards a different set of habits than email does, and importing your email instincts, or your spoken instincts, gets it subtly wrong. This page is the chat-specific rulebook: the small moves that make a message easy to answer, and the common ones that make a whole channel harder to read.

After studying this page, you can:

• Explain why chat is its own medium, faster and looser than email but with an etiquette of its own, and why getting it wrong costs the whole team attention.
• Apply the core habits of a clear chat message: no hello, one message, and a front-loaded ask with its context.
• Use threading, mentions, and urgency signals so a channel stays readable and only the right people get pinged.
• Write a help request that someone can act on, stating the goal, what you tried, the exact error, and what you need.
• Decide when to stay in chat and when to move to a call or a document, and route to professional email and tone in writing for the neighboring skills.

Before we dive in

Here is a moment you have lived through. A teammate’s name lights up the channel. The message says, in full: “hey, you there?” You are mid-task, so you finish your thought, then reply “yep, what’s up?” Three minutes pass. Then: “got a quick question about the deploy.” Another pause. Then, finally, the actual question. What could have been one message you answered in ten seconds has become a five-minute back-and-forth that pulled you out of focus twice and told you nothing until the end.

Nothing here was rude. The other person was being polite by their own lights, opening with a greeting the way you would before knocking on someone’s door. The trouble is that chat is not a door. It is closer to leaving a note on someone’s desk that also taps them on the shoulder. The greeting taps the shoulder, then makes them wait for the note. Multiply that across a busy channel and a busy team, and a medium that was supposed to be fast becomes a slow drip of interruptions.

So the problem this page solves is not “how do I type a message.” You can do that. The problem is that chat has its own physics, different from speech and different from email, and the polite habits you carry in from those other media misfire here. In speech, a greeting buys a moment while the other person turns to face you; in chat, it only delays the point. In email, length and formality signal care; in chat, they signal that you have misjudged the channel. Once you can see chat as its own medium, with its own etiquette built around the reader’s attention, the right habits stop feeling like rules and start feeling obvious.

No hello: put the question in the first message

Start with the single habit that fixes the scene above. The rule has a name in chat-heavy workplaces: “no hello.” It does not mean “be cold” or “skip the pleasantries forever.” It means do not send a bare greeting, or a bare “got a sec?”, and then wait for a reply before saying what you actually want. Put the question, and enough context to answer it, into the very first message.

The reason is the asynchronous nature of chat. When you say “hi” and stop, you have started a conversation the other person cannot continue, because you have not told them what it is about. They have to interrupt their work to type “hi, what’s up?”, and only then can you begin. You have spent one of their interruptions on nothing. If instead your first message is “Hi, quick one: does the staging deploy need the migration to run first, or does the pipeline handle it?”, they can answer the moment they get to it, in one turn, on their own schedule. The greeting is still there if you want it; what changed is that the answer is now possible immediately.

One message, not a stream of pings

The next habit is about how many messages you send, not what they say. Many writers compose in chat the way they think out loud: a line, then another line, then a correction, then the real point, each sent as its own message. To you it feels like natural conversation. To the reader, each of those messages can be a separate notification, a separate badge, a separate buzz on a phone. You have pinged them four times to deliver one thought.

The fix is to write the whole thought, then send it once. Use shift-and-enter, or whatever your tool’s “new line without sending” is, to build a complete message with its line breaks inside, and press send only when it says what you mean. This is the opposite of the spoken habit, where breaking a thought into beats is friendly and natural. In chat, the beats become interruptions, and a stream of fragments is harder to read back later than one structured message, because the eye has to stitch the pieces together.

Read the right-hand column as a single style. Every better version does the same thing: it puts the reader in a position to act in one pass, without a second message and without guessing. That is the through-line for the rest of this page.

Front-load the context and the ask

A message can be a single send and still be hard to answer, if it makes the reader assemble the picture themselves. In your head, a question sits on top of a whole stack of context: which project, which environment, what you were doing, what went wrong. The reader has none of that stack. They see only the words on the screen, with no thread of your thinking behind them. So you have to hand them the stack, briefly, before or alongside the ask.

Front-loading means leading with what the reader needs to make sense of the question, then the question itself, in that order. Compare two openings. The buried version: “I have been trying a few things and it is still not working, do you know what could be wrong?” The reader knows nothing: what is “it,” what did you try, what is “wrong.” The front-loaded version: “On the payments service in staging, checkout returns a 500 after my change to the tax module. I tried reverting the config and it still fails. Any idea what I am missing?” Same length, but now the reader can think about the actual problem instead of first interviewing you to find out what it is.

Threading: keep a topic in one place

So far the habits keep a single message clean. Threading keeps the whole channel clean. A thread is a side-conversation attached to one message, so replies about that topic stack underneath it instead of flowing into the main channel. Without threads, two or three conversations happening at once interleave line by line in the main channel, and reading it back is like overhearing three phone calls in one room.

The rule of thumb is simple: if you are replying about an existing message, reply in its thread; if you are starting a genuinely new topic, post in the channel. The diagram below shows the difference between a channel where everyone threads and one where nobody does.

The diagram makes the cost visible. The top path keeps each topic self-contained, so someone scanning the channel later reads one tidy thread per subject. The bottom path is what a busy channel becomes without threading: every topic shredded across every other, so nobody can follow any of them. Threading is not bureaucracy; it is the difference between a readable channel and an unreadable one.

Mentions, urgency, and the cost of a ping

A clean message in a clean channel can still go wrong at the last step: who you notify, and how loudly. Both of these spend other people’s attention, and both are easy to overspend.

At-mention etiquette

An at-mention pings a specific person, lighting up their notifications no matter what they are doing. That is exactly what you want when you genuinely need that one person and no one else. It is exactly what you do not want when you mention five people “to be safe,” because four of them now have to stop, read, and work out that the message was not really for them. Mention the person who needs to act, and leave everyone else to read the channel at their own pace.

The blunt instruments are the channel-wide pings, the ones that notify everyone in a channel at once. Reserve them for messages that genuinely concern everyone right now: the deploy is frozen, the office is closing early, the incident is resolved. Using a channel-wide ping for an ordinary question, or for something only a few people care about, interrupts dozens of people to reach two, and it trains the team to start ignoring those pings, which is worse, because then they fail when you actually need them.

Signaling urgency versus FYI

The other half of notifying well is telling the reader how to weigh the message. The same words can mean “drop everything” or “no action needed, just so you know,” and the reader cannot tell which unless you say. An ambiguous message defaults, by negativity bias and missing voice, to a stressful reading: people often assume the worse case, that you need them now, and interrupt themselves to check.

So state the weight explicitly. If something is blocking you, say so and say by when: “Blocking the release, I need a yes or no on this in the next hour.” If it is information with no action attached, mark it: “FYI, no action needed, the staging database is on the new host now.” The reader then knows instantly whether to switch tasks or keep going, which is precisely the judgment you stripped from them by leaving urgency implicit. The one-word labels do real work here: a leading “Urgent,” “Blocking,” “FYI,” or “No rush” front-loads the weight before the reader has even parsed the content.

Emoji, reactions, and the curtness problem

Chat has a tool email mostly lacks: the reaction, a small emoji you attach to a message instead of replying to it. A thumbs-up on a request is a complete, valid answer. It says “I saw this, I am on it” or “agreed, go ahead” without adding another message to the channel. Used well, reactions are the cheapest acknowledgment there is: they close the loop, so the sender knows they were heard, without pinging anyone or cluttering the thread. When someone posts “deploying now,” a single thumbs-up from the people who need to know is the whole conversation.

Emoji also do tone work, and that matters more in chat than almost anywhere, because chat messages are short, and short text reads as curt by default. A bare “ok” or “no” lands colder on a screen than it ever would in your voice, since the reader has none of your warmth to go on. A small emoji, a thumbs-up, a smile, a wave, puts some of that warmth back, which is why “sounds good” with a friendly emoji reads as genuinely pleased while “sounds good” alone can read as merely tolerating the idea. The full mechanics of why short text turns cold, and how to fix it, are in tone in writing; the chat-specific point is only that the medium’s brevity makes the problem sharper, and emoji and reactions are the fast, native fix.

Asking for help so someone can actually help

Now the highest-value habit on the page, because it is where chat saves or wastes the most time: asking for help well. The unhelpful request is familiar. “Hey, the deploy isn’t working, can you help?” The helper cannot do anything with this. They have to ask which deploy, what “not working” looks like, what you already tried, and what you actually want from them. Four questions and several minutes later, they have the picture you could have handed them at the start.

A good help request front-loads everything the helper needs, in a predictable shape: the goal you are after, what you already tried, the exact error or behavior, and the specific thing you need from them. State the goal so they know where you are headed. State what you tried so they do not suggest the thing you already ruled out. Paste the exact error, not your paraphrase of it, because the precise wording is often the whole clue. And name what you need, an answer, a review, a pointer, so they know what “done” looks like. The contrast below shows the same problem asked both ways.

Notice that the good version is not longer because it is padding; it is longer because it front-loads the four things the helper would otherwise have to drag out of you one question at a time. You spend thirty extra seconds writing it so that five people do not spend five minutes each decoding it. That trade, your time against the team’s attention, is the economics underneath every habit on this page.

Code blocks, not walls of pasted text

One small formatting habit saves a surprising amount of pain. When you share code, a log, an error trace, or any text where the exact characters and layout matter, put it in a code block, the chat tool’s monospaced, fenced format, rather than pasting it as ordinary message text. Pasted raw, code loses its indentation, the chat tool may “helpfully” turn straight quotes into curly ones or auto-link fragments, and a long trace floods the channel as a wall of unwrapped lines. In a code block, the formatting survives, the reader can copy it cleanly, and a long block can be collapsed instead of dominating the channel.

The principle generalizes: match the format to the content. Prose goes in a normal message; code and logs go in a code block; a long document goes in a document, not the chat. Pasting a wall of anything into the main channel is the formatting version of the stream-of-fragments mistake, it dumps the work of parsing onto every reader instead of doing it once yourself.

Knowing when to leave chat

The last skill is knowing the medium’s limits, because the most expensive chat mistakes are not bad messages but using chat for the wrong job. Chat is built for quick, roughly synchronous, low-stakes exchange. It is poor at three things in particular: big decisions, long debate, and durable records.

A decision with real consequences, hashed out in a fast-scrolling channel, tends to come out muddled: positions get lost, half the people who should weigh in miss it, and a week later nobody can find what was actually decided or why. The signal that you have outgrown chat is usually felt before it is named: the thread is getting long, the same points are circling, two people are clearly talking past each other, or you are about to commit the team to something. At that point the move is to switch channels deliberately. For anything that needs real back-and-forth, propose a short call, where five minutes of talking replaces fifty messages. For anything that needs to be found and trusted later, a decision, a spec, a postmortem, write it in a document and link the document in chat. Use chat to start and to coordinate; use a call to resolve; use a document to record.

This places chat among its neighbors. Reach for chat when the exchange is quick, internal, and roughly live. Reach for professional email when the message is external, formal, or needs to stand as a record on its own. Reach for a call when the topic needs back-and-forth that chat would stretch into an afternoon. The skill is not loyalty to one channel but moving between them as the job changes, the same way the right tone signals change when you move between them.

Mental Model: chat is a shared room, not your outbox

The wrong model, the one that produces almost every mistake above, is that chat is a private channel between you and one other person, like a string of text messages. On that model, a greeting first is polite, thinking out loud across several messages is natural, pinging “to be safe” is thorough, and the format barely matters because it is just you two talking. Each of these is reasonable for a one-to-one text. None of them is reasonable for chat.

The better model is that a chat channel is a shared room full of working people, and almost everything you do in it touches more than the person you meant. Every message is a small claim on the room’s attention; every ping taps a specific shoulder; every untreaded reply is talking over whatever else is being said; every wall of pasted text is something everyone now has to scroll past. Once you see the room instead of the outbox, the etiquette stops being a list of rules to memorize and becomes one question you ask by reflex: what is the least I can spend of other people’s attention to get what I need? No hello, one message, front-loaded context, a thread, a precise mention, a clear urgency label, a code block, a move to a call when it is time, these are all just answers to that one question. Chat done well is not about being terse or being warm; it is about being cheap to read and easy to act on, in a room you share.

Common mistakes

The first mistake is “hi” and then silence: a bare greeting or “got a sec?” with the real question withheld until the reader replies. It feels polite and it costs an interruption for nothing. Front the question and its context in the first message, and let the reader answer in one pass.

The second is the wall of unthreaded fragments: one thought scattered across many sends, or a topic spilled into the main channel instead of a thread. Each fragment is a separate ping, and an unthreaded channel becomes unreadable as topics interleave. Compose the whole message before sending, and reply in threads.

The third is the contextless help request: “it doesn’t work, can you help?” with no goal, no attempt, no exact error, and no specific ask. The helper has to extract all of it before they can think. State the goal, what you tried, the exact error, and what you need.

The fourth is ambiguous urgency and needless pinging: a message that does not say whether it is blocking or just information, or an at-channel that interrupts everyone to reach a few. Label the weight (“Blocking” or “FYI”), and ping only the person who must act.

The fifth, and the most expensive, is using chat for a decision that needs a document or a debate that needs a call. Chat is poor at big decisions, long debate, and durable records. When the thread starts circling or the stakes rise, move to a call to resolve it and a document to keep it.

Mastery Questions