An engineering decision posted in Slack on Tuesday is unfindable by Friday. By the next sprint, it might as well never have happened. The cause is structural — Slack is a stream, not a record — but the fix is also structural, and it takes about five minutes per decision.
Why decisions decay
Decisions decay because the place they were made does not retain them. They get scrolled past, archived, replied-to-in-thread, or simply forgotten. By the time someone asks "why did we choose X?" the answer requires forensic Slack archaeology.
The fix is not better memory. It's separating the place a decision is discussed from the place it is recorded.
The four-field decision template
Every decision worth keeping fits this template:
- Decision — what was decided, in one sentence. Imperative. "We will use Postgres for the new service."
- Why — the two or three reasons that mattered. Not a list of every consideration. The ones that tipped it.
- Rejected — what was considered and rejected, with one-line reasoning. This is the field everyone skips and everyone needs in six months.
- Authority — who decided, and who would need to be involved to reverse it.
Five minutes per decision. Faster than you'd think; slower than "+1 in Slack."
Where to store it
Anywhere with a stable URL and search. A decision log in your wiki. An ADR folder in the repo. A governance tool. The format matters less than the property that the document is still findable in six months by someone who wasn't in the original thread.
Avoid: Slack threads, ephemeral docs, personal notebooks, presentation slides. All of these will be unfindable.
Promote, don't duplicate
If the discussion happens in Slack, fine. After the decision is made, write the four fields somewhere durable and link back to the Slack thread for full context. The durable record is the source of truth; the thread is the appendix.
This is the workflow change that separates teams whose decisions survive from teams whose decisions decay.
Make Decisions Findable Next Week
StandIn stores decisions with rationale, authority, and scope — so the team queries the record instead of asking who decided.
See the Workflow →Write the Why so it survives the personnel change
The Why field has one job: make sense to an engineer who joined three months after the decision was made. "Because Maria preferred it" is not a Why; Maria might not be on the team in six months. "Because we needed transactional guarantees for the billing path" is a Why — it explains itself.
Make reversibility explicit
For each decision, note what would change it. "Reverse if performance benchmarks miss target by more than 30%." "Reverse if we move off AWS." Most engineering decisions are not forever; saying so out loud prevents the assumption that they are.
Common failure modes
Failure: writing the decision before the team has actually decided. Discussion logs are not decision logs. Wait until there is a decision; then write it.
Failure: hiding the dissent. If engineers disagreed and were overruled, say so in the record. "Three engineers preferred Y; we chose X because of the deployment constraint." Hidden dissent festers; recorded dissent is healthy.
Failure: writing decisions only for big architecture choices. The small decisions — naming conventions, error handling style, branch strategy — are the ones that get reversed accidentally. Record those too.
What to do tomorrow
Pick the last three decisions your team made in Slack. Write the four-field record for each. Put them somewhere durable. Notice how long it took — probably 15 minutes total. That's your baseline for the practice going forward.
Frequently asked questions
How many decisions per week is normal?
A team of 5-10 engineers usually makes 3-6 records-worth decisions per week. If you're recording 20, you're recording too much — most are just preferences. If you're recording zero, you're missing the actual decisions.
Should decisions require approval?
No. Decisions require explicit authority — one person, or a named group, who decided. Approval workflows slow decisions to a crawl. Authority lets you move fast and still know who to ask later.
What about decisions that didn't survive?
Update the record. "Reversed on 2026-06-12 because of latency issues — see new decision #47." Don't delete; supersede. The reversed decision is data for future similar choices.
Get async handoff insights in your inbox
One email per week. No spam. Unsubscribe anytime.
Ready to eliminate your daily standup?
Distributed teams use StandIn to start every shift with full context — no standup required. Engineers post a 60-second wrap. The next shift wakes up knowing exactly what to work on.