The decision log you don't have but desperately need

If you have been in a leadership role at an SME for more than two years, you have almost certainly run a decision log initiative. Maybe twice. The first time, you set up a Notion database with categories and owners and templates. Everyone agreed it was a great idea. The first week, six decisions got logged. The second week, three. By week six, the database had quietly stopped being updated. By month three, nobody remembered it existed.

The reason this happens, every time, is not laziness. It is structural. A decision log is the wrong shape for the thing it is trying to capture. Until you understand why, you will keep trying to set up new ones, and they will keep dying for the same reasons.

What a decision log promises

The promise is appealing: every meaningful decision the company makes is recorded, with the context, the reasoning, and the date. Future you can go back and see why something was decided. New hires can learn the company's decision history. Disagreements about "did we decide that?" become resolvable by looking at the log.

In principle, this is exactly what a company needs. In practice, the gap between principle and execution is enormous, and it is not closeable by adding more discipline.

Why decision logs fail, structurally

The first reason is the boundary problem. What counts as a "decision" worth logging? Big strategic ones, obviously. But almost all the decisions that compound over time are small. We will email the supplier rather than call. We will quote a discount of 8% rather than 10%. We will skip the security review this once. The threshold for "important enough to log" is impossible to define and even harder to apply consistently.

The second reason is the moment problem. Decisions are made in flow, often inside a longer conversation, often without a clear "we just decided" beat. By the time someone notices that a decision has been made, the meeting or the thread has moved on. Going back to log it requires interrupting the next thing.

The third reason is the latency problem. The value of a decision log accrues months and years after a decision is made. The cost of maintaining it is paid immediately. People are very bad at paying immediate costs for diffuse future benefits, especially when nothing breaks if they skip it today.

Stack these three reasons together and you have a structural guarantee that any decision log initiative will atrophy. It is not a discipline problem. It is a design problem.

The real cost of not having one

Companies without a decision log do not feel the absence directly. What they feel is symptoms.

They feel the symptom of re-litigating decisions. Six months after agreeing to use Stripe, the team debates switching to GoCardless and only halfway through realizes the same debate already happened. Nobody remembers the conclusion.

They feel the symptom of contradictory practice. One department is doing things one way because of a decision made two years ago. Another department is doing things differently because they never knew the decision was made. Both think they are aligned with company policy.

They feel the symptom of decisions silently changing. A standard that was set deliberately drifts because nobody remembers it was deliberate. Three years later, the standard is unrecognizable, and there is no way to know whether the drift was intentional or accidental.

These symptoms are real and ongoing. They are also so distributed that no one ever puts them on the same page as "we don't have a decision log" and sees the connection.

Why "just be more disciplined" cannot work

The instinctive response to any of these failure modes is to try harder. Get more buy-in. Use a better template. Assign an owner. Add a weekly review.

We have watched dozens of companies try variants of this. The success rate is, roughly, zero in the medium term. The initial enthusiasm carries the initiative for a few weeks and then it dies, for the structural reasons described above.

The brutal truth is that the discipline required to consistently log decisions exceeds any human team's actual discipline budget, especially in an SME where everyone is wearing multiple hats. The discipline is being asked to come out of the same pool that is also funding all the other "we should really be doing X" practices the company is failing to maintain.

A different shape

What you actually need is not a discipline practice. It is a structural property of how the company communicates. If decisions are visibly made in threads — in Slack, in email, in meeting transcripts — and if those threads are searchable and structured by topic and project, then the "decision log" emerges as a byproduct of how the company already works, without anyone having to do extra work to maintain it.

This is the inversion that solves the problem. Instead of asking people to record decisions after they make them, you make the conversation in which the decision was made into the record.

Concretely: when the team debates "Stripe vs GoCardless" in a Slack thread, that thread is the decision log entry. When someone asks, six months later, "have we discussed switching payment processors before?" the answer comes from a query into the actual thread, with the reasoning intact. No one had to write a second document. The thread was always the record.

The piece this requires

For this to work, the communication has to be structured well enough to be queryable. A raw dump of every Slack channel for the past two years is not useful. The queries you want to make are organized by project, by topic, by client, by decision area — not by channel.

This is the role of the "company brain" layer we have written about elsewhere. It sits over your communications, organizes them against the entities your work is actually about, and makes them queryable in plain language. The decision log emerges from this layer as a special case: any query that asks "what have we decided about X" becomes answerable.

The crucial thing is that this requires no behavior change from the team. They keep working the way they already work. The decisions get made in the conversations where they were always going to be made. The difference is that the conversation is no longer ephemeral. It is a queryable, structured part of the company's working memory.

What this looks like in practice

A few patterns are common at companies that have done this.

The "let me check" pattern. Before re-debating something, anyone on the team can run a quick query — "have we discussed X in the last year?" — and get back the relevant threads. This catches most re-litigation cases before they restart.

The "context for new hires" pattern. A new person joining a team can ask "what decisions have been made about Project Y over the past six months?" and get a structured answer drawn from the actual conversations. They build context without needing one-on-ones with seniors.

The "audit trail" pattern. When a client or a regulator asks "when and why did you decide to do X", the answer is reconstructable from the actual record, not from memory.

None of these patterns require anyone to maintain a decision log. They all require the underlying communication to be organized well enough to be queried.

Stop trying to log. Start making the conversation legible.

The honest advice for any SME currently planning a decision log initiative is to skip it. The initiative will fail for the same reasons every other one has failed, and you will spend the team's already-stretched goodwill on something that won't deliver.

The real path is to invest in the layer that makes your existing communication queryable. The decision log you wanted will appear as a free byproduct. You won't have to maintain it. It maintains itself.

The decisions are being made every day, in threads that are being recorded automatically. The only question is whether you can read them when you need them.