The short version
- On a team of twelve, the channel usually functions as a support desk with one unpaid operator.
- Four steps, in order: publish a response time, move questions out of direct messages, name owners per area, then point the support desk at a record.
- Notification settings are a personal defence against a team-level expectation. Change the expectation or the settings will not hold.
- The last step is the one that matters. Until asking a record is faster than asking a person, the person keeps getting asked.
A twelve-person team generates enough traffic to be genuinely noisy and not enough to justify a dedicated support rota. The result is a channel that functions like a help desk, staffed by whoever answers fastest, with no ticket queue, no hours, and no relief.
"The channel is a support desk for the senior engineer."
The channel as a support desk
The dynamic forms without anyone designing it. One person knows most things and replies quickly. People learn that and address their questions there, sometimes explicitly and sometimes by posting in the channel where that person will see it. Within a quarter the channel has a de facto operator.
What makes it worse than a real support desk is the absence of every structure a real one has. No queue, so everything is immediate. No hours, so it runs as long as they are online. No routing, so questions do not reach the person best placed to answer. And no acknowledgement, because helping a colleague does not appear in anyone's performance review.
Step one: publish a response time
One working day for channels and direct messages, stated in the recipient's own zone. This is the cheapest change and it is nearly always skipped, because teams assume everyone already knows. They do not: in the absence of a stated time, everyone calibrates on the fastest responder.
Then the senior people have to visibly use the full day sometimes. A promise nobody exercises is not believed, and one manager replying in ninety seconds at 22:00 undoes the announcement for everybody.
Step two: get questions out of direct messages
A question in a direct message is the most expensive form of the same question. It interrupts exactly one person, it cannot be answered by anyone else, and its answer is invisible to the next person who wonders the same thing.
The redirect is simple and it has to be done consistently for a month: answer in the channel rather than the direct message, with a light note. "Moving this here so Ana can see it too" costs nothing and teaches the norm faster than any policy. What does not work is asking people to stop sending direct messages, since the direct message felt safer and more polite to them, which is exactly why they chose it.
Step three: name owners per area
Much of the load on one person is a routing failure. People do not know who owns the deployment pipeline, so they ask the person who always knows. Publish a short list, one name per area, in the channel topic.
Expect this to feel unnecessary and to work well. Three or four lines of ownership redirect a surprising share of traffic, because most askers would rather not interrupt the busiest person and simply did not know there was an alternative. The related structure is in ownership clarity for distributed teams.
Step four: point the desk at the record
The first three steps redistribute and slow the traffic. They do not remove it, and the remaining volume is mostly retrieval: where something stands, what was decided, whether a thing was tried. Those questions have answers, they are just only reachable through a person.
So point the support desk at a record that can answer. With StandIn, each person confirms a ninety-second brief at the end of their day, mostly pre-drafted from the work they already did. While they are off, their StandIn answers questions from that brief in their words, with a source under every answer, clearly labelled, and never guessing: when the answer is not there, it says so and names who to ask.
That is the step that changes the volume rather than its distribution, and it is last for a reason. The first three steps make the team's expectations coherent, which is what stops the fourth from being treated as a way to avoid colleagues. See how StandIn works.
Common Questions
How do we reduce Slack interruptions without people feeling ignored?
Publish a response time and keep it, so waiting is normal rather than a sign of being deprioritised. What makes people feel ignored is uncertainty about whether a reply is coming, not the wait itself.
Should we ban direct messages for work questions?
Discourage rather than ban, and do it by redirecting in public every time. Bans push the behaviour somewhere less visible. A consistent gentle redirect changes the habit within a month and costs nobody anything.
Do notification settings help?
They help the individual and they do not change the team. A person with notifications off is still expected to reply quickly, so they check anyway, and now they check without prompting. Fix the expectation first, then the settings become genuinely usable.
What about the person who likes being the one everyone asks?
That is common and worth taking seriously, since it is real status. Make the alternative genuinely better for them: they keep the expertise and lose the interruptions, and their name is still on every answer that comes from what they wrote.
When you're off, your StandIn is on.
It answers your teammates' questions from work you've already done, in your words, with a source under every answer.