/ Library/ Not Enough Meaning/ Moral Luck
Connect Bias № 109 · Last updated 6 June 2026

Moral Luck.

"A good outcome makes a reckless decision look wise — and vice versa."

01Overview

Moral luck is the paradox that we praise or blame agents for outcomes influenced by factors outside their control. A reckless launch that coincidentally helps users is called visionary. A careful process punished by a bug is called failure.

Design retrospectives reward outcomes. Teams copy lucky playbooks and avoid unlucky good practices. Moral luck distorts organisational learning — and how users experience accountability when harm was process-predictable but outcome-rare.

02Detailed explanation

Outcome-based judgment permeates product culture:

  • A skipped research phase ships; market timing saves it — "move fast" becomes doctrine.
  • Thorough testing delays release; unrelated competitor stumble makes delay look like loss.
  • Privacy near-miss never breaches; team cuts security investment — "we were fine."
  • Designer blamed for metric drop driven by backend outage.

Outcome bias is the analytics cousin — evaluating past decisions by results. Moral luck adds ethical weight: good people / bad people narratives from luck.

03Why it exists

Outcomes are visible; process is not. Retrospectives screenshot metrics, not decision logs.

Narratives need heroes and villains. Luck complicates plot — so luck gets edited out.

The short version

Would you make the same decision again knowing only what you knew then — regardless of how it turned out?

04Effects on users

Users suffer when organisations learn from luck — doubling down on risky patterns that worked once, cutting safeguards that failed once despite sound reasoning.

They also attribute moral character to brands from single outcomes — one apology for a visible harm redeems or condemns years of process.

05Effects on designers & teams

Teams encode moral luck in rituals:

  • Outcome-only retros. Win celebrated; process unexamined.
  • Hero/villain PM stories. Attribution to individuals, not systems and chance.
  • Risk appetite from anecdotes. One near-miss or one jackpot sets policy.
  • Punishing unlucky quality. Teams that did right thing with bad luck lose budget.

6Introspective view

Look inward. Teams judge decisions by their outcome rather than the process, distorting accountability.

From an introspective perspective, ask how Moral Luck may already be shaping your research, critique, planning, and interpretation — not only what users encounter in the finished interface.

Retrospectives

The story of the sprint

Retros on Moral Luck tend to rehearse the narrative that is easiest to tell — usually the one that matches how people already feel about the work. Teams judge decisions by their outcome rather than the process, distorting accountability.

Stakeholders

The loudest frame wins

Alignment workshops on Moral Luck can converge on whoever articulated a direction first, even when the room never formally agreed. Teams judge decisions by their outcome rather than the process, distorting accountability.

Measurement

Metrics that flatter the release

Iteration reviews for Moral Luck gravitate toward dashboards that make the recent release look successful, while quieter indicators of harm stay uncharted. Teams judge decisions by their outcome rather than the process, distorting accountability.

User Interviews

What you hear first sticks

In early interviews about Moral Luck, the opening participant can set the frame for everyone after — which pains feel central, which workflows seem broken, which quotes get repeated in synthesis. Teams judge decisions by their outcome rather than the process, distorting accountability.

07Practical takeaways

  • Retrospect on process quality. Separate decision quality from outcome.
  • Document decision conditions. What was known, unknown, and risky at ship time.
  • Reward good process with bad luck. Explicitly — or learning dies.
  • Pre-mortems before post-mortems. Predict failure modes independent of outcome.
  • Avoid copying lucky shortcuts. Ask if shortcut caused success or coincided.
  • Fair accountability. Blame systems and scope, not only individuals when luck dominated.

08Design examples

Launch

Skipped research, lucky timing

A team ships without research during a news cycle that drives traffic. Leadership cites agility. Next skip during quiet week flops — moral luck masqueraded as method.

Security

No breach, no budget

Years without incident. Security UX investment cut. Breach follows — blame lands on engineer, not years of outcome-lucky underfunding.

Design critique

Blamed for the outage

A redesign ships; backend fails same day. Metrics drop. Design rolled back despite research quality — outcome luck judged process.

Ethics

Near-miss invisible

A dark pattern trial stops after legal scare without user harm. Team records win. Same pattern ships elsewhere with harm — luck differentiated outcomes, not ethics.

09Ethical risks

Judging ethics by outcomes lets harmful processes survive until rare luck runs out — users pay on the unlucky draw.

Punishing unlucky careful teams incentivises reckless luck-seeking across the industry.

Self-test: Which process would you repeat even though the last outcome was bad?

10Suggested reading