Somewhere in your company, a decision was made a few weeks ago that will shape a product for the next two years. Four people were involved. It happened in a Slack thread, underneath a reply to an automated build alert, in a channel created for a launch that has already shipped.
All four people would probably tell you the decision is documented. And technically, they would be right. The problem is that nobody else knows the decision happened. The person who will have to live with it may not even be in the channel. Six months from now, the same question will come up again. Someone will search Slack for forty minutes, give up, and the team will make the decision again. Probably a little differently.
Does it sound like fiction? I bet it doesn’t. I bet it sounds like something that just happened the other day.
I have been working at companies that use Slack to varying degrees for about six years now, and this is the part I have never managed to get comfortable with. I don’t think Slack is a bad product. In many ways it is an excellent one. I just don’t think it knows what kind of product it is.
And because Slack doesn’t know, neither do the people using it.
The Sender Has to Invent a Protocol
Slack is instant messaging. It is also email, a forum, a notice board, a notification feed, an automation platform, and increasingly, an intranet. Bots report failed builds there. Executives announce reorganizations there. People send each other jokes there. Product and engineering teams make decisions there that will still matter two years later.
On screen, all of those things look almost identical, and that creates a surprisingly basic problem every time you want to say something.
Suppose I need to tell three people something important. Do I send three direct messages? Start a group message? Put it in the team channel? The project channel? A company-wide channel?
If I use a channel, who is actually in it? More importantly, who is expected to read it? How do I make sure they read it?
Do I tag the people I care about? If I do, I have effectively turned a public message into a private request. If I don’t, am I allowed to assume they saw it?
And how should I write it? Two lines because this is chat? Four paragraphs because the subject needs context? Am I expecting an answer in ten minutes, by the end of the day, sometime this week, or not at all?
Slack supports all of those choices. What it doesn’t give you is much guidance on what any of them mean.
We tend to call that flexibility. In practice, each company invents its own rules, then each team invents a few more, and eventually every individual develops a private interpretation of how Slack works.
The Receiver Is Using a Different Product
Response time is the easiest place to see this.
For one person, sending a Slack message is the digital equivalent of walking over to your desk. They sent it because they want an answer fairly soon. For somebody else, Slack is asynchronous. They check it a couple of times a day and reply when they get to it. Neither person is using Slack incorrectly. That is exactly the problem.
The same thing happens in channels. Someone posts an announcement to two hundred people and considers the message delivered. Technically, it was. But was everybody expected to read that channel? Was there any signal that this message mattered? Or did it arrive between fifteen automated alerts, a support question, and a discussion about lunch?
Email has problems, plenty of them, but the basic contract is clear. You choose recipients. You write a subject. The message remains in an inbox until the recipient does something with it. WhatsApp is clearly conversational. A knowledge base is for information you expect people to find later. A ticket system is for work with an owner and a status.
Slack puts all of those behaviors into one interface and makes them look similar. A lot of the context that used to tell us how to treat a message disappears.
Slack Is Very Good at Producing Information
It is much less good at helping you find that information again.
Think about something important somebody sent you three days ago. Was it a direct message, a group message, or a channel? Which channel? The project one, the product one, the team one, or the temporary launch channel that nobody ever archived? Was the useful part in the original message or fourteen replies down a thread? Do you remember who wrote it? Better yet, do you remember one exact word from the message so search has something to work with?
The longer a company uses Slack, the stranger the channel list becomes. Some channels are active, some are dead, some have almost the same name, and some exist only because whoever created them did not know another channel already existed.
Just managing the list becomes work. Joining the right channels is work. Leaving the irrelevant ones is work, and if you later need that channel, good luck finding it. Figuring out which channels you are expected to follow is work. And because something important can appear almost anywhere, ignoring a channel always feels dangerous.
Threads help, but they also create another hiding place. A channel can look quiet while several important discussions continue under messages posted days ago. If you were not already following the thread, there is a decent chance you will never know the discussion happened.
This is the irony of Slack as company memory. It captures almost everything, which makes it very easy to believe the organization has a record. The hard part is knowing where any particular piece of that record lives, which is the same gap I keep running into when I write about why institutional memory is the missing layer in how teams work: capturing information turns out to be the easy half of the problem.
That wasn’t an accidental side effect. It was part of the original promise. Before Slack launched, Stewart Butterfield famously told his team to sell the outcome rather than the software. One of the outcomes he described was “zero effort knowledge management.”
Slack did make capturing knowledge almost effortless. Finding the right thing later is a different problem. At enough scale, solving the first problem can make the second one harder.
Some Friction Was Doing Useful Work
A huge part of Slack’s success came from removing friction, and most of that was good. You can ask a question in seconds, pull someone into a conversation, create a channel, share a file, add a bot, or start a call without ceremony. I don’t want to go back to the world before that.
But we have a habit in software of treating all friction as waste. It isn’t. Sometimes friction forces you to make a small decision before you communicate.
An email makes you choose recipients. A subject line makes you name the topic. Creating a document is a small statement that this information should survive. Opening a ticket means there is work here, with an owner and some kind of state. Booking a meeting means I believe these people need to be present at the same time.
Those little bits of structure are information too. They tell the receiver something before the first sentence is even read. Slack removed many of those decisions. That is part of why it feels so easy to use, but it also means the receiver has to reconstruct the missing context.
Huddles are a good example of the pattern. When communication inside Slack becomes awkward, the answer is often another way to communicate inside Slack. The product gets broader, but the meaning of the existing pieces does not necessarily get clearer.
It now costs almost nothing to send information, so naturally we send much more of it. That does not automatically mean we communicate more effectively.
Etiquette Is Not the Answer
The usual answer is that companies need better Slack discipline. Define naming rules. Archive dead channels. Decide when direct messages are appropriate. Agree on response times. Move important decisions to a system of record. Use @channel and @here sparingly.
All sensible advice. I have written versions of those rules myself.
But there is something odd about needing a governance framework around a communication product just to explain what each kind of communication means. A new employee doesn’t just have to learn Slack. They have to learn your company’s invisible version of Slack, including all the local conventions nobody bothered to write down because everybody who has been there for a while already knows them. And those conventions are different everywhere.
Good tools usually have an opinion about how they should be used. They make some behaviors natural and others a little awkward. That opinion can be limiting, but it also gives the tool meaning.
Slack mostly hands you the pieces and leaves the meaning to the organization.
The Strongest Argument Against Me
For a long time I assumed my problem with Slack was mostly personal. Maybe I am too structured. Maybe I just like email more than I should. After seeing the same problems in several very different companies, I stopped believing that explanation.
Still, there is a serious counterargument here. Tools with strong opinions become rigid. Email has a clear contract and still became a disaster in many companies. Highly structured systems create shadow processes next to them because real work refuses to fit the structure. One reason Slack survives so well inside messy organizations is that it doesn’t force people into a model that will be wrong three months later, and that is a fair point.
Modern work really is contradictory. It is urgent and asynchronous at the same time. Public and private. Temporary and permanent. Teams form, split, and disappear. Projects overlap. Decisions happen in the middle of conversations rather than at some clean checkpoint in a process.
Maybe Slack looks messy because the organizations using it are messy. If that is true, Slack is an excellent mirror. I am just not convinced a mirror is enough when everybody spends the entire day looking into it. Tools don’t only reflect behavior. Eventually they shape it.
Slack’s Current Answer Is AI
Slack clearly knows retrieval is a problem, and its current answer is AI. The pitch is that Slack is becoming a work operating system: search across messages, files, and connected systems, AI recaps, and a Slackbot that can use workspace context. Instead of remembering where a conversation happened, you should be able to ask what the team decided about a launch and get the answer.
I would love that version of Slack. It is not the one I use today.
Search is one of the things I find most frustrating about Slack. If I don’t already remember who said something, who they were talking to, roughly when it happened, where the conversation was, and at least one of the actual words they used, I often cannot find it. I know the information is somewhere in Slack. That does not mean I can get back to it.
Maybe AI will make that much better. I hope it does. But even then, it only fixes the first layer of the problem. It puts a smarter retrieval system on top of an information space that was never given much structure in the first place.
Suppose the model does find the conversation. It still has to infer whether the conversation produced a decision, whether that decision was final, and who owns the result now. If nobody marked those things when the discussion happened, the model is reconstructing intent from text. And text is often ambiguous. Four people thinking out loud can look almost identical to four people committing the company to an architectural direction, which is exactly the distinction a Judgment Log is built to preserve and a chat transcript is not.
This is also why I am skeptical that summaries solve the deeper problem. A recap can tell me what people talked about, but compression can make it harder to distinguish between a suggestion, a disagreement, a tentative conclusion, and a real commitment. Those distinctions are exactly what I care about later.
So yes, make search dramatically better. Please. But even perfect search only gets me from “I can’t find the conversation” to “I found the conversation.” It still does not tell me what that conversation meant.
One Question to Ask Before You Type
Before posting in Slack, ask one question: what do I need this message to do?
Most work messages need to be one of three things.
- Received. Specific people need to see it soon. Slack is good at this.
- Found. Someone needs to find it months from now. Put the durable version somewhere built for that.
- Resolved. A task, question, or decision needs an owner and a state. Track it somewhere built for that.
Slack can start all three, but it should not necessarily be where all three end.
The problem is not that we use Slack for everything. The problem is that we often do it without deciding which of these jobs the message is supposed to do.