Learning to Solve Problems By… Wait for It… Solving Problems

Becoming a lean enterprise isn’t easy. Even individually, consistently thinking lean, especially in practice, isn’t easy. Thankfully, our forebears have given us models like the TPS house and various frameworks for lean transformation that we can return to when things go sideways. Recently, I needed to do just that. 

I was on a call with an executive team. It was a year or so into launching a new business line with an innovative model for their industry (healthcare). As a small business, the ambitious endeavor required their staff to be fully engaged, contributing all their talents and ideas. The executives hypothesized that a lean transformation would enable this. On the call, however, one of the executives was exasperated with how things were going. 

“We all agree that problem-solving capability is critically important. We’ve been building it, I guess, for more than a year. We’ve been doing a lot of stuff anyway. Yet it seems like we do everything but actually solve problems. Can anyone tell me the last problem we solved? I mean, really?” 

Silence. 

Eventually, another executive responded. “Look, our team’s mindset is changing. The KPIs we’ve established… the daily huddles we’ve set up… the team’s talking about performance and problems every day!” 

“Exactly,” the first executive snapped back. “We talk about problems. We just don’t solve them.” 

As background, the company’s patients are afflicted with a chronic disease. Unfortunately, the insurance model that funds their care, including the company’s services, puts caps on their treatment. Seeing this as their problem to solve, the executive team is trying to prove out a new model that overcomes these limitations to prevent unnecessary suffering. By demonstrating what’s possible, they ultimately hope for widespread adoption of this model across the industry. Again, for a small business, it’s ambitious, to say the least. And admirable. 

A Process (Questions) for Reflection 

This moment caused us to reflect, drawing upon the Lean Transformation Framework’s five questions. One, the purpose was clear. The executives had been doing a lot of work to clarify it, establishing a vision, a mission statement, and even an actionable strategy for the year. Two, the work was… well, I’ll come back to that. Three, the capability in development was problem-solving, check — that was the intention anyway. Four, the management system’s development had made considerable progress. Lots of activity there. And five, mindsets were changing! 

Even a quick run-through of the Framework’s questions provided insight: We could see that the focus had been on developing a management system for problem-solving: KPIs, visuals, huddles, a standard agenda, info in, info out. And correspondingly, leader behaviors, such as how they’d respond to problems. On the other hand, we saw less progress, in practice anyway, on improving the work — where we’d expect to see the impact of problem-solving. Thus, the executive’s lament that problem-solving capability was being developed theoretically at best but not in actuality.  

To illustrate what had been happening: A problem would come up. The executives would huddle to discuss what would have helped them better detect the problem sooner, how they could better organize themselves, and how they could tackle it more effectively. Better KPIs? More frequent huddles? A revised agenda? They’d update their management system accordingly. 

As “good” as these mechanisms were, however, lost in the response was actually solving the problem in the work. So, while a management system was under construction, it was never tested. The work never changed. Therefore, whether the management system could fulfill its purpose remained unknown. What we had here was a meta-problem — a problem with our problem-solving approach.  

No Reflection is Complete Without Self-Reflection 

This experience reminded me of a hard lesson I once learned in a factory. Well, nearly learned, as it turns out. Because here I was relearning it. As I said, lean thinking and practice isn’t easy. 

My early lean learning occurred as a member of the corporate lean team at Starbucks. One process at a time, my team observed the work in detail and defined the problems to solve. For example, we discovered millions of dollars of product waste in the brewed coffee process and issues with product quality and availability. Then, in a lab store at the headquarters, we experimented with local baristas to develop “better ways” of doing the work that addressed these problems. And finally, through trial and (plenty of) error, we created a leader-led approach to introducing these process improvements that simultaneously built problem-solving capabilities throughout the management ranks.  

Over time, an operating system based on lean principles emerged as a program and as a platform for subsequent adds, such as management routines for multiple levels. We eventually named this program Starbucks Playbook. Through this experience, I learned about lean transformation from the perspective of a corporate lean team based at headquarters.  

A couple of years later, I was challenged with an assignment in a manufacturing company. Perhaps unusually, as a lean practitioner, it was my first time working in a factory. Basically, I was given a target to incorporate an isolated workstation into the nearby assembly line that it supplied.  

I ran the only play (pun intended) that I knew: I observed the relevant work in detail, defined the problem clearly, experimented “offline” with potentially better ways of doing the work, and detailed an implementation plan for the areas managers to carry out. I captured all of this on an A3.  

But when I handed a copy of the A3 to my coach, he ripped it up! Frustrated, he pointed to the workstation and asked, “What’s changed?”  

All I could say was, “Nothing.”  

“Well, do you believe in learn by doing or not?” He then clarified my assignment. “You can’t leave until the target’s been achieved, physically. Not just theoretically on paper.” (As you might imagine, his language used was more colorful.) 

I learned more about lean transformation over the next few days than at any other time in my career. Unlike at Starbucks, I could engage directly with the people doing the value-creating work and the relevant cross-functional and managerial stakeholders needed to make changes within hours. Some of the new ideas for the work were accepted. Some weren’t. Moreover, these new ideas could be tried immediately. Some worked. Some didn’t. In other words, I could complete multiple cycles of lean transformation — improvement and learning — in a day. 

By following all the way through on my problem-solving, all the way to changing the value-creating work, I confronted every aspect of lean transformation as defined by the Framework’s five questions:  

1. clarity of and alignment about the problem, 

2. the work and how it would be improved, 

3. the knowledge and skills (i.e., capabilities) required for the work and its improvement, 

4. the management system and leadership behaviors around the work and the workers, 

5. and the basic thinking of the entire group of stakeholders.  

Nothing was left to the imagination. Nothing remained theoretical. I learned what it took to solve a problem.  

(I kept up my A3, by the way. I still needed to share the thinking and helpful narrative, supported by facts, with the people I was working with. That said, the “story” of the A3 became way more … oh, what’s the word?…ah, colorful.) 

Learning, Relearning, and Passing It Along 

I ended up sharing this story with the executives on the call. And for what it was worth, I advised them to accept the same challenge my coach had given me on that shop floor: The next time a problem comes up, tackle it. Solve it. Now. And then, once that’s done, reflect and start iteratively building the systems that will help you solve the next one even better. 

I’m sharing this story with you because I get to interact with many of you, often at your gemba. What I see is a lot of “lean stuff.” More specifically, a lot of “lean management system stuff.” And while it’s theoretically good for problem-solving, that’s not what I typically see, in the work anyway.  

Again, it’s not that the lean stuff is “bad.” We don’t need to tear up our A3s. We don’t need to tear down our management systems. We just need to remember what matters. And when we go sideways, which we all will, over and over again, we can revisit the models and frameworks left behind by those who have been there and done that. And then, we can practice, practice, and keep practicing.