After a setback occurs, you have two choices: blame someone, or get wiser. Executive coach Alisa Cohn explains why it’s important not to point fingers or shut down and never mention the fiasco again—tempting as that may be. Instead, it’s critical to run a disaster debrief. By reframing the conversation as a ‘learning lab’ it can help defuse tension and build a stronger team that has found and fixed its weak spots. What is the key to running an excellent debrief after a failed project or difficult delivery? Using an example, Cohn explains why working down the multiple tiers of “why?” is so powerful when you’re trying to learn actionable lessons from failure.

Alisa Cohn: The thing about building a company is that inevitably things go wrong, and bad things happen.

You don’t want that to happen, you don’t anticipate when that happens, but it is inevitable in the lifecycle of any company.

When that happens the best way to react to that is to use it as a learning lab. Use it as an opportunity to call everybody together and really have a laboratory, have a workshop, have an understanding of: how do we unpack what happened and why it all happened with no blame but with understanding of the systems that got us here, and then how do we think about how do you respond right now together, and then how do you move forward from there, both in terms of establishing maybe new procedures, establishing some new policies, some even new ways of thinking, some new operational tactics, but then also this is equally important, how does the company and the CEO and the team around him or her successfully move on emotionally, kind of create a new point of view recognizing that that was in the past and there’s the future to look too? You can’t change the past, you can only change the future.

So the best way to debrief any bad thing that happened, any problem is just to go down the tiers of “Why.”

And so you start with—so let’s assume that the project that you’re working on is late, let’s assume it’s a product release, and that it is now definitely not going to make its deadline, and it’s probably three or six months late.

First of all it’s important just to create an environment where people can talk freely and not feel blamed, because we’re just debriefing to understand what happened.

So it’s about understanding the structure of it not looking to finger point.

But the first question is, why? So why was the release late? Well, engineering, for example, didn’t deliver the code on time.

Why didn’t engineering deliver the code on time? Because they weren’t given the specs early enough. Why weren’t they given the specs early enough? Because product didn’t get them to them early enough. Why didn’t product to get them to them early enough Because product didn’t understand from marketing the requirements early enough.

So if you keep going down those and you understand why did marketing not get them early enough, it’s because they didn’t have a good plan to get the customer data they needed to, then you can take a look at what went wrong here.

Is it about we need to tighten up our process (which is very often true, especially with startups)?

Is it that we need to have a better timeframe for deliverables (which is often very true when you’re working on complicated multi-domain projects)? Or do we just forecast incorrectly? Did we not take into account all the multiple steps that leads to the product release, and that’s often very true as well? And maybe why didn’t we take into account the multiple steps? Because there wasn’t one person in charge.

Great. So going forward we know that we need to all take into account the multiple steps, and declare one person the owner of the project overall, and let’s try those two interventions, those two changes, and that’s going to help us have more excellence in operations.