Field notes · Idea · 3 min read · Keep commitments

Write the decision down before you know the outcome

A project goes badly and you tell yourself the decision was obviously wrong. Another goes well and you remember being sure all along. Months later you cannot say what you actually knew when you decided.

The idea

Annie Duke's Thinking in Bets names this trap "resulting": judging a decision by how it turned out. A good decision can have a bad outcome, and a bad decision can get lucky. Her underlying point is that memory rewrites what you knew at the time, so once you know the result, the decision looks obvious or foolish. Writing down your reasoning when you decide is the practical way to judge it by what you actually knew.

Peter Drucker made a similar point in his article "Managing Oneself". Each time you make a key decision, write down what you expect to happen. Several months later, compare it with what did. He argued this shows you where your strengths lie and where you need to improve to use them, and he applied it to key actions as well as decisions.

Software teams have a practical version. Michael Nygard's "architecture decision record" is a short page for each significant decision: the situation, the decision, its status and its consequences, so someone arriving later can see why.

What it gets right

It asks for the reasoning while it is fresh, and it makes later reflection fairer. A record also helps a team: the next meeting can start from "here is what we decided and why" instead of a half-remembered argument.

Where it breaks in a real week

None of these has been tested in a controlled study; they are practitioners' habits. Recording everything is a chore, and a decision log nobody reads is just paperwork. Duke's advice is also easy to misuse as an excuse: "my process was good" does not make a poor outcome acceptable. And "write it down" is my gloss on her argument, not a rule from her book. Write the decision down when it matters, and keep it short.

How Trellis builds it in

Meetings and Decisions are distinct things in Trellis. A Decision records the statement and its rationale, can cite evidence by reference and can be linked to the meeting where it was made. When you change it, the earlier wording stays in its history, so you can see why a direction moved. A capture after a meeting can produce a Decision, the Actions that follow and a note about what is still unclear, all in one review. Trellis does not prompt you for an expected outcome, and a reflection is not a field on a Decision. You can capture a reflection later and confirm it as a Reflection, naming the decision in the text, and the Timeline then shows the sequence.

If you want Drucker's habit, write what you expect into the decision's rationale, and read it back when you reflect.

Try this week

1. After your next meeting, write one decision in a sentence specific enough to tell apart from another choice.
2. Add why, and what you expect to happen.
3. Put a date in your calendar to compare, and write one line about what you learned.

How strong is the evidence?

These are practitioners' arguments from poker, management and software practice. They are well regarded and sensible, but they are not experimentally tested, and what works for a team may not for you.