Six weeks after your team picks the vendor, the rollout is behind, the first demo flopped, and someone in the retro asks the question that cools the whole room: why did we go with them again?
Nobody has a clean answer. The person who pushed hardest remembers one set of reasons; the person who signed off remembers another. The doc where the trade-offs actually lived is buried under forty newer docs. So the loudest memory wins, the decision gets re-argued from scratch, and whoever made the original call ends up defending it against facts that nobody in the room had at the time.
You’ve probably sat through some version of this. It surfaces in retros, and it surfaces in 1:1s, usually phrased as “I still don’t get why we did X.” The hour lost re-arguing a settled question is the smaller cost. The bigger one is what it teaches people: that making a clear call is risky, because the reasoning evaporates and only the outcome survives to be judged. The decision itself came through fine. What vanished was the reasoning behind it, the part everyone actually needed to make sense of the call. And once that’s gone, people backfill the gap with what they know now, which always makes the past look more obvious than it really was.
What a decision log actually is
A decision log is a short, running record of the calls you make and the thinking behind each one, written the moment you decide rather than reconstructed weeks later. One entry per decision, a few sentences each. That’s the whole tool.
It works because of when you write it. The entry goes down while the decision is still live and the reasons are still honest, before the outcome has had any chance to color them. A choice worth an entry is any call you’d struggle to reconstruct in three months and might one day have to defend: a hire, a scope cut, a tool you standardized on, a bet on one approach over another.
Two heavier things tend to crowd this idea out, so it’s worth drawing the line. A decision log is not a RAID log or an architecture decision record, the formal artifacts a project keeps so an auditor or a future engineer can trace what happened. Those serve the project. A decision log serves you. It’s also lighter than an investor-style calibration diary, where you assign a probability to every prediction and grade your accuracy over months. That’s a forecasting discipline, and it’s more overhead than most people will keep up with past the second week.
What’s left once you strip both of those down is deliberately small. It exists to answer one question later: what was I actually thinking when I chose this?
The four-field decision log template
The template has four fields, and keeping it to four is the point. Anything longer and you quit filling it in by Wednesday.
- Situation. The decision in one line, with the date and what forced it now.
- Options considered. The real alternatives, including the ones you killed fast.
- Why (rationale). The actual reason you picked this option over the rest.
- Expected outcome. What you think will happen, and the signal that would tell you the call was wrong.
That’s it. Under two minutes to log. Filled in for a hiring call, the kind of decision that gets second-guessed for months, one entry looks like this:
| Situation | Options considered | Why (rationale) | Expected outcome |
|---|---|---|---|
| 31 Jul. Two finalists for the analyst role, one offer to give before B takes another job. | Offer A (stronger SQL, quiet with stakeholders); offer B (weaker SQL, strong with stakeholders); reopen the search. | The role is mostly stakeholder-facing this quarter, and SQL is teachable on the job. Reopening loses the Q3 reporting cycle. | B ramps on reporting inside a month and leans on the team for SQL until then. If B is still stuck at the 60-day mark, the bet was wrong. |
Notice what that last field does. It records, in advance, the exact condition that would prove the choice wrong. That one sentence is what makes the log worth keeping, and it’s the field almost everyone leaves blank. Keep the whole thing wherever you’ll see it: a running note in your notes app, a pinned doc, a channel only you post in. Any of those works. What matters is writing the entry before you know how things turned out. If a field genuinely doesn’t apply, leave it blank instead of inventing something to fill it. A half-filled entry you wrote in ninety seconds beats a polished one you never got around to starting.
The review step that turns a decision log into better judgment
A decision log you never reopen is just a diary. The writing feels productive, but nothing comes back to teach you anything. The value lives in the review, and the review is the part almost everyone drops.
Keep it small enough that you actually do it. Ten minutes, every two weeks or once a month, tacked onto a ritual you already keep: the end of a 1:1, your Friday planning slot, whatever already holds a recurring spot on your calendar. Open the two or three entries whose expected-outcome window has come due, and run each one through three questions.
- What actually happened, next to the outcome I wrote down?
- Was the call wrong, or was it a reasonable call that drew an unlucky result?
- What did I know then that I’d weigh differently now?
That second question is the one that changes how you decide. A bad outcome doesn’t always mean a bad decision, and a good outcome doesn’t always mean a good one. Say you greenlit a feature that shipped late. If your note shows you flagged the timeline as the biggest risk and chose to proceed anyway with eyes open, that’s a process that worked, even though the result stung. If your note shows you never weighed the timeline at all, that’s a gap worth fixing. Same bad outcome, two very different lessons, and only the written entry tells you which one you’re actually looking at.
Naming which one it is has a practical payoff: you only ever get to adjust the process, never the luck. When a review turns up a real gap, write the fix into how you’ll handle the next call of that type. When it turns up a sound decision that simply drew a bad result, let it go without second-guessing a choice you’d make again.
Over a few months the entries start to rhyme. You notice you consistently overrate the option that lets you dodge an awkward conversation, or that your shakiest calls cluster on the days you decided in a rush. No single entry tells you that. The stack of them does, and spotting a pattern you can name is the quiet second payoff of keeping the log at all.
Why writing down what you expect beats trusting hindsight
The reason the expected-outcome field matters comes down to a quirk in how memory works. Once you know how something turned out, your brain quietly rewrites what you believed beforehand to match the result. What researchers call hindsight bias is this tendency to see an outcome as obvious after the fact, even when it was genuinely uncertain at the time. It’s why the retro so often ends with someone insisting the failure was predictable, and why the person who made the call struggles to defend a choice that felt perfectly reasonable a month ago.
A written record makes it harder to rewrite your own reasoning after the fact. You can’t claim you saw it coming when your own note from that week says otherwise. The idea isn’t new. Investors and writers have kept decision journals for years for exactly this reason, capturing their thinking before the outcome lands so they can check it honestly later.
The expected-outcome field borrows a second move too. Forcing yourself to predict what will happen, and to name what failure would look like, is a lightweight version of the premortem that Gary Klein popularized, where a team imagines the decision has already failed and works backward to why. You surface the risks while you can still act on them, and you leave a marker you can hold yourself to. Put those two together and the “why did we decide this?” fight mostly stops happening, because the answer is sitting right there in your own words, dated and unedited.
Biases like this rarely travel alone, and hindsight is only one of the cognitive biases that quietly bend how you decide. A log won’t make them disappear, but it leaves a paper trail your memory can’t quietly overwrite.
Team decision logs and personal decision logs use the same template
The four fields don’t change when you move from your own decisions to your team’s. What changes is who writes the entry and how you review it.
For personal use, the log is private and the review is solo. You’re building a clearer read on your own patterns, where you tend to overweight speed, or consensus, or the last confident voice in the room.
A team entry reads the same as a personal one, just with a name on it: the owner, the date, the options the group weighed, the reason it landed where it did, and what everyone expects to see if the call was right. The decision owner writes it in a shared doc, and the review rides along on a ritual you already run, a monthly retro or a planning session. Logging every routine choice just buries the ones that matter, so keep it to the calls that are expensive to reverse or easy to forget. That way the reasoning behind the decisions that count outlives the meeting they were made in, which is most of how to make tough decisions as a group without relitigating them later.
Good judgment is a skill you practice, and a log is where you practice it
A decision log is a rep. Every entry you write and later reopen is a small, honest look at how you think under real constraints. Do enough of them and you start catching your own tendencies before they cost you, which is the entire point.
If you want a read on those tendencies before you start logging, decision-making is a skill you can measure. The free assessment shows you where your judgment is already strong and where it tends to slip, so you know what to watch for in your own entries.
And when a logged decision comes due for review, you don’t have to reopen it alone. Talk it through with Merlin, Risely’s AI coach: paste in the entry, walk through what actually happened against what you expected, and pressure-test whether the call was wrong or just unlucky before you carry the lesson into the next decision.