5 exercises — know when to reply in a thread, when to post in the main channel, when to DM, and how to keep async communication discoverable by your whole team.
The core decision framework
Thread: replies to an existing topic, operational updates during an incident, sub-discussions, debate under a decision post
Main channel: new topics, important decisions/resolutions that everyone needs to see, incident alerts, announcements
DM: personal/sensitive messages, messages only relevant to one person, minor corrections
Rule of thumb: if the answer benefits more than one person → channel; if it's only for one person → DM
0 / 5 completed
1 / 5
A developer posts in #engineering (40 members): "Hey, anyone know if we support HTTP/2 server push? Quick question."
Two colleagues reply. A third wants to answer. What should the third colleague do?
Reply in the thread. When a message already has replies, continuing in that thread is the correct Slack/Teams etiquette:
① Context stays together — all responses are nested under the original question; anyone who searches later finds the full conversation in one place ② Channel noise is reduced — 40 people in #engineering won't be notified for every follow-up reply; only those who have joined the thread get pinged ③ Scannable channel history — the main channel shows the original question + a "3 replies" indicator; anyone interested can join the thread; others can skip it
When to post in the main channel instead of a thread: If your message is a NEW topic, or if you want to deliberately re-surface something for everyone's attention (e.g., "thread resolved — the answer is: YES, we do support HTTP/2 push, see architecture doc [link]").
Sending a DM: only appropriate if the question is sensitive or only relevant to that one person. Creating a new channel: only for ongoing, recurring topics — not for one-off questions.
2 / 5
It's 14:03. A P1 incident is in progress. The on-call engineer posts in #incidents: "🚨 P1 — payments API returning 502. Investigating."
Where should live incident updates go?
A mix: thread for continuous updates, main channel for major breakthroughs. This is the standard SRE/DevOps incident communication pattern:
Thread (under the original alert): • "14:07 — checking nginx logs on prod-west-1" • "14:09 — metrics spike at 14:01, correlates with deploy #4412" • "14:12 — rolling back deploy #4412 now" These are operational updates for the incident team — they don't need to interrupt the whole #incidents audience.
Main channel (new top-level post): • "✅ 14:18 — P1 resolved. Root cause: bad config in deploy #4412, rolled back. Full post-mortem to follow." This gets maximum visibility — everyone following #incidents should see the resolution.
Why not all in thread? Resolution announcements buried in a thread risk being missed by stakeholders who are watching but not scrolling into the thread. Why not all in main channel? 15 status updates in #incidents each generating notifications for 60 people would cause significant notification fatigue.
3 / 5
A product manager posts in #team-alpha: "Quick decision needed: should we delay the v3.2 release by one week to include the search feature, or ship on schedule without it? Please share your thoughts 🙏"
Six engineers respond with opinions, creating a long discussion. What is the best practice here?
All replies in the thread — this is the right approach for a discussion that started in a specific message and is expected to generate multiple responses.
Why thread works well here: ① Decision traceability — the full thread (original question + all responses) becomes the record of how the decision was made. Future team members can find it by searching for "v3.2 release" ② Channel stays scannable — not everyone in #team-alpha needs to follow this decision; they can see "14 replies" and join only if relevant ③ Threading signals closure — once the PM posts the final decision in the thread, everyone who participated is notified; those who didn't join won't be disrupted
When does a decision discussion need a top-level channel post? When the outcome is important for everyone, the PM should summarise the decision as a NEW top-level message: "✅ Decision: we'll delay v3.2 by one week. Thread has the reasoning. New ship date: [date]." This ensures even those who didn't follow the thread see the outcome.
4 / 5
A developer is about to send a Slack message. They can't decide between posting in a channel or sending a DM. Which scenario is most appropriate for a direct message (DM) rather than a channel?
The typo heads-up is the right DM scenario. DMs are appropriate when:
① The message is only relevant to one person — a typo fix note for the PR author doesn't need to be seen by all of #backend ② The message is minor / could be embarrassing if public — pointing out a small error can feel awkward; a DM is a kindness ③ It's personal feedback — performance feedback, sensitive observations, or anything you'd say privately in person
Why channel is better for the other three: • "Staging CI failing" — technical debugging benefits from multiple eyes; someone in the channel may know immediately. Channel → thread • "Deploy at 17:00. All good?" — this is a team-status check; relevant to everyone in #devops; belongs in channel • "Who owns the auth service?" — a routing question; asking in channel gets the fastest answer and may be useful for others who had the same question
The DM vs channel rule of thumb: If the answer would benefit more than one person → channel. If the message is personal/sensitive/only for one person → DM.
5 / 5
Your team uses Slack. A colleague has been sending long technical design explanations as direct messages to team members one at a time. Other team members are unaware of these discussions and duplicating work. What is the correct feedback?
Design discussions belong in a channel or thread — not DMs. This is one of the most common async communication mistakes in distributed teams, with real organisational costs:
Problems with DM-based design discussions: ① Knowledge siloing — information lives only between two people; the rest of the team can't benefit, challenge, or build on it ② Duplicated effort — as described in the scenario, team members reinvent decisions that were already made in a DM conversation they didn't know about ③ No searchable record — a DM thread between two people about a design decision is invisible to anyone hired in 6 months; a channel thread is searchable forever ④ Reduced team trust — teams that primarily use DMs can feel fragmented; channel-first communication builds shared context
Best practice: • Start design discussions in a relevant channel (e.g., #architecture, #team-alpha) • Use threads to keep sub-discussions tidy • Share decisions as top-level messages with a brief summary • Post a TL;DR if the thread becomes long: "TL;DR: we're going with approach B. Reasoning in the thread above."