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 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
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:
Regarding the bug report ‘person to blame’…make it autopopulate the boss’s name, 94% of the time. ;)
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?
Marty –
If you haven’t read the following article by John Shook, I believe it might provide at least some of the answers you are looking for.
HOW NUMMI CHANGED ITS CULTURE
http://www.lean.org/shook/displayobject.cfm?o=1166
John Toussaint took very public steps to NOT blame people when they reported a problem… and word spread quickly through the organization at ThedaCare.
Once management starts proclaiming “Problems are Gold” you will see a few brave souls test the waters. If they get shot down, it’s game over for culture change.
I think the problem of “CEO says problems are gold and then shoots down the first person to admit a problem” is one of the few exceptions to the “problems are gold” statement? :-)
Good thoughts. Thanks guys. Walter, I have read that article, but it’s been a while. I will definitely take another look!
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!
Great examples of system problems… thanks for adding the comment.
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 ]
I see what you mean… I don’t think I can move that box. I might just eliminate it and test to see if spam increases.
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.
You might enjoy this podcast then, on “Get rid of the performance review!”:
https://www.leanblog.org/2011/04/podcast-117-samuel-a-culbert-get-rid-of-the-performance-review/
[…] I would hope they are looking for process problems and how to prevent that problem from reoccurring, rather than simply assigning blame and firing somebody. […]