Three weeks ago, your team made a good decision. Someone proposed using a queue instead of a cron job for the retry logic. Two people pushed back. A third explained why the queue was right. Everyone agreed. The work shipped.
Today a new engineer asks why the retries go through a queue. Nobody can quite remember the reasoning. The person who explained it is on vacation. The thread is somewhere in a channel that has had four thousand messages since. So the team relitigates a decision they already made, well, the first time.
This is the decision graveyard. It is where good engineering reasoning goes to die, usually inside Slack.
Why Slack eats decisions
Slack is built for conversation, not memory. That is not a flaw; it is the point. The cost is that anything important said in Slack has roughly the shelf life of the messages that follow it. A decision made on Tuesday is functionally gone by Friday, buried under standups, deploy notices, and lunch plans.
Search does not save you, because you have to remember the right words, the right channel, and roughly when it happened. By the time you have reconstructed that, you could have just made the decision again. Which is exactly what teams do.
What a lost decision actually costs
A decision that disappears does not cost you the five minutes it takes to find it. It costs you in three quieter ways:
- Relitigation. The same debate runs twice, sometimes three times. Each round burns senior-engineer attention on a question that was already answered.
- Reversal by accident. Someone who never saw the original reasoning undoes it, reintroduces the failure mode it was meant to prevent, and nobody notices until production does.
- Onboarding tax. Every new hire hits the same wall of undocumented "why," and the only way through is to interrupt someone who remembers.
None of these show up on a dashboard. They show up as a team that feels slower than its headcount should allow, and nobody can point to why.
The fix is not "write more docs"
The usual answer is a decision log: a doc where someone is supposed to write down every decision. It fails for the same reason every manual-capture process fails. The moment a decision is made is the moment everyone is most eager to move on, and least willing to stop and write a wiki entry. The log is empty within a month.
The decisions are already being made in writing, in the conversation itself. The problem is not that they are not written down. It is that they are not captured and kept. The reasoning exists; it just is not findable six months later.
What changes when decisions stick
When the decision and the discussion that produced it are saved together and stay searchable, the new engineer asking about the retry queue gets the answer and the reasoning in one place, without interrupting anyone. The debate does not run a second time. The reasoning survives the person who had it.
That is the whole game: keep the "why" attached to the "what," and make it findable when someone needs it, not just when it was fresh.
Malve watches your discussions for decisions and saves them automatically, linked to the conversation that produced them, so the reasoning is still there six months later when someone asks why.