Some_Developer "m104, I screwed up the system because I pushed out the development build on production."
m104 "Well Some_Developer, next time you make a list or you're fired, you should be kicking yourself for this mistake"
That doesn't solve the problem of why Some_Developer was doing a build, why Some_Developer could have done a dev build on production and why there is no pre-production environment.
If you read the blog post (http://codeascraft.etsy.com/2012/05/22/blameless-postmortems... ) you'll see that there are two opposing views to human error. The side I stand rather firmly on is the idea that if ANY person can bring our system down with a few keystrokes or cause hours of pain then we have a VULNERABILITY in the system. I don't care about fat fingering, I don't need to remind people they are stupid, I don't need to give warnings or last chances. I don't care about WHO ore WHY I want to know HOW to fix it.
Reprimanding for human error achieves the opposite effect and is a common trait of weak/inexperienced management.
Ah, I can see why our opinions differ so much: you believe that human error can be mitigated or eliminated with the right systems, training, documentation, procedures, etc. In other words, you can build a system that, while being run and maintained and managed and extended by humans, will prevent human weakness from crippling the system. Within that view, blaming humans for human problems is counter productive, since you've got a better way to prevent failure.
I don't share that view, but I think I can tell you why it's working for you (now) and what sorts of issues you'll run into eventually and why:
You've got great people working for you. I don't need to tell you this, of course, but it's true. That's why you're having success. Great people are already preventing most screw-ups and blaming themselves for their own screw-ups, so there's no need to apply much in the way of corrective management. Adding tools and documentation and procedures to help everyone learn from this process is great, but your people would do fine without all of that. They're going to do their job well, in any case. That's what great people do.
But, not all of your people are great. You've got at least a few in there who have started to (or always have) felt that their issues and problems and screw-ups aren't actually their fault. They can hide now, fairly unseen amongst their coworkers. But they are there, regardless, causing small issues here and there which are mostly taken care of by their more responsible peers. More documentation, training, and system verification won't help them, unfortunately. These people either need to face the music or be terminated before they cause real damage. Identify them, if you can, before things get worse.
The worst employers I've worked for have all had a "blameless" culture. They didn't call it that, of course. What it meant was that if the cause of a problem or failure was difficult to face, the problem was blameless. I don't think any one of them started out that way, but weakness crept in and suddenly the company just couldn't pin blame where it needed to go, because (for what ever reason) that was uncomfortable.
And this is where the breakdown ultimately happens, and why: Management decides that it's soooo uncomfortable or legally risky to hold an employee's (or another manager's) feet to the fire that they come up with all sorts of rules and procedures and training and even philosophies to avoid having to, you know, actually manage the team. And the employees that don't like feeling personally responsible love it because they've got an out for their mistakes. "I didn't know!" "I didn't realize!" "No one told me!" "What was I supposed to do?!?" And management can go back and order their more responsible employees to "fix the system" so that their irresponsible employees don't cause as much damage next time.
And anyone who questions this is being judgmental or biased or seeking a vendetta or in some way not being the caring and compassionate soul that the company's "blameless" policy demands. Greater employees leave eventually or are fired for causing trouble. Eventually, the continued wave of failure overwhelms the company itself.
(Of the three employers I've worked for with this sort of environment, two no longer exist and one is cresting this year. Anecdotal, of course, but this is how my opinions on teams has been forged.)
Ok, so back to your blog post. You're telling the world and your employees that this is exactly the type of environment that you want to create and maintain! Not one of failure, of course, but one in which no one person can be, ultimately, responsible for failure. It would be so cool if this actually works, but think about what you're actually saying.
The great people in your team(s) don't need this sort of support and the irresponsible people will lap it up and ask for more. If you're not prepared to deal with the second set, they will drive the first set out and use company policy as their justification.
Some_Developer "m104, I screwed up the system because I pushed out the development build on production."
m104 "Well Some_Developer, next time you make a list or you're fired, you should be kicking yourself for this mistake"
That doesn't solve the problem of why Some_Developer was doing a build, why Some_Developer could have done a dev build on production and why there is no pre-production environment.
If you read the blog post (http://codeascraft.etsy.com/2012/05/22/blameless-postmortems... ) you'll see that there are two opposing views to human error. The side I stand rather firmly on is the idea that if ANY person can bring our system down with a few keystrokes or cause hours of pain then we have a VULNERABILITY in the system. I don't care about fat fingering, I don't need to remind people they are stupid, I don't need to give warnings or last chances. I don't care about WHO ore WHY I want to know HOW to fix it.
Reprimanding for human error achieves the opposite effect and is a common trait of weak/inexperienced management.