Self-serving bias

What is self-serving bias?

Self-serving bias is our habit of taking credit for successes and blaming something external for failures. When things go well it's down to our skill and effort; when they go badly it's bad luck, other people or the circumstances - a tidy accounting that protects our self-esteem but distorts what we learn.

Also known as: self-serving bias, attribution bias

Prefer to watch? Watch the recap 1:00

The demo

You ran two projects. One was a hit, one flopped. For each, pick what you think really caused the outcome. Then we'll look at the pattern in your answers.

What this demo shows (text version)

You're shown two outcomes of your own projects - one success and one failure - and asked to choose the cause of each from the same set of options, some internal (your skill, your effort) and some external (luck, the market, other people). Most people credit the success to themselves and blame the failure on outside forces, and the demo highlights that asymmetry once both answers are in.

That pattern is self-serving bias: we internalise wins and externalise losses to protect self-esteem. It feels fair but blocks learning, because you over-credit yourself when things work and miss your own role when they don't. Honest, blameless post-mortems counter it by deliberately asking the other half of the question each time.

We attribute our wins to ourselves and our losses to outside forces. It feels good and guards self-esteem, but it quietly wrecks learning: if every success proves you're brilliant and every failure was someone else's fault, you never find the real causes. In product teams this is corrosive - a launch that worked was "our strategy", one that flopped was "the market" or "users not getting it" - and it shows up in users too, who often blame themselves for a confusing interface (or blame the system for their own slips). Counter it by judging decisions against evidence, not ego: look for your own contribution to failures and outside help in your wins.

The bias protects self-esteem and a sense of control: internalising success ("I'm capable") and externalising failure ("it wasn't me") both feel better than the reverse. It's reinforced because we have privileged access to our own intentions and effort but only see others' outcomes, so we naturally weigh our contributions more generously.

On teams it quietly distorts learning and post-mortems: wins get over-attributed to our own skill and strategy while losses get pinned on the market, the timeline, other departments or "users not understanding". This blocks honest cause-finding, breeds blame, and means the same mistakes recur because nobody owns them. Blameless retrospectives and decision logs exist partly to counter it.

It shapes users too, and asymmetrically. Many people blame themselves when an interface confuses them ("I'm useless with computers"), which erodes confidence - so forgiving, non-accusatory design matters. Others externalise their own slips onto the system. Either way, designing error messages and flows that neither blame the user nor let real problems hide helps everyone attribute causes accurately.