Monday, September 22, 2008

Assigning Blame

Blame is a funny thing.

It's pretty common, particularly in startups, to hear statements made that try to avoid blame entirely:

"Fault doesn't matter; we're not here to blame each other. We just all work together to get it done. After all, that's what's important."

As soon as you hit a really hairy situation, though, or the company grows, blame starts happening under the surface. Oh, sure, "blaming others is a waste of time", but it happens anyway.

So that leaves us with two questions:
  1. How do I know when blame starts to matter?
  2. What do I do about it?
Before we address whether we have blame and what to do about it, let's step back and talk about some of our assumptions going into it:
  • Blame is something we can avoid. We're all friends here. Actually, blame is a pretty inherent trait. Even Koko the gorilla blamed things on others (scroll down), as do children just learning to communicate. It's not something we really outgrow.
  • Blame is inherently bad. If you think about it, root cause analysis is really assigning blame within a software system. Blame there is great - "hey, we found it!". The same thing applies to humans. Blame is good if it provides insight into why a problem happened.
  • Blame helps it not happen again. Yes and no. If blame is found rather than assigned, then it can help figure out what went wrong (and preventive measures can then be implemented). Self-defensive blame isn't productive, though, and can hide the underlying problem.
So we've established that blame is going to happen, and that it can be productive but isn't necessarily productive. So the real question to ask ourselves is not whether there is blame (because most of the time, there is!) and what we can do to avoid it. The real question is whether that blame is productive. Let's swing back around to our questions from earlier.

How do I know when blame starts to matter?
Blame happens. Sometimes it's a very personal background thing (e.g., "Shoot! I logged a duplicate bug! How did I miss that one?"), and sometimes it can extend much further.  It starts to matter when it:
  • starts taking up time
  • is unresolved or unsatisfactorily resolved
  • causes working relationships to break down
Blame doesn't always have to be addressed. Only when it starts to matter does it need to be handled explicitly.  Blame isn't always obvious. Rarely in an average organization do you find an employee stalking the halls declaiming loudly that, "Shelia did it!" Instead, you have to look for the signs that blame is simmering underneath the surface:
  • meetings start coming out with much more detailed meeting notes and action items that so-and-so committed to such-and-such
  • you find people being talked about and hear second-hand
  • your boss starts asking you what the real story behind XYZ is
  • your subordinates start asking you what the real story behind XYZ is
  • previously informal conversations turn into emails or meetings
The goal of handling blame should always be to preserve working relationships and resolve the issue. Think of it as root cause analysis for the corporate system (rather than your software system).

What do I do about it?
Once we've identified that blame is going on and is starting to consume a company's time, it's time to do something about it. Specifically what you do will vary greatly depending on your position in the organization - the higher up you are the more rarely you should get involved, but the more effective you can be in finalizing a situation. That being said, there are always some things you can do:
  • Get the whole story. You may or may not know what incident(s) occurred, but get the whole story from several perspectives quietly before you attempt to do anything.
  • Study your own behavior. You or your team may have the blame here, or at least share it.
  • Figure out if it's productive or spinning. If blame assignment is really problem cause analysis, the best thing you can do is nothing. Let it work itself out. If it's going nowhere, that's when you have to step in.
  • Solve the problem, not the person. In all likelihood, the people involved have a lot of pride in their work, and don't like to screw up, much less be pointed out as being at fault. Make sure that any blame assignment centers on the problem, not the person or group. Talking about blame in terms of process rather than in terms of individual names can help.
  • Assign multi-fault. Just like many software issues have proximate and underlying causes, so do corporate incidents. Sure, maybe the proximate issue is that support restarted something they shouldn't have. But the underlying cause may be an issue with an outdated procedure, or a change that dev should have made to make that kind of restart safer or even unnecessary. When groups or teams share the blame, then they don't get out of balance - it's easier to move on when everyone took a little bit of the blow.
  • Change the tone. The tone of the conversation should not be "to assign blame". Rather, the tone of the conversation is "to find the root cause and contributing causes of the issue". 
  • Close it out. Once the problem is identified and addressed, don't mull over it. Part of your job is to simply not bring it up again; the issue is in the past and dwelling will only create resentment. Keep it in the back of your mind, in case of recurrence, but never tolerate the situation being flung in someone's face in a future situation. The words, "Well, you messed it up last time" should be reprimanded quickly and firmly.

No comments:

Post a Comment