How to talk about failure in a culture that punishes it

In a culture that punishes failure, do not start by asking people to celebrate it. Start by changing the words and the format: talk about tests and what they showed, separate the kind of failure that deserves a review from the kind that deserves a fix, and review the decision, not the person. When the first honest conversations are small, structured and protected by a senior person, the culture starts to shift without anyone being asked to be brave.

Why "celebrate failure" backfires

Posters and slogans about failure are common in organisations that still punish it. Staff notice the gap immediately. A leader who says "it's fine to fail" and then asks "who approved this?" at the next setback has taught everyone the real rule.

There is also a fair objection. Some failures should not be celebrated. A missed safety check or a careless error in a payment run is not a learning opportunity to applaud. Amy Edmondson, the Harvard professor best known for her work on psychological safety, draws a useful line in Right Kind of Wrong (2023). She separates basic failures (errors in well-understood work), complex failures (several small factors lining up in a complex system) and intelligent failures (a thoughtful test in new territory that did not work out). Only the last is something to seek out. The first two are to be prevented and learned from.

Once you make that distinction out loud, two things happen. People who fear being judged for real mistakes are reassured that standards still apply. And people running new tests are given permission to report results honestly, because a negative result from a well-designed test is a good outcome.

Seven steps to start talking about failure

1. Change the vocabulary before you change the culture

Words carry consequences. "Failed project" lands on a person. "Test that showed this approach does not work" lands on the evidence. Use language like test, hypothesis, what we learned, what we will stop. Write a hypothesis test before work starts, so that a negative result is one of the two outcomes everyone agreed in advance, not a surprise.

2. Name the type of failure every time

Before discussing a setback, ask: was this a basic error, a complex breakdown or an intelligent test? The answer changes the conversation. A basic error needs a fix to the process. A complex failure needs a look at the system, using five whys or a fishbone analysis. An intelligent failure needs a short record of what was learned and a decision on what comes next.

3. Review the decision, not the person

The question "who decided this?" creates silence. The question "what did we know when we decided, and was it reasonable?" creates learning. Good decisions can lead to bad results, and bad decisions sometimes get lucky. Separate the two. The US Army's After Action Review, widely borrowed by other organisations, uses a simple frame that keeps the focus on events: what was supposed to happen, what actually happened, why there was a difference, and what we will do next time.

4. Start with small, low-stakes reviews

Do not start with the most painful project of the year. Run a short retrospective after an ordinary piece of work, where the stakes are low and nobody's reputation is on the line. Practise the format until it feels normal. Then use it on bigger things.

5. Have the most senior person go first

In a punishing culture, the first honest admission must come from the top. Ask the sponsor or director to open a review by describing one decision of their own that did not work and what they took from it. Keep it short and real. This does more than any number of policy statements, because it shows that admitting a mistake does not cost status.

6. Talk about failure before it happens

A premortem asks a team to imagine that the project has failed a year from now and to list why. It makes it legitimate to talk about failure while it is still hypothetical and nobody is to blame. Teams that have done a premortem find it easier to report a problem later, because they named the risk together at the start.

7. Protect the people who report bad news early

Watch what happens the first time someone reports, early, that a test is not working. If they are thanked and the decision is made quickly, others will follow. If they are questioned about why they did not succeed, nobody will report early again. Leaders should make a point of saying publicly: "You told us early. That saved us time and money."

How to present a failed project to management

When you must report a setback upwards, use a short, fixed structure:

1. What we set out to test, in one sentence.
2. What we expected, including what we said would count as success.
3. What happened, with the evidence.
4. What we learned that we did not know before.
5. What we recommend now: stop, change or continue, with a reason.
6. What it cost, honestly, and what it would have cost to find out later.

Lead with the recommendation if your audience is senior. Bring evidence from users, not opinions. Do not apologise at length; it shifts the conversation to blame. Our article on how to stop a project well covers the decision side.

Worked example (Illustrative)

A water utility in Portugal ran a six-week pilot of text-message reminders for customers with overdue bills. Payments in the pilot area did not change. The project lead, worried about her annual review, drafted a report that described the pilot as "partially successful" and recommended a longer trial.

Her director asked for a different conversation. He opened the review by mentioning a billing system change he had pushed through two years earlier that had to be reversed. Then the team walked through the pilot using the four After Action Review questions. They found that most overdue customers in that area were not on mobile contracts the utility could reach, which nobody had checked. The pilot itself had been well designed and cheap; the assumption about reach had been wrong.

The recommendation changed from "extend" to "stop, and test reach first". The director thanked the team in the monthly operations meeting for finding the problem in six weeks rather than after a full rollout. Two other teams asked to use the same review format that quarter.

Do's and don'ts

Do

• Distinguish basic, complex and intelligent failures out loud.
• Agree what counts as success and failure before a test starts.
• Ask senior leaders to share one of their own setbacks first.
• Thank people publicly for reporting bad news early.
• Keep reviews short, regular and focused on decisions and evidence.

Don't

• Don't put up "celebrate failure" posters while people are still being blamed.
• Don't treat careless errors and thoughtful tests the same way.
• Don't open a review with "who is responsible?"
• Don't dress up a negative result as "partially successful". It trains everyone to stop believing reports.
• Don't wait for the big failure to start practising. Start with small reviews.

Questions people ask

How do you overcome fear of failure at work? Make it safe in small steps: agree success criteria before a test, review decisions rather than people, and have leaders share their own setbacks first. Fear drops when people see that honest reporting is rewarded, not punished.

How do you change a blame culture? Change what happens after a setback. Use a fixed review format focused on what happened and why, protect people who report early, and make the distinction between careless errors and intelligent tests clear. Slogans do not change blame cultures; consequences do.

Is it ever right to punish failure? Accountability still applies to negligence, rule-breaking and repeated careless errors. What should not be punished is a well-designed test that produced a negative result. Making that distinction explicit protects both standards and learning.

Where to go next

The guides behind these steps are retrospective, premortem, hypothesis test and five whys. For the wider culture, read innovation culture: what it is, and how leaders actually build it and psychological safety in innovation teams.