Every chat workspace over two years old has the same archaeology. Channels named after projects that finished. Three channels for the same team, created at different moments by different people, all partly alive. A general channel nobody uses and a random channel everybody does. Somewhere in there, two channels whose names differ by a hyphen.
The usual response is a naming convention. Prefixes, a taxonomy, a document explaining it. This works for a quarter and then decays, because a naming convention describes what channels are called and not what they are for, and the actual problem is the second one.
Why team channels decay
Channels get created at moments of need by whoever felt the need. That is the correct behaviour and it is also why the structure drifts, because nobody creating a channel is thinking about the overall shape, and nobody owns the overall shape.
Three specific forces:
Projects end but channels do not. Nothing prompts closure, and archiving feels slightly rude, so finished work accumulates as live-looking channels indefinitely.
Reorganisations move people but not channels. After a restructure the channels reflect the previous structure. People join the new ones and keep half an eye on the old ones, and information splits.
Nobody knows where to post, so they post everywhere. The most costly outcome. When the structure is ambiguous, people cross-post to be safe, which raises volume, which makes the structure feel more ambiguous, which produces more cross-posting.
Organise around decisions, not departments
The most common structure mirrors the org chart: a channel per team, a channel per department. It is the obvious approach and it works less well than it should, because it maps onto how the organisation is arranged rather than onto how work actually flows.
Work flows across teams. So do most of the questions worth discussing. A department-shaped channel structure means every cross-cutting conversation has to pick a channel that half the relevant people are not in, or get cross-posted into three.
A better organising principle is to structure around what gets decided where. Each significant channel corresponds to a domain of decisions with a clear owner, which means anyone can answer the question "where does this belong?" by asking "whose call is this?", and that question usually has an answer.
This has a useful side effect. It makes gaps visible. If a conversation genuinely has no channel because no one owns that domain, you have found an unassigned area of authority, which is worth more to know about than the channel was.
The precondition is that decision authority has been made explicit. If nobody knows who decides what, this structure cannot be built, which is why mapping decision rights tends to be the actual unlock rather than a naming convention.
A workable structure
Four types, and a rule that every channel is exactly one of them.
Domain channels. One per area of decision-making, named for the domain and not the team. Long-lived, with a named owner. This is where most substantive discussion happens.
Working channels. Time-boxed, created for a specific piece of work with an expected end. Named with the thing and, crucially, a closing condition agreed at creation. When the work ends, the channel is archived, and the decisions it produced have already been recorded elsewhere so nothing is lost by closing it.
Team channels. One per team, for coordination rather than decisions. Deliberately narrow: who is out, what is happening this week, internal logistics. Keeping decisions out of these is what stops team channels becoming the place where cross-team commitments get made invisibly.
Social channels. As many as people want, with no expectations attached. These are not a problem and organisations that try to rationalise them are solving the wrong thing.
The one rule that does most of the work. Every channel has a named owner and a one-line purpose in its description, written as what belongs there rather than what it is about. "Decisions and discussion about pricing and packaging" is a purpose. "Pricing" is a label. The difference determines whether anyone can tell where to post.
How many is too many?
There is no correct number, but there is a diagnostic.
Ask five people, separately, where they would post a specific realistic question. If you get five different answers, the structure has failed regardless of how many channels there are. If you get the same answer, the structure is fine even if it looks sprawling.
The instinct to reduce channel count is usually misplaced. Twenty well-purposed channels beat eight ambiguous ones, because the cost people actually experience is not the number of channels but the moment of hesitation before posting. Ambiguity is the tax, not volume.
Symptom | Actual cause | What to change |
|---|---|---|
Cross-posting to three channels | Ambiguous purposes | Write purposes as what belongs there |
Nobody replies in a channel | No owner | Assign one, or archive |
Decisions made in the wrong place | Team channels used for cross-team calls | Move decisions to domain channels or out of chat |
New joiners overwhelmed | No default set | Define a joining set of five to eight |
Channels for finished projects | No closing condition at creation | Agree one when the channel is created |
Cleaning up your team channels, once
If your team channels are already a mess, this takes an afternoon and it is worth booking.
List every channel with its last message date and its member count. Anything silent for ninety days gets archived, not deleted, and archiving is reversible so this needs no debate.
For everything remaining, assign an owner and write the one-line purpose. Any channel where nobody will take ownership is a channel to archive; the absence of an owner is the answer.
Where two channels overlap, merge them and redirect. Where a channel has become the venue for decisions that belong to a different domain, that is a decision rights question rather than a channel question, and worth resolving properly.
Then define the joining set: the five to eight team channels a new person is added to on day one. Most workspaces have never defined this, which is why new joiners either join everything or nothing.
What this does not fix
A good team channels structure improves findability of conversation. It does not make conversation a durable record, and no arrangement of channels ever will.
The decisions made in your well-organised domain channels will still be as hard to retrieve in eighteen months as decisions made in a badly organised one, because the retrieval problem is a property of chat rather than of channel design. Better team channels reduce the noise you have to search through. They do not give a decision a completion state, attach its reasoning, or record who was entitled to make it.
That is a separate problem with a separate answer, which we have covered in how to stop decisions getting lost in chat.
Autono's Chat organises conversation by thread and channel and keeps it end-to-end encrypted, then links each thread to the decisions, tasks and documents it produced. It sits alongside a decision log rather than substituting for one, so conversation can stay fast and informal while the conclusions end up somewhere they can be found. For organisations distributing authority across teams, that separation is what keeps both halves working.
If your channels are tidy and your decisions still evaporate, we would like to show you the other half. Get started with Autono.
Also in this series: how to stop decisions getting lost in chat, and encrypted Slack alternatives for teams if you are evaluating a move for security reasons.
