How to keep a decision log your team will actually use

What a decision log is

A decision log is a single, running record of the decisions a team makes. Each entry says what was decided, when, who owns it, why, and which options were turned down. It's not meeting minutes and it's not a task list. It answers one question months later: "Why do we do it this way?"

Here's a template you can copy today. Then we'll go through where it comes from and how to keep it alive.

A decision log template

One entry per decision. Keep each entry short enough to read in a minute.

• Decision: one sentence, in the active voice. "We will move the weekly release from Friday to Tuesday."
• Date: the day it was decided.
• Owner: the one person accountable for carrying it out and for keeping the entry up to date.
• Context: what prompted it, in two or three sentences.
• Reasons: why this option won.
• Options rejected: what else was considered, and why each was turned down.
• Status: proposed, accepted, or superseded (with a link to the entry that replaced it).
• Link: the meeting note, thread or document where it was discussed.

A filled-in example:

• Decision: We will ask every new customer for a 20-minute onboarding call in their first week.
• Date: 14 October. Owner: Priya.
• Context: Three customers in September asked support the same setup questions.
• Reasons: A short call answers the common questions once, and gives us direct feedback.
• Options rejected: A help-centre article (we already have one and it isn't being read). A recorded video (no chance to ask questions).
• Status: Accepted.
• Link: Product sync, 14 October.

The names and details are illustrations. The structure is the part to keep.

Where the template comes from

Two traditions shaped it. The first is formal minute-taking. The University of Manchester's guidance on committee minutes says they should record formal decisions, "document the reasons for the decision and include sufficient background information for future reference", and indicate responsibility for actions (University of Manchester). That's where the reasons, context and owner fields come from.

The second is the architecture decision record, or ADR, from software teams. In a 2011 post, Michael Nygard proposed short records with a title, context, decision, status and consequences, each one or two pages long. His reason is the problem every team recognises: "One of the hardest things to track during the life of a project is the motivation behind certain decisions." Without it, a newcomer either accepts a decision blindly or reverses it blindly (Nygard, 2011).

AWS's guidance on ADRs adds two ideas that work outside software too. A collection of decision records creates a decision log, and once a record is accepted it doesn't get edited. If the team changes its mind, it writes a new record that supersedes the old one. When a proposal is rejected, the owner adds the reason, to prevent future discussions on the same topic (AWS Prescriptive Guidance).

What counts as a decision worth logging

If you log everything, nobody reads it. If you log nothing, you're back to guessing. A useful test: log a decision if someone could reasonably ask "why did we do that?" in three months. That usually includes:

• Choices between real alternatives, such as pricing models, tools or suppliers.
• Anything that's expensive or slow to reverse.
• Decisions that affect another team or a customer.
• Decisions not to do something. These are the easiest to forget and the most often reopened.

Day-to-day calls, like who takes notes this week, don't need an entry.

Where to keep it

Keep it in one place the whole team can open, and in a format that's easy to search. A shared document or a single page in your notes tool works for a small team. A spreadsheet works if you want to sort by date or owner. The format matters less than these three rules:

1. 1One log per team, not one per meeting. Decisions scattered across meeting notes are hard to find.
2. 2Newest entries at the top, so the current state is visible first.
3. 3Link both ways: the log entry links to the meeting note, and the meeting note links to the log entry.

Habits that keep it current

Most decision logs die from neglect, not bad design. A few habits keep yours alive:

• Close every meeting by asking "what did we decide?" and writing the entries before you leave the call.
• Make the person who proposed the decision its owner, and make them responsible for the entry.
• Read the last few entries at the start of planning meetings. It takes two minutes and stops old debates from restarting.
• When someone asks "why do we do it this way?", answer with a link to the entry. If there isn't one, write it.
• Review the log once a quarter and mark anything that no longer applies as superseded.

For the meeting note that feeds the log, see how to find what was said in a meeting or customer call, which includes a short template for decisions and actions.

Finding old decisions later

Even a tidy log gets long. Consistent wording helps: use the same names for products, customers and teams in every entry, so a search finds them all. Start each decision with "We will" or "We won't", as Nygard suggests for the decision itself, so entries are easy to scan.

If your team keeps meeting notes in Lumyo, you can choose the notes for a project and ask "what did we decide about onboarding calls, and why?" The answer cites the notes it used, and tapping a source opens the exact line. If the notes don't cover it, it says so, which is often a sign the decision was never written down.