Lean Transformation: A Long and Winding Road

The Management Brief is a weekly newsletter from the Lean Enterprise Institute that bridges the gap between theory and practice in lean management. Designed for leaders focused on long-term success, it delivers actionable insights, expert perspectives, and stories from real-world practitioners. Each edition explores the principles of lean management—strategy deployment (hoshin kanri), operational stability and continuous improvement (daily management), and problem-solving (A3)—while highlighting the critical role of leadership. Subscribe to join a growing community of leaders dedicated to creating organizations built for sustained excellence.

Last month in The Management Brief, we published a WLEI podcast that featured Charlie Murphy, a senior vice president at Turner Construction who led the New York business unit for two decades. He told the story of its yearslong lean transformation.

A listener wrote to tell me how much they enjoyed my conversation with Charlie. While that was nice to hear, it was one of their observations that stuck with me. As a lean transformation leader themselves, they called out the “turning points” in Charlie’s story, saying they took away a lot from the moments when he “checked and adjusted.” That prompted me to revisit the conversation, looking for my own takeaways from the turning points.

What I picked up on was a practical pattern that any leader can utilize in navigating the “long and winding road” of a lean transformation. And since my colleague Mark Reich has supported Charlie for many years as a coach, I was not surprised to recognize the LTF—LEI’s Lean Thinking / Transformation Framework—in the pattern. For this article, I will overview the turning points to illustrate the pattern and show how those events led to the development of a lean management system for an enterprise.

What is the problem to solve?

The story began with a small experiment around a core business process: procurement. It’s the process by which a general contractor—Turner, in this case—selects subcontractors for a given project. Basically, the general contractor puts together trade-based scopes of work, commonly referred to as “bid packages,” and then groups of potential subcontractors submit plans and prices. The process ends with the execution of a contract between the general contractor and the subcontractor chosen to perform a given scope of work. Essentially, the experiment was a “model line,” trying out a new (to the company) approach to lean thinking and practice.

Charlie set up the experiment because the procurement process frequently impacted projects negatively in terms of timing and quality: lead times were longer than planned and unpredictable, and projects were riddled with potentially preventable change orders because bid packages were based on “drawings” still in development. On the positive side, the problems to solve were clear.

What is the process? How is it improved?

The experiment began when a small group laid out and analyzed the process based on what had happened on a troubled project in the recent past. First and foremost, the value-stream mapping exercise revealed the value of digging into the details of the work. It also revealed that people had different understandings of the process, lacked clarity about roles and responsibilities, did not know the status of the process at given times, and generally struggled to collaborate. For example, scheduling meetings, as innocuous as that sounds, was a major pain point. Out of these revelations, the exercise also led to the generation of lots of ideas with the potential to greatly improve the performance of the process.

One such idea was to set up a basic daily management system. I will call this the first turning point because it was not pre-determined. Rather, it emerged from the experimental process and everyone’s learning therein, including Charlie’s.

The daily management system they created had two main components: (1) an obeya space with a visualization of the procurement process and its performance and (2) a set of cadenced meetings for managing the work—doing it and improving it. The visualization provided near-real-time information about the flow of bid packages through the process. When a bid package was “stuck” for whatever reason, it was “flagged” visually, indicating the need for problem-solving. Then, during the cadenced meetings, the problem was either quickly resolved, next steps for problem-solving were defined among the project team, or help with problem-solving was requested from upper management.

What capabilities are needed? How are they developed?

Over a series of these meetings, Charlie, who participated regularly, noticed two things about the problems that the daily management system was highlighting. First, some bid packages remained stuck for extended periods of time. Second, the ways that bid packages were unstuck were often workarounds. In other words, root causes were not identified, and nothing was done to prevent the problems from reoccurring. Both issues were happening despite the involvement of Charlie and his direct reports.

Charlie realized that they—everyone in the business unit, including Charlie and his leadership team—needed a better way to solve problems. Specifically, they needed to solve problems in the work. This led to another turning point: adding the A3 problem-solving process. And to his credit, Charlie realized that learning A3 problem-solving should start with him.

Charlie also believed in “learning by doing,” so he organized and was part of an A3 learning cohort with his direct reports. They would learn A3 through a combination of classroom training and on-the-job coaching. Effectively, they would learn A3 problem-solving by using the tool and following the process on a real problem. And for the learning to be as practical as possible, they would choose a problem to work on that was within their scope of control and, therefore, really mattered to them.

In Charlie’s case, he chose a problem on a project that had fallen behind schedule due to issues with its exterior wall. Despite his full calendar, he managed to observe everything that happened with the exterior wall’s panels on the jobsite. He also managed to talk to everyone involved in receiving, hoisting, and installing the panels. Then he summarized his learning on a single piece of A3-sized paper, which enabled him to collaborate on solving the problem with all relevant stakeholders. He even went to visit the gemba of the panel manufacturer after discovering deformities on some of the panels that had been delivered.

What leader behaviors are needed? How are they established?

As you may know, the A3 process is for more than problem-solving. It’s also a process for learning and development. By writing down the facts they’ve gathered about the problem, along with their thinking through the problem and what to do about it, the author of the A3—the problem owner, if you will—gives visibility to the “gemba of their mind.” This allows others, including the problem-solver’s coach, to engage in the process effectively. In the case of the coach, it enables them to ensure the problem-solver’s approach is fact-based, structured, and collaborative.

So, after the first cohort, which included Charlie and his direct reports, went through a cycle of learning as problem-solvers, they embarked on another learning cycle as A3 coaches and to spread their learning about A3 problem-solving. Charlie organized a second cohort with a few dozen people who reported to members of the first cohort. Charlie and his leadership team would take them through a similar experience with classroom training and on-the-job coaching. The only difference was that Charlie and his direct reports fulfilled the coaching roles. This, in turn, began to transform the role of a leader at Turner, adding coaching as a key responsibility.

What management system is needed? How is it built?

The next turning point in the lean transformation that Charlie was leading was triggered by something that happened during the kickoff training for the second cohort. To get the process going, and to start building ownership of the problems to solve, he asked each member of the cohort to choose a problem they would work on. A list of these problems that were chosen was visualized on a whiteboard. During a break in the action, Charlie reviewed the list of problems. There were issues with schedules, change orders, punch lists, and budgets, but nothing related to safety. He was taken aback.

For sure, the business unit had plenty of problems with quality, schedule, and cost from which to choose; the problems on the whiteboard were legit. But there were also plenty of safety problems that could have been chosen. And, in fact, the safety record in New York was relatively poor. Moreover, the CEO and other top leaders in the company, were consistently messaging safety as a top priority. So, Charlie wondered, why didn’t anyone choose a safety problem to work on? (Come to think of it, why hadn’t he chosen to work on a safety problem with his A3?)

Basically, Charlie had two options: (1) He could simply force people to work on safety problems, but he knew this would put their willingness to own their problems at risk. (2) He could create conditions that lead people to choose to choose safety problems on their own. It was Mark Reich who pitched hoshin kanri as a way to do the latter. Thus, adding hoshin kanri to the business unit’s emerging management system became the next turning point. With the addition of hoshin kanri, the management system was complete in terms of enabling bottom-up and top-down collaboration and improvement, and ongoing transformation as needed by ever-changing circumstances.

What is the basic thinking?

Charlie’s story perfectly illustrates a major challenge with large-scale lean transformation. It takes time. While the vision or future-state target may be clear and relatively fixed, even initially, what will happen along the transformation path is unpredictable. For one thing, the external environment will change. Therefore, while there is value in planning, there is also value in equipping yourself with ways to “check and adjust” as you go. Charlie was equipped with the questions of the LTF, practicing its use with the support of a coach who had more experience with it than he did.

What about you? Are you embarking on a lean transformation, perhaps trying to implement a lean management system, with a fixed plan and timetable? Or are you, like Charlie—with the vision of a collaborative, fact-based, problem-solving culture that increasingly improves performance and helps people learn and grow—setting off on an undefined path, acknowledging that turning points are inevitable and can even be desirable so long as there’s a way—a process—to navigate them effectively? If you do have this mindset, then I encourage you to start practice with the LTF. You can start by asking, “What problem am I trying to solve…here and now?