Lean Product and Process Development at Scale: Implementing Obeya Across Global Teams
By Steve Shoemaker
“Make it visible” are the words I most remember from any discussions I’ve had with Jim Morgan, PhD, a globally recognized expert in product development and coauthor of Designing the Future and The Toyota Product Development System. “It” is the work. Seeing “it,” the work, in a factory is relatively straightforward. Seeing “it” in the world of product development is hard at best and grows increasingly difficult with project complexity, including locations involved in the project.
Our division jumped into Lean Product and Process Development (LPPD) in the summer of 2018, taking advantage of attending the first “Designing the Future” conference in Traverse City, MI. I had elected to send engineers from the US and French campuses, a total of five locations and 17 engineers. This exposed all product lines equally to this new development approach. In addition to these five primary locations, there were teams in Italy, Brazil, India, Thailand, and China that were intertwined.
When I say jumped, I mean exactly that. The conventional approach to introducing lean is to develop a single experiment that demonstrates success so that it can then be replicated across the organization. In the case of Caterpillar’s Earthmoving division, I did not have the confidence that this approach would work given our circumstance. We were under tremendous cost pressure, both variable and period costs. Management was impatient for change and so action on all fronts was vital.
The division had a common banner to drive a feeling of unity. However, each location operated under its own manager and set of financials. This independence was a source of pride and a barrier to ideas from elsewhere. Not invented here reigned supreme. Consequently, seeds had to be planted in each location to bloom in the light of local teams. Finding common ground for sharing best practices would come in time.
Make it visible
The obeya is a common starting place for most LPPD journeys. It builds off the value-stream map and quickly helps the team see the flow of work for better value creation. It also helps team members see who their customers are from a value-creation perspective. It is easy to think only of the end user as the customer in the development cycle. To be sure, this is the person exchanging currency for your product. However, from a development cycle, there are many customers throughout the process. In the case of an engineer, he or she could be designing a part that will be manufactured by an external supplier and then shipped into a factory for final assembly into a machine or automobile. In this case, the engineer would need to collaborate closely with the supplier to create a successful design.
The obeya serves as a coordination center to ensure the value stream flows smoothly. It allows the team to see development in real-time and respond to problems as mole hills before they become mountains.
Different strokes for different folks
My first obeya visit was at the Solar Turbine facility in San Diego, CA. At the time, I was based in North Carolina in our small-machine division and was eager to build on the momentum from another part of the company. I was intrigued by the process and the metrics used to run the obeya. As I snapped pictures so we could replicate it back home, Howard Kinkade, the leader responsible for the obeya, commented, “Take all the photos you’d like, but I don’t think they will help you much.” I was dumbfounded. “It works here. Why shouldn’t we just take what you’ve got and run with it?” I retorted. “The team needs to own the obeya and part of owning the obeya is deciding what gets used to run the project,” Kinkade emphasized.
Conventional wisdom suggests that each team and location should have the same look and feel. They should all work to the same metrics. They should all have the same charts. This is an easy trap to fall into. The intent is not bad but can negate creativity. Most teams have their own ideas and part of the creativity and knowledge development aspect of lean is to learn by doing. Creating an obeya purpose fit for a common team or project allows the team to try ideas and to adopt what works and trash what doesn’t.
Seldom is a project run entirely in one location. The obeya must be flexible to accommodate team members from multiple sites, sometimes in different locations in the same facility or city and sometimes in different states or countries.
In our case, it was common to have teams around the world engaged in the same project. For example, team members in China, India, France, and the US would be working on the same bulldozer program. This is where the visibility enabled by the value stream map in the obeya is crucial. Inputs and outputs (to and from different locations) are made visible and become part of the development process. Technology has simplified this significantly and it remains imperative that someone be part of the obeya process who is accountable for representing workflow (inputs and outputs) even for remote locations. This can be challenging and, at times, will require special effort to accommodate time zones. It is worth the effort to include all locations, even if it is difficult. Inclusion builds team accountability and is vital to a well-run obeya.
Project obeyas are for teams (not for management)
An important equation introduced in the book Designing the Future is: MS = OS x LB.
It means that a Management System (MS) is a product of the Operating System (OS) and Leadership Behaviors (LB). When leadership behaviors are good, they have a compounding impact. Bad leadership behaviors have a deteriorating impact and become challenging to overcome.
I suggested earlier that we introduce LPPD at multiple locations concurrently. This allowed multiple teams to experience this new way of development together and yet in their own locations. We had many obeyas running, and naturally, they were not the same. I asked the chief engineers to share what was working and not working at their locations with their peers. This allowed cross-site learning to be pulled rather than pushed (by me) and adoption of what each team considered a best practice. Consequently, it enabled them to solve problems while enhancing organizational learning.
Jim Lancaster shared a similar lesson in his book The Work of Management. He highlighted that in his factory, he did not require common charts that made it easier for him to move from one zone to the next but rather wanted to ensure ownership from the team to continuously improve their work: “We decided on a few standards for presenting information on the board. Improvement activities to raise the level of performance always went on the right side of the board, while daily issues about maintaining performance went on the left. But mostly, we wanted those boards to be useful to the people on the front line.”*
I considered myself blessed to experience the innovation that each team demonstrated as they launched their obeyas at sites around the globe. My leadership staff and I could not have prescribed the solution that best served each team. Naturally, common themes developed around quality, velocity (AKA timeline), resources, and priorities. Over time, much of the content migrated to be similar and often the same. This was by the teams’ choice and not by a management mandate.
Steve Shoemaker is Senior Advisor, Product and Process Development for the Lean Enterprise Institute. Previously, he served as Vice President of Engineering for Caterpillar’s Earthmoving Division until his retirement in December 2022. Since 2017, Shoemaker led the division’s global product development with offices around the world.
*Jim Lancaster, The Work of Management: A Daily Path to Sustainable Improvement (Boston: Lean Enterprise Institute Inc., 2017), 29.
