If I had to point to the most significant thing I’ve learned in the last dozen or so years I’ve spent working as a manager, it would be acquiring a better understanding of mistakes and what they mean.
As a young software engineer managing technical groups, I buried myself in the latest thinking and writing about high-performance teams, and I was pretty confident that my approach to errors by my group was a sophisticated one. We were measuring the dimensions of our performance that mattered most to us, including error rate, and that alone helped improve our performance in those areas. If we saw an uptick of important mistakes, we talked to the people involved and investigated possible fixes to our systems. Generally speaking, we always called a mistake to the attention of the person who made it, and asked him to fix it. But we went out of our way to keep things neutral and not be accusatory. We grokked that mistakes were part of doing business and we didn’t sweat them.
Unless, of course, our company ended up shipping something with a major bug that cost a lot of money to fix. In that case, directors lost their shit, and people sometimes got fired. But whatever, we didn’t ship too many major mistakes. And we could usually fix them quickly and cheaply if we did.
When I carried this culture into the restaurant world, I learned its limitations. In the restaurant, you “ship” your work not once a month, but hundreds of times per night. And a significant error can cost not just a customer, but everyone the customer tells about her experience. With that in mind, in the cauldron of managing a busy restaurant, I reacted to errors the same way those company directors used to, when we shipped a faulty product.
I freaked out.
I should have known better. Back in the cube farms of the tech world, with my team of engineers, I was closer to the right idea. Identify, fix, tabulate, move on. But even then, I was still blind to the key question to ask about mistakes.
The money question to ask about mistakes is: how many mistakes do we want to make?
Most people in any organization, if you ask them this question, will tell you, of course we want zero mistakes.
Those people, sadly, are totally, completely, tragically wrong.
Indulge me in a quick thought experiment: suppose your organization ships a product with a significant mistake once per week.
Well, if your organization is in the business of launching billion-dollar rockets into space, that’s probably way too many mistakes. You will have to completely re-engineer your organization, and load up on people and processes to make sure you stop releasing faulty products. Or else you will not be in business.
On the other hand, if you’re running a bustling, casual neighborhood restaurant, making one significant mistake per week is also going to put you out of business — because it’s way too few mistakes. Making only one error in, say, five thousand dishes — an error rate of .0002 — is incredibly expensive and time-consuming. It means you’re staffed up several times more than you need to be, and spending a ton of money on labor, training, and quality control. You can’t do this and make your financials, at prices that anyone is going to be willing to spend.
Fortunately, in a restaurant, you don’t have to have an error rate of one in five thousand. Think about the math this way: if you patronize a casual restaurant fifty times, and order a hundred dishes, and 99 of the dishes are super delicious and one dish is incorrectly prepared, you’re going to think this is an awesome restaurant — as long as the restaurant handles its one error gracefully and fixes the situation. An error rate of one in a hundred, combined with great hospitality, is probably much closer to the ideal target for a restaurant like this.
Similarly, if you’re in the business of releasing online games that generate revenue, in which errors can be fixed in a matter of minutes or hours, one error per hundred releases might be too low. Because all those testing and QA processes are keeping revenue-generating features from hitting the market, and every day those new features wait for release costs you a lot more money than a bug fix does.
With that in mind, let’s return to the question: how many mistakes do we want to make?
To which we can add its underlying question: What is the cost of us making and fixing a mistake, versus the cost of us preventing mistakes?
Once you answer those two questions, everything else is easy. Just measure your mistakes, and change your systems if you are making too many — or if you are making too few.