Something Christian “Boo” Boucousis said during our recent conversation on The Unfolding Thought Podcast has been sticking with me: fighter pilots debrief everything.
They debrief good missions. They debrief bad missions. They debrief missions interrupted by weather or equipment problems. They do not wait for something dramatic to go wrong, and they do not assume that doing the work again means they learned from doing it the first time.
Most businesses do.
Think about a project that did not go as planned. Maybe it was a marketing campaign that did not produce enough qualified leads. Maybe a product launch was late. Maybe a good employee left, a client relationship deteriorated, or a strategy everyone liked never produced the expected result.
What normally happens next?
People explain. The audience was wrong. Sales did not follow up. The client changed the brief. Someone missed a handoff. The market shifted. We did not have enough time. The technology did something strange.
Any one of those explanations might be true. Several might be true. But, more often than I think most leaders would like to admit, the explanation is accepted because it is plausible, not because anyone really tested it. The meeting ends, everyone goes back to work, and a few months later the organization encounters a suspiciously similar problem wearing different clothes.
That is experience. It is not necessarily learning.
Experience is only evidence. It becomes learning when it changes what you do next.
Most companies repeat more than they iterate
Businesses like to say they are iterative. Agile companies work in sprints. Marketing teams run experiments. Product teams release versions. Leaders collect metrics and talk about continuous improvement.
But repetition and iteration are not the same thing.
If you run the next sprint with the same assumptions, incentives, decision rights, and behaviors, you did not iterate. You just started over. If you collect customer feedback, put it in a report, and then proceed with the plan everyone already preferred, you did not close a feedback loop. You documented feedback.
Boucousis makes a useful distinction between speed and velocity. Speed is movement. Velocity includes direction. A business can answer emails faster, create more content, ship more features, and hold more meetings while moving very quickly in the wrong direction.
This is one reason a good debrief actually begins before the work. You need to know what you are trying to achieve well enough for reality to disagree with you.
“Launch the campaign” is not a useful objective. That is an activity. “Create 40 qualified sales conversations from this audience without taking acquisition cost above the level we agreed upon” is an objective. It gives you a result to compare with an intention.
The same is true of meetings, hires, technology implementations, and nearly everything else. “Install the CRM” tells you what people will do. It does not tell you what should be different when they are done. Without that difference being made explicit, the team can complete every task, celebrate the launch, and still have no reliable way to know whether the work was worth doing.
We explain results before we understand them
Human beings are very good defense attorneys for our own decisions.
When a result is poor, circumstances were difficult. When a result is good, our strategy was smart. We might not say it that bluntly, but most of us can find a story that protects what we already believed about ourselves, our teams, and our choices.
This is not because everyone is dishonest. It is because the story arrives almost immediately. We experience the result through our own expectations, identities, incentives, and incomplete view of what happened. By the time the meeting begins, each person might already have a different version of reality.
The Plan-Brief-Execute-Debrief model Boucousis uses tries to slow that down with four questions:
- What was the objective?
- What result actually occurred?
- What caused the difference?
- What action will change before the next attempt?
The sequence is important. Start with what you intended. Then describe what happened before explaining it. Otherwise, the explanation has a way of changing the standard by which the result is judged.
You have probably seen this. A team misses its revenue goal, but the conversation quickly shifts to how much awareness the campaign created. A project is late, but everyone focuses on how much they learned while building it. A new system is barely used, but the implementation is called a success because it went live.
Awareness, learning, and launching might all be valuable. They are not substitutes for the result you said you wanted before the work began.
This is also why success needs to be debriefed. Success is much easier to accept and therefore easier to misunderstand. A good result can hide a bad process, an unrepeatable advantage, a near miss, or an assumption that happened not to hurt you this time. Research on after-event reviews found that people who examined successes and failures improved more than those who reviewed failures alone.
If the campaign worked, you still need to know why. Otherwise, you may take the wrong lesson from it and confidently repeat the part that mattered least.
This is not an excuse to avoid accountability
Whenever a conversation turns toward systems, context, and root causes, someone worries that personal responsibility is about to disappear. If everything is a system problem, can anyone ever be held accountable?
Of course they can.
A person may have ignored evidence, violated a standard, failed to prepare, or simply not done the job. A leader may also have created incompatible incentives, withheld information, assigned responsibility without authority, or punished someone the last time they raised an uncomfortable issue. Both can be true.
The point of a debrief is not to make responsibility disappear. It is to make responsibility more accurate.
Most organizations use accountability too late. They invoke it after the result, when everyone is looking for the person who should own what went wrong. Real accountability starts before execution. It requires a clear objective, an owner, visible constraints, agreed evidence, and the ability to question the plan before everyone commits to it.
It also requires people to be able to say what actually happened.
If telling the truth about the work is dangerous, the debrief is theater.
Boucousis describes debriefing as nameless and rankless. I like the intention, but rank does not disappear because the highest-ranking person says it has. Everyone watches what happens to the first person who contradicts the leader, admits an embarrassing mistake, or says that the favored strategy did not make sense.
If that person is humiliated, interrupted, ignored, or quietly punished later, the organization still learns a lesson. It is just not the lesson the leader intended. People learn that protecting the story is safer than examining the result.
Psychological safety sometimes gets described as making everyone comfortable. That is not how I think about it. It is what makes productive discomfort possible. Research on debriefing and psychological safety connects it with speaking up, sharing information, and learning from errors. Safety makes the evidence available. Accountability makes the evidence matter.
Root cause can become too neat
A few years ago, I wrote about how businesses tend to self-diagnose and then go straight to a specialist. Revenue is down, so the company decides it has a website problem and hires someone to build a new website. Six months later, the website is new, the underlying problem remains, and everyone is looking for the next solution.
A debrief should help with this, but only if people resist the desire for an explanation that feels cleaner than reality.
Organizations like a single root cause because a single cause creates a sense of control. The campaign failed because the offer was weak. The product was late because one team missed a handoff. The client left because the account lead did not communicate.
Maybe. But complex outcomes usually emerge from several conditions interacting with one another. A weak offer might have worked with a different audience. A missed handoff might not have mattered if the project had enough slack. Poor communication might have been recoverable if months of inconsistent delivery had not already weakened the relationship.
The goal is not to make the past look inevitable. The goal is to improve what the organization believes before it acts again.
Sometimes that means ending the debrief with, “We do not know yet.” I would rather hear that than a confident story supported by little evidence. “We do not know whether the audience or the offer was the primary constraint, so our next test will separate them” is a useful conclusion. It turns uncertainty into a better next action.
This is where red teaming can help. The red team is not there to complain or to make the meeting more dramatic. Its job is to ask what would make the preferred explanation false, which assumptions the next plan depends upon, and what an outsider might notice that the team has learned to ignore.
AI will make the learning problem more obvious
AI lowers the cost of doing things. We can produce analysis, copy, code, plans, reports, experiments, and variations much faster than before.
That sounds like an unqualified advantage until you remember that organizations already have trouble learning from the amount of work they do now.
When production becomes cheaper, the bottleneck shifts. Judgment, attention, and organizational memory become more valuable because the business now has more actions, results, and explanations to sort through.
AI can help an organization remember. It can also help the organization repeat a bad explanation much faster.
AI can compare a stated objective with the reported result. It can find contradictions across accounts, identify causes that recur across projects, retrieve a prior lesson during planning, and red-team a proposal before reality does it for you. Research systems such as Reflexion have even shown that an AI agent can use feedback, create a reflection, retain it as memory, and improve a later attempt.
But storing a meeting transcript is not the same as creating organizational memory. A report is not intelligence simply because it contains more information. The lesson has to show up when someone is about to make a relevant decision, and it has to change what the person or system does.
AI also cannot decide which purpose is worth pursuing, which tradeoff is acceptable, or whether a local success damaged the larger system. If the destination and values are vague, AI can help you move faster without helping you move in a better direction.
What I would actually put in a debrief
I do not think every project needs a long, ceremonial meeting. In many cases, 15 focused minutes would be an enormous improvement over the hour-long status meetings people are already attending.
I would make the team answer these questions:
- What did we intend to change? Not what did we intend to do. What effect were we trying to create?
- What actually happened? Describe the result before anyone explains it.
- What evidence supports our explanation? Separate what we know from what we think.
- What else could explain the result? Give someone permission to challenge the explanation everyone prefers.
- What will we do differently next time? Name the action, the owner, and the condition that should trigger it.
- Where will this lesson live? Put it somewhere the next person will encounter it before repeating the decision.
- When will we find out if we learned the right lesson? The corrective action needs its own review.
That final question matters. A corrective action is still a hypothesis. It might be reasonable and still fail. If no one checks, the organization can turn a mistaken lesson into a new standard operating procedure and call that learning.
What changed because of the conversation?
The advantage is not simply moving faster. It is learning faster.
A business with a high learning rate does not need every decision to be right. It needs wrongness to become visible, discussable, memorable, and useful. It needs leaders who can tolerate evidence that complicates their own story. It needs success to be examined instead of merely celebrated.
When the debrief is over, ask one last question: What changed because of this conversation?
If the answer is nothing, you had a meeting. You did not debrief.
This essay develops ideas from my conversation with Christian “Boo” Boucousis, CEO of Afterburner and a former Royal Australian Air Force fighter pilot. Watch or listen to “Why Fighter Pilots Debrief Everything” on The Unfolding Thought Podcast.
