“Blame & Shame” is Shameful

20
18

Many leaders in healthcare (including John Toussaint, Paul Levy, and others) are working to eliminate the “name, blame, and shame” culture that often exists in hospitals. This push (in my mind) started with W. Edwards Deming, who taught that 94% of problems are caused by the  system, and continued to the modern patient safety movement, which also teaches a systems-based view of what's needed to  prevent errors, not just punish an individual after the fact.

With a hat tip to Patrick Vlaskovits, I saw this post online, related to software development:

My boss decided to add a “person to blame” field to every bug report. How can I convince him that it's a bad idea?

My short answer would be: “You probably can't.” Does a blaming leopard change its spots?

There were a lot of great comments, mainly from programmers and developers who seem to understand systems better than many of the managers do.

The poster of the question added:

My arguments that this will decrease morale, increase finger-pointing and would not account for missing/misunderstood features reported as bug have gone unheard.

Adding “who” to blame doesn't seem like a move that would increase teamwork or improve morale in any setting. Is a software defect something that's truly an individual error, or, like healthcare, are the results of a system the result of all of the interactions and different moving pieces and processes? Not being a software developer, I wonder, though, if Dr. Deming's 94% principle would still apply… maybe 6% of bugs are caused by a sole person's individual error?

The default view of blaming managers seems to be that an individual is the root cause of a problem unless proven otherwise.

I think the more correct view is to assume it's the  system unless proven otherwise – whether it's a software bug or a medication error.

I'd also predict, in a software setting, that the number of reported bugs would go down in a “shame and blame” culture… mirroring the underreporting of medical errors in such cultures.

I'm also reminded of Eric Ries, who is trying to change the blame culture in startups. From his book The Lean Startup  (see via google books):

Anyway, check out the discussion there and I'm curious to hear your comments about “shame and blame” cultures and any steps you've been able to take to reduce it in your  organization.


What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.

Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.


Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:

Get New Posts Sent To You

Select list(s):
Previous articleRadio Story (KOMO, Seattle) on “Healthcare Kaizen”
Next articleSan Diego’s Big Batch of Fireworks – At Least Nobody Was Hurt
Mark Graban
Mark Graban is an internationally-recognized consultant, author, and professional speaker, and podcaster with experience in healthcare, manufacturing, and startups. Mark's new book is The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation. He is also the author of Measures of Success: React Less, Lead Better, Improve More, the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, and the anthology Practicing Lean. Mark is also a Senior Advisor to the technology company KaiNexus.

18 COMMENTS

  1. Great Post Mark,

    In my opinion this is one of the most crucial parts of a culture change that must occur for Continuous Improvement to happen. My question for you is this. Once you have Managers convinced to not search for blame and instead use root cause analysis and 5 Why’s to find the root of the issue, how do you coax employees to participate.

    I find that even long after managers change, employees will still resist drilling to root cause and will fight tooth and nail to “prove” that they weren’t at fault and “prove” that the problem was unavoidable.

    Any thoughts on reducing employee defensiveness? How do we switch attitudes to accept that for most problems we do have control of our own destiny?

    • Marty – thanks. I think reducing employee defensiveness (or fear) requires leaders to demonstrate that they can be trusted. Trust can’t be built overnight (although it can be eroded pretty quickly).

      I think employees (or managers) working to prove they aren’t at fault or that the problem was “just bound to happen” (said a lot in healthcare), then it traces back to culture and culture is really (I think) the responsibility of top management.

      If the employees aren’t participating, I think you can’t blame the employes for being bad people… look at the system. Management owns the system (which is different than saying I “blame” management).

      • Sure, I totally agree this is a culture issue, and culture is owned by top management. But what specifically would you say would be the top three actions Senior Management should do to start to move the train around to reduce defensiveness? I know cultural change is a lot of little things, but would you suggest should be the first three steps?

  2. I have mixed feelings about this. On the one hand, it’s pretty well established that blame and shame doesn’t work. Yet, in a manufacturing environment, we track defects to production assets, to identify where we might best need to focus resources.

    Isn’t a coder analogous to a manufacturing asset?

    If we see that a high percentage of bugs stems from one individual or team, might that point us to ask whether the right tools and/or information is available for that team?

    Perhaps we go to the gemba and find out the team with the highest number of bugs is maintaining legacy code, or working with a new API that is not properly documented.

    I don’t necessarily see anything wrong with collecting the data. Unless, of course, if it is used to, e.g., determine who gets the lowest performance rating this year.

    • I think it’s fine to collect data to see *where* defects are occurring in the code and which team was involved (it seems programming is more of a team endeavor these days, which makes the blame thing even more dubious).

      It’s a matter of what you do with the data. Are you looking to improve the system (as Eric Ries writes about and I advocate for) or are you looking to just blame and punish?

      If I were running a hospital, data about which units had the most medication errors would be very helpful for the sake of improvement. As I’ve said before, data is for improvement, not for punishment.

    • If there is a higher errors from a single individual, he is either not trained for the job or your systems in place are not strong enough to find errors quickly or there was a hiring mistake. In good software development environments, you have multiple levels of safety nets(review/testing at various levels) that errors made by an individual doesn’t go out of the system. Again you may have a weak development environment that exposes the errors of individual programmers to your customers creating problems for both!

  3. re: “Not a Spammer” check box –

    Is there anyway you can move it above the submit box?

    The last two times, I’ve had to go back because the workflow is currently:

    Click the “Notify me of followup comments” box.

    Click Submit

    Get popup box saying I didn’t click the spammer checkbox.

    Go back and click the spammer checkbox that is BELOW that Submit button.

    Click submit (again)

    [and I almost did it a 3rd time on this post! I guess I’ll “Be More Careful (TM)” lol ]

  4. The individual performance evaluation systems in place in most organizations accentuate this problem – you can’t expect team work when you are pitted against each other in your own team.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.