Not Every Failure Counts Against You - MAC158

Two people walk out of two different meetings having heard the same sentence: it didn't work. One of them skipped a step in a process the company has run four hundred times. The other tried something the company has never tried. Same sentence, same tone in the room, same quiet adjustment in how each of them gets described in the next talent review.

That's the problem underneath this whole piece: your organization almost certainly cannot tell those two people apart. Not because anyone up the chain is cruel — because sorting the difference is genuinely hard and the meeting has twenty minutes. That failure to sort is expensive in a very specific, very avoidable way, and there's a fix that costs about ninety seconds and changes the entire conversation.

Three kinds of wrong

Before any of this is useful, the terminology has to be exact. Amy Edmondson, a Harvard Business School researcher who has spent a career studying how organizations handle things going wrong, lays out three distinct kinds of failure, and argues they need opposite responses.

A basic failure has one cause, is usually preventable, and happens in territory that is completely known — the invoice with last quarter's numbers, the wrong client name in the deck, the checklist step skipped because the day ran long. There's no mystery and no glory here. A basic failure needs a system, not a lesson.

A complex failure happens when several things go wrong at once and no single one of them would have caused the problem alone — the vendor slips a week, the reviewer is on leave, the requirements quietly changed in a meeting nobody wrote down. You don't eliminate complex failures. You build slack and make the pieces visible to each other.

And an intelligent failure is the one nobody teaches. Edmondson sets four conditions for it: it happens in genuinely new territory where no playbook exists; it's a credible route toward something that matters; it's informed by what you already know, not a wild swing; and it's kept as small as possible while still teaching you something.

An intelligent failure isn't a mistake. It's the price of information you couldn't have bought any other way.

I want to sharpen something I said in an earlier episode, Own Your Mistakes, Deliver Results (MAC-149). I stand behind most of it, but I treated "your mistake" as one category — a thing you step toward, own cleanly, and move past. What I missed is that a good chunk of what gets called your mistake was never a mistake at all. It was a bet. And owning a bet the way you'd own an error isn't integrity — it's a filing error, and you're the one who filed it.

Here's the distinction: a mistake is something you should have known. A bet is something nobody knew. Notice that has nothing to do with the outcome — both end in it didn't work. The difference sits entirely in what was knowable beforehand, which is exactly the information that disappears the moment the result is on the table.

The lane nobody is driving in

Most organizations respond to all three kinds of failure identically — not from cruelty, but because sorting them is slow and the meeting is short. So the org reacts to the outcome, the one piece of information everybody already has. Basic, complex, intelligent — same flinch, same footnote in the calibration room. I covered where that instinct goes once it's left alone in The Blame Game (MAC-099); what's happening here sits one step upstream of blame, in the sorting that never occurs in the first place.

People learn fast, and what they learn isn't "don't be careless." It's "don't be the person standing next to the uncertain thing." They stop volunteering for the ambiguous project. They stop floating the idea that would need a real test. I've watched this happen to people who were, on paper, the strongest performers in the room. None of them decided to become conservative — they just took the only signal the system was actually giving them: unpredictability is expensive.

That produces an empty lane. Almost everyone in your organization competes in the same place — flawless execution on known work — because that's where the incentives point. Meanwhile the genuinely ambiguous projects go undersubscribed year after year, carrying a risk everyone has correctly identified and nobody has learned to manage.

Everyone wants the person who takes smart risks. Almost nobody wants to be the person mid-risk. That gap is the opportunity, and it's not because risk-taking is inherently virtuous — plenty of people have torched a career on a wild swing they couldn't explain afterward. It's that the skill of running a bet well is rare, visible when present, and almost never taught. Being the person who can take the ambiguous project and give leadership a clean account of it either way is a method, not a personality trait — and the method is learnable.

There's a line I keep returning to on the show, from Seneca: luck is what happens when preparation meets opportunity. I built an early episode around it in A Little Bit of Luck (MAC-013), and returned to it in Posting Publicly (MAC-144) and Manufacturing Serendipity (MAC-147). In those episodes, the missing half was almost always opportunity — people preparing in private and waiting for a door to appear. Here the equation inverts. The opportunity is already staring you in the face: the empty, ambiguous project everyone else is avoiding. Standing next to it without the right preparation doesn't make you lucky — it makes you exposed. The preparation that matters here isn't another title or another hour of overtime. It's learning to run a bet cleanly, so that what looks like a lucky break to everyone else in the room is just preparation meeting the door nobody else opened.

There's a habit worth building alongside this. A Princeton professor once published what he called a CV of failures — the grants he didn't get, the papers rejected, the jobs he didn't land — and it traveled further than his actual research. The venture firm Bessemer keeps a public version, an "anti-portfolio" of the enormous companies they had a chance to invest in and passed on.

Keep your own private version. If you already keep the brag document from MAC-141 or the prevention ledger from MAC-155, this is one more column in the same file: what you bet, why it was reasonable at the time, what it cost, and what you now know that you couldn't have known any other way. The brag document records what worked. The prevention ledger records what never broke. This one records what you were willing to find out.

The stated bet

None of the above protects you on its own. Here's the mechanism, and it's smaller than you'd expect: the reason a bet gets processed as a mistake has almost nothing to do with the bet. It has to do with when you described it.

Picture the version most people run. You believe something will work, you spend six weeks on it, it doesn't work. Now you're standing in front of your manager explaining that this was always exploratory, that the outcome was uncertain, that you learned a lot. Every word might be true. It doesn't matter — you're saying it after the result, so it arrives as a defense, and a defense carries the smell of the thing it's defending against.

Run the same six weeks with one difference. Before you start, on the record, out loud, to whoever would have to approve it, you say: here's what I think is true that nobody here has tested, here's what result would tell me I'm wrong, here's when I stop. Six weeks later, the identical failure — but what you're delivering is not a defense. It's the answer to a question you both agreed to ask.

That's the whole move. I call it the stated bet, and the entire mechanism is sequence. Said afterward, it's an excuse. Said beforehand, it's a method.

Two pieces go into it. The claim: what you believe that isn't currently known, stated plainly enough that it could turn out to be wrong. "I think we're losing most of these renewals in the first two weeks, not at the contract date" is a claim. "I'd like to explore the renewal process" is not — it can't fail, which means it also can't teach you anything, and your manager can feel that even without naming it.

The stop is the piece people skip: what result, or what date, ends this. A stop condition feels like planning to lose, but it's what makes the whole thing affordable. Edmondson's fourth condition — keep it as small as possible while still learning something — is a stop condition in different clothes. Killing it in month two is a decision. Killing it in month nine is a casualty.

There's a technique that makes both halves dramatically easier, and it costs about twenty minutes. It comes from research psychologist Gary Klein and it's called the pre-mortem: before you start, you assume the thing has already failed completely, then work backward and list the reasons why. That framing — imagining the failure has already happened, rather than asking what might go wrong — surfaces meaningfully more of the real failure modes, and it does something else useful in a room: naming a risk starts to feel like insight instead of disloyalty.

Run the list and it hands you both halves of the stated bet. The failure modes you can prevent become the design of the thing. The one or two you can't prevent, but could see coming, become your stop conditions. And there's a side effect worth naming: when you walk into the approval conversation carrying a claim, a stop, and a list of the ways this dies, the question "what if it fails" has already been answered before it's asked. You didn't defuse that question. You brought it with you.

You don't get punished for the failure. You get punished for the surprise.

Where this actually lands

The difference between the two people from the opening was never the outcome. Both things didn't work. One was operating in known territory and dropped something; the other was operating where no map existed. That difference is completely invisible on the day of the result — which is exactly why it has to be established before there is one.

Your organization is not going to build that distinction for you. It doesn't have the time, and most of the people judging the outcome weren't in the room when the decision got made. What you can do is make the category impossible to miss: say the claim out loud, say where you'd stop, put both in front of somebody before you spend a single week. Do that, and the failure, when it comes, arrives pre-sorted.

Because the thing that ends careers was never being wrong. It's being wrong about something everybody assumed you already knew.

Get the Episode + Prompts

The full episode and show notes are at managingacareer.com/158. The prompts from the action plan are below — copy them, and change them to fit how you actually work.

Prompt — the sort. I'm going to describe three things at work that didn't turn out. For each one, classify it as BASIC (a known process done wrong, one main cause, preventable with care), COMPLEX (several factors that individually wouldn't have caused it), or INTELLIGENT (new territory with no existing playbook, a reasonable bet given what was known, kept small). Rules: if there was a known correct procedure, classify it BASIC even if I describe it sympathetically or emphasize the circumstances. Do not tell me what I learned — I didn't ask for the lesson, I asked for the category. Do not tell me any of these were good ideas. If my description doesn't contain enough information to classify it, ask me one question instead of guessing. Here they are: [describe them].

Prompt — the pre-mortem. Here's something I'm considering proposing at work: [describe it, including what I'd be testing and roughly how long it would run]. Assume it has already failed completely. List the plausible reasons why, then sort them into (a) failure modes I could design around before starting and (b) failure modes I couldn't prevent but could detect early. Rules: prioritize boring and likely over dramatic and unlikely. Exclude anything I could only discover after it's too late to act on — those are useless to me here. Do not include generic risks that would apply to any project; every item should be specific to what I described. Do not evaluate whether this is a good idea.

Prompt — the draft. Turn the following into one short paragraph I could say out loud to my manager before starting: a claim that could turn out to be false, and an explicit stop condition (a date, a number, or an observable signal) that would end the work. Here's the raw material: [paste your idea and your pre-mortem list]. Rules: write it so a skeptical manager could reasonably say no to it — do not sell it, and cut any adjective that's doing persuasion rather than description. The claim must be falsifiable; if what I've given you can't fail, tell me that instead of rewriting it into something vaguer. If I haven't given you a specific number or date for the stop condition, ask me for one — do not choose one for me. Do not tell me this is a good idea. I didn't ask.

Links & References

• Research & sources — The Three Types of Failures: Basic, Complex and Intelligent
• Research & sources — Intelligent Failure Is the Right Kind of Wrong: Amy C. Edmondson
• Research & sources — The Pre-Mortem Method of Risk Assessment — Gary Klein
• Research & sources — The CV of Failures
• Related Managing A Career episodes — Own Your Mistakes, Deliver Results (MAC-149)
• Related Managing A Career episodes — The Brag Document (MAC-141)
• Related Managing A Career episodes — The Prevention Ledger (MAC-155)
• Related Managing A Career episodes — Just Because You're Scared, Doesn't Mean You Do NOTHING (MAC-123)
• Related Managing A Career episodes — The Blame Game (MAC-099)
• Related Managing A Career episodes — A Little Bit of Luck (MAC-013)
• Related Managing A Career episodes — Posting Publicly (MAC-144)
• Related Managing A Career episodes — Manufacturing Serendipity (MAC-147)

TAKE THE SURVEY!

Are you looking for a career coach? If you reach out to me via the contact form, I will arrange an introductory session where we can talk about your career goals and how I can help. If we're a good fit, we can schedule regular coaching sessions.