The hardest and best thing about errors is that they’re unavoidable. Hardest because getting it wrong is not our vision for our work—we bridle at facing the reality of our inadequacy. Best because the best thing for growth is a steady diet of error. Provided errors aren't squandered, that is. And the not squandering part depends largely on what’s more important: avoiding the hardest thing or getting to the best thing.
Both isn't an option.
Not long ago I witnessed the former in all its glory. As a guest at a meeting in which some mistakes were brought to light, I watched while denial and blame ping-ponged interminably around the table. Finally—out of sheer exhaustion, no doubt—the responsible parties reluctantly acknowledged the errors but with the caveat that it was too late to fix them. Besides which, they insisted, the client accepted the work. Took it home, drove it around (so to speak). The onus is on them, not us. “Not me.”
This mindset is a quality control anti-pattern. Even worse, it’s a growth killer.
The basic problem here was the underlying assumption that perfection is the default and errors are an anomaly. A brief look at human history should persuade us that this assumption is not valid. Failure abounds. And if what we want most is to avoid it, errors will always be a curse. Dogging us, embarrassing us, slowing us down. But if it’s growth we want, well—that’s a different story.
At Open Door Teams, we accept defects as inevitable. This saves us the energy of trying to stave off the unavoidable and allows us to focus instead on what to do about it. And what we do, in short, is own-fix-learn.
The first thing to do with a reported defect is to own it. The person reporting the issue did nothing wrong. Make sure they know that. Empathize. Past experience with IT has probably predisposed them to expect an obtuse response somewhere between buck-passing and outright assertion that their problem is exactly that: their problem.
Flip the script. Take the blame. And acknowledge the inconvenience of having to resort to a support request in the first place.
Why is this important? Two reasons:
Immediately owning the problem allows us to reap something good from the defect right away: a customer service win.
Defending against blame slows us down. We can get to growth faster by skipping right over the arguing and denying and going straight to owning the problem.
A note to leaders: it takes both personal courage and corporate culture to make error ownership possible. If you see a problem with ownership in your organization take a hard look at the culture you’ve created. What happens to people who report issues with processes or products? What attitudes are predominant when your organization encounters an unexpected result? Are people valued as people, separate from their ideas and work products? Or is their value tied inexorably to their production? If the latter, I think you’ll find the people in your organization struggle with error-ownership and are struggling to grow personally.
Before we learn from our error we first limit the damage to the most important person in the room: the user. They don’t care about the root cause. They don’t care about conflicting requirements, lax user testing, vendor’s missing documentation, previous acceptance, outdated technology, management’s mandates, etc. They shouldn’t have to care. Their priority is to deliver the value they are creating to their stakeholders. Our priority is to deliver the value we are tasked with. So deliver it. Cut corners, be pragmatic. And get them running again ASAP. The pragmatic fix may be messy and not at all the right way. But if it avoids mission failure for your customer, it’s the right way for now. You can shower later and do it right (really right) in the next release.
Again, it’s about using errors; harvesting them for good. The customer has a problem. Solve it. With bells. Do this, and the first fruits of your error are customer service wins.
This is where all that time and energy saved by owning and fixing gets put to use. It’s also where team culture plays the starring role. Because when fear of failure reigns, you end up in meetings like the one I described above, and you can’t do what’s necessary to learn:
Ask: What happened?
Then ask: Why, why, why, why, why. (Yeah, that’s 5 Whys).
Asking those questions amid a culture that shames mistakes and their makers will generate very little (if any) growth. But in a culture where mistakes are accepted as inevitable side effects of working towards something good, investigating what led to them is more a joint fact-finding mission than an us vs. them interrogation. Which makes growth not just possible, but interesting. Rewarding. Maybe even a little bit fun. Stepping down the chain of whys may unearth many additional own-fix-learn loops for as-yet-manifested errors. Great! That’s what growth’s all about. We learn what went wrong and then we do something about it. And though perfection is the ultimate goal, it’s a long way off. Not tomorrow. This problem may happen again in a new way. But so long as we learn something each time and make it less likely to happen the same way again, there is growth.
Think of errors as a crop to be harvested and processed into beneficial byproducts. (They don’t even have to be your defects to reap rewards from them.) Positive experiences with defect reporting and correction are so fleetingly rare that, chances are, the customer will find the excellent treatment they received when they had a problem far more memorable than the initial negative feelings at discovering the defect in the first place. That’s reward number one. When you own-fix-learn, you get reward number two: growth and a reduction of the conditions that lead to the error. That is, you get better and better at delivering sustainable value. And there’s a third reward: a happier, less fearful team that stays engaged and asks the all important, growth-seeking... Why?
(And none of those exhausting meetings.)