“Blame & Shame” is Shameful

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.

Thanks for reading! I’d love to hear your thoughts. Please scroll down to post a comment. Click here to be notified about posts via email. Learn more about Mark Graban’s speaking, writing, and consulting.

Related Posts Plugin for WordPress, Blogger...

Mark Graban's passion is creating a better, safer, more cost effective healthcare system for patients and better workplaces for all. Mark is a consultant, author, and speaker in the "Lean healthcare" methodology. He is author of the Shingo Award-winning books Lean Hospitals and Healthcare Kaizen, as well as The Executive Guide to Healthcare Kaizen. His most recent project is an book titled Practicing Lean that benefits the Louise H. Batz Patient Safety Foundation, where Mark is a board member. Mark is also the VP of Improvement & Innovation Services for the technology company KaiNexus.

18 Comments on "“Blame & Shame” is Shameful"

Trackback | Comments RSS Feed

  1. docdisc says:

    Regarding the bug report ‘person to blame’…make it autopopulate the boss’s name, 94% of the time. ;)

  2. Marty says:

    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?

    • Mark Graban

      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).

      • Marty says:

        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?

  3. Walter Reade says:

    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.

    • Mark Graban

      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.

    • Jayadeep Purushothaman says:

      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!

  4. Walter Reade says:

    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 ]

  5. Jayadeep Purushothaman says:

    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.

Post a Comment