Decision Logs Beat Meeting Minutes

Meeting minutes are a corporate artifact almost nobody reads. They are produced because someone, at some point, decided they should be produced. They are filed somewhere. They are searched, occasionally, by a lawyer. They do not change what anyone does on Tuesday.

A decision log is a different artifact. It records, for each meeting, only the decisions — and for each decision, four things: what was decided, who decided it, what the decision was based on, and what would cause the team to revisit it. That's the entire format. It fits on one screen per meeting. People actually read it.

The difference between the two artifacts is the difference between an organization that learns from its decisions and one that keeps re-litigating them.

What goes in the entry

A good decision log entry has four fields. Keep them short.

Decision. One sentence. "We will not pursue the enterprise tier in 2026." Not the discussion that led there. The decision itself.

Owner. A person, not a team. Decisions made by committees are decisions nobody owns, which means decisions nobody can revisit, which means decisions nobody will admit were wrong.

Basis. Two or three sentences. The actual reasons. Not the rhetoric in the meeting — the load-bearing facts. "Pipeline data shows enterprise deals at 40% of revenue but 80% of CS load. Margins on enterprise are 22% vs 71% on mid-market. Mid-market sales cycle is 4x faster."

Trigger to revisit. This is the field nobody includes, and it's the most valuable one. Under what conditions would we change our mind? "If enterprise inbound exceeds 10 qualified leads per month for two consecutive quarters" is a useful trigger. "If circumstances change" is not.

Why minutes fail

Minutes try to capture the meeting. They are organized around the agenda. They include who attended, when the meeting started, what was discussed in what order. Most of this information is operationally useless. Worse, it dilutes the small amount of actually useful information — the decisions — to the point where finding them later requires reading the whole document.

A decision log inverts the structure. It is organized around the decisions, not the meetings. The meeting is just the timestamp.

The practical effect is that you can ask a decision log questions you cannot ask of a minutes archive. "What did we decide about pricing in Q3?" returns a list. "What decisions are we due to revisit this month?" returns a list. "Who has owned the most decisions this year, and which ones got reversed?" returns a list. None of these queries are tractable against minutes.

How to start one

Don't try to retrofit. Start from the next meeting. After each meeting, spend ten minutes writing the entries for that meeting only. If no decisions were made, write that. (A meeting that produced no decisions is itself a useful piece of information; six in a row is a flag that something is wrong with the meeting cadence.)

Keep it in one place that's searchable. A single Notion page, a single Google doc, a single Linear project, a single channel — pick one and don't fragment. The whole point is queryability across decisions, and that breaks if half of them are in a different system.

Make the owner write the entry, not the meeting organizer. The person who has to live with the decision is the person whose framing of it should be on the record.

The hardest part

Writing the basis field honestly. Most decisions in most companies are made on a mix of evidence and instinct, with the instinct doing more work than people want to admit. A decision log entry that says "based on our judgment that the enterprise market is too crowded" is more useful than one that pretends to a level of analytical rigor the decision didn't actually have. The honest version is the one you can revisit in eighteen months without embarrassment.

The decision log doesn't replace the meeting. It just produces, from the meeting, the part that mattered. If it turns out, after a few weeks of keeping one, that most of your meetings produce no decisions worth logging, that is not a problem with the log. That is the log doing its job.