Most decisions in a modern team are not made in meetings. They are made in a thread, on a Tuesday afternoon, when someone writes "fine, let's go with option B" and three people add a thumbs-up. Then the thread scrolls away.
A month later someone asks why the team went with option B. Nobody quite remembers. Someone searches for "option B" and finds forty results. The discussion starts again, and occasionally reaches a different answer for no better reason than that the original one was lost.
Why separate decision documents go stale
The usual fix is a decision document: a page in the wiki, a spreadsheet, a template. It works for a few weeks. Then it stops being updated, because updating it means leaving the place where the decision happened, opening another tool, and writing a summary of something everyone involved already knows.
The problem is not discipline. It is distance. A record that lives somewhere else from the conversation depends on someone remembering to copy it across. The fix is to keep the record where the talking happens, and make marking a decision take about as long as adding a reaction.
What a good decision record contains
A decision record does not need to be long. It needs to answer the questions someone will ask later.
- What was decided. One sentence. Specific enough that someone outside the conversation understands it.
- Who decided. The person who made the call, not everyone who was in the thread.
- When. The date matters more than people expect, especially once circumstances change.
- Link to the discussion. The reasoning, the objections, the options. This is the part a separate document usually loses.
- What was considered. Briefly, the alternatives and why they were not chosen. Often this is already in the linked thread, which is another reason to keep the record next to it.
Anything more than that tends to be skipped, and a record that is skipped is worse than a short one.
A lightweight team convention
Conventions work when they are small enough to remember. Here is one that fits most teams.
Who marks it. The person who made the decision, or whoever notices that a decision has just been made. It should not be a single designated scribe, because that person will be on holiday when it matters.
When. At the moment of the decision, not at the end of the week. If it is not marked within the day, it probably will not be.
How to name it. Start with a verb and the subject: "Use the EU region for all new customers", "Drop the Friday release". Avoid "Decision about pricing", which tells you nothing when scanned in a list.
What does not count. Small, reversible choices that affect nobody outside the thread. If nobody would ever ask "why did we…" about it, it does not need a record.
Open questions and resolved threads
Decisions have a quieter sibling: questions that were asked and never answered. They are just as easily lost, and more quietly harmful, because the person who asked often assumes someone is working on it.
Two habits help. First, when a thread reaches its conclusion, say so explicitly. Mark it resolved, or write "resolved" and the outcome as the last reply. Second, when a specific reply answers a question, point to it, so the next person reading does not have to work out which of twelve replies was the answer.
It also helps to keep a view of questions that are still open. Not as a task list, just as a way to notice that the question from last Wednesday is still sitting there.
Reviewing decisions
A decision log earns its keep when someone reads it. Two rhythms work well.
Weekly, in the team. Five minutes at the start of a regular meeting or in a written update: here are the decisions from this week. It catches misunderstandings early, and it tells people who missed the thread what changed.
Monthly or quarterly, with a wider group. Look at the decisions from the period. Are any worth revisiting now that more is known? Did any turn out to be decisions nobody actually followed? It is better to find that out on purpose than by accident.
Example decision entries
A decision log does not need to be elaborate. Here is what a few entries might look like in a product team's channel.
| Decision | Decided by | Date | Considered |
|---|---|---|---|
| Move the weekly release from Friday to Tuesday | Head of engineering | 2 September | Keeping Friday with a freeze; releasing daily |
| Use the EU region for all new customer data | CTO | 9 September | Customer choice of region at sign-up |
| Pause the referral programme until the new onboarding ships | Product lead | 16 September | Reducing the reward; running both in parallel |
| Answer support tickets in the customer's language where we can | Support lead | 23 September | English only; machine translation for all |
Each row links back to the thread where it was discussed. That link is what makes the log useful rather than decorative.
How Tandly helps
In Tandly, the decision log lives inside the chat.
- Any message can be marked as a decision. It uses the first line of the message as its title, or a custom title if you give one.
- Each channel has a decision log that lists its decisions, so the record sits in the same place as the discussion.
- Threads can be marked resolved, and a reply can be marked as the answer.
- Questions, meaning messages ending in "?", are tracked as open until they are answered.
- Decisions and open questions also appear in the "since you were away" catch-up, so people returning from time off see what was decided without reading every thread.
The decision log, resolved threads and open questions are available on every plan, Free included. On Business, channels can set a response-time target, and Tandly nudges when a question has gone unanswered for too long. The plan details are on the pricing page.
Because Tandly keeps full history on every plan, the log does not stop at the edge of a free tier. The case for that is in why your team chat should keep its full history. And if the aim is fewer threads that need chasing in the first place, a calmer team chat covers the habits that help.
Questions people ask
Won't people mark everything as a decision?
In practice the opposite is more common: people forget to mark anything. If the log does fill up with trivial entries, tighten the convention. A useful test is whether anyone outside the thread would ever ask why.
What if a decision is reversed later?
Mark the new decision, and mention the one it replaces in its first line. The old entry stays in the log. Seeing that a decision was reversed, and when, is often exactly the history someone needs.
Is this a replacement for formal decision records?
For most day-to-day decisions, yes. For decisions that need formal sign-off, a structured document may still be required. Even then, marking the decision in chat and linking to the document means people can find it from the conversation they remember.
Do open questions become a to-do list nobody asked for?
They should not. Open questions are there to be noticed, not managed. Most get answered in the normal course of things; the view simply makes the few that slipped through visible before someone has to ask again.