Resulting — why judging decisions by outcomes backfires

A team makes a bold decision. It works. The team is celebrated. The decision is studied. The approach becomes a template.

A different team makes the same bold decision, with the same information, using the same reasoning. It doesn't work. The team is questioned. The decision is scrutinized. The approach is abandoned.

Same decision. Same quality. Different outcome. Different evaluation.

This is resulting — the automatic, unconscious tendency to judge the quality of a decision by the quality of its outcome. And it's embedded so deeply in how we evaluate performance that most people don't realize they're doing it.

How resulting works

Resulting is a composite bias. It's not one cognitive error — it's three operating simultaneously:

Outcome bias: Evaluating a decision as good or bad based on whether it produced a good or bad result. This ignores the fact that good decisions can produce bad outcomes (variance) and bad decisions can produce good ones (luck).

Hindsight bias: After knowing the outcome, believing that the outcome was predictable — and therefore that the decision should have anticipated it. "Obviously that was going to happen" is easy to say after it happened. Before it happened, it was one of many possibilities.

Behavioral change: The most damaging component. Resulting doesn't just distort your evaluation of past decisions. It changes your future behavior. Good outcomes reinforce the behavior that preceded them — even if the behavior was wrong. Bad outcomes suppress the behavior that preceded them — even if the behavior was right.

This triple mechanism makes resulting self-reinforcing. You judge by results, which changes your behavior, which gets judged by results, which changes your behavior further. The feedback loop runs on outcomes, not on process — and outcomes are the noisiest possible signal in any uncertain environment.

Resulting is what happens when you let the scoreboard coach the team. The scoreboard shows who's winning. It says nothing about who's playing well.

The 2x2 that matters

Every decision-outcome pair falls into one of four quadrants:

| | Good outcome | Bad outcome | |---|---|---| | Good process | Deserved success — reinforce | Bad luck — reinforce the process anyway | | Bad process | Dumb luck — correct the process | Deserved failure — correct the process |

Standard evaluation only sees the columns: good outcome = praise, bad outcome = critique. Resulting-aware evaluation sees the rows: good process = reinforce, bad process = correct — regardless of outcome.

The two most dangerous quadrants:

Bad process, good outcome (dumb luck). This is the silent killer. The decision was poorly made — skipped checks, emotional reasoning, insufficient analysis — but the outcome was positive. In a standard review, this gets celebrated. The person is rewarded. The approach is validated. And the bad process gets reinforced, making it more likely to recur.

The next time the same bad process is used, it might produce a bad outcome. But by then, the person has been trained — by resulting — to trust the process that got lucky once. The correction comes too late.

Good process, bad outcome (bad luck). This is the silent victim. The decision was well-made — thorough analysis, proper checks, sound reasoning — but the outcome was negative. In a standard review, this gets questioned. The process is doubted. The person loses confidence. And the good process gets abandoned in favor of something that "works" — meaning something that got lucky recently.

Every time a good process is abandoned after a bad outcome, the organization's decision quality degrades. Not because of the single event, but because the system that produced good decisions was discarded for the wrong reason.

Why resulting is so persistent

Resulting persists because outcomes are visible and process is not.

You can see the P&L. You can see the project result. You can see the hire's performance. These are concrete, measurable, unambiguous.

Process quality is invisible unless you've built systems to surface it. Did the person follow the protocol? Did they evaluate alternatives? Did they define exit criteria before committing? Did they check their state? These questions have answers — but only if the process was documented in real time and evaluated before the outcome was known.

Without that infrastructure, resulting is the default. The outcome is the only data point available, so it becomes the only data point used.

The off-process success problem

The most dangerous form of resulting isn't punishing good process after bad outcomes. Organizations can learn to tolerate that — "it was just bad luck" is a narrative that fits.

The most dangerous form is rewarding bad process after good outcomes. Because this compounds.

Every off-process success teaches the person: "I don't need the process. My instinct is better." Each repetition weakens the system's authority. The person starts bypassing protocols more frequently, and because intermittent reinforcement is the most powerful conditioning mechanism, the occasional win from bypassing is enough to sustain the behavior even as the average outcome degrades.

By the time the off-process approach produces a catastrophic failure, the person has accumulated dozens of off-process "wins" that feel like evidence. "I've been doing it this way for months and it's worked fine." The sample is biased — the losses were small and forgettable, the wins were large and memorable — but the narrative is compelling.

The only defense is tracking off-process decisions separately and evaluating their complete distribution, not their highlights.

Resulting in organizations

Resulting scales. It doesn't just affect individuals — it shapes organizational culture.

Strategy: The company's last major bet paid off. Therefore, the strategic approach is sound. But was it sound? Or did the market cooperate? Without separating process from outcome, the organization can't tell — and the next strategic bet will be made with false confidence derived from the previous outcome.

Hiring: The last hire from a particular school performed well. Therefore, candidates from that school are strong. But was the hire's success due to their school, their individual qualities, or random variance? Resulting can't distinguish, and the hiring criteria drift based on outcome noise.

Product: The last feature launch succeeded. Therefore, the development process works. But the launch succeeded because of timing, market conditions, and a competitor's misstep — not because of the process. The process had significant flaws that the good outcome obscured. Those flaws will surface in the next launch, when conditions are less favorable.

In each case, the organization is learning from outcomes instead of process. The lessons are wrong, the confidence is misplaced, and the corrections come only after the resulting catches up — usually at the worst possible time.

The anti-resulting protocol

Combating resulting requires structural intervention at two points:

At decision time: Document the reasoning, the alternatives considered, the risk assessment, and the expected range of outcomes. This creates the raw material for process evaluation independent of results.

At review time: Evaluate the documentation first, blind to the outcome. Score the process quality. Then reveal the outcome and compare. The mismatch between process quality and outcome quality is where the real learning lives.

Additionally, build a specific review question into every post-decision analysis: "Would my evaluation of this decision change if the outcome had been different?"

If the answer is yes — if you would have praised the decision with a good outcome but criticized it with a bad one — then your evaluation is resulting-based, not process-based. The decision quality didn't change. Only the outcome did.

The goal isn't to ignore outcomes. Outcomes are data. The goal is to stop using outcomes as the primary evaluation of decision quality — and to build systems that evaluate the decisions themselves, separated from the noise of results.