How NOT to Handle a Crisis
I grew up in a quite harsh environment. Unfortunately, street mugging, fights and some other ugly things were normal. Once bunch of my friends and I got stopped by a group of people who did not intend to just make friends with us. While some of us tried to solve the snafu diplomatically, the others were either silent or started panicking or were ready to fight back if things went further south. A friend of mine, let’s call him Russel, who was trying to sort things out, was acting quite provocatively and it seemed that he was actually escalating the conflict instead of resolving it. Some others at least might have felt so. So some of us tried to placate and silence him or told him how what he was doing was definitely not helping.
In the end, things worked out well for us and it was actually Russel who somehow turned the situation around. And then, after everything was over, he said something that made me realize a very important principle about crisis resolution: “guys, when we are in trouble and shit is hitting the fan, let’s first deal with the problem as one and only afterwards start figuring out what is wrong and what is right”.
Always separate Problem Solving from Retrospection and Prevention
These are two different stages of crisis handling. When the problem arises, the whole team should stand as one and address it with all the attention and resources at hand. And only afterwards you should discuss the problem and its causes rigorously in your next retrospective meeting (even if you are not using SCRUM, you do some sort of retrospective, don’t you?!).
During one of the projects I worked on, a developer merged the code that broke a quite important feature of the website. The code had been reviewed and tested, but this dependency had slipped unnoticed. What made the matter worse is that the only person who could revert to the older version left the office earlier. And it was Friday.
While some of the developers jumped into understanding what broke, there were a few people exchanging messages in a team skype chat about how this could have happened in the first place. One of the product managers even instantly came up with a few new rules and processes for the future. This whole conversation was running in parallel to the efforts of the developer who released the buggy code and a few others trying to solve the problem. Afterwards this very developer told me that what happened in the chat made her feel uncomfortable. It nailed her attention to feeling guilty rather than fully concentrating on getting the bug out of the way.
Eventually we fixed the bug. But the way the problem was perceived and handled by the team missed the very important rule of separating problem resolution stage from feedback and process repair stage. It would be much more effective if developers first fixed the bug and product owners and other managers stood out of the way and let the team do the work no matter how badly their souls were aching for their product.
To sum it up: Crisis management must be a team effort. And this effort should be broken down into two bigger stages — problem handling and problem debriefing. Combining the two is like sending a firefighter to inspect a burning house to investigate the reasons of combustion. When I make a mistake, I feel bad anyway. There is no need for anyone to point at it. I believe the same way goes for everyone. The more effective way of helping me (or anyone else) cope with it is to let me fix it and only then discuss as a team about what to do in the future to avoid facing similar situations.
