Back in the early 1990s I was an avid skier, putting in 40+ days on the slopes every season. I was part of a group that did days in local (to Seattle) ski areas; annual trips to Whistler, BC (my favorite place); Mount Hood and Mount Bachelor in Oregon; and a semi-fateful trip to Red Mountain in Trail, British Columbia in March of 1993. Red Mountain is known for its challenging terrain.
March 13, 1993: Mark and the Red Mountain ski patrol
I was a pretty good skier, though not an expert. There were places where I would be in over my head. And I followed some expert skier friends into one of those places. To cut to the chase, I ended up learning how to spell “anterior cruciate ligament” and later on how to spell “arthroscope.”
My torn ACL was a technical problem, but not one I was (or am) qualified to fix. I outsourced the solution to a technical expert – an orthopedic surgeon and his team. They did a great job. Today that knee is better than the original equipment.
But the surgical, technical repair did not address the root cause of the problem. I could not outsource that. The work was mine, and mine alone, to do. Dealing with the root cause required me to change my own behavior. I had a few choices:
I could give up skiing entirely. Nope, too much fun.
I could take fewer risks, though that would mean plateauing my own learning.
I could work deliberately* to become a better skier so I can take on more challenging terrain with reduced risk of serious injury.**
No matter which of those courses of action I chose, they are not things I can assign to someone else to do for me. I have to do the work myself. Solving the problem requires a change in my own behavior.
I believe it was Ron Heifetz at Harvard who coined the term “adaptive leadership” to describe leading for behavior changes vs. simply guiding technical solutions. If you are a change agent, you are (or need to be) engaging in adaptive leadership.
In the context of continuous improvement, we are talking about the culture change that has to accompany any technical implementations if they are to stick for more than a few months.
Trying Technical Solutions on Adaptive Problems
An organization had a culture of working around their ERP / MRP system. If production fell behind, they extended lead times in the system (which is the worst thing you can do in this case). They would schedule “hot” orders in the past to force them to the top of the queue, driving material shortages for later orders – repeating the cycle.
They all believed that the computer system itself wasn’t up to the task of managing their “complex requirements.” (Which actually weren’t that complex at all – everyone seems to think their production portfolio is more complicated than everyone else’s.)
The new system, though, would fix all of this.
When the new system went into place, though, things got worse. Much worse. They doubled down on the same things they had done in the past, which made things worse again.
This wasn’t a problem with the computer systems. It was a problem with the way the team members worked together, a problem with their understanding of how their computer systems responded to their manipulations. It was a problem that no changes to the I.T. systems could solve.
Not surprisingly the same organization had tried kanban in the past. And not surprisingly they had worked around the system to “solve” perceived problems, and not surprisingly they had blamed the system for the failures.
It would not matter what technical system they had, their results would ultimately be shortages, expediting, scrambling to rush late shipments out the door. It was not the technical systems that produced those results, it was their behavior.
What Kind of Change Do You Have to Make?
This is adapted from material published by the Kansas Leadership Center, see more below under Further Information and Reading. The expansion, examples and explanations are my interpretation.
What kind of problem are you facing?
Is the problem clearly defined (like my torn ACL)? Or do you have to begin work to learn what actual problem(s) you are facing? If the later, you are dealing with adaptive, culture change work.
What kind of solution can be applied?
If there is a clear solution, or one can be researched, then you are dealing with a technical problem. But if the solution must be learned, then more likely it is adaptive. One key indicator – if you have put in a technical solution (like “standard work” or “5S” for example), but then seen it erode, then you are probably in adaptive territory. You have to learn what unseen factors are driving how people respond.
What kind of work is involved to apply the solution?
If you can just implement, like buying or upgrading a machine, then you are in technical territory. But if you have to diagnose, experiment, learn about things like the organizational dynamics then you are dealing with people’s behavior – an adaptive problem. Like above, I have seen many cases where a technical solution was implemented only to have that surface all kinds of adaptive and leadership issues. A new ERP system is a prime example. The software is the easy part. Beware of someone selling a “solution” by the way.
Whose Work Is It?
Even though this is a header, I bolded it, because this is The Critical Question. If technical experts or authority can just tell you what to do, then it is a technical problem.
But most meaningful change requires the stakeholders – the people responsible for the system and the results – to actually do the work themselves. This is the difference between fixing my torn ACL and the work I had to do.
In other words, if you put in “lean tools” (or complete a “black belt project”) only to see the results quickly eroding, then the technical tools, no matter how well you see them work elsewhere, are not going to help you. The organizations where you see them working have fundamentally different systems of leadership, and that is where the change must occur of the tools are going to work as promised.
What Timeline Should You Expect?
Technical solutions can be put in quickly. Anyone who has been though a classic “kaizen event” knows this. But changing people’s default thinking and behavior takes time because it takes practice and correction. And the default thinking and behavior is what created the technical systems you are trying to adjust. Eventually your kaizen blitz rocket runs out of fuel, and things fall back to Earth because gravity pulls them there.
What Are Your Expectations?
This is a tricky one. The whole reason to do any of this is to change results, change outcomes in some way. Technical solutions can do that pretty directly.
But when you are in adaptive territory, learning you way in, then you need to celebrate making progress and learn to trust the process – the results will come. Impatience does not serve us here.
Required Mindset
For technical solutions, skill and confidence are enough. You can hire someone with that. But if you are seeking to make real, meaningful change then you are better served with curiosity.
Further Information and Reading
If you want to learn more about Adaptive Leadership, here are some sources you can start with. Of course you can also leave a comment or click on “Contact Mark” in the right sidebar and ask me if any of this is interesting to you.
(Books are Amazon affiliate links, I get a small kickback at no cost to you if you buy through them.)
Teaching Leadership by Chris Green and Julia Fabris McBride, who are also affiliated with the KLC, is more technical and more advanced. It is targeted more at people who understand the basics, and have practiced a bit, who now want to begin to coach others.
The Practice of Adaptive Leadership by Ron Heifetz, Marty Linsky and Alexander Grashow is what I would call the baseline reference. The books above are geared toward developing your practice. This book is more about the underlying principles. It is also a heavier read, just so you know.
*Note the word deliberately. This meant taking lessons specifically targeting my skill gap. Simply putting in more hours skiing would not be deliberate practice, I would simply be reinforcing the habits I already had. In other words – get a coach.
**Some of my more astute – probably younger – readers may question my judgement about not wearing a helmet. At that time, helmets were pretty uncommon for recreational skiing. Thankfully that has changed in more recent times. And yes, today I wear one.
In early spring of 1999 I was sitting in a classroom at Boeing with a couple of dozen other employees. Everyone with a “management” job code was being sent to this session over a few weeks’ time.
The topic was a major new direction for the company. From this point forward, management was to use “shareholder value” as the primary consideration for decisions.
The main emphasis here was on a financial metric that would drive all decisions: RONA, or Return On Net Assets.
This was obviously a long time ago, and I have long since (unfortunately) discarded the handout materials because I wanted to reuse the fancy tabbed folder for something else. But as I recall, there were two primary topics discussed.
The first one was around what “shareholder value” meant. To that end they explained why maintaining a high stock price was important to the company: So they can raise money more easily for growth.
This was all about stock price. They didn’t talk about profits or dividends. Nor did they talk about executive bonuses or using excess cash for stock buybacks to raise the price of outstanding stock rather than investing that money into developing new aircraft; improving existing products or processes; or distributing that profit as dividends to the shareholders.
Of course, a high stock price enriches those people who already own shares, and makes options and stock grants more valuable, but they didn’t get into that either.
With the justification aside, they next had us go through exercises calculating net present value and ROI for a hypothetical capital investment in tooling – as though a shop floor supervisor would do this at any point in the course of their job. Maybe they wanted to show the thinking behind how requests for things like upgraded tooling were evaluated. I left the class not really sure of why they took us through that. I already understood those calculations from my background, but the shop floor guys were kind of scratching their heads.
The second part of the class involved a facilitator leading our group through discussion of the “grieving process” as it relates to “change” and trying to draw out how we felt about it. Then we were video-linked to other groups in identical sessions, perhaps in some effort to show how we were all in this together. Again, I wasn’t sure of the point of all of this.
Sidebar: If anyone reading this has better memory or still has any of the original materials from that class, I’d love to talk to you.
Overall, this shift was about the management process becoming financially centric. Boeing’s performance as a company since this shift has been (painfully) obvious to anyone who has been following business news over the last decade or so. The details have been covered elsewhere, so there is no need for me to reiterate them here. However, if you are interested in a succinct and well researched history, Petter Hörnfeldt is doing a fantastic job with a multi-part series on his Mentour NowYouTube channel.
Optimizing for RONA
RONA is calculated by dividing net profit by total assets. The obvious way to improve RONA is to improve operations and optimize processes to create maximum customer value for any given level of capital investment.
And this is exactly what Boeing had been working to do prior to this pivot toward “running like a business.” It was even developing a name: “Working Together.”
The Original Pivot: From “Do What You’re Told” toward “Working Together”
Ten years before this shift toward financialism, Boeing had been going through a different shift.
The Boeing that emerged from the early 1970s downturn was highly engineering centric. Engineers ran the company, engineers decided what would be designed and built. In the world of production, though, the culture was far from ideal.
I hired into Boeing in July of 1989. I was fresh out of the Army, and one of the contractors I had worked with in my last assignment was working as an Industrial Engineer in Boeing Flight Test. He introduced me, I had an interview (and couldn’t get a word in edgewise), and was offered the job.
At the time, Boeing was scrambling to keep up with deliveries for the hot-selling 747-400, and the Flight Test teams were helping prepare new planes for delivery. This involved inspections by the customer and test flights which, in turn, produced lists of things that needed to get fixed. My job, essentially, was to keep track of what was getting fixed, by who, and when, and produce daily reports on progress. My first plane was RT001 (internal production line number), the first 747-400 Combi being delivered to KLM.
The production processes were archaic, with legacies going back to the 1940s. Industrial engineers dutifully analyzed each job, and determined the time it should take. They used those times to build what were essentially Gantt Charts of the production plan for each worker. These were called “bar charts” and “making your bar” was, for all intents and purposes, how workers were evaluated.
The system was not robust, overtime would swing: When production managers were being beaten up about being behind schedule, they would turn on the overtime. A few weeks later, when overtime costs were climbing they were beaten up over that, and overtime would be shut down, leading everything started to get behind again.
Those costs were out of control. One bit of “common knowledge” in the company at the time – and I have to way to know if it was true, but it is certainly credible to me – was that for every four 747-400’s that Boeing delivered, they built the equivalent of five and threw one away into the scrap bins.
There wasn’t a lot of focus on the things that actually got in the way of people doing the work. There wasn’t time for that. Things were behind, and there was work to do.
With all of that, though, things had started to change. Boeing had brought in some of the well known quality names (Conway, Deming) in the late 1980s. In the late 1980s and early 1990s Colin Fox, an early consultant in the world of flow production, had led a series of study missions to Japan that engaged Boeing’s top 100 or so leaders.
Some of the pull quotes from those sessions were interesting – like the indignant reaction that Airbus would somehow dare to talk to long-established Boeing customers. These study missions were quite eye-opening for the participants.
These leaders had learned about the emphasis on quality, consistent execution, focus on the needs of the customer, using flow and just-in-time production to progressively surface problems, and engaging everyone to progressively drive those problems out of the system.
Those groups came back from their experience with an visceral understanding that the status-quo wasn’t going to cut it in the face of the then newly emerging Airbus. They realized then that Boeing had to transform itself from an engineering company focused solely on meeting engineering challenges to one focused on meeting the needs of the customers. But the key to meeting the needs of the customers was more than just understanding those needs better. It required creating a company culture that supported employees – everyone – to do the right thing for those customers.
Soon after these study missions someone decided, “Everyone in management needs to hear this.” The result was a 32 hour course that ran two days, then a break, then two days the following week. During the break, work teams were expected to do some homework assignments.
The idea was that the original leadership teams would teach this course to the next level of leadership, then train people at that level to teach the next – and cascade the teaching through the leadership ranks. The hypothesis was that since the message was coming from your immediate supervisory level, the thinking went, it would resonate better than if it was just professional instructors.
Sometime in late 1992 somebody then decided, “EVERYONE needs to hear this,” and the deployment was changed to include everyone in the company, all 130,000 people. That was, in my opinion, a smart move if only because it was a move toward transparency. The class wasn’t some secret management thing.
I was aware of all of this because one of the supervisors (though not my direct supervisor) in the Industrial Engineering group I was working in had become an evangelist, and ultimately put in charge of coordinating the delivery of the class through about half of the company. (The “Renton Division” – at the time Boeing was essentially North Boeing (in Everett) and South Boeing (in Renton.))
He and I had a lot of common values and background, and he shared a lot of his excitement with me.
When they started rolling the class out to second shift he told me they had an extra slot on one of the sessions and I managed to wrangle attending, probably about a year before I would have otherwise. I went to a 2nd shift schedule, and attended the class… on crutches, as I was recovering from ACL reconstruction surgery at the time. This would have been late spring 1993.
But his real agenda here – I later learned – was that he wanted me to teach it. To that end, he had established a program of inviting “non-management volunteers” as instructors. Within a month of having attended the course, I was one of the instructors delivering it. I taught it (always as part of a team of four) about a dozen times, always to an audience of hourly employees (union members). They could be a tough audience, but not necessarily for the reasons you might expect.
Why am I telling you all of this?
I think it is important to relate that this is my personal story and experience rather than just reporting on something. I do not pretend to be a journalist, and am certainly not objective in this case. While Boeing had lots of issues, at the time I felt they were generally trying to move in the right direction and the potential was, simply put, unlimited. I believed, and still believe, that Boeing at the time had the technical capability – if they had the financial resources – to land people on the Moon (and return them safely to the Earth).
Managing for World Class Competitiveness
The name of this course was Managing for World Class Competitiveness.
The core message was (quoting from an introductory slide):
Management is responsible for and committed to making Boeing a world-class company.
To become a world-class company requires an understanding how world-class companies operate.
Continuous Quality Improvement encompasses all of what you are about to learn.
Remember that this was 1992 or so. The “continuous improvement world” was in a gradual shift from the language of TQM (big ‘Q’ Quality) to looking at the Toyota Production System as a specific benchmark. Although The Machine That Changed The World had just been published, the word “lean” was not yet in common use to describe these things. We referred to “Japanese Management” or “JIT” to describe what, today, we call “lean.”
Other context – Six Sigma was largely a Motorola thing, and was just beginning the morph that happened as it passed through G.E. It for sure had not yet had the word “Lean” spliced onto it. I think that happened in the late 90s, and if I recall correctly (and I could be wrong), it happened at Maytag.
Other WCC Key Messages (Quotes from Key Slides)
Superb manufacturing processes, delivering world-class levels of quality, are a primary source of competitive advantage.
The product development process, likewise, must be focused, fast, and integrated with production.
Leadership and management systems focus on operational strategic objectives that, in turn deliver financial performance.
This last bullet is a critical point. It is the one that was totally lost later.
World Class Principles
Without going into all of the content, I think I can summarize the core messages with the “Twelve World-Class Principles” which, I think, have aged pretty well:
Quality First: policy in action.
Customer-driven.
Partnership with people.
Management leadership.
Quality built in.
Organizational alignment.
Cross-organizational coordination for the customer.
Elimination of waste: Focus on adding value.
Reliable processes through reliable methods.
Healthy work environment.
Simplify.
Continuous improvement as a way of life.
The Impact
The course rolled down through the company into 1994. There was also an economic downturn happening, at least in aerospace. Some of the hourly mechanics in the classes I was teaching had already been notified they were being laid off. That could have created some real awkward moments – and it did. But most of those guys were actually thankful to have been sent to the class when there was no business need to do so. “You guys are showing me how to run a business if I end up starting one.”
In the background, also in the early 90s, Boeing was beginning to experiment with things like 5S and “Accelerated Improvement Workshops” (AIW) (aka kaizen events). Most of these were small-scale tactical affairs.
Also happening in this time was the development of the Boeing 777. Alan Mulally, as the chief engineer / program owner (and later the President of Boeing Commercial Airplanes) had introduced the theme “Working Together” to describe how they were going to involve key customers, like flight-line mechanics from United Airlines, directly into the process of specification, design, and testing.
The new plane was also being designed with producibility in mind. The structural designs were far more tolerant of production variation, for example. This was also the first Boeing plane to be designed in electronic 3D CAD systems that showed things like interference. Boeing had worked with Dassault Systems to develop CATIA pretty much for this project.
Outside of 777 development, around 1994 or so, Pratt and Whitney (who are profiled in Womack and Jones’ book Lean Thinking) introduced Boeing to Shingijutsu, the Japanese consultants that were made famous by that book. My experience was that they, especially Mr. Iwata and Mr. Nakao, challenged Boeing to take the game up quite a few levels.
Peak Boeing
On April 9, 1994 I took my then-girlfriend-now-wife as my guest to the rollout for the new Boeing 777. There were actually 15 “rollouts” that day – this was a major celebration, and over 100,000 people attended. The company had hired Dick Clark Production to stage the event, and even thinking about it today still brings (good) chills. It was a triumph moment for everyone.
What followed was regarded as the most intense, and smoothest, flight test and certification program Boeing had ever done. The goal was to deliver this long-range twin-engine plane with the certification to fly long-haul over water from day one. This was the first time that had ever been done. It was ambitious, to say the least, as these were also new engine designs from G.E., Pratt and Whitney, and Rolls Royce. Side note: The engines on the 777 are roughly the same outside diameter as a single-aisle airliner’s fuselage.
The first 777 delivery took place in May, 1995 – pretty much exactly as had been promised back in late 1989/early 1990 when the design program was officially launched.
All of the above was a triumph in the engineering and product development process.
Production, though, still had work to do.
Working Together in Manufacturing
The story about the overtime cycles I told earlier was the world my by-now-wife was dealing in when she was working night shift on the 777 assembly line in 1998 as she was part of the team putting together the fuselage section that sits over the wing (called the “44 Section”). By the time she was working there, they were running a takt time of 3 days, which, for something this large and complex, is impressive.
While the design of the airplane made the airframe much easier to assemble compared, for example, to the 1970 era 747, there were still supplier quality issues and general “stuff” to deal with in production. They worked very hard, much harder than they really should have needed to.
While this was all happening in Everett, there was a revolution happening in Renton.
At some point, Mr. Iwata, the chairman of Shingijutsu Consulting, had challenged Boeing to build planes on a moving assembly line.
The original response to that challenge was a team trying to design a moving assembly line. Their approach was to try to work out solutions to all of the problems that would entail and then build the line and run it. There were a few iterations of this effort, but they all got overwhelmed in the thousands (millions?) of details. They were trying to develop solutions to every problem they could imagine.
Just for context, this is what Boeing 737 final assembly looked like in 1990 when they were running a cycle of 20 planes / month (one per workday):
There were actually two lines running parallel, each one on a two day cycle. Toward the top of the picture you can see the “slant positions.” Each time the line was indexed, it generally took a shift to, in succession, pull each plane back, then forward, then dock it into the next position. And because this was a schedule-driven line, the planes moved on time, ready or not. Incomplete work became “travelers” – jobs that traveled with the plane to be completed later when, for example, the parts became available. Exactly who was supposed to do that out-of-sequence work while everyone was busy with the scheduled jobs was a little vague. Usually… overtime.
There are about 23 planes of work-in-process in this photo.
The assembly manager for 737 then ran an experiment. Instead of trying to solve all of the problems they could think of before trying anything she took the opposite approach. She got an RV winch, bolted it to the floor by the door, hooked the cable to the last plane, and started pulling it – slowly – through the work position. If everything was going smoothly, they kept pulling. If something disrupted the work, they stopped the winch, wrote that down, and picked off a few of those things to try to fix on the next cycle.
It took a few years, but this is what the same line, making the same planes, at the same one-plane-a-day rate, looked like by 2000:
There is only one line. The planes are nose-to-tail. What you can’t see here is that those planes are all moving toward the door at about three inches per minute.
After I had left Boeing, I had the opportunity to organize a study mission group through a series of factories in the Puget Sound area. One of them was the Boeing 737 moving line. This was late 2002, they had gone through a recession, and were in the process of ramping back up. (There was no public tour for this, you had to know someone.)
This is part of the report I submitted to our VP of Operations at Genie (Colin Fox – remember that name from earlier?) the next day:
Renton is building the 737 at a rate of 14 planes per month with a two shift operation on a moving assembly line. Although they are very clear that they are still in transition, our tour guide (the 737 program manager) told us their hours worked per plane have been cut roughly in half. The reduction has been through the elimination of rework and overtime – building the plane on the intended schedule – rather than absolute gains in productivity. They achieved this by implementing aggressive expectations for problem escalation and response from support organizations. This has been a major culture shift as the support organizations shift their approach from “I’ll get back to you” to a sense of urgency about getting production started again. There are andon and status screens for each position on the assembly line.
Additionally they have ship sets (What we would call a “unit set.”) of parts and tools delivered to the work position for each shift of work. This has eliminated the shift start-up ritual of a mechanic looking up his jobs, investigating the engineering drawings, going and finding his parts, going and getting his tools, visiting the chemical crib to get his materials, etc, etc. Instead the mechanic can get straight to work.
Just as impressive is that they do this with less than half the number of aircraft-in-process as they would have had with their traditional slant-position approach. Where they used to have a month or more of flow through the line they are down to a little over a week.
Mary, our tour guide, also discussed some of the leadership challenges at length. She encountered considerable “what about” type resistance from traditionally thinking support organizations who wanted to solve every problem they could imagine before proceeding. She was adamant that the only way they could get anywhere was to just try it and see what happens. They started the way Henry Ford did – by pulling a plane down the line with a winch to see what disrupted the flow, and fixed the problems as they came up.
Boeing’s other assembly lines are studying the lessons from 737 (and 717 in Long Beach). The gains realized in converting from a pulse type line to a continuously moving line are no longer in question there because someone has gone and tried it. Equally impressive is that the “Snohomish Airplane Company” (Everett) is studying and adapting ideas from the “Lake Washington Airplane Company” (Renton). Traditionally there has been very little travel of ideas across this divisional boundary. (“Big airplanes are different from little airplanes” and vice-versa.) The 747 is continuously moving through part of its production – using the winch mechanism that 737 gave them.
On that same tour we also saw amazing efforts in their Fabrication Division in Auburn.
Like all of Boeing’s operations, the Fabrication Division has been severely impacted by their workforce reductions. They told us they are down to approximately 8,000 employees from 14,000. They have been consolidating plants – partly due to reduced capacity requirements and partly due to lean manufacturing improvements. They recently sold a major portion of their Auburn property to Safeway. In addition, they are consolidating operations out of Harbour Pointe (near Everett) into Auburn and Everett.
At our request, the tour highlighted their technology for developing custom ‘right sized’ equipment and machinery. Boeing’s first chaku-chaku line went into operation in early 1999, but faced significant management resistance. Since then Boeing has had a clear, but unpublished, intention to get out of the fabrication business and outsource it. The Fabrication Division has seized the crisis. Everyone we spoke to is very clear that they must compete against a world-wide supply base to stay in business. They want to be the “preferred supplier” for the parts they make. The Fabrication Division no longer regard their existence as a given.
Their response has been to attack capital expense.
The technology is most widely deployed in their Integrated Aerostructures operation. This is where the original chaku-chaku line was developed. That line is still in operation, along side a second generation set of equipment.
Throughout the tour I observed that they have a technology base – a consistent approach for designing and developing this equipment. But this base is not an anchor. Rather, it gives them a platform from which to improve. Each generation or project clearly adds features and sophistication (though not complexity). In all cases they are focused on single-piece takt time production with minimum capital, minimum labor and maximum quality.
Although the machine shop and emergent manufacturing are not as far along, they have boosted the level of effort in those areas by shifting people from the Integrated Aerostructures moonshine teams into those operations. The solutions we saw in those facilities were no less innovative, they simply did not have the breadth of implementation yet.
We also saw early examples of ‘bus routes’ for drop-off and pick-up of work in process from point to point, visual scheduling and pacing boards.
On the down side, their orders are still ERP / MRP generated, and they have yet to integrate their internal supply chains with pull. In my opinion this will be a difficult challenge as it requires a breakdown of traditional organizational boundaries. While they are deploying innovative production technology, those areas are still islands of flow in a largely batch environment. This is even more true in the Interiors operation in Everett (which I visited this Fall) where one-piece-flow fabrication cells are loading carts of parts that feed batch assembly operations a few feet away.
The obvious (to me) end-game would be to develop right-sized processing and finishing operations that allow detail fabrication to be exported from the Fabrication Division in Auburn to the line side at the assembly plants in Renton and Everett. Again – whether they do this or not will depend on whether Fabrication Division shift their emphasis from being a parts supplier to being a technology supplier, and overcome a reluctance to take on processes that affect metallurgical characteristics such as aging or heat treating.
Just to be clear, I did not cite this report from memory 20+ years later, I copied and pasted from the report that I actually submitted. This was my reflection at the time.
To put it simply, Boeing was on the verge of the breakthrough. They knew what to do, they knew how to do it. The approach was diffusing beyond a few staff specialists. There was a sense of purpose.
But all of this was 2002. The pivot to financially driven management had been underway for three years by that point.
The bit that is lost here is that all of these efforts were focused on improving RONA – Return on Net Assets. In Renton they were working on improving the return to get more value out of the assets that were already in place rather than continuing to add more. In Auburn they were working to develop equipment that was cheap and scalable that was just as (or more) capable as the large, expensive, automated equipment it was replacing. Less capital, more flexibility, linear scalability, little or no depreciation costs booked.
But from corporate HQ, the Jack Welch protégés that were now running the company had a quicker way to get to that RONA number: Attack the denominator: slash assets. To that end they were working to outsource large swaths of production, especially capital intensive parts like fabrication and airframe assembly; as well as a large portion of the design process itself.
By 2003 I had left the Puget Sound area for a few years and the only information I had about things happening inside Boeing at that point would be from reports in the press. The 787 program had run years behind schedule and billions over budget. The 767 Tanker program for the Air Force had been through a series of scandals, and then persistent overruns and quality issues.
Years later I joined another group touring the 737 “moving” line. By this point, though, the line was not actually moving. The tugs were just used to pull the stationary planes to the next position. We were told they would start moving the line again, “once we have solved enough problems.” The thinking had reverted – we have to solve the problems before we try, rather than trying to surface the problems we have to solve to make it work.
Fear had re-entered the equation. It was becoming palpable even to me as, now, an outsider just visiting.
Then in late 2018 and early 2019 two 737 Max planes crashed within five months of each other, for the same reason, with the loss of 346 lives.
Up to that point the cost of managing for “Shareholder Value” had been tremendous, but limited to damaging Boeing’s reputation and finances, as well as the morale in its workforce. Now people had died.
The rest of the story, honestly, remains to be told.
Boeing is at another turning point.
All of Boeing’s CEOs since the resignation of Phil Condit, have been Jack Welch protégés. Welch’s legacy at G.E. was, ultimately, to destroy the company. As I am writing this G.E. has finally completed the breakup into major divisions. Their current CEO, Larry Culp has, at least from what I have heard from people working there, repudiated the Welch era and is focusing on building a culture of teamwork.
If Boeing’s board can find the courage to admit that the results of last quarter decade have been the direct and predictable (and replicable in other companies) outcome of the way the company has been led and managed then maybe, just maybe, they have enough airspeed and altitude to recover from a flat spin.
I recently did an “Introduction to Toyota Kata” session for Kata School Cascadia. The intent is to give an overview of my interpretation of the background, and how Toyota Kata fits into, and augments, your Continuous Improvement effort.
Here is a direct URL in case you can’t see the embed on your phone or pad: https://videopress.com/v/4vWvDZRe
In this presentation I go over what I mean when I say “culture” and then briefly discuss a “continuous improvement culture.” Then introduce the “why” of Toyota Kata as a way to start to nudge the culture in the direction we want it to go.
Finally I overview the structure of the Improvement Kata and Coaching Kata, then answer a couple of questions.
Continuing on the theme of value stream mapping (and process mapping in general) – in the last post, Where is your value stream map? I outlined the typical scenario – the map is built by the Continuous Improvement Team, and they are the ones primarily engaged in the conversations about how to close the gap between the current state and the future state.
The challenge here is that ultimately it is the line leadership, not the Continuous Improvement Team, that drives whether or not this effort is long-term successful.
Getting a continuous improvement culture into place means changing the day-to-day patterns of interaction between people and groups of people. We can put in all of the lean tools we want, but if those conversations don’t follow, the system quickly reverts to the previous baseline.
What is interesting (to me, but I admit I’m a geek about this stuff) is that this is a meta level thing. While we are working on improving the performance of the value stream, we really have to be working on the performance of the process of leadership in the organization.
The value stream map can help with this, but we have to be deliberate about it, and realize that it will be an incremental and iterative process, just as we find in trying to improve how any process functions.
Start With Where You Want To Go
For line leadership, before we even start drawing process boxes, the first step is deciding why you are even doing this. What problem are you trying to solve? What aspect of your current performance needs to change… dramatically?
Is your system unresponsive to customers? Do customers expect deliveries inside your nominal lead times? Does that disrupt your system? What lead time capability would let you routinely handle these issues so they weren’t even issues anymore, just normal operations? That objective is going to bias your current state VSM toward understanding what is driving your lead times, where, when, and for how long, work is idle vs. actually being processed, etc.
Or maybe you need to increase your capacity while holding your costs (vs. just duplicating the existing processes). Now you are going to be focusing on the things that constrain your throughput, activities that consume time within cycles of output and the like.
Establishing that focus is a leadership / management task. It doesn’t work to just say “We need to improve” or even worse “We need to get lean.”
Sometimes these things are obvious frustrations to management, but often they are overwhelmed with general performance issues, or trying to define problems in terms of financials. That is an opportunity to focus back on the kind of performance that would address the financials.
The cool thing here is that you really can’t get this wrong. If you set a goal of radically improving your performance on any single aspect of your operation, you will end up improving pretty much everything in the process of reaching that goal. But it is critically important to have a goal to strive for, otherwise people are just trying to “improve” without any objective.
Then map your current state. The challenge gives you context. The current state map gives you a picture of how and why the system performs as it does.
Just so we don’t get sucked down the whirlpool of focusing too much on the business process in this discussion, the reason why you are getting this clarity is to get (and keep) the leaders engaged. If the objective is something abstract like “get lean” it is easy for them to think they can just get updates while they deal with the “real issues.” We want to attach this to a real issue that they are already working on.
Thus there is no “lean plan.” So many companies make “lean” somehow separate from other business objectives. I never could understand that. Maybe they are trying to separate “gains” that are a result of the “lean program” from those created by other initiatives. It doesn’t work that way. There is only one operating system in play, and that is what drives your day-to-day performance. If you don’t like the performance, you have to change the operating system. That is a management function, and it can’t be delegated.
The photo above is a current state map from a process that took several weeks to ship a part that the customer had ordered. Since it was a make-to-order shop, this was, shall we say, challenging for the customer relationship people.
As the team built the map it began to sink in that the time actually making the part was less than 30 minutes, and the value add was about six of those minutes. Their performance metric was “Past Due Hours” which was an abstraction of the programmed jobs that were behind the promised ship date.
Because the customers were always asking the business team members, “Where’s my stuff?” those customer reps were, in turn, always on the shop floor trying to get their orders expedited. They were competing with one another for a place in the production queue.
There is an icon in the middle of the map. Here is a close up:
This is Jim. He was an hourly associate whose nominal job was to pull the paperwork, match it up with raw material, and stage the work package into the production queue.
But this role made him the gatekeeper. So the customer service people (you can see their names in the lower left corner) would be pressuring Jim to jump their hot orders (and they were all hot by the time it got to the point where there was paperwork release – another story) into the queue so they could tell their customers that their orders were “in production.”
This put Jim in the position of having to make the priority decisions that the leadership wouldn’t make. Ultimately it was Jim who decided which customers would be disappointed that day. That made his day way more stressful than his pay grade. Respect for people? Hardly.
It also resulted in a staged order queue (materials and paperwork on carts) that snaked through the shop until it finally (days later) got to the actual production cell which, once they started, could actually knock things out pretty fast.
None of this addressed the past due issue. In fact, this made it worse.*
The key question for this team was “Who needs to have what conversation about work priorities so it isn’t all on an hourly associate to decide which of our customers will be disappointed?”
Who Needs To Fix This?
We want to solve problems at the lowest possible level, but no lower. In this working example, asking the shop floor workforce to fix this problem would be futile. Yes, they can propose a different structure, but they do not control how orders are released, they do not control how capacity is managed, they do not control the account managers who are fighting for a spot in the queue. They had been complaining about this bind for a long time. It wasn’t until the people running the business saw how the overall system worked that they understood that this is a systemic issue, and “the system” belongs to line management.
The facilitation question that got their attention was “Do you want Jim to be the one who decides who gets production priority?” Of course the answer was “No.” And that wasn’t about Jim, rather it was the realization that this WAS the existing process, and that wasn’t how they wanted things to operate. As my friend Brian says, “You may not like your normal, but you have to deal with it.”
That is generally the case at the value stream level. Value stream problems are usually at the interfaces between processes. The shop floor can’t, for example, transition from a push scheduling system to pull on their own. If they try, they create conflicts with the existing scheduling system and this usually tanks their metrics – even if performance is actually getting better.
These are all management discussions.
Key Point: The value stream level is a systems view. While you absolutely want input from the people who are engaged in the work every day, working on the system itself is not something that can be delegated by line leadership. They are the ones who are responsible for the overall system, and they are the ones who need to be responsible for changing it.
The Future State Map is a Hypothesis
Once you understand the current condition, the next step is to answer the question, “How does the process need to operate in order to meet our goal?”
The purpose of mapping a future state is to design process flow that you believe will meet your challenge if you can get the system to work that way.
It isn’t about seeing what you could do by removing waste. It isn’t “what could we improve,” it is “what must we change to reach our objective?” Again, this is a management function. It’s called “leadership.”
Which brings me to the title of this post.
Who Is Talking About This Stuff?
If the Continuous Improvement Team simply facilitated the process for line leadership (the actual stakeholders) to grasp the current condition and establish a target (future state) condition, what is crucial is who takes ownership of closing the gap. If the C.I. team are the ones discussing the problems they are often in a position of having to sell and justify every step of the effort to get to the future state.
Likewise, I have seen a lot of cases where the people primarily participating in building the value stream map were working level team members. Yes, it is absolutely necessary to have their insights into how things really are for people trying to get stuff done. Yes, it is critically helpful for them to understand the bigger picture context of what they do. However, all too often, I see senior leaders disengaged under the umbrella that they are “empowering” their workers.
Just to be clear: We absolutely want to create conversations about improvement at the level of the organization where value and the customer’s experience is actually created. The point here is that those conversations cannot be the exclusive domain of the working levels. It is critical for line leadership to be, well, leading. They can’t just delegate this to the continuous improvement specialists. Nor can they simply leave it to the working levels to sort it out – not if they expect it to work for any length of time.
Who reports on progress?
When an executive wants to know the progress toward an improvement goal, who do they call? Do they call the continuous improvement team to report? Or do they call the actual stakeholder who is responsible?
This is an easy trap to fall into. The C.I. Manager wants to show they are making a difference. The senior manager knows the C.I. Manager probably has better information. But that isn’t the conversation we want to create. The conversation needs to be between the line leaders. Yes, the C.I. team can (and probably should) help structure that conversation, but if they inject themselves into the middle (or allow senior management to put them there) the vital vertical connections are weakened – if they ever existed.
Thus, it is critical for the Continuous Improvement team to have a crystal clear picture of who should be having these conversations, and be actively working to nudge things in that direction. This is the process the C.I. team should actually be working to improve.
What should people talk about?
Ah, here’s the rub. For some reason managers today have a reluctance (or even disdain) to talk about operations, preferring to keep conversations in financial terms of cost, earned hours, yield and the like. These are all outcomes, but they are outcomes of process, and it is only by changing the process that those outcomes can sustainably change.
That conversation about progress I talked about above? That can’t be solely about the performance. It has to be about what is changing in the way the work is being done, and more importantly, what is being learned.
What the future state value stream map does (or should be used to do) is translate those business objectives into operational requirements for the process.
What Is Your Target Condition?
How we start to see the organic intersection between Toyota Kata and the value stream map.
The future state map defines a management goal. It also highlights the problems that must be solved to get there. (Those are the “kaizen bursts” that Learning to See has you put on the future state map.)
Those problems, or obstacles in Toyota Kata terms, at the value stream level become challenges (again in Toyota Kata terms) for the respective process owners.
Now the conversations move to the right level. Rather than asking for the status of action items for the “lead time reduction initiative,” the line leaders are discussing progress toward getting the changeover in stamping down to 17 minutes, and the cycle times in the weld cell under the takt time.
In my working example above, the first target condition was to have Jim simply pull the next order from a FIFO queue in a series of slots on the wall. The customer service reps had to meet every morning and could reshuffle the orders in those slots all they wanted, but Jim’s job was just to take the next one. That pushed the initial conversation to the one they had been avoiding: The customer service team talking among themselves, rather than making Jim the arbitrator.
There was a lot of other work as well. They established a rigid FIFO with a fixed WIP level of staged orders. Instead of pushing days of work into that queue, there was a buffer of about an hour (to absorb variation in processing times between various jobs).
At the same time, the team running machines now understood the rate of processing that was required to keep up with the volume of work. That had been totally hidden by the queues before. All they knew is that they were behind. Now the conversation shifted to “Are we going fast enough?” It shifted from discussions about backlog (which really are not productive) to discussions about rate of processing which is the only thing that affects the backlog.
Getting all of this dialed in and stable took a few weeks of daily conversations between the Operations Director and the various managers and supervisors whose work impacted the flow. It involved walking the floor, putting in visual indicators that clearly defined what should be happening – the target condition – and they discussed reasons things looked different: The actual condition now, and what obstacles were being surfaced as they worked to reduce the WIP buffers.
The net result?
Learning is Critical
The current performance is an outcome of the current system. People do their best within the system they have to work within, and we have to assume the system reflects management’s understanding of how things should operate to get the best results.
Even if someone knows a better way, that knowledge is wasted unless it is applied to the overall system of operating – the way we do things.
Epilog
You would never say “The freezer is cold enough, we can unplug it now.” You have to keep putting energy into the system just to keep the temperature where it is. Tightly performing production systems are no different. Over the course of the next year or so past due hours slowly crept back up for unknown reasons. Why? Because they didn’t talk about it every day.
*When a shop is behind, the management reflexes are (1) increasing batch sizes and (2) expediting. There really aren’t any better ways to make the throughout and response times worse.
Thanks to everyone who left comments on the last post, Learning to See in 2023. You are making me think.
Although Learning to See (the book) describes building your value stream map on A3 / 11×17 paper, most of the maps I have seen have been large affairs on a wall.
I like this approach because it shifts people into the position of standing side-by-side talking about what is in front of them, which fosters collaboration.
The question in the title, though, is more about whose wall is it? Who sees this every day, who is standing and talking about the current state, the future state, and steps to close the gap between them?
I usually see these in the Continuous Improvement team’s workspace. That was certainly the case for the one in the photo. Sometimes they would bring management into that room to discuss progress, but all too often that became a report-out to the managers.
And right there we have an interesting situation: The Continuous Improvement Director and his team have a much deeper understanding of what was going on than the people in charge.
This was partly because it was the Continuous Improvement team members who made these maps in the first place. And they were the ones tracking the metrics, including quality, productivity. They were the ones identifying the problems, and they were the ones working to solve the problems.
And they were the ones complaining when things eroded because management “wasn’t supporting the changes.”
As a Continuous Improvement team (and if you are reading this, that is likely you), your ultimate goal is to enable the line leaders by engaging through them rather than engaging for them.
You likely have to get there step-by-step, with successive target conditions, but it is the level of engagement of those leaders, and their growing competency in doing so that you and your C.I. team should be tracking on your walls.
Lately the term “socio-technical system has been starting to show up more and I thought this would be an opportunity to weigh in on what I think it means.
Though the concept has been around since at least 1951 (see below), I think I have tended to “bleep over” the term as jargon without giving it a lot of thought. I don’t think I am alone in that.
People who try to describe the meaning tend to describe a system “that integrates the social and technical aspects” or words like that.
I would posit that it goes much deeper, and we “bleep over” the concept at our peril if we want our organizations to function well.
The Origin of Social-Technical Theory
*Up through the 1940s, coal mining in the UK was largely pick and shovel work aided by drills and, sometimes, explosives. A work crew typically consisted of three to half a dozen men (and they were all men) who were task organized to strip the coal off the seam face, shovel it into mining carts, and move those carts to the transport system.
These teams were distributed through the mine, and because the distance and working conditions really precluded a lot of supervision, the teams largely oversaw their own work.
Since each team worked independently, the system as a whole could easily accommodate the simple fact that in some spots the coal is harder to dig out than in others.
The work also met every definition of “difficult, dirty and dangerous.” That work environment, though, created a social bond among the team members as they worked together to accomplish the task of “mining coal.”
The system was not without its problems, however. The social structure was built around loyalty to the small work team. When “trams” (coal carts) were in short supply, for example, the “trammers” would horde carts to optimize their team’s performance at the expense of other teams being limited by the number of carts available.
This all changed shortly after WWII.
The Long Wall Method
In the late 1940s the industrial engineers turned this craft production system into a factory system with the tasks divided between three shifts.
Long Wall Mining Shift Schedule
The process would begin on the evening shift. They would drill blast holes along the top of the coal seam, then dig an undercut about six inches high at the base to allow the blast to drop the coal. This would be done along a long (up to a couple of hundred meters) face of the coal seam. (Hence the name “long wall mining.”)
Meanwhile another team would break down the conveyor system that ran parallel to the coal face in preparation for moving it forward to position it for removing the loose coal.
Then night shift had two teams. One would extend the “gateway tunnels” at either end of the coal face. This was a crew of 8 men. Simultaneously another team would rebuild the conveyer in the new position.
Once all of this work was done, the shots would be fired, dropping the coal into a pile along the coal seam face.
Day shift would take the loose coal and transfer it to the conveyor system to be taken out of the mine.
Yes, this is an oversimplification, but it suffices for this discussion.
On paper, this process was far more efficient.
In practice, though, things did not go smoothly.
“Isolated Dependence”
A “filler” loads loose coal onto the conveyor.
Looking at this work breakdown, the first two shifts are prep work. Only the day shift, the “fillers,” actually get the coal out of the mine. But their success was entirely dependent on how well the first two shifts did their jobs. If everything was not “by the book” then the fillers would be significantly hampered. Since they were paid by the ton of coal extracted, there was more at stake than just a sense of accomplishment.
If the previous shifts ran into problems – such as a “shot” that failed to separate all of the coal from the roof of the seam, or harder material, etc. these inconsistencies slowed down the “fillers” and made them less successful. If the conveyor was not completely or correctly assembled, they could not begin work until this was corrected.
Because management pressure was on the key performance indicator – the rate of coal extraction, and because the “fillers” were paid by the ton of coal extracted, this created resentment between the “fillers” and crews on the other two shifts, as well as conflicts with management which the working crews began to regard (with ample evidence) as disconnected from the realities of their work.
Then, if the “fillers” were too far behind at the end of their shift, that would delay the start of the next cycle and things spiraled downward from there.
Productivity plummeted. The study I am citing here was commissioned to determine why. Their conclusion, in short, was that the new work organization was built around the paradigm of a factory assembly line without regard for the variation of geology. Success of the three shift cycle depended on each shift meeting a rigid schedule, but that schedule did not account for the simple fact that coal seams are not uniform.
In addition, the work organization destroyed the social structure of the mining crews. Their success was dependent on people they no longer saw or interacted with. The oncoming filler shift, in particular, would be confronted with all of the obstacles left by the previous two shifts. As their resentment for being unsupported built, their willingness to put in any extra effort dropped to zero.
Again – this is an oversimplification. If you want to read the full paper there is a link at the end of this post.
Oversimplification or not, however, the effect was stark. The social structure of the organization was driven to fundamentally change by alternations in the technical structure of the work. Quoting from my source material* :
The effect of the introduction of mechanized methods of face preparation and conveying, along with the retention of manual filling, has been not only to isolate the filler from those with whom he formerly shared the coal-getting task as a whole, but to make him one of a large aggregate serviced by the same small group of preparation workers.
The work design was based on a mechanistic view that ignored the how the social structure impacted the performance of the team.
By the turn of the last century we thought we had the ways of the universe pretty well understood. Hundreds of years (thousands of years in some early societies) earlier we had the ability to predict the motion of the stars and planets – to the point that we could build machines that were analogues of their movements.
The prevailing model in psychology was classical conditioning which, in essence, said that behavior is an almost algorithmic learned response based on previous positive and negative reinforcements.
This mechanistic model leads to a belief that we can carefully design the machine and people’s work within the machine can be carefully designed and shaped through rewards and consequences.
And as long as everything, and every one, works as they are supposed to, it’s all good. If a machine malfunctions, we fix it. If people don’t follow procedures, we “motivate them” with incentives.
This model prevails even today and even colors our teaching of continuous improvement. One of the places we need tend to inherently adopt a mechanistic view is when we use the word “system.”
The Mechanistic View of “System”
In today’s world, when people talk about “the system” they are often referring to an information system of some type. Common examples are an Enterprise Resource Planning (ERP) system, or an Electronic Health Records (EHR) system. And these information processing systems do tend to shape how the organization functions, for better or for worse.
So when people talk about a “system” I think the reflex is to think of the system as a machine that is carefully designed, built, and tuned to perform a particular function or behave in a particular way.
And people tend to assume that once it is working, it will continue to work so long as it is maintained to be kept in the same condition.
This thinking often extends to the people as well. They are often viewed as servicing “the system” – providing it with information, and following the instructions it gives. (this is particularly true in ERP / MRP environments.) Everything is part of a machine, and as long as everyone does their jobs, and the equipment functions as intended, then it all works.
In practice, though, these systems tend to isolate people from one another, or into small single task groups in much the same way as happened in the coal mine.
The Mechanistic Paradigm at Work
The reason I explained all of this is so we can look at our own workplaces through this lens. The crucial question is: Do the work structures and systems support or hamper the social structure of effective teamwork?
Let’s take another look at those ERP or EHR systems. Without the interaction with and the interaction between the people who use them, those “systems” are inert. They do nothing. The mechanistic paradigm, though, tends to look at people as performing a task to serve or enable the system. Instead, we should look at the information system as a tool that should enable people do to a job they otherwise could not.
On the Shop Floor
The sign says “Hearing Protection Required.” The reality is that it is impossible for more than 3 or 4 people to have a conversation on the shop floor, as they are shouting to be heard. The final operation is highly automated, each machine has two people working in isolation, even from one another for the most part. In addition, the machine crews are isolated from one another, both by distance and by the noise level.
The machine operator is measured on his hourly rate of production vs. a standard expectation.
Meanwhile at the opposite end of the building, the production scheduling team works to carefully orchestrate the availability of packaging materials, purchased components, as well as scheduling each phase of production so work is available for the next step.
They do all of this with their ERP system and every day they create orders to issue components, production orders to the various areas in the shop, and purchase orders to their suppliers. They adjust priorities at least daily, based not only on lead times and changing customer requirements, but also on the reality of what has actually been produced, or not, up to this point. Items are early, they are late, production runs ahead, though mostly behind, the scheduled intent.
Everyone is frustrated. The planner / schedulers because production never seems to make what they planned. And production because scheduling never seems to schedule things that can be made with the available materials, etc. Shortages are discovered, an ad-hoc plan is created to keep things moving – but that may well consume components that were earmarked for something later in the week, and the cycle continues.
To make things even more interesting, the planner / schedulers are using production capacity numbers that they know are higher than reality. They are under pressure to put in unrealistic numbers because the real numbers would make the site’s cost estimates too high and attract scrutiny from corporate.
This means “the system” produces schedules that cannot be met by actual production even if everything else works, which, in turn, means continuously over-promising, under-delivering, and adjusting priorities.
Though the work is very different, we have a social structure not unlike the British coal mine.
This is what “isolated dependence” looks like in today’s work environments. If you are seeing blame casting and conflict between groups who are dependent on one another you likely have a similar situation in your organization.
Counter-Productive Response
Unfortunately the typical management response is to increase monitoring, control, incentives, “accountability” on individual parts of the process rather than looking at the entire system.
These things tend to increase the sense of isolation and frustration as they can create a sense of victimhood between the separate groups. For example, in the above situation everyone there told me that they used to have pull system on the factory floor, and it had worked really well, operated predictably, and gave them a lot more insight into what was actually happening. But some time ago a new management team wanted to track everything in the computer “for control” so the current system was installed.
Ironically, that management team had turned over, but for whatever reason people were very reluctant to return to what they knew had worked in the past. But I digress.
The Implications
Human beings are innately social. In any organization, or casual group trying to get something done, people develop webs of social networks. The more they can interact, the more everyone stays on the same page.
There are a few things we can do to reinforce this.
Bring People Together
And I mean bring them together literally, physically. Rather than just confronting one another in the morning meeting, have them literally work side-by-side with the common goal of a smooth process.
Have a Shared, Objective, Truth
Eliminate the need to ask or query “status.” Eliminate the one person who knows the big picture. Get the truth out there in the open– literally, physically. (See a trend here?)
In a well managed operation I nearly always find rich “information radiators” that are an inherent part of the process itself (rather than being a display of information that was input just so it can be displayed). This information is not simply a passive display. It is actively used by the people doing the work to they know where they stand, what comes next, and when they need to raise a concern.
A classic example of this is a heijunka or load-leveling box. The cards, or work orders, or pick tickets, are placed in slots that are based on the time that work is expected to start if everything is working normally. Thus it is insanely easy to spot if something is getting behind, long before it would show up in the daily production report. Menlo Innovations’ Work Authorization Board does the same thing.
The goal is for conversations to be about “How to respond” rather than discussions about “what is happening.”
This is really the purpose of nearly every “lean tool” — to ask, and answer, two key questions:
What should be happening?
What is actually happening?
and then invite a conversation about any difference between the two.
The fact that “we have made 234 widgets” is meaningless without a point of comparison of “how many widgets should we have made up to this point?” The goal is to invite curiosity and foster actual conversations, and eliminate debates about what should be and what actually is.
But more often, this is what I most find lacking. People well tell me they can easily query status, look up individual orders, but even then there is rarely a timely comparison between “nominal” and “actual” in that information. Even if status can be queried, there is often a lack a “compared to what?” Or worse, the status is abstracted from reality, for example, measured in “earned hours” or some other financial metric. Often “ahead or behind” is not known until the end of the day… or the week, or sometimes even the month. The greater the lag, the bigger is the scramble to make up production with overtime.
So here is question #1 for you: If I were to ask you, right now, “Is this operation ahead or behind?” could you tell me? Can the people who are actually doing the work tell me? And by “tell me” I mean immediately, without having to go research or launch some kind of query.
Another version of this question is, “How far behind do you allow yourself to get before you actually know there is a problem?”
Social-Technical
So what we have is a technical aspect of a process that is deliberately designed to support meaningful social interactions between the people responsible for carrying out the work and accomplishing the overall task… as a team. We bring people together rather than isolating them from one another.
This is hard – Yup.
And these principles run against management “best practices” that have been taught since the 1920s.
Where to start? If any of this seems impossible, work on trust. Think about this – Why would people be reluctant to display an objective truth without the ability to first qualify it?
Why would people be reluctant to create a true dependent relationship with another department?
All of these things come down to a culture of self-defense because people feel a need to protect themselves from something or someone. Even if that force is long gone, the effects of leadership-by-fear linger, sometimes for many years, unless you take proactive and direct steps to eliminate that fear.
Once again I am going through old files. These are some notes I wrote back in 2005 that I thought might be interesting here. Looking back at what I was writing at the time, I think I was thinking about nailing these points to a church door somewhere in the company. That actually isn’t a bad analogy as I was advocating a pretty dramatic shift in the role of the kaizen workshop leaders.
All Saint’s Church – Wittenberg, Germany
This was written four years before I first encountered Toyota Kata, and reflected my experience as a lean director operating within a $2billion slice of a global manufacturing company. What reading Toyota Kata did for me was (1) solidify what I wrote below, and (2) provided a structure for actually doing it.
Perhaps this will create some discussion. If you are interested in getting a Zoom session together around it, feel free to hit the Contact Mark in the right sidebar (or just click it here) and drop me a note. If there is interest, I’ll put something together.
Kaizen Events
Kaizen events (or whatever we want to call the traditional week-long activity):
Can be a useful tool when used in the context of an overall plan.
Are neither necessary nor sufficient to implement [our operating system].1
There are times when any specific tool is appropriate, and there are no universal tools. Kaizen tools included.
(Our operating system) is, by our own model, the “Operational Excellence” pillar of (our business system). This is keyed in leadership behavior, not implementation of tools. The tools serve only to provide context for leaders to rapidly see what is happening and the means to immediately respond to problems.
Thus, focusing on implementing the tools of TPS (takt time, flow, pull, etc) outside of the immediate response and problem solving context is an exercise which expends energy and gains very little sustainable change. This is independent of whether it is done in a week-long intense event or not.
However, in my experience, organizations which take a deliberate and steady approach implementing have had more success putting the sustaining mechanisms into place. While it is sometimes necessary to bring teams together for a few days at times to solve a specific problem, or to develop a radically different approach, these efforts tend to be more focused than a typical kaizen week I see.
When the kaizen week is scheduled first, and then the organization looks for what needs improving, this is a symptom of ineffective use of the tool.
In general, a kaizen, whether it is a week, a month, or even just a few minutes, must be focused on solving specific problems which are impeding flow or are barriers2 to the next level of performance. Without this focus, there is no association with the necessities of the business, and no context for the gains.
There are a few simple countermeasures which can be applied to a kaizen week activity that focus the participants much more tightly on learning the critical thinking.
Improvement can, and must, take many forms. A week-long kaizen activity is but one. It is expensive, time consuming, disruptive, and should be used deliberately only when simpler approaches have failed to solve the problem.
Classes and Courses ≠ Teaching and Learning
Bluntly, even though we preach PDCA and say we understand it, we are not applying PDCA in our education approach.
Some fundamental tenets:
All of our teaching should be contextual and focused on what skill or knowledge is required to clear the next barrier to flow or performance.
The above does not rule out teaching fundamental theory, but fundamental theory must be immediately translated into actions and put into practice or it will never be more than a nice discussion.
The vast majority of our teaching should be experiential, and based in real-world situations, solving actual problems vs. examples and contrived exercises.
We want to move our teaching toward an ideal state (a True North in our approach) where it is:
Socratic – focusing people on the key questions.
Experiential – learn by application to solve real problems and thus gain experience and confidence that the concepts translate to the real world.
Thus, education and training is but one tool used by leadership to help people clear the barriers and problems that block progress toward higher levels of performance.
As far as I can determine, the “Toyota Way” of teaching is similar to this model.
Content
The content of training is as critical as the way it is delivered.
Our objective is to shift people’s thinking, and in doing so, shift their day-to-day behavior as they make operational decisions. The target audience for all of our efforts are the people who make decisions which impact our direction and performance. This is anyone in any position of leadership, at any level of the company – from a Team Leader on the shop floor to the CEO.
The key is to embed the structure of applying PDCA into all of our content. For example:
Every tool, technique, etc. we teach, or should teach, is some application of the above. (The rules-in-use include problem detection, response, and problem solving.) I have yet to encounter an improvement tool or technique that does not fit this model.
This approach fundamentally re-frames the concept of “problem” and what should be done about it.
The Toyota Production System (in its pure state) is a process which delivers a continuous stream of problems to be solved to the only component of the system that can think – the people. This is how people are engaged, and this is what makes it a “people based system.” Leave this out, and “people based system” is just hollow words. Nearly every discussion talks about how important people are, but then dives right into technical topics without covering how people are actually engaged — outside the context of a week-long kaizen.
The Role of “Workshop Leaders” in the (Continuous Improvement Office)
No one has disputed the critical make-or-break role played by the line leadership, not only in implementation, but even more so in sustaining.
Workshop leaders are generally taught to plan and lead workshops. The emphasis is on the week-long workshop logistics; on presenting modules in classroom instruction; and on the skills to facilitate a team through the process of making rather dramatic shop floor improvements.
In a typical (not saying it happens here) implementation scenario, it is the workshop leaders who go to the work area, do the observations (usually without a lot of skilled mentoring, and usually just to collect cycle times); build the balance charts and combination sheets; plan what will be changed; how it will be changed, set objectives, targets and boundaries.
They are the most visible leadership of the teams during the week, and they are the ones tracking and pushing follow-up and completion of open kaizen newspaper items.
The effect of this (which is fairly consistent across companies) is:
The standard work tools are something workshop leaders use during improvement events.
Cycle times, observations, and looking for improvement opportunities is something that is the domain of the workshop leaders.
Actually guiding the team members through the problem solving process is the job of the workshop leaders.
The supervisors and managers are there as team members, in order to learn by participation, from this outside expert.
The question is: Who is responsible to coach the line leaders through the process of handling the problems that the TPS is designed to surface in operation?
Once the basic flows are in place, there will be a stream of problems revealed. Those problems will either be seen or not seen. IF problems are seen, they will either be dealt with quickly, following good thinking, or they will be accommodated so they go back to being unseen. This is a critical crossroad for the organization…. and it is the behavior of the first and second line leaders, and the support they get from their leaders, that most influences whether the system backslides or continues to get better and better.
IF problems are seen, they will either be dealt with quickly, following good thinking, or they will be accommodated so they go back to being unseen.
Note: There is not middle ground. One-piece-flow really can’t sustain in a stable state. It is either improving or getting worse. It isn’t designed to stay still, and it won’t. Continuous intervention is required for stability, and that intervention is what improves it.
Who is teaching the leaders to do this?
Each leader must have a coach, by name, who can, and will, always challenge his thinking and his solutions to problems against a specific thinking structure.
My view is this is the primary role for the Kaizen Promotion Office.
The way to do this is through application of a few core skills, and skills can be taught.
We should:
Include this vital role into the expectations of a “workshop leader” – to take them closer to being “coordinators” in the Toyota factory start-up model.
Provide these “coordinators” with a specific support process so they know that they can quickly get assistance if they feel they are in over their heads.
The role of that assistance is not to step in and solve the problem. It is to take the opportunity to teach both the workshop leader and the area manager by guiding them through solving the problem.
My experience with this concept is that teaching these skills to someone is not as difficult as most people assume. The basics of observing and seeing flows can be taught over a few days to someone who is motivated to learn. The skill of teaching by asking questions can be accelerated from the “pure” method by telling them what is being done in why. “This isn’t about the answers, it is about learning the questions.”
Application and good teaching can easily be verified by checking the leader’s (the student’s) level of skill and behavior. (The senior teacher checks the teacher by checking the student… just as the area supervisor checks the Team Leader’s teaching by verifying the standard work on the shop floor.
None of this is an advanced topic. These are the basics. Once a good context is established in people’s minds, my experience suggests that the Toyota system is no longer counter-intuitive. The tools and techniques that, at first, seem alien now make sense.
——–
1 By this I meant to shift the operating culture to one that inherently supports continuous improvement.
2 In Toyota Kata language, we would say “obstacles.” I had used the term “barriers” up to that point.
In the early morning of March 23, 2022 a leaked email with the subject “Why gas increase is good for hiring” surfaced on Reddit. (Click the hot link to see the actual post.)
The email in question was sent by the Executive Director of Operations of Apple Central LLC, a major franchisee of Applebees restaurants. He was describing the “opportunity” presented by higher gas prices, increasing prices and increased cost pressure on smaller restaurants. Quoting a couple of key lines:
“The advantage [of higher gas prices] has for us is that it will increase application flow and has the potential to lower our average wage”
He continues:
“Any increase in gas price cuts into [our employees] disposable income […] that means more hours employees will need to work to maintain their current level of living.”
Now, to his credit, after saying “besides hiring employees in at lower wages to decrease our labor cost” he closes with the advice to “Do the things to make sure you are the employer of choice” But this means “Get schedules completed early so they can plan their other jobs around yours.” though he does close with “have the culture and environment that will attract people.”
According to reports in the local newspaper, the manager in the Lawrenceville, Kansas Applebee’s was so angered by the content and tone of this message that he made copies of the email, distributed it to the employees, and he and two other managers quit on the spot in protest forcing the store to close for at least a day. One of those copies ended up being scanned and uploaded.
Blowback
Within an hour of the posting on Reddit, the thread was picked up on Twitter by Rob Gill. There were tens of thousands of forwards, retweets, views.
To Applebee's franchise executive Wayne Pankratz, surging gas prices are an opportunity for his business, rather than a downside – because it'll "force people back into the work force" https://t.co/6jmCXgVpeo
There are more. Many more. Just search for “Wayne Pankratz” email and you will turn up lots of hits.
OK – so what can we learn here?
I didn’t write about this just to pile on to the story. The mainstream business press has done more than I can ever do. Rather, I want to explore some of the deeper implications, not just for Applebee’s and Apple Central LLC, but for our own organizations.
First the obvious. This was a potential public relations disaster. There was a lot of damage to be sure. At the same time, the story was quickly buried by the ongoing news about the Ukrainians’ fight for their very existence as a nation, and juicier national political stories coming out of Washington D.C. Had this been a slow news period, this story is the type that can get legs under it and reverberate for weeks. That didn’t happen in this case.
Once the story hit the mainstream press, we had P.R. responses like:
Kevin Carroll, COO of Applebee’s: “This is the opinion of an individual, not Applebee’s. This issue is being addressed internally by the franchisee who employs this individual and who owns and operates the restaurants in this market. Our team members are the lifeblood of our restaurants, and our franchisees are always looking to reward and incentivize team members, new and current, to remain within the Applebee’s family.”
And from Apple Central LLC, the company where the email originated: “The main message here is that this in absolutely no way, shape, or form speaks to our policies or our culture, or anything like that with our brand.”
And ultimately Mr. Pankratz lost his job. End of story, a rogue employee, a bad apple (pardon the pun) if you will. Maybe.
Looking Deeper
Still, I have some questions – and that is all they are, just questions. I know nothing about the culture of Apple Central LLC, the company that owns the franchises where the email originated.
But the email was written on March 9. This story broke two weeks later, and the response was a few days after that – once reporters started calling the company.
What happened in those two weeks?
There is a hint in the email itself. Or more specifically the forwarding chain. Someone in the store in Springfield (Springfield-8289) responds to the original email: “Great message Sir!” and right away we see that maybe this message isn’t so rogue.
It is then forwarded again by a redacted user with the message: “Words of wisdom from wayne!!!”
It was sent to [redacted] Distribution List – that implies a lot of people saw it. It was sent in the evening of March 9. What happened on March 10th? Those are the actions that would tell us if this was a break from the way business is normally done.
The Questions for Everyone
The more subtle story seems to be about the difference between espoused vs. actual values.
Simply, it is the internally triggered response, not the response to outside inquiries, that reflects the actual values of this company.
Was there any effort at all to repair the employee relationships that were damaged? Is there evidence that anyone objected, retracted, or attempted internal damage control with the employees who saw the message before it blew up in online in the press?
Would this story have even happened if someone from Apple Central LLC immediately got in touch with everyone on the distribution list and even visited the Lawrenceville restaurant in person to make amends?
In the face of this kind of blowback, wouldn’t that be something a company would highlight in press releases? None of the press releases or statements said anything about efforts to repair the damaged relationships with employees. None of them said anything about actions being taken immediately. Simply put, there isn’t any evidence of alarms about breaking with the policies, culture or brand until reporters start asking about it two weeks later.
Nor is there any evidence that the individuals who enthusiastically forwarded the message along were acting outside of the cultural bounds of the company.
Quite the opposite.
What Problem Were They Trying to Solve?
Based on all indications it seems this was managed as apublic relations problem. It was not managed as a culture problem.
All of the messaging says “Our culture is fine.” Just this guy, who happens to have the title Executive Director of Operations, but we are told he doesn’t make hiring policy.
A Question for You
Let’s even take email out of it. If someone made this case in your company’s leadership meeting, what would the response be from around the table?
Would anyone push back? Would anyone say “Wait, we don’t talk about our people that way.” “We don’t look to trap them in the job here.” “No! That isn’t who we are!”
Maybe there would be an awkward silence until someone changed the subject, but nothing else said.
Or would head nod in tacit agreement, good point, next topic?
Or would there be “Great point!” with nods and smiles?
Or… would there be a discussion about actual ways to take advantage of this so-called opportunity?
Your leadership values are not what is printed on the posters in your hallways. Nor are they what your public relations people tell the reporters when there is an adverse story.
Your leadership values are reflected in what you do, what you say, how you respond day-in and day-out.
If you want to know your values, just listen to what people, especially those in authority, say when they “can talk freely.” Listen to things people say that get no pushback or objection. Those are the values that are driving policy and decisions.
Listen to yourselves. Listen to your values. Own them. If the public face is different from everyday discussions ask yourselves why, especially if the word “integrity” shows up anywhere in your values statement.
Whether you are a line leader or an internal or external consultant, if you are reading this you are likely working to shift the culture of your organization.
The technical “tools” alone are pretty useless unless you are already operating in the kind of culture that embeds the mechanisms of learning and collaboration deep into the structure of day-to-day work. If that kind of culture isn’t present, the “lean tools” will reveal those issues just as quickly (more quickly, in fact) as they reveal shortages, work balance mismatches and quality problems.
Making these kinds of changes is a lot harder than teaching people about how the “lean tools” work, and a lot of change agents are frustrated by the perception that the changes are not sustaining or being supported.
Back in February 2019 I gave a talk at KataCon5 in Savannah on some of the challenges change agents face when trying to influence how people respond to challenges and interact with one another. Here is the direct link in case the embed doesn’t work for you: https://youtu.be/NnvwOF4J3g8
As you watch the video (assuming you are *smile*) give some thought to how well you can paint a picture of how your efforts are influencing the patterns of interaction within the organization. Do you have something in mind for what you are trying to achieve there? What patterns are you actually observing?
And what is your role in those dynamics? How do you influence the patterns of who talks to whom, how, when, and about what? Are you acting as an intermediator between groups that don’t communicate or who are antagonistic toward one another? If so, what would happen if you stopped?
What happens when a production team member, or a nurse doing rounds on the med-surg floor, or your front-line customer service agent encounters something that is different than it should be? What is the threshold of starting action?
All of these things are cultural norms. And the “lean tools” all impact those norms in ways that people often are not prepared for.
None of these questions are on a checklist. Rather, they are the kinds of things to think about.
Many years ago I wrote an article for SME called The Essence of Jidoka. In that article I described a four step process designed to improve productivity and drive continuous improvement. Since then these four steps have been picked up and incorporated into the training materials of many consultants, used to write the Wikipedia article on jidoka (which I most assuredly did not author), and even found their way into some academic papers. Sometimes with attribution back to my article, may times without.
In that article, “jidoka” was described as a four step process:
Detect a problem.
Stop.
Fix or correct the problem.
Find the root cause and implement a permanent countermeasure.
But I would like to take a hard look at the first step: Detect the problem. This is where, I believe, most organizations actually fall down. And in doing so, they also fall down on respect for people.
The key question is: “What do you consider a problem?”
Most organizations do not see a problem until the symptoms are bad enough that they are compelled to do something about it. This means people have been struggling with issues for some time already. The machine isn’t reliably producing good parts. Or someone is having to rework material. Or the supplies cabinet is always short, and the nurses have to launch a safari to find what they need.
Contrast this with a company like Toyota. Every Toyota-trained leader I have ever dealt with is very consistent. A problem is any deviation from the standard. More importantly, a deviation from the standard (1) forces people to improvise and (2) is an opportunity to learn.
Spear’s research concluded there were four tacit rules for how activities, information connections, flow paths, and improvements were designed and executed in Toyota operations. Each of those rules describes:
Any deviation from the standard triggers some kind of alert that gets someone’s attention. And whose attention is explicitly defined – That is a standard as well.
As I look at a work area, I often see a lot of 5S type of activity. Things and their intended locations are marked and labeled. These are standards. They establish what should be where. But the question to ask is “What happens if something is out of place?”
That is a deviation from the standard. It is a problem.
Stop
Fix or Correct (put it back – restore the standard condition)
Investigate the root cause
“What’s going on with the air wrench today?”
“Actually it is an extra one.”
“Really? Where did it come from?”
“I borrowed it from the Team Member in work zone 3.”
“Ah, OK. Why did you need his?”
“The regular one isn’t working.”
“Hey – thanks for letting me know. I’ll get it to maintenance.”
“Thanks”
“Did you tell anyone about the problem before now?”
“No, I just borrowed the wrench. I just needed to get this job done, then forgot. It’s no big deal, it’s easier to just borrow Scott’s wrench.”
And in that exchange, what have you discovered about your daily management system by simply being curious about a trivial deviation from a 5S standard?
Is this the Team Member’s fault?
Probably not. What is your standard? What is he supposed to do if the wrench stops working? Is there an escalation process and a response for this kind of small stoppage? Or are your Team Members just expected to find a way to work through the issue? Which of those responses is more respectful of the Team Member who spends her time trying to create value for you?
Often times there is no standard.
But without a standard you have no way to tell if there is a problem (other than a feeling that something isn’t right). And if you are sure there is a problem, without a standard you can’t really define what “fixed” is.
So start with defining the standard. First, go back to Decoding the DNA of the Toyota Production System. You can get an idea of the kinds of things you should standardize.
As you think of standards, consider a standard for your standard:
Express it from the viewpoint of the process customer.
Define it in a way that can be verified as “met” or “not met.” No gray zones. You can quantify the magnitude of a problem, but not whether you have one.
There is a visual or other control tells the appropriate person, right away, if there is a deviation from your standard?
Is there a standard that triggers a response to clear the problem?
5S is nothing more than the first step of setting standards. Many people say to start there, but don’t say why. The point is to practice setting standards and holding them. Taiichi Ohno is quoted as saying:
“If there is no standard, there can be no kaizen.”
Any deviation from the standard is a problem.
Your choice, as a leader, is how to handle that problem.
