Finding Problems – Big Ones and Little Ones
I recently read Michael Roberto’s book, Know What You Don’t Know. Spoiler Alert!! The core message from the book is that it’s more important for leaders to be able to find problems than it is for leaders to be able to solve problems.
This sounds like a genuine “Duh!” But it’s actually extremely important. Obviously, you have to find a problem before you can solve it – right? That would be good. What about those problems that erupt full-blown into the middle of your operations? NASA’s Challenger disaster was one of those – a BIG problem that took center stage on live TV in front of millions. It was a problem that, after the fact, was preceded by lots and lots and lots of little problems. Similarly, the recent explosion in the Chinese port of Tianjian was apparently preceded by Chinese government official concern about adherence to safety and environmental standards, since there was an official visit focused on safety just days before the explosion. The explosions seem to have occurred in a warehouse that contained numerous flammable, explosive and toxic substances – in large quantities. Migrant worker housing was located in close proximity to the warehouse and was destroyed by the blast. Safety concerns, undisciplined storage of HAZMAT and location of housing in proximity to dangerous industrial operations are all violations of best practices and, individually, small problems indicative of a potentially larger problem. The trick, in both cases, should have been to find the problems before they became disasters.
A couple of sea stories (for the non-cognoscenti, a sea story is a story about seagoing experiences that differ from fairy tales mostly in the beginning – sea stories do not start with “Once upon a time…”):
- A friend of mine was hired as president of one unit in a large conglomerate. It was his first job at that level, and he invested a lot of effort in understanding his company. Being a genuinely smart guy, he understood what he saw and what he heard, and he found lots of problems. He duly reported these problems to his boss at “corporate.” His boss chastised him for finding the problems. He wasn’t interested in problems – even the ones that were well beyond my friend’s authority to fix and which would, eventually kill the company. Now, my friend’s boss was a world-class jerk, but that is, unfortunately, not rare. This kind of attitude (the boss’) is precisely the kind of attitude that results in the sudden and catastrophic emergence of a problem.
- On the other hand, while in the Navy, I once encountered a (smaller than my friend found – but non-trivial nonetheless) problem. I notified my boss and told him that I didn’t have an answer yet, but was working on it and might need his help. My boss was a good leader, and he listened to me and told me to get back to him in 24 hours and give him an update. That was fine. My boss now knew about the problem and wasn’t giving any help that I didn’t want. My team worked through the problem, I updated my boss, and we got the problem solved – and we got it solved before it bubbled up to a Fleet Commander level with associated four-star message blasts.
The difference between those two stories is the attitude of my friend’s and my bosses. One boss was content to sweep problems under the carpet (and, I suppose, hope that they didn’t explode before he was promoted or left), and the other boss understood that problems are a “gravity issue” (gravity exists – it may, at times, be very inconvenient, but you simply have no choice but to deal with it). Problems, particularly when you’re dealing with cutting edge ideas or in competitive environments, will happen – deal with them.
So, the idea is to find those problems when they’re small – as I was fortunate enough to do in the above example. But more important is to find those problems because you’re looking for them – like my friend was – while they are small and can be solved before they escalate into disasters.
Most big problems do not suddenly erupt full blown (like Athena emerging from Zeus’ forehead). They almost always result from an accumulation of smaller problems coalescing into the big problem. The Challenger didn’t explode because of some black swan event. Engineers throughout NASA and Morton-Thiokol knew about the erosion of the external booster O-rings, and they knew the risks. Executives at NASA, like my friend’s boss, didn’t want to hear about it. There was a great deal of, not so subtle, pressure to report higher reliability than was justified by the engineering.
How do you find small problems? I think that there are a number of different tools that leaders need to use to find those small problems:
- Create and enforce an acceptance of problems – the founder of Build-a-Bear created a Red Pencil Award for people who found new problems, the correction of which improved efficiency or morale or customer service or whatever. That’s not the only way, but it is an example of creating that atmosphere of embracing problem finding.
- Get out of the office and walk around – this is not “Managing by Walking Around.” It’s more like just getting your people (particularly those at the bottom of the pyramid) used to you showing up and talking about “what’s happenin’ now.” Your people will tell you “what’s happenin’ now” and some of it will be little problems that need to be fixed or that will correlate with little problems in other parts of the organization that need to be fixed. These are important tidbits of knowledge, and you can learn about them if the organization embraces finding problems.
- Talk to “customers” – the people who benefit from what your organization does. Find out what is and is not working for them.
- Talk to suppliers, too – your suppliers have a vested interest in what’s happening in your organization, and they care. They can often provide excellent insights into small problems.
- Talk to knowledgeable third parties, people who are not employees, customers or suppliers about their perspective of your organization – do they see anything that could indicate problems? They are very likely to be more objective in their assessments than people whose “dogs are in the fight.” By the way, don’t discount these inputs “because they don’t understand the organization.” Maybe their perspective is more accurate than yours.
Obviously, there are other ways to learn about small problems, but they don’t involve tasking someone else to find them. As the boss, you need to bypass all those layers of filters and gatekeepers who are invested in keeping you from being submerged in trivia. They’re right to do that, but you also need to test that trivia on a regular basis looking for signs of small problems that are maturing into catastrophes.
Colin Powell observed, “Problems are not wine – they don’t get better with age.”