Too many channels, and the message nobody saw
Every distributed team eventually has a communication problem that is really a routing problem.
The symptom is familiar: important things are missed, people feel both overwhelmed by messages and under-informed, and the response is to send more messages to more places. For broader context on distributed asynchronous work, GitLab’s all-remote handbook is a useful reference.
Almost always the cause is that there is no rule about where things go, so everything goes everywhere and nothing is reliably anywhere.
Assign each channel one job
The rule that resolves most of it is that each medium has a single stated purpose and a matching expectation. For a practical software-side reference on task switching across communication channels, task switching cost adds useful detail.
- Chat: transient coordination. Assume nothing here is permanent or read by everyone.
- Documents: anything that should still be true next month.
- Issue or task tracker: work that has a state and an owner.
- Email or announcements: the small number of things everyone must see.
- Calls: opening problems, disagreement, difficult conversations.
The productive discipline is the promotion rule: anything in chat that turns out to matter gets moved into a document or a ticket, and the chat message becomes a link to it.
Anything that needs to survive the week has to leave chat. Teams that treat chat as memory rediscover the same decisions every few months.
Fewer channels, more specific
Channel sprawl is the usual state: one per project, per client, per topic, per ad-hoc concern, all half-alive. The result is that nobody can follow everything, so people follow nothing reliably.
Periodically archive aggressively. A channel with no activity for a month is not a channel; it is a place messages go to be missed. Consolidation is uncomfortable and it is what makes the remainder readable.
Mentions are the routing mechanism
In a large channel, a message addressed to nobody is addressed to nobody. Naming the person who needs to act is not impolite; it is how the message arrives.
The converse matters as much: broadcast mentions to everyone should be rare and should carry a real reason, because a channel where the all-mention is used casually is one where notifications get switched off entirely.
Do not require people to read everything
Some teams treat comprehensive reading as a virtue. In a distributed team of any size it is impossible, and pretending otherwise means important messages compete with everything else on equal terms.
The alternative is an explicit small set of things everyone is expected to read, distributed through a channel used only for that. It works precisely because it is rare.
Write a page about where things go
One page, listing each channel, what it is for, and what response to expect. It takes twenty minutes and it is the artefact that makes onboarding a distributed team possible.
Without it, every new joiner spends their first month learning the routing by getting it wrong, and the conventions drift a little further with each person who guesses.