Failure Is a Degree, Not an Event

A guest on a podcast I was listening to had a clean theory about interviews. Candidates can talk about their wins all day, he said. Ask them about a failure and they freeze. He treats that freeze as a red flag: no failure story, no self-awareness, no growth.

I have run enough programs and hired enough people to know the freeze is real. But the conclusion is wrong. The freeze does not mean the person never failed, or that they are hiding it. It usually means the question is built on a broken definition of failure.

The hidden assumption

“Tell me about a failure” presumes failure is a single, discrete event. You did a thing and it collapsed. There is a clear before and after, a clean villain, and a tidy lesson at the end. Roll the tape.

That kind of failure exists but it is just rare. Most failure in real work does not look like a collapse. It looks like a program that shipped, with a hundred small corrections buried inside it that nobody logged as failures because they got fixed before they mattered.

So when you ask for the collapse story and the person has mostly lived the correction story, they go quiet. You read the silence as a deficiency. It is actually a category mismatch.

Three reasons we genuinely cannot recall our failures

This is not evasion. There are real mechanisms behind the freeze.

1. The fix happens inside the motion, so the brain never files it as a failure. You are mid-project, something slips, you turn around, you correct it, you keep going. There is no salient bad outcome to tag in memory, so the episode gets filed under “Tuesday.” You cannot retrieve what was never encoded as a failure in the first place.

2. The win at the end overwrites the messy path. Once a project succeeds, hindsight reshapes the story. We remember the route as cleaner and more inevitable than it was. Psychologist Baruch Fischhoff named this in 1975: once we know the outcome, we systematically misremember how uncertain things felt along the way (Fischhoff, “Hindsight is not equal to foresight,” 1975). The local failures get quietly reabsorbed into the global success.

3. In a complex program, “I failed” is rarely even true. A real project has a dozen moving variables and several owners. When something goes wrong, it is usually the system, not a single person. Sidney Dekker calls this the difference between the “old view” and the “new view” of human error: the old view hunts for the one bad actor, the new view sees failure as something that emerges from the system around the person (Dekker, The Field Guide to Understanding ‘Human Error’). Asking someone to narrate a systemic failure as their personal failure asks them to be inaccurate. The honest ones refuse, and pay for it in the interview.

The racing line

Here is the model that reframes the whole thing.

In motorsport, the “optimum lap” is a construct nobody actually drives. Telemetry software stitches together your fastest mini-sectors from different laps into one ideal lap that may never have existed as a single continuous run. It is a theoretical best, not a thing that happened.

Every real lap, then, is a percentage of that ideal. You ran 99.6 percent of optimum. You lost two tenths in sector two, specifically on entry to the slow corners.

No driver calls a 99.6 percent lap a failure. The question is never “did I fail?” The question is “where did I leave time on the table, and how do I know?” The telemetry will not let you say “it went fine.” It tells you exactly where the delta is.

That is the difference. Failure is not a binary event you either have or do not have. It is a degree of distance from an ideal you will never perfectly hit. And it is distributed: a little lost here, a little there, across many corners and many variables.

Two axes, not one

There is still a hard-failure category. You can put the car in the wall. You can DNF. Some projects genuinely collapse. That is real and it matters.

So failure actually lives on two axes:

• Continuous failure: degrees off optimum. The micro-corrections, the time left on the table, the slips caught in flight. This is where almost all real work lives.
• Discrete failure: the crash, the DNF, the program that actually died. Rare, and usually multi-causal.

The mistake the podcast guest makes is collapsing everything into the discrete bucket, then penalizing people who do not have a discrete story. He is grading composure under an awkward prompt and calling it self-awareness.

The better question

If you want to know whether someone learns, do not ask for the crash. Ask for the delta.

• Not “tell me about a failure.” Ask “where did you leave time on the table, and how did you know it was there?”
• Not “what went wrong.” Ask “what did you catch and fix mid-flight, before it became a problem?”
• Not “whose fault was it?” Ask “what would you do differently on the next lap, and what was actually yours to change?”

These questions sidestep the collapse-and-catastrophe framing entirely. They surface judgment instead of storytelling. And they give your honest, systems-aware candidates a way to answer truthfully instead of forcing them to invent a villain.

This is not just an interview trick. It is exactly how a good retrospective works. The strongest post-mortems are blameless by design. Norm Kerth’s Retrospective Prime Directive opens every review with the assumption that everyone did the best they could with what they knew at the time (Kerth, Project Retrospectives, 2001). The US Army’s After-Action Review runs four plain questions: what was supposed to happen, what actually happened, why the difference, and what to do differently next time. The doctrine is blunt that an AAR “does not grade success or failure” and is not a forum for assigning blame (US Army, A Leader’s Guide to After-Action Reviews, TC 25-20, 1993). Notice what is missing from both. Nobody asks “who failed.” They ask where the delta was and what to do about it.

How we run this at NanoCoeur

When NanoCoeur runs a program, the retrospective is not a blame search and the status report is not a highlight reel. We track degrees off optimum: where the program left time on the table, what got corrected in flight, and what the next lap should look like. That is how you actually compound learning across a portfolio instead of repeating the same slip on the next IND.

We built a short guide that turns this into questions you can run on yourself, in a 1:1, or across a table in an interview. It is called the Delta Review, and you can download it below.

If your programs keep losing time in the same corners and your retrospectives are not catching it, that is the work we do. Book a call.

Sources and further reading

• Fischhoff, B. (1975). “Hindsight is not equal to foresight: The effect of outcome knowledge on judgment under uncertainty.” Journal of Experimental Psychology: Human Perception and Performance, 1(3), 288–299. DOI: 10.1037/0096-1523.1.3.288. (Origin of the hindsight-bias research.)
• Dekker, S. The Field Guide to Understanding ‘Human Error,’ 3rd ed. (Routledge). (Old view vs. new view of human error; the Bad Apple Theory; failure as systemic.)
• Kerth, N. (2001). Project Retrospectives: A Handbook for Team Reviews. (The Retrospective Prime Directive: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”)
• US Army. A Leader’s Guide to After-Action Reviews, Training Circular 25-20 (September 1993). Note: the AAR doctrine explicitly states it “does not grade success or failure” and is not a forum to assign blame.
• Behavioral interviewing / STAR method (Situation, Task, Action, Result): standard structured-interview practice, useful as the contrast case to the delta questions above.