Ian Pettigrew said something on Corey-osity Unleashed I keep coming back to. In every situation, he told us, "we either succeed or learn."

I like it. I want it to be true. Ian said in the next breath it's easier to say than to do, and he's right, because the line leaves out the most common outcome in software.

You fail. You learn nothing. You ship the same bug in six months.

The third outcome has no slogan and no poster. It has a shared drive full of incident reports nobody opens.

A printed report on a desk with typed lines at the top and a large empty box at the bottom

Failure Doesn't Teach by Default

Our industry loves a failure story. Fail fast. Fail forward. Move fast and break things. Every conference has a speaker who lost a fortune and came out wiser.

Lauren Eskreis-Winkler and Ayelet Fishbach tested the idea. Across five studies with 1,674 participants, people answered two-choice questions and heard "correct" or "incorrect". With only two choices, both messages carry the same information. A wrong answer tells you the right one as clearly as a right answer does.

People still learned less from failure. The result held in professional, language and social tests. It held when learning from failure took less mental effort. It held when the researchers gave people an incentive to learn.

The authors' explanation is uncomfortable. Failure threatens your ego, so you tune out. People who got failure feedback even remembered fewer of the answers they'd given.

So picture your last incident review. The person who caused the outage sits in the room. You ask the person with the most ego on the line to do the deepest learning, at the moment their brain wants to leave.

A software engineer leaning back with eyes closed and a hand over one ear, a red error graph on the laptop in front of them

Heart Surgeons Do It Too

You might write off a lab study. Try this one.

KC, Staats and Gino followed 71 cardiothoracic surgeons over 10 years and more than 6,500 procedures using a new surgical technology. These people have every reason to learn from a bad outcome. A patient's life rides on it.

The surgeons learned more from their own successes than from their own failures. They learned more from other surgeons' failures than from other surgeons' successes.

Look at the pattern again, because the lab study found the same thing. In the Eskreis-Winkler and Fishbach work, people learned as much from someone else's failure as from someone else's success. Take the ego out and the lesson comes back.

Your failures make a poor teacher for you. They make a decent teacher for the person at the next desk.

Organizations Learn Where People Don't

Here's the part I find most useful. Madsen and Desai studied the global orbital launch industry and found the reverse. Organizations learned more from failures than from successes, and the knowledge from failure faded more slowly.

Rockets and surgeons, opposite results. Why?

I'm not sure about this part: the abstract doesn't explain the gap, and I haven't read a study testing it head to head. My read is a blown-up rocket forces a formal investigation, with people outside the blast radius asking the questions. No investigation, no lesson.

If I've read this right, the fix isn't a braver attitude. The fix is a process which doesn't depend on the person who failed being in a fit state to learn.

There's a second trap. In Hidden Failures, the same researchers found people reluctant to share what they got from failing, teachers included, partly because they don't see the useful information in it. Point out the information and they share more.

So your people tune out their own failures, then keep quiet about them. Everyone else loses the one version of the lesson their egos would have let in.

I told you about a forty-minute checkout outage of mine a while back. I said the outage taught me more than the good weeks. Reading these studies, I'd give the credit elsewhere. The write-up I sent round did the teaching. The outage only supplied the material.

Ian Already Had the Answer

None of this makes Ian wrong. Listen to what he did with his own line.

He'd entered a book award and was heading to London for the shortlisting. He told us his default if he missed out: "I will be devastated. I will be gutted." So he made a plan before the result. If he didn't get shortlisted, he'd round up other people who hadn't and record a mini podcast on reframing failure.

My wife Debra jumped in. We'd been at a book awards do ourselves, and I'd told her to get something out of it... go meet five amazing new people. We didn't get shortlisted. She still had an amazing time.

Neither of us found a lesson in the wreckage. We decided what we'd walk away with before the result.

Ian's real point sits here. He worries about walking away feeling like a failure, because hopelessness spreads. The next day you don't bother getting on the bike. Hope needs a route, and "succeed or learn" keeps you on your feet long enough to find one.

So the line does a job. It keeps you in the game. The learning takes a second job, and you have to staff it.

What to Do About It

Decide what you'll learn before the result. Before the launch, the migration, the big bid, ask one question: if this goes badly, what will we know afterwards we don't know now? Write the answer down. A failure with a question attached has somewhere to go.

Read other people's failures on purpose. This is the cheapest training in engineering. Google's SRE book describes postmortem reading clubs and a postmortem of the month, often on incidents months or years old. You don't need your own material to start. Dan Luu's public list of postmortems has over 12,000 stars on GitHub and costs you nothing. Pick one for Friday, bring biscuits, ask what would have happened here.

Five engineers around a wooden table with mugs and a plate of biscuits, reading printed pages together

Swap who leads the review. Put someone from another team in the chair. They carry no ego in this one, so they'll hear what the person at the center of it won't. Keep the person who failed in the room as the expert witness, and ask what they tried before you tell them anything.

Don't scatter people after a bad day. A study of 4,306 heart operations at a European hospital found failure hurt performance in the short term and helped over the long term, and familiar teams softened the short-term hit. Your instinct after a bad incident says pull the person off the work and reshuffle. Keep them with people they know.

Make the lesson a change. "We learned to communicate better" isn't a lesson. Name the change, the owner and the date. Google's book puts it well: "An unreviewed postmortem might as well never have existed." The same goes for actions nobody finishes, which is how your retro turns into a broken promise.

Go first. Share your own failure, and point at the useful part out loud. I've written about why rank matters when someone shares a mistake, and the Hidden Failures work adds a reason: people miss the information until someone shows it to them.

The Test

Keep saying "we succeed or learn". I'll keep saying it too. It's a good thing to tell a team on a bad day.

Then earn it. Pick your team's last real failure, and name one thing you do differently today because of it.

If you've got an answer, you learned. If you've got a shared drive, you're in the third outcome.

Which one is it?