I don't want to know whose fault it is"Don't you want to know who caused the failure?" No. No, I don't.
Something’s gone terribly wrong.
Now it’s time to pick up the pieces, and figure out how to keep this from happening again.
“Who’s responsible for the problem?” someone asks. “Somebody obviously made a mistake. We need to educate them.”
Whoa! Hold your horses! Knowing who made the mistake is dangerous. I prefer not to even ask the question, becuase I honestly do not want to know the answer. Here’s why:
Except perhaps in some cases of malicious action, no single person is ever at fault. Someone deleted the production database? Well, why was this possible? Why weren’t there safeguards? Why weren’t there backups?
Assigning fault short-circuits prevention. Our goal should be to prevent this mistake from happening again. If we’ve decided that human error was the cause, we tend to stop looking for systemic causes.
The past is the past. Fault-finding focuses on the past. We ought to be focused on the future.
Blaming destroys morale. If you want your team to be unmotivated, assigning fault is a great way to go! If you want your team to be highly motivated, teach them that honest mistakes won’t be punished.
Blaming encourages cover-ups. Aside from the issue of morale, if you want to be aware of mistakes (to improve), one of the best ways is encourage people to report mistakes, even their own. But placing blame encourages people to hide their mistakes.
Blame changes my impression of the person. As soon as I believe that an individual is responsible for a problem, it tends to color my impression of them, whether it’s wrongly, or “rightly” applied. And for reasons above, I don’t believe it can ever be rightly applied anyway.
Don't behave like a 2-year-old
Many software development teams seem stuck in the imitative stage, when it comes to business practices.
Improve your software delivery