Originally coined by Wired Magazine’s Gareth Branwyn, blamestorming is meeting to discuss why something went wrong (a failed project, a missed deadline, a PR mess, a tech disaster) and who is responsible. In blamestorming, “who is responsible” is the real focus.
This is an example, courtesy of the Urban Dictionary:
I just got out of a three hour blamestorming session with IT about the server failure last week; Someone’s going to end up in unemployment over this.
What a waste of everyone’s energy. When you assign blame, you act to protect yourself at the expense of another. In most workplaces, there’s rarely one person or department to blame for any significant problem and trying to find one is a signal of poor problem solving.
Instead of blamestorming next time something goes wrong, spend your energy thinking about the contributions that many people or departments probably made. Individually, those contributions may have had little impact, but collectively they created a problem.
For a sad example of from this week’s news, consider the crash of Comair Flight 5191 in Lexington, Kentucky. Initial information suggests a confluence of errors, any one alone of which may not have resulted in disaster. Together, they took 49 lives. Is it really helpful to identify the one person or organization for primary blame? How will correcting that one error prevent a confluence of the other errors in the future?
You’ll find that the shift from blame to contribution, once you’ve proved that’s really how you want to work, motivates creativity, personal responsibility and, better yet, joint problem solving. Blame just builds defensiveness, anger, denial and avoidance.
Let go of the blame game.
