Analytics functions produce an enormous amount of documentation. Data dictionaries, model documentation, runbooks, architecture decision records, methodology notes. What almost none of them keep is a record of the decisions the analysis was for.
This is a strange omission, because the decision is the point. Everything else is machinery in service of it. And the absence of that record causes a specific and recurring set of problems that are difficult to diagnose precisely because the missing artefact was never expected to exist.
What a decision log is
Short entries, one per material decision, written at the time. Five fields is enough.
- What was decided, in a sentence.
- Who decided it.
- What evidence was in front of them, with links to the actual artefacts.
- What they expected to happen, stated concretely enough to be checked later.
- When it should be reviewed.
That is the whole thing. It takes a few minutes to write. Teams resist it anyway, usually on the grounds that the decision is obvious to everyone present and writing it down is bureaucracy.
It is obvious to everyone present. That is precisely the condition under which nobody writes it down and everybody later remembers it differently.
The four problems it solves
Analysis with no destination
The most common waste in analytics is work that was never going to change anything. It is hard to spot in advance because every request has a plausible rationale attached.
Requiring a linked decision changes the conversation at intake. Asking which decision this informs, and what the requester would do differently depending on the answer, either produces a clear response or reveals that there is not one. Both outcomes are useful. A meaningful share of requests do not survive the question, and the ones that do get scoped better because the destination is known.
Nobody checks whether it worked
Decisions get made on the basis of an expected outcome. Almost nobody returns to check whether that outcome occurred, because there is no mechanism prompting them to and no record of what was expected.
A review date turns this from an act of conscience into a calendar entry. The learning that accumulates is the thing that actually improves institutional judgement, and it is entirely lost in organisations that do not capture the expectation at the time.
The same argument, annually
Organisations relitigate settled questions with striking regularity. Whether to weight a metric by volume. Whether a particular segment should be excluded. Whether attribution should be first or last touch.
These get decided, and then eighteen months later somebody new asks the same question and the whole discussion reruns, often reaching a different answer for no better reason than a different room. A log does not prevent revisiting a decision. It means the revisit starts from what was previously concluded and why, which is a much shorter conversation.
The reasoning leaves with the person
When someone leaves, their documentation stays and their reasoning goes. The successor inherits a set of arrangements with no rationale attached, and faces a choice between preserving conventions they do not understand or changing things without knowing what depended on them.
This is where the log pays back most visibly. We have watched a new analytics lead work through eighteen months of decision entries in an afternoon and arrive at a level of context that would otherwise have taken a quarter to reconstruct, incompletely.
Keeping it alive
Decision logs die for ordinary reasons. Nobody writes entries because nobody reads them, and nobody reads them because there are no entries. Breaking that requires deliberately lowering the cost of writing and raising the visibility of reading.
Practically: keep it where the team already works rather than in a separate system. Accept rough entries, because a scrappy record beats a polished absence. Have someone read the review-due items at an existing recurring meeting, so the log has a standing audience. And log the decisions that went badly, which is both the hardest discipline and the source of most of the value.
Do not attempt to log everything. Material decisions only, meaning ones that would be expensive to reverse or that commit resource. Attempting completeness is the reliable way to end up with nothing.
The secondary effect
The benefit teams report most often is not any of the four above. It is that writing the expected outcome down forces a precision that the meeting did not require.
Saying a change will improve conversion is easy in a room. Writing that it is expected to move conversion from 3.1 to somewhere above 3.4 within six weeks is a different act. It occasionally reveals that the group did not actually agree on what they were expecting, which is worth discovering before the work starts rather than during the review.
For an artefact that costs a few minutes per entry and requires no tooling, that is an unusually good return.
The pushback, and what is right about it
The objection we hear most is that a written record of decisions creates exposure. If a decision goes badly, there is now a document with a name on it. In organisations where things go wrong publicly, this is not a paranoid concern.
It is worth taking seriously rather than dismissing, because the fear determines whether the log gets honest entries or defensive ones, and a log of defensive entries is worse than none. It consumes effort and produces a record that describes how people wanted decisions to look.
Two things reduce the risk meaningfully. The first is recording the decision as a group output rather than an individual one wherever that is accurate, since most material decisions genuinely are. The second, and more important, is what happens the first time a logged decision turns out badly. If the review is conducted as an examination of what was knowable at the time, the log survives. If it is conducted as an examination of who was wrong, the log is finished, and the entries after that point will be written for the reader rather than for the record.
The distinction to hold onto is between a bad decision and a bad outcome. A decision made sensibly on the evidence available can produce a poor result, and treating that as an error teaches people to avoid decisions rather than to make better ones. The log is useful precisely because it records what was known at the time, which is the only fair basis for that assessment.
Start with the ones already being made
If you want to try this, do not announce a process. Take an existing recurring meeting where decisions genuinely get made, and spend the last five minutes writing down what was decided and what is expected to follow. One person, in the meeting, in whatever tool the team already uses.
Within a quarter there will be entries with review dates falling due, and reading those becomes the second habit. The practice either earns its place at that point or it does not, and either answer is worth having cheaply.
