Solving our own problems teaches us to distinguish what we know from what we don’t
Solving daily performance problems is not about taking every small rock out of a well-oiled machine so that, one day, the process works perfectly because there are no more problems.
Discussing how we solved one problem every day is about developing our ability to solve problems, and to explore how much we really know about what we do every day, as opposed to how much we think we know.
To make this work, we have to take special care in filling the problem solving board:
- Any problem should be expressed as a performance gap explained by a process gap: “I arrived late at work because of a traffic jam” Writing “arrived late at work” in the problem box and then “traffic jam” in the cause box doesn’t get us very far.
- A cause is a gap to a standard: when you write the cause, make explicit how the real process deviated from the standard. For instance, there was an accident on the freeway, which slowed the traffic at the South entrance, adding half an hour to the normal journey.
- A countermeasure is what we did to return to standard or minimize its consequences: Once you’re stuck in traffic there’s not much you can do, but you can phone ahead to move your first appointment.
- Checking whether the countermeasure worked: is the key to see whether customers and colleagues accept the countermeasure as valid or not, and to start thinking about root causes.
When formulating the cause the trick is to look for the standard, not simply come up with it from memory or “everybody knows.” Find the paper, the norm, the checklist somewhere, dig it out from the files or the intranet or the manual. Studying the standard is immensely valuable because, as the saying goes, “it ain’t what you don’t know that gets you in trouble, it’s what you think you know that just ain’t so.”
Checking one’s standards one at a time as we write our reasoning on our daily problems (the equivalent of checking your references when you write a paper) is the way to keep our knowledge fresh and updated, and discover that some standards change, or that our own understanding of the standard has evolved. As long as we can’t tell for every problem whether:
- there is a standard but something else happened
- there is no standard and we should write one
- there is a standard but it doesn’t apply in this specific case
- the standard is just plain wrong or has evolved
We have not really understood the problem. Facts have a half life – half the facts you now know will turn out to be wrong at some point (trouble is we don’t know which half). Real learning is not just about learning new things, but also about constantly checking that we do know what we know: that’s what detailed standards are for.
