Sometimes, a thing can go not-the-way-we-planned and it isn’t bad. Technically you’re inclined to call it a failure. But if it’s something purely experimental, whatever you learn from the outcome is good, right? That’s knowledge you didn’t have a minute ago. This is the whole idea behind agile software development: you’re constantly learning and adjusting.
Amy Edmondson is a professor of leadership at Harvard Business School. More importantly, she’s the leading author and researcher in the space of psychological safety. (I recommend her book The Fearless Organization)
Professor Edmondson has come up with a particularly insightful tool everyone should know about: the spectrum of failure.
On this spectrum are different ways to classify not-the-way-we-planned. At one end we do, in fact, have the classic blameworthy failure. Something like, “We have a proven process, you chose not to follow it.” That’s deviating from a process and we can totally blame you for that.
At the other end of the spectrum, though, we have praiseworthy failure. When you’re performing a new experiment, any outcome is valuable. It’s new knowledge. And presumably you wouldn’t have performed that particular experiment unless that knowledge was going to be useful.
What’s important as a leader is to frame what type of mishap you’re dealing with when it occurs. There are video game companies, for instance, that hold a party when they cancel a project after an early prototype doesn’t meaasure up. Cake and champagne. Because they did something new and experimental and learned something from it. You do not, however, want a similar celebration when someone decides to skip Step 19 and winds up venting radioactive waste into the nearby town’s drinking water. So tell your folks up front where they are on the spectrum.
It gets trickier in the “lack of ability” portion of the chart, though. If something goes badly, was it the engineer’s lack of ability? Was it the lack of ability of the manager who put the engineer into a situation without adequately preparing them? Was it the hiring team’s lack of ability because they extended a Senior Engineer offer to someone who’s actually only mid level at best?
It’s worth noting that – regardless of which type of failure you’re looking at – separating the concept of blame from failure is important. You don’t want people afraid of reporting mishaps. What if the person vented the waste into the drinking water and didn’t tell anyone for fear of losing their job? Like, yeah, maybe they shouldn’t be employed at a nuclear power plant. But if they tell you about their error you at least have a chance to prevent everyone in Middletown from coming home to a dog with eyestalks.
Accountability following a failure is still critical. Maybe Biff shouldn’t be fired the first time he spills the milk. But if he spills the milk once a month for three months, at some point you’ve got to do something. True, maybe the milk transfer process is flawed and it’s not on him. But if the process is solid and he’s just not up to the job…one of the best ways to get your best team members to leave is by not addressing the poor performance of others.
image courtesy of Torsten Martens via unsplash
1 comment
Comments are closed.