Back to blog
Decision records

The Decisions That Never Make It Into Confluence

Last updated: 3 min read
Decision records

Your team writes plenty down. Specs, meeting notes, the doc after a big call. But the question still comes back weeks later: "why did we do it this way?" The answer was real. It just never landed anywhere you can find it.

Confluence, or whatever your wiki is, holds the decisions someone remembered to write up. It misses the ones that happened too fast, too quietly, or too much by default. Here are six kinds that almost always slip through.

1. The direct message call

Two people are stuck, so they hop into a DM. One says "let's just go with the second option for now," the other says "works for me," and the thread scrolls away. That was a real decision. It shaped the code. But it lives in a private message no one else can see, and search will never surface it.

2. The choice made in the meeting, not in the notes

The meeting notes capture the agenda and the action items. They rarely capture the moment someone said "okay, we are not doing the queue, we will poll for now." The reasoning happened out loud, got nods, and moved on. The notes list what to do next, not what was ruled out and why.

3. The option you tried and dropped

Someone spent two days on an approach, hit a wall, and backed it out. That failure is worth more than most of what gets documented, because the next person will consider the exact same idea. But dead ends almost never get written up. The knowledge that "we already tried that, here is what broke" leaves with the person who tried it.

4. The default nobody chose on purpose

Some decisions get made by not deciding. You kept the library the last project used. You matched the pattern already in the file. No one argued for it, so no one wrote it down. Later it looks deliberate, and someone spends an afternoon guessing at a reason that was never there.

5. The temporary fix that stayed

"Let's hardcode it for the demo and clean it up next sprint." Everyone agreed it was temporary, so it did not feel worth a doc. Then it shipped, and the demo hack became load-bearing. Six months on, no one remembers it was supposed to be temporary, and no one remembers what the real fix was meant to be.

6. The verbal sign-off

A lead says "yeah, ship it" in a standup or a hallway. That approval is the reason the change went out. But it was spoken, not typed, so if anyone later asks who signed off, the honest answer is a shrug and a name.

Why these are the expensive ones

The decisions that make it into the wiki tend to be the big, formal ones that were already going to be remembered. The six above are the small, fast ones, and small fast decisions are most of the work. They set defaults, they close off options, they assign responsibility. When they vanish, the cost is not one lost fact. It is the same question asked again and again, each time to a person who has to stop and reconstruct a call they made months ago.

You cannot fix this by writing more docs. Nobody is going to open Confluence to record a two-line DM. The record has to form from the work as it happens, and it has to be answerable, so a teammate can ask "why did we go with polling?" and get what was decided, who decided it, and when, without pinging the one person who knows.

That is the gap StandIn is built for. You write one short brief at the end of your day, in your own words, and while you are off it answers your teammates from what you wrote, with a source under each answer. When the reason was never captured, it says so instead of inventing one. It will not catch a decision you never mention, but it makes the ones you do mention findable, which is where most of these six quietly go missing.

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.

You might also like