Fighting fires vs. problem solving: what's the difference?
Dear Gemba Coach,
I hear that lean is about less fighting fires and more problem solving but I am unsure of how one differs from the other?
Good question. “Problems” in lean tend to have a very specific definition as a gap with a standard, which is quite different from the common sense of, say, Merriam Webster’s definition: something that is difficult to deal with: something that is a source of trouble, worry, etc.
In the lean sense, problems come in two main types:
- Problem solving: standard performance is known, and so is the (technical) process to achieve it. Unfortunately, standard performance is not met and so we need to compare standard (ideal) to actual step by step to find the gap, ask why and come up with the appropriate countermeasure.
- Kaizen: standard performance is met through following the standard process, but we challenge ourselves to improve performance, say by 50%, and therefore seek new ways to achieve this by examining the process step-by-step, and without any radical new investment to start with.
In real life, obviously, many situations are problematic without any standards in place, and hence you run across the lean conundrum of “no improvement is possible without standards in place.” At the gemba, I remember several cases where Toyota engineers would intervene at a supplier to solve a problem. The supplier would expect Toyota’s guys to arrive with a ready-made “Toyota” process, which they assumed would be better than their own and solve the issue.
Problem or Fire
On the other hand, the Toyota engineers would then ask: what is your existing process? Let’s first make sure this happens consistently. The supplier engineers would then get agitated because they knew, for sure, that their own process wasn’t so good, and they expected to “learn” a new, better way of doing this or that. In some cases it took weeks for both parties to agree to first run the existing process consistently and then improve it step by step in order to achieve the known potential. This is an interesting case because the known standard in the Toyota environment tells you what to expect, what is realistically possible, but not how to get there from there. Hence, first standardize the existing process and then work through problems step by step. This we understand.
But in many cases we come across real burning fires. This is quite another sort of problem: something has happened unexpectedly with potentially catastrophic consequences and no clear way to resolve. A supplier goes bankrupt without warning and it takes months to find another. The customer’s purchasing department decides that it’s going to get 5% off the price no matter what. A bottleneck machine breaks down and no idea how or why. A supplier component is suddenly bad and no one understands why. And so on.
With your question in mind, I was walking a gemba with a CEO and we tried to categorize the problems we came across as either “problem” or “fire.” Thankfully, most of the issues we came across were “problems”: we understood what was going on, but solving it was difficult so we worked on it slowly (sometimes too slowly), but we knew where we were. There were a few fires as well, such as a supplier suddenly taking a component off its catalogue without warning because of a corporate-led rationalization. A key person in the scheduling department had a bad personal problem and lost all interest in work, that kind of thing. At the end of our walk, the CEO suggested that a problem was an issue he could learn from, whereas a fire was one with no clear lessons (other than survival).
I feel he’s on to something there. The border between problems and fires is not always clear as the size of the issue matters as much as its nature, but overall we find that we have problems in areas we look at, we investigate and we kaizen, and burning fires in areas where we don’t – and simply don’t know what we’re dealing with.
Although we don’t necessarily have clear standards everywhere, identified problems with a kaizen intent tends to clean the window and at least the ins-and-outs of the situation are better understood. Issues are then problems: they can be uncomfortable and worrying, but there’s less of a sense of panic because we roughly understand what is going on. Contrarily, areas without gemba walks, with no kaizen intent, can yield real fires, with lasting consequences on the company.
Take unlikely, but real, dishonesty issues – I’ve personally witnessed both an employee taking kick-backs from suppliers and two employees scamming the company for cash (thankfully, not the same company). My favorite one was an intern in purchasing setting up a supplier account and paying herself for thousands of dollars of non-existing software licenses. Such problems range from the silly to the dramatic for the company, and hence I’d advocate a system of spot-audits in any company, not to burden processes with wasteful controls, but to randomly check systems to flag any weirdness.
To answer your question, a problem is one where although you might not have an immediate solution, you understand the problem space. I know of many such problems with people who are slow to grasp some of the things expected from them: we don’t know how to teach them faster, but we also think firing would make matters worse, so we soldier on. A fire is a situation where you’re caught with your pants down because you simply didn’t see it coming, don’t know what to do and have to act quickly because if not consequences can be dire.
In my experience, lean practice definitely shifts the burden from fires to burdens. In the previous mentioned company, the CEO and I reminisced of what the business was like when he took over: every situation was a crisis and management was made of heroes – people who could jump in, yell at everyone and save the day, somehow.
Today’s company is very different, rather dull in fact. It does have a few fires burning, but the CEO knows about them and can isolate the damage and grit his teeth. Most of the other issues are problems, such as how to better improve collaboration between functions, how to better control this or that technical process and how to develop people faster – but none of this are fires.
How to Turn Fires into Problems
In this particular industry, for instance, market conditions are very tough and suppliers fold regularly. This used to be a fire, but it’s now a problem. Frontline managers are asked to look for signs of financial distress and have a few approved way to help suppliers along if necessary (as well as look for replacements at the same time). Such crises never resolve themselves cleanly but what used to be a fire has now turned into a problem. It’s no longer a case of “what should we do?” but of “how can we do this better?”
The key to turning do less fire-fighting and more problem solving? Gemba visits. By being on the gemba, looking and listening and challenging people on why things happen in a certain way, or what standards are in place (or not), executives create a mental space where fires and now less likely and problem solving becomes the norm. There will always be fires, and managers have to put them out – that’s a given. But, yes, I’d agree that one way to look at lean management is to turnaround the proportion of problems to fires, and as we learn to problem solve, the number and intensity of the fires is reduced.
There are so many lean management principles to know and tools to master at the start – is there an easier way to begin?
Dear Gemba Coach,
Isn’t there an easier way to start lean? For a beginner, it seems like such a mountain to climb – all these things to know, tools to master, counter-intuitive principles to grapple with. Can’t we make access easier?
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?