What do you think are the pros and cons of merging lean and TOC?

Dear Gemba Coach,

In the DevOps movement, the amalgamation of agile, lean, and IT service management practices, there is a new entry that is making a big impact. This is The Theory of Constraints by [Eliyahu] Goldratt. Many believe that combining the thinking of Ohno and Goldratt can produce amazing and sustainable results far easier and faster than either can separately. Have you considered the pros and cons of lean and TOC or merging them?

Why merge them? Frames are more powerful when they are not united – in trying to blend powerful approaches you occasionally get something new and original, but most likely you end up with something bland and uninteresting. There are several interesting – and difficult –aspects to this question.

Firstly, thinking through things is mostly about orienting on a perspective. Once a person has acquired a perspective, an angle of view, on a topic, most of the reasoning follows along that line towards “logical” but often not very original conclusions. Reality seldom conforms to our models and wishful thinking, and in order to think smart thoughts, the trick is to be able to maintain different perspectives on things – which is hard, because our mind demands, often quite strongly, consistency (probably, actually, the source of your question).

To keep one’s thinking flexible and fluid, the first thing is to master several approaches without seeking consistency. TOC will show you one thing, lean another. New insights will be born from applying one or the other to a situation, but not from blending them. I love this picture of one of my sensei, Joe Lee, in Taiwan, reminding me that we always think we’ve got a handle on the full elephant when, in fact, we’re only grasping a small part.

The difficulty with frames and theories is the same as with tech: what is heritage, what is legacy? Our minds tend to fall in love with theories, particularly, as mentioned if their consistent and internal coherence will generally trump fit-to-fact. The hard mental work is to distinguish:

• Zombie ideas: ideas that we like but that we can discard because they have outlived their usefulness and are no longer relevant to the current context. Think of the “Maginot Line” of your thinking. The Maginot Line did its job in 1940 in avoiding a war front between Germany and France but was pretty irrelevant as panzers simply drove around. Which of your ideas are Maginot Lines? Not incorrect, necessarily, but irrelevant and holding you back?
• Deeper truths: some ideas, however, have staying power and keep feeling truer and truer as time goes by, as they’re increasingly useful to deal with current situations. In my case, for instance, finding the most competent people and increasing collaboration with them, is an idea I’ve been taught since I was a young man. I discovered it slowly at the start of my career, and find it increasingly relevant as things advance and my hair goes gray.

If lean or TOC work for you, by all means, keep deepening your understanding of both or either – but blending them sounds like a bad idea, because it will hide the specificity of both, and will not help you to develop the real valuable asset of flexible thinking.

Personally, the Theory of Constraints has taught me a lot:

1. Learn to see a process as a sequence of dependent steps – emphasis on dependent (It’s easy to see the sequence of steps, but unless you can pinpoint dependency, this could be an artifact of organization or your own mind).
2. Look for the most limiting factor to output growth (I’m told it’s called “limfac” in military parlance, though Achilles’ heel sound more poetic)
3. Decide how to deal with the constraint and subordinate other decisions to that one.
4. Making money is the goal of any enterprise.

Now, practicing lean has given me a very different take on these 4 points:

1. There is no such thing as “people-free” processes. Processes don’t exist in the abstract, but they are the result of what people do. Although it’s easier to describe it as a “process” with a chart on the gemba, people are far more flexible than we think and do … all sorts of other stuff, both better and worse than we think.
2. The limiting factor is not revealed by a bottleneck. A bottleneck can appear at the time when you look at operations, but I’ve only come across a handful of stable bottlenecks. In real life, most people have dealt with bottlenecks already (mostly through overcapacity) and the issue is more about created demand that saturates resources (mura leads to muri leads to muda) than actual bottlenecks. In a system, the weakest link in the chain is the weakest link at any one time – according to how the system behaves, this weakest link can move around. The limfac is usually something more deeply hidden and built into the structure of the thinking itself.
3. Output is not the same as outcomes. Fixing the output problem doesn’t necessarily get us closer to solving our real problems. And, again, no process is people-free, so problems can’t be seen independently from how the people who experience the problem themselves see it. People, however, will fixate on a limiting factor, sometimes to a crazy extent, as we can see in politics. Getting outcomes right is more a question of creating winning dynamics rather than fixing the process.
4. None of the CEOs I know that practice lean as their main management method are in it for the money. Money is necessary to keep playing at the table and nice to have, but their motivation is usually about doing things right: building the right products for their customers and having more fun with their staff, creating a better work environment for everybody. So money matters, clearly, but it’s one goal, not the goal – outcomes are rarely that simple and far more yin-yang.

I’m not casting stones at TOC – I still will take a step back from a situation and separate the people from the problem and think in terms of goals, throughputs, and constraints. It’s very helpful. But I’ve learned to be very careful about the hypotheses I then formulate – they’re a good starting point, but they also tend to be very wrong in real life.

Which brings us to the second issue here, which is that frames are powerful but largely a fool’s promise. A frame is a mental scaffolding, but it should not be confused with the reasoning itself, as the building should not be confused with its scaffolding. One of the key lessons in learning lean with senseis is how much our thinking is conditioned by a deeper, harder to see frame: administrative problem-solving. We genuinely believe that we solve a problem when we:

• Publish a new process
• Add a checklist to an existing process, or a written standard
• Add an audit sheet
• Put in more final inspection or managerial control
• Etc.

If there’s one thing that lean shows is that this is not problem-solving: this is burdening the process with more management control and red tape. Problem-solving is rather different, either:

• Giving the people who do the job the means to better see problems and solve them as they work
• Changing a root cause condition that makes problems no longer appear in the first place.

Real problem solving is concrete. Most thinking about frames is at a level of abstraction that will never solve any problems. This is why I spend my time on the gemba and stay away from think tanks. Not only do I believe that blending interesting approaches doesn’t help clear thinking, but I also feel it encourages scholastic abstract discussions that lead to arguing about how many angels can fit on the head of a pin, when no one knows what an angel is or has been pricked by a pin in a long time. True, this is endless fun around a beer. True, it hones your thinking about frames when you discuss the commonalities and differences among friends, but it can get stale very quickly.

Still, TOC and lean do show us very different things. Coincidentally, I was on the gemba yesterday with a CEO visiting one of his operations where inventory was exploding because the rate of production had fallen quite visibly. As we walked the process with the plant manager, he argued that his main problem was a sudden shift in mix with much higher work content products than usual.

In this case, they’re making rather large objects in few production steps, so walking up the process was quite easy and, TOC thinking, we were looking for the bottleneck. The CEO was really keen to get the output flowing again and not opposed to investing cash for it, but every time he suggested either investing in further capacity at one stage or another, the plant manager argued against it and thought this would not solve his problem. Tempers were rising, but the simple fact was that the plant manager didn’t know where his bottleneck was – or even whether he had a bottleneck. Were key operators missing? Were some elements of the work content mix more difficult to handle?

As we walked up and down the process we finally there were a lot of in-process parts stashed in various places waiting for missing components. When challenged about that, the plant manager explained that his teams were doing all they could, but part of the problem was sourcing some of the rare components.

In the end, I stepped in and asked, “Why not stop pushing and start pulling just to clear the window so we can understand what is really going on?” The plant manager said he had tried pulling once and this had reduced even further his production output so he had concluded pull didn’t apply to his specific process.

So that’s it? Fall off the bike once and never try again? Most discussions about frameworks don’t change anything in the end because they still assume we can get to the correct diagnostic using this frame or that, and then decide what to do, make an action plan, and get on with it.

With difficult problems, however, smart people on the ground have already tried that. If it hasn’t worked the issue is that they have something to learn, not something to do. So the deeper question here is: how many attempts at pulling will you do before you give up? Are you willing to go at it again and again until you crack it?

Furthermore, going to pull will, unless we’re very lucky, not solve the problem, but it will, however, make us see more clearly what the real problem is and where the bottleneck is if there is one.

Most management frameworks, TOC included, are born from administrative problem solving (diagnosis and action plan to change the process), lean is born out of a completely different deep frame: learn by doing. Discussing how to handle different frameworks doesn’t help with the basic lean questions of:

• What is the first thing we need to learn to progress on this challenge?
• How many cycles do we intend to go at it until we either crack it or give up?

Combining thinking movements won’t help much with getting to the point where you fall off the bike, pick yourself up, dust off, and start all over again, as the song goes.