To solve your problems, stop looking for their causes
In the late 2000’s to early 2010’s my company became quite serious in implementing Lean Management practices. Year after year, performance and activity boards flourished on the walls, daily meetings turned from awkward to necessary, and the managers and their teams got an increasingly informed eye on what came in and what came out, their lead-time, their rate of complains, and so on.
It was all very satisfying indeed. The team leaders were better informed than ever about their own numbers, the middle management was less in control of the narrative that they would serve high management, everything was in its right place. But of course, there was a “but”.
Back then, implementing Lean Management was a big part of my missions and aspirations, and I was obviously an enthusiast. It is why I was taken aback when one of the team leaders on whom I counted as an “ally to the cause’’ told me: “Yeah, Fred, thank you for your help on performance management and all, but, you know, after awhile, it kind of sucks to be permanently reminded that our numbers are bad without being able to do anything about it.”
I was mystified. It was implicit to me that problem solving was part of performance management, and that once faced with their “room for improvement’’, teams would spontaneously find ways to improve.
Bless 10-years -ago me.
So we had to implement problem solving. In order to do that, we of course had to break all kind of resistances. From those who didn’t really want to solve problems (because otherwise how are we going to have these extra FTEs we’ve been asking all those years?) to those who thought that it was just more trouble for no more money, and those who had no clue where to start.
Somehow there were some managers who did want to improve their team’s performance, and so my team and I started teaching them and their teams problem solving. Our main focus was to get them to stop treating the symptoms of their problems, and to start treating the cause. You know the deal: if you have a leaky pipe somewhere, you can either spend your life carrying buckets and mops, or call the plumber once and (hopefully) for all. And if you have spent 2 years sweeping the floor, the plumber won’t be any cheaper, so you’d better call him now.
Successful problem solving was all about the root cause, and that was the core of our training, our coaching, and the tools we shared with our colleagues. Some of you are probably already guessing what’s coming. As a result of all this activity, a considerable amount of time could be spent using sophisticated methods to solve problems that were not always worth it. In other words: big guns for shooting small flies.
One day, a colleague came to me with a request. She wanted to deploy problem solving in her department, and her idea was to have all 120 of her employees attend 10 solving problem workshops within a week, and to trust her team leaders with the facilitation, knowing that several of them were new to the topic. Oh, and, for some reason the only time we found to train them was during a one hour lunch. Did I mention that I was an enthusiast? Of course I accepted the challenge.
Our PDCA training was a half-day operation, so I couldn’t use it to train the managers. I needed to give them a simple, self-explanatory tool, so that the training would mainly consist of them asking questions about it and me answering in between some refreshing œufs mayo and a delicious confit de canard. (Yes, this story is located in France). I also wanted to help them find solutions proportionate to the impact of the issues they would tackle. So I came up with this:
Besides my over-simplification of the Problem Tree, the trick was to have them talk about the consequences of their problems before anything else. Not only did it unify the teams by letting them finding new reasons to solve them, it also insured they would all speak about the same thing, making the rest of the workshop all the more efficient. Listing the causes, choosing the main ones, finding solutions and defining an implementation action plan, everything turned out easier after that.
The 10 workshops proved successful, and the same model was reproduced by the department in the following years. And I learnt that the first step to solving a problem, is to understand its consequences.
