Separating Decisions From Outcomes

Picture the review that always tempts you: a launch you green-lit misses its numbers, a hire you championed washes out, a pricing move you backed underperforms. The room turns to the decision and starts tearing it apart. That instinct feels like accountability, but it hides a trap. You're judging the decision by how it turned out, not by how it was made.

In this lesson, you will learn to:

• Separate decision quality (sound reasoning given what you knew) from outcome quality (how it landed)
• Run a post-mortem that judges the call on the evidence available at the time rather than on hindsight
• Build a decision journal that freezes your reasoning before the outcome is in

That trap has a name in decision science: resulting. Resulting is judging a decision only by how it turned out — treating a bad result as proof the decision was bad and a good result as proof it was good — while ignoring whether the reasoning behind it was actually sound at the time you made the call.

The fix is to hold two things apart. Decision quality is how sound your reasoning was, judged against the information available to you at the moment you made the call. Outcome quality is simply how it landed. Over hundreds of calls, good reasoning wins more than it loses. But on any single decision the two can fully decouple: a well-reasoned bet can lose to bad luck, and a sloppy call can get bailed out by a lucky break.

So in any post-mortem, force the split. Ask two separate questions: "Was this a good decision?" and "Was this a good outcome?" Answering them together is how good reasoning gets scrapped over one unlucky result.

Here's what that split sounds like in a real review. Jake's team just lost an account weeks after signing and he's ready to scrap the qualification process. Victoria slows him down before the result rewrites the decision:

• Jake: We lost the account six weeks after signing. That qualification process is broken. Let's scrap it.
• Victoria: Hold on. Given what we knew when we signed them, was the process sound?
• Jake: ...Honestly, yes. They cleared every check. The budget freeze that killed it came out of nowhere.
• Victoria: Then the process made a good call on a deal that got unlucky. Scrapping it punishes good reasoning for a bad break.
• Jake: So the real fix isn't the process. It's adding an early signal for sudden budget freezes.

Notice how Victoria never argues the outcome was fine. She separates the decision from the result, and the actual lesson surfaces instead of an overreaction.

When you run a decision post-mortem, your job is to reconstruct the decision as it actually stood at the time: the evidence you held, the assumptions you named out loud, and the confidence that was reasonable then. Hindsight will try to smuggle in facts that only surfaced later, and your job is to keep them out.

The clean test is one question: "Was there evidence available at the time that we ignored or misread?" If yes, that's a genuine reasoning flaw, and it deserves a fix. If the killer information only became visible after the fact, that's a bad outcome, not a bad decision. A budget freeze nobody could have seen, a competitor move that came from nowhere, a supplier collapse with no warning signs: those are breaks, not process failures.

Guard both edges. Don't excuse a real reasoning flaw by waving it off as bad luck, and don't let one painful result convince you a sound process is broken. Picture the account that churned six weeks after signing: if the team ignored a credit warning that was sitting in the file, that's a genuine flaw worth fixing. But if a company-wide budget freeze hit out of nowhere, no check could have caught it — that's a bad break, not a bad process. When a colleague slides toward "it failed, so it must be wrong," name it plainly: that's resulting. One bad outcome is a data point, not a verdict.

Honest reviews are hard because memory is unreliable, and once you know the result, your brain quietly rewrites what you "always knew." A decision journal blocks that by freezing your reasoning before the outcome is in.

For any consequential call, capture a short entry with these fields:

Two of these fields do the heavy lifting. Confidence forces a real number — writing "70% this vendor hits its service-level agreements" commits you to something you can be right or wrong about later, unlike a fuzzy "I think they'll be fine." The disconfirming signal names exactly what you'd have to observe to conclude you were wrong — for that vendor, maybe "two missed service-level agreements in the first quarter." Together they make a later review resulting-proof: when the review date arrives, you compare what happened against what you actually wrote, not against a memory the outcome has quietly edited.

The discipline is simple: record the reasoning now, judge it later against what you actually said, not against how it turned out.

The single takeaway is simple. Judge a call by the quality of the reasoning available at the time, not by the result that happened to follow. Up next, you'll take on three practices — a quick self-check to spot resulting in review statements, a live conversation holding the line on a sound process that produced one bad deal, and a decision-journal template you can reuse.