Blame: Not as Important As Fixing What's Broken.

I'm sure you've often heard people ask not to 'Play the Blame Game' when an issue comes up during a project (or after a project has launched). Typically, they are two types of people: 1) people who feel the blame game would end very poorly for them and 2) people who are actually interested in solving the issue as soon as possible, and don't want to wade through the morass of figuring out who did it when making it not exist is the company/team/group priority.

Note, the two types of folks opposed to the blame game are not mutually exclusive.

Those invested in the blame game--who dive immediately into "who did this"--are 1) trying to figure it out so they can assign someone to fix it, 2) trying to figure it out so that it never happens again, 3) feel impotent because they can't fix it and finding who did this is something they can do 4)know exactly who did it and are trying desperately to push blame elsewhere for reasons of their own or 5) some combination of these things.

When dealing with an issue that results in some version of the Blame Game--either people deliberately asking not to play it and then playing it like crazy or folks invested in it for other reasons as listed above--you have to consider two main things: 1) Everyone involved needs to escape with their face intact (ie: not losing face) and 2) getting through the process (or skipping it if possible) as fast as you can so you can address the issue; as much as upper management may wish to know whom to crucify, they are twice as interested in knowing whom to hoist on their shoulders for leading them out of this calamity.

I like to do the following to step around the entire blame game and all the emotional and political investment within it: postpone it. Explain to everyone you can have a review or a post mortem or whatever you want to call it (I've always thought calling it a post mortem was too akin to investigating a death, which is not really what I want people to think of when they think of me and my projects) AFTER the problem is solved.

People who are scared (either because this is their fault or their afraid it will be blamed on them) will try to force the issue now. Some very well meaning people may wish to push the issue to "prevent it happening again." I liken it to a group of Girl Scouts in quicksand. Yes, putting up a sign that there is quicksand here will really help the next pack of scouts, but probably won't save the lives of the current girls slowly descending.

That said, if you have to do so, you can work with those folks who are alarmed and create an investigation of some sort to keep them happy and occupied. For example, my preferred method would be to talk to a senior dev and ask her/him to "investigate" how things happened, to appease those who are very concerned, and then work with the rest of the team to fix the issue immediately.

Investigations can also be highly useful for getting rid of people who are not actually helping. That is to say, when the Titanic sank, there were a lot of people squabbling about the iceberg and how to avoid it blocking the exits for other people trying to get off the sinking ship. Give those people something to DO. Put boundaries around their investigation, such as not being able to talk to the team until the issue is resolved, and spend some personal time with them (so they don't go looking to talk to the team, anyway) with some suggestions for future prevention that they can write up and "explore" with others.

You'll have to sell investigations to avoid a blame game, but you'll find it much easier to sell an investigation than to actually PLAY the blame game. Also, having an investigation in place while the team works to resolve the issue sounds very good in status reports to upper level managers anxious to find out what's being done NOW.

Now that the game is postponed, work to fix the problem. Offer amnesty to the entire team. It is your job to take it on the chin so they can get their work done, and this is one of those cases where you should do that. Anything they say will be kept within the team unless they agree otherwise. Let the team be honest and open with each other about mistakes, forgotten features, misunderstandings in implementation, unclear requirements, whatever. This honest is the fastest possible way to get the issue resolved. Be available to get them anything they need, from additional technical expertise to a product manager in the room to answer specific questions for them (but not actually grilling them on what they're doing or why this happened).

Resolve the issue. Note I did not say "fix." Fixing things often takes additional releases and external input. But triaging and resolving the immediate issue will make consumers, management, and the team happy.

Next step, face the postponed music. I like to gather the investigators and the team and have the investigators start by declaring their "findings." These are abbreviated to three or fewer bullet points on a white board. Then I put up the categories of "What Went Well?" "What could have gone better?" and "Action Items." If people want, I include a column for "Kudos."

We go through the "What went well?" category, drawing in investigatory findings as appropriate, and we follow that up with "What could have gone better" in the same way. Once folks feel they've got a good amount of stuff in both columns, we move to Action items and try to derive what next steps will be taken based on what went well as well as what went poorly, for the next version of the product and/or the immediate future of this resolution. Finally, I like to go over the Kudos column and end the meeting on a high note, celebrating team members, investigatory team folks, etc., for their work on SOLVING the problem.

Take all the notes from the meeting and pass them to all attendees and upper management. Post the action items where they can be seen/used for future versions.

Note this process completely avoids blaming anyone. If people try to pigeonhole in on that, drive them right back out. I like to say "It's not the people we are unhappy with, it's the behavior, so let's mark the behavior and not the people. Behavior is easier to change." This is where you protect the team to avoid finger-pointing and blaming. Even at this phase in the process, after the issue is triaged, blaming isn't helpful. Knowing which individual screwed up isn't as important as knowing how not to screw up again, and this review/post mortem/whatever you call it is going to help you not screw up again, with findings that reinforce that and can be shared with any and all involved...thus shutting down the blame game entirely.

In summary, avoid the blame game in all it's forms, postpone the blaming, include investigation to keep people busy (and out of your hair), protect your team and encourage honesty and cooperation, resolve the issue, face the postponed meeting music, and walk away with next steps to avoid this in the future. Above all: don't let any one person be blamed for anything. Its counterproductive and if you plan on working with these people again--which you probably will unless you immediately quit your job--its in your best interest everyone continues to get along.