Fear is good if there's a tiger in the room. Not so good if there's a bug in the software.

From time to time, emergencies will arise. Maybe a serious production defect will show up, leading to a bunch of things going wrong. Maybe whoever was handling a problem let it go too long before getting help. Maybe the customer is in a panic and everyone is starting to run around in fear.

The trick is this: pretend you aren’t afraid.

Get some blank cards, or go to the whiteboard. Pretend you aren’t afraid.

Get everyone to gather around. They probably will, anyway, because they want to know why you aren’t in a panic like you should be. Pretend you aren’t afraid.

Erase a big chunk of whiteboard if you’re using it, or clear some space on the carding table. Keep pretending you aren’t afraid.

Just start asking questions. Write the answers on the whiteboard or the cards.

Ask the team what happened. Identify the symptoms of the problem. Let people talk, but don’t let them go on too long. Be sure you get the facts (there are always a few) before going on to causes and solutions. Write each symptom on the whiteboard or on a separate card. Don’t blame, don’t complain, and above all …

Keep pretending you aren’t afraid. If other people are acting less calmly, just let your calmness wash over them. Ask them to just wait a moment. Focus your questions on the people who are responding calmly.

Now work on causes, briefly. Sometimes causes are really known; more often they are not. Allow people to speculate. For each speculation, ask a followup question: how could we find out whether that’s what happened? Make a note of the answer nearby on the whiteboard, or on the same card.

When the causes die down, work on action steps. Ask the team what steps might need to be done. Accept all ideas, and make sure you get them all. Note that action steps include determining what has gone wrong as well as fixing it. If there are still hypotheses outstanding about what’s up, define the steps needed to be sure. And get down the repair and recovery steps as well.

Then, for each action, go back and note when it needs to be done. You’ll generally find that some things need to be done right away, but some can wait for hours or days. Even some of the diagnosis steps can often wait: you might need to know what form the database damage takes immediately, but you don’t need to know what caused it until the next time you run that job. Mark the action steps H, M, L depending on their priority.

Now, get people to sign up for the H tasks, and some of the M tasks if people and priority make that possible. It’s usually best to have pairs take on tasks in times of stress. Remember, the monsters always get you when you split off from the group. Ask folks to report back to the group whenever they learn something. Make sure everyone understands that everyone is interested. Keeping the information flowing will help everyone stay calm.

By now, everyone should have something to do, even if it’s just to go back to their normal work. Everyone should be pretty calm, and working on a mission. And it all happened because you pretended you weren’t afraid.

During the recovery, whatever task you picked up, try to keep an eye on everyone. Some folks will need a new dose of calmness. Drop in and give it to them. Get small groups, or the whole group, together whenever it’s needed.

Modify this process to deal with any situation. There are only three key steps:

  1. Pretend you aren't afraid.
  2. Get everyone to brainstorm and prioritize what needs to be done.
  3. Pretend you aren't afraid.

It’s just like iteration planning, except in iteration planning you really aren’t afraid.