Most decision logs read like meeting minutes. ‘We decided to go with vendor A on 2024-09-12.’ That sentence is the entire record. Six months later, when the question of whether to renew vendor A comes up, nobody can remember why vendor A was picked, and nobody knows whether the reasons still hold. The log was there, and it was useless.
A decision log that works has to do two things the simple version doesn’t. It has to record what fed the decision. And it has to record the conditions under which the decision should be looked at again.
Start with what fed the decision. By that I mean the inputs, not a summary of the meeting: what you believed to be true about the world, and what you weighted against what. If you picked vendor A over vendor B because vendor A had a better compliance posture and price was the tiebreaker, that gets written down. If you were betting on vendor A’s roadmap more than on their current product, that gets written down too. The inputs are the reason the decision made sense.
Most people skip this part because it feels redundant at the time. You know why you’re picking vendor A. Everyone who made the call knows. Writing it down feels like overhead. Three months later the people who made the call have moved teams or left, and the reason the decision made sense has moved with them. The log sits in a wiki page saying ‘we chose vendor A’ and tells no one anything.
The second half is the part almost nobody writes. The conditions under which the decision should be revisited. Most decisions made at a senior level are made under assumptions that won’t hold forever. You’re betting on a team that’s the current size and a market that looks the way it does right now. When one of those changes enough, the decision that was right stops being right, and somebody has to notice. If you haven’t written down which assumptions mattered, nobody will notice, and the decision will keep running long after it should have been unmade.
What this looks like in practice is a short list. ‘Revisit if vendor A’s roadmap slips by more than two quarters.’ ‘Revisit if our contract value with them grows past the point where the renewal is worth negotiating hard.’ Each item names a condition specific enough that someone reading the log a year later can check whether it’s been met.
The log doesn’t have to be long. A good decision log entry is half a page. The top half is what fed the call: the tradeoffs considered, and the option that won over the options that lost. The bottom half is the revisit conditions. The name of the person who made the call goes somewhere visible, so future readers know who to ask if the context isn’t clear.
This format handles the specific way decisions decay in an organization. A decision log that captures only the outcome decays in months. One that captures the reasoning and the revisit conditions holds up much longer, because it carries inside itself the instructions for when to read it.
The compounding benefit shows up later. A senior operator with two years of decision logs written this way has a document of how the company arrived at its current shape, which is a specific and rare thing to have. When a new executive joins, the log is most of the onboarding they need on why things are the way they are. When a decision needs to be made that resembles an old one, the log tells the operator what they were thinking last time and whether the thinking still applies.
The failure case is writing the log for the wrong audience. If the log is written to justify the decision to the people who made it, it’ll read as defensive and will be useless to anyone else. Write the log for the person who’ll inherit the decision. That person is either a future version of you who’s forgotten the context, or someone who takes over the role in two years and has to figure out why things are this way. Both of them need the reasoning and the revisit conditions, rather than a defense of why the call was right.
A decision log is a handoff mechanism from the present operator to the future operator. The present operator usually turns out to be the main reader of it.