Posts

Posted on

Toyota Kata: From Kaizen Newspaper to Experimenting / Learning Record

In a traditional kaizen event there is usually some kind of todo list for keeping track of progress implementing the ideas of the team. A common name for this form is “Kaizen Newspaper.” The below example is pretty typical. This is a real one from the early 2000’s.

Generic kaizen newspaper showing What, Who, By When, Status

This form reflects a bias in western (certainly USA) business to focus on getting stuff done. I think it might be helpful to reflect a bit on the assumptions that are built in to this structure.

One of my favorite quotes is from Grace Ng: “All customers have problems, all problems have solutions. But not all solutions have problems, and not all problems have customers.”

In the context of this form, the “What” or “Action Step” is usually a solution. We are going to do something. And once the “What” is decided, then the rest falls into place- Who is going to do it, by when are they going to get it done, and what is the current status? And it is all to easy to get pulled into the implement vortex without ever thinking about “Why?” are we doing this – what are we trying to accomplish? How will we know we have accomplished it?

This is also a typical structure for a management staff meeting, and even discussions about strategy – they devolve into “What are we going to do?” and often skip over “Why are we doing it?” In other words, “What problem are you actually trying to solve?”

The “Progress Wheel” tracking percent complete implies an assumption that there are multiple steps involved, and implies a conversation about what those steps are as that wheel is filled in. The quality of that conversation depends on the skill of the coaching and facilitation.

The “By When” or “Due Date” implies that days will pass before we expect this action to be completed. It might be tomorrow, but often is not in practice.

This means that we expect that we wouldn’t get everything done that week. These newspaper items frequently carry over and are supposed to get done as follow-up work after the kaizen week is over. In practice, these things often fall victim to the daily whirlwind and languish. The “newspaper” is now more of an archive. It isn’t about today anymore.

Here is form from another company in the same era. As an aside, this company added “Complexity” to their list of wastes, and perhaps we can see some of that reflected here. But it takes a step in the right direction by adding “Problem to be solved” and, through the “Target Reference” block tries to tie it back to an intended result. It also has a column for “Results” on the far right.

What neither of these forms does, though, is ask “What result do we expect? They depend on skilled facilitation and coaching to ask that question as the team is proposing the idea. One of the challenges we often face (again, in the West and especially the USA) is with our focus on action we don’t default to asking that question.

One exception I experienced in May 2001 was a Shingijutsu consultant (and I don’t remember who it was, unfortunately) who had us modify our kaizen newspaper that week to add a column that captured the cycle time we expected to save as a result of implementing that step. (I know the date because I did the modification on the original file and still have it in my archives.)

The idea was to make sure that we were implementing enough changes to deliver the cycle time target.

What it didn’t do, though, was capture the actual cycle time savings from the action.

What Are We Trying to Achieve?

A common assumption in many continuous improvement efforts is that if people participate in enough of these kaizen events they will experience a mindset shift. The challenge here is that the events themselves are usually focused more on results than on explicitly teaching and practicing the mindset1.

Don’t get me wrong – results are important, especially if you want to keep doing this. It is rare that any organization has infinite (or any!) patience for a lot of discussions around history, hypotheticals, or theory.

That means we have to actually solve real problems. We have to get stuff done. We have to at least look like there is a bias toward action if we want to survive as change agents in most organizations. The key is to solve the problems in ways that develop people’s problem solving skills.

That means making the mindset we want to teach more explicit.

This is the whole point of Toyota Kata.

Build the Coaching Into the Process

A highly skilled coach or facilitator brings teaching the problem solving / scientific mindset into the process, regardless of the forms and structure being used. But we can make this easier on both the coaches and the learners with adjustments to the structure.

While all of the artifacts of Toyota Kata are designed to do this, I want to avoid my tendency for scope creep and stay focused on one (really two) of them that fulfill the intended purpose of the Kaizen Newspaper in a way that develops peoples problem solving skills.

The Learning Record (aka the Experiment Record aka the PDCA Cycles Record aka the PDSA Cycles Record)

I call this form the “powered gear” that drives the entire process. Let’s look at the structure2. The form is structured in a way that turns action items into hypothesis tests.

The first, obvious, thing is that we aren’t just saying what we are going to do and by when. Each action, which we are calling a Step or an Experiment, has a specific predicted result or outcome. Separating the step being taken (the action) from the intended or predicted result helps people distinguish between the two. Allow me to elaborate.

I often see a result or outcome being listed as something that we are going to do. This can go as far as something like “Increase gross margin by 3%” as an action to take.

But that is an outcome (and an indirect outcome at that). It doesn’t say what we are actually going to do that we predict will produce that outcome.

One (the action) is cause. The other (the result) is the effect. Distinguishing between cause and effect is one of the core fundamentals we are trying to teach people who are making improvements or changes.

Explicitly separating what we are going to do from the result we expect helps people practice this mode of thinking. But the coach has to be prepared to ask good questions rather than just buying whatever is written in the boxes.

Taking this a step further, I have sometimes found it helpful to ask a learner to first decide what they want to learn, or the effect they are trying to achieve and write that in Box #2 first. THEN I ask, “What action are you going to take that you think will [ read what is in Box 2 ] ?” and write that action in Box #1.

I can also ask the learner to say, “I intend to [ read what is in Box #1 ] in order to [ read what is in Box #2].” For example, “I intend to rearrange the end of Alice’s work path in order to cut 3 seconds of walking from her cycle time.” If that sentence doesn’t make grammatical or logical sense, there is more thinking to do.

In general (this is a rule of thumb, not a hard rule) there are three kinds of actions that get listed here.

  1. A straight up hypothesis test – make a change with a predicted effect on the process, like the example with Alice’s work cycle above.
  2. Gathering more information – for example getting more detailed information about the current state of part of the process. This might be something like breaking down the cycle time of an individual operator into discrete steps. This could be where I learned Alice has 4 seconds of walking back to the start.
  3. Trying something in order to learn. For example, we have a target process that we can run, but we don’t have a good idea what the obstacles might be. The experiment would be something like “Run to the target process and carefully observe what actually happens” and the expected outcome would be “To learn what the obstacles are.” This is particularly effective for finding sources of process variation.

In general, and this is also more of a guideline, I want to see enough detail that we could give the sheet to someone familiar with the process and they could carry out the experiment from what was written. (This is just a thought experiment! DON’T actually do this. I can confidently predict that you’ll end up repeating the experiment because “what actually happened” won’t be what you thought – though that is an experiment in communication in its own right.)

The “Review / Coaching” line (yellow on this form) is the gate. We don’t cross that line until we have the coaching conversation, just to make sure everything I mentioned above is tight.

All we have at this point, of course, is a hypothesis. “If I do what is written in Box #1, I predict I will see (or learn) what is in Box #2.” Now we have to test that hypothesis. That is why we call this an experiment.

WAIT A MINUTE! Back up! What Obstacle Are You Addressing?

When you are running experiments, you are working to overcome some obstacle that is between you and your goal – your target condition. You want the process to operate in a new way (the target condition), but for [reasons] it can’t. Those reasons are obstacles.

This is different than the typical approach of just brainstorming a bunch of things to do and implementing them. We are targeting a specific way of operating (which is often an intermediate stage on the way to something more challenging).

We want our learner / improver to have an obstacle, problem, unknown of some kind, in mind. It may take – it usually takes – more than one experiment to learn enough to overcome that obstacle and move on to the next.

Address one obstacle at a time.

The Experimenting Record provides structure to reinforce this mindset by having the improver write the specific obstacle or problem in the space on the upper left corner before engaging any experiments. If they don’t know what the obstacles are, then write that as the obstacle, try to run to the new work pattern in order to learn.

“What problem are we actually trying to solve?” is a question that can often reign in an otherwise chaotic discussion about what to do.

The upper right corner has a space for a “process metric.” Without going off on another deep tangent, this is the attribute of the process result that we are trying to affect. The target condition should include a target value for the process metric so we can tell if we are actually making progress toward the target condition.

The process metric can be something like the cycle time of a particular operator; the minutes of exercise I am trying to achieve every day; the amount of variation in a process parameter we are trying to control. These are all things that we can immediately, directly, measurably affect by changing the process in some way.

Why did I address this part of the form second when it should be done first? Because it is very common to bleep over this part and just start writing experiments only to have the effort get diffused later.

Maybe my little digression was unexpected which might result in you remembering it a little better.

Now – Run Your Experiment

In the classic Plan-Do-Check-Act cycle we discuss “Do” and “Check” as sequential activities. In practice they are simultaneous, or nearly so. You should verify that the action you are taking is actually the action you planned to take. CHECK that your DO matches your PLAN.

If you ended up doing something different, you want to make a note of that, because you likely can’t say your plan didn’t work if you didn’t actually carry it out. What ACTUALLY happened? What did you experience? What did you see? What result did you actually get?

The things that we want to see written in Block #3 of the Experiment Record are objective facts. Please don’t just repeat what was in Block #1 in past tense. As a coach I want to see what you actually did as well as the actual outcome vs the planned outcome. And this includes outcomes that you didn’t anticipate. Sometimes those are good surprises – collateral benefit. Sometimes you learn that you need to pivot to a different idea.

Block #4 is subjective. What did you actually learn? There is usually more to this than what was simply in Block #2. This is also a good time to look at your obstacle list and make additions, deletions, and edits. Those are also things that you learned.

After Your Experiment

If you have had an impact on the current condition, update that. As I mentioned above, scrub your obstacle list and make sure it is up to date.

Have you achieved your target condition? If yes, awesome. Time to do a summary reflection, take a deeper look at your current condition, and establish a new target condition with new obstacles. (Same thing if you have reached the “achieve by date” without hitting the target condition.)3

If not, are you still addressing the same obstacle? If yes, then move to the next line on the experimenting record and fill in Block #1 and Block #2 for your next experiment.

In all cases, let what you have learned inform your next step. Notice how this is different than blindly executing a complex action item.

If you are addressing a new or different obstacle, then same thing, but please start a new form.

Why So Much Detail?

Our results-as-action-item corporate culture has a heavy bias to glossing over the details, and they are often not discussed or thought through. An action item might have a due date that is weeks in the future, and other than saying “It’s on track” not much will be discussed.

The Experiment Record is designed to have a small step every day (or nearly every day), discuss what was learned, and allow that to inform the next step so we aren’t blindly executing into something that has become irrelevant.

To be clear, a skilled, experienced coach can bring all of these questions out with a team using the traditional kaizen newspaper. The purpose of the Experiment Record is to make it easier for everyone, the coach included, to dig deeper into the kind of thinking we are trying to teach. It makes these questions explicit rather than relying on the experience and skill of the coach or facilitator.

Honestly, having these things explicit also establishes an expectation that the coach is going to ask about them. When a coach or facilitator starts pushing for more detail within the structure of a process that is overtly superficial they can, well, come across as a jerk. We call it “Socratic Teaching” but we have to remember what happened to Socrates. Better to have a process that makes the structure transparent to everyone.

Even outside of the Toyota Kata ecosystem, this process can bring a cadence of accountability to things as mundane as staff or project status meetings. The key is to not allow any step to go beyond the next scheduled meeting. “I can have that done in four weeks” becomes “What will we do before next Wednesday?” and “What result do we anticipate from taking that step?”

Back to the Kaizen Event

Try this experiment in your next kaizen event.

Throw away your kaizen newspaper.

Ask your team to list the problems that have to be overcome to achieve the goal for the week (which is really a target condition). Put those on a seperate sheet. You can use the Toyota Kata “Obstacle Parking Lot” but that is really just jargon. Call the problems whatever you want – just make sure they are problems and NOT actions to take, or things to implement. What is it about the process that makes it hard to change to the new way? What kind of issues come up that prevent the new way from working smoothly?

Then pick off one of those problems and start a rapid cadence of learning using the Experiment Record format. Keep those cycles quick. Can you do one every 15 or 20 minutes? Probably. The first experiment may well just be a simulation of sorts to learn if this idea is even worth pursuing. Cardboard, tape, holding things by hand to represent a fixture.

If you have a large team you might be tempted to work on more than one of these problems at a time. OK – but first convince me there won’t be any cross-talk between those problems or those experiments. It is really hard to learn when the conditions are changing under your feet because someone else is tugging on the other end of the rope.

At each major step you want to work to stabilize what you have before making the next change. Do this quickly, but incrementally. Doing otherwise is leaving a shaky process behind, and this is disrespectful to the people who have to deal with the aftermath.

At the end of the event celebrate, not so much the results, but what you have learned about making improvements. Wherever you are is where you should be.

Come Monday morning – here is the cool part – don’t stop. Maybe you only run one experiment a day vs. three or four every hour, but keep moving. Keep those coaching cycles running at least once a day.

Congratulations – you are now solving problems in a way that develops people’s problem solving skills.

What’s Next?

Did you find this helpful? Would you like me to go into similar depth on other pieces of the Improvement Kata, such as obstacles, process vs. outcome metrics, etc? Is there something specific you would like me to cover?

Leave a comment and let me know.

1 Another challenge is that most leaders only participate in these events a couple of times a year. The question, then, is what do they practice the other 48 weeks?

2 There are a lot of variations of this form, but those variations tend to be limited to phraseology. The fundamental structure remains the same.

3In a week long kaizen event you should really only have a single target condition to reach by the end of the week – if it is planned well – another deep digression I could go into.

Posted on

The Value of a Little Bit of Information

Shortly after 9am last Friday my home Internet went down. After doing my own troubleshooting, I was pretty certain it wasn’t anything in my control, so I called the technical support line of my provider.

The person on the other end (who I later in this saga learned was in the Philippines) was obviously reading a script as we went through reporting which blinkenlights were working (and not working) on the interface box (ONT – Optical Network Termination), doing a power cycle of same, “While ..we.. are.. waiting,.. Mark,.. how.. is.. the.. weather.. there.. in.. Everett?”

Whatever remote diagnostics they ran apparently didn’t detect anything out of norm with their system, and he said they would send a technician out “between one and five pm.”

Around 3pm I got a call from the technician, and went outside to meet him. He was still in his van in my driveway, obviously looking at something. When he looked up and saw me, he said, “I just figured out what the problem is. Does your interface box have a steady green power light, with the optical light blinking slowly?” Yes it does.

He showed me his notes. He had been sent to a number of customers with similar problems, and had connected the pattern to a couple of common hubs. My hub, apparently, was hub 1004. There was a failure somewhere upstream of those hubs. He left without needing to see anything in my house.

Fast forward a few hours and things weren’t resolved, so I was kind of wanting to know what was going on.

I got on the online chat (via my phone) with the provider, confirmed my account, and just as they wanted to run another (futile) diagnostic, I interrupted the script:

The tech that was sent out here said the problem was upline of hub 1004, do you know what the problem is yet?

Long pause, then I got more information:

The card in PON #1 has been replaced, they are still working in the cards in PON #3 and #4.

I thanked them for the update.

A quick online search (on my phone, no Internet, remember?) told me that a PON is a Passive Optical Network, so they were probably talking about the Optical Line Terminal (OLT). (Again, a little bit of knowledge can be leveraged into more.)

Illustration by user Riick from https://commons.wikimedia.org/wiki/File:PON_vs_AON.png

By leveraging a bit of information that they didn’t expect me to know (that the problem was upline of Hub 1004), I got more information. Now, in this case, that information was not actionable (to me), but it demonstrates how knowing a bit of accurate information can help you get more. If I were working to reverse engineer their network architecture I now have a working hypothesis that Hub 1004 is not part of PON #1 (since that has been fixed, and my Internet is still down), and is downline in either PON #3 or #4.1

What Does This Have To Do With Continuous Improvement Change Agents?

I’m glad you asked. Sometimes, probably most of the time, we are entering situations where we don’t have a great deal of information. And sometimes we encounter situations where people are not particularly forthcoming to our initial curiosity.

Sometimes asking about something specific will invite someone to open up and share more than they might have from a general generic “Can you tell me about this?” question.

If you show you know nothing, it is easier to dismiss you than it is if you show you know something.

This general technique is widely used in the world of intelligence gathering and law enforcement investigations, but it does not have to be deceptive. Having a little bit of information can open up the conversation because it simply shows you have already made an effort to learn.

“I think this process works like this [explain how you understand it]. Is there anything I am getting wrong?” invites the expert to correct your misconceptions rather than having to tediously explain everything from the beginning.

Each additional bit of information can be used to ask a deepening question as you extend your threshold of knowledge.

(Thanks to Craig for adding the following) Don’t be afraid to get it wrong when describing a process. In fact, people often feel more comfortable correcting you than confirming vague guesses. When someone says “no” they can feel more in control and are more likely to offer corrections or additional insights. As a change agent, that’s exactly the kind of dialogue you want.2

At some point, of course, you will likely bump into the threshold of knowledge for the entire organization – the point beyond which nobody really understands how it works. That can be our next obstacle, and the discussion can turn to “What do we need to learn, and what must we do to learn it?”

  1. Ultimately my Internet was down for about 32 hours, which is much longer than I would have anticipated. I also learned that the call centers get no information at all about estimated time to repair. It isn’t that they won’t say, it is that they are not told.

    I will not divulge my ISP in this case since, with this one exception, we have been very happy with the service we get. That being said, if your Google-Fu is good, you probably can leverage the information in this article into figuring out who it is.
    ↩︎
  2. This is also a good example of “Cunningham’s Law”: “The best way to get the right answer on the Internet is not to ask a question; it’s to post the wrong answer.” If you are willing to be corrected, you can gain a lot of insight. ↩︎
Posted on

Is Your Problem Technical or Adaptive?

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.)

Best starter book: Your Leadership Edge by Ed O’Malley. This is also the text for a course by the same name taught by the Kansas Leadership Center.

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.

Posted on

Boeing: The Turning Point(s)

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 Now YouTube 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:

  1. Quality First: policy in action.
  2. Customer-driven.
  3. Partnership with people.
  4. Management leadership.
  5. Quality built in.
  6. Organizational alignment.
  7. Cross-organizational coordination for the customer.
  8. Elimination of waste: Focus on adding value.
  9. Reliable processes through reliable methods.
  10. Healthy work environment.
  11. Simplify.
  12. 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.

When former Airbus executives are chiming in about what Boeing must do, it might be time to think a little harder than doubling down on what they have been doing.

They almost did it.

Posted on

Introduction to Toyota Kata

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.

Posted on

What Conversations Does Your VSM Drive?

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.

Posted on

Where is your value stream map?

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.”

What’s the problem here? What were they actually expecting the line leaders to do?

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.

Think about what that would look like.

Posted on

Learning to See in 2023

Pat’s comments on my last post reminded me of another post I had written a decade (!!!) ago titled Learning to See in 2013*. I think it is time for reflection and an update. That being said, I think the 2013 post has actually aged pretty well. I don’t see anything in it I would retract, just some things to further clarify or amplify.

Of course that implies that we (our community) is still largely stuck in the same groove we were a decade ago. *sigh*

Let’s ask some questions:

Who is “Learning to See?”

The first time I made a real value stream map was in 1999. A plant manager asked me to build a map of the flows in his factory. I spent three or four days talking to his area managers to get their understanding, observing flows on the shop floor, getting actual cycles, comparing what I observed with what those managers thought was going on.

With all of that information, I mapped out the factory’s flows. It took four 11×17 (A3 size) sheets taped together to depict what happened as raw steel came in one end of the building and was cut, bent, welded, painted, and assembled with purchased components into the final product.

I learned a lot, not only about mapping a process, but about the way this factory functioned, and had pretty compelling evidence that the bottleneck was not what the common knowledge said it was.

I dutifully presented my findings to the plant manager and his continuous improvement manager. And things pretty much ended there.

Years later, another plant manager asked me to come out to their site and map their value streams. This time I was pretty insistent that though I was happy to come out and facilitate the process, it really had to be the site leaders that were doing the observations and building the map. What they wanted, though, was for me to report my findings to them once I was done. I still scratch my head about that one as the General Manager was an ex-Toyota guy who knew better.

Which brings us to:

Who is mapping the process?

A production team reviews their understanding on a value stream map

Regardless of what structure you use to map your process (VSM, Swim Lanes, SIPOC, to name a few), the learning comes from the experience of building the map and then having to explain it to someone else.

That second bit is important: If you can’t explain it to someone else, you probably don’t understand it as well as you thought.

So, if you are a consultant or internal change agent, and you build the map and then try to explain it to management, guess who learned the most? (Hint: It wasn’t your audience.) The key point here is if your objective is for the line leaders to gain insight into what is actually happening, you are unlikely to accomplish that objective by explaining it to them. They will never gain as much insight as you did.

In the photo above, it is the operational leaders who are explaining what they are learning to me. I’m just asking questions until I understand. They ended up going back out to the shop floor more than a couple of times as the picture came into focus.

Why are you mapping the process in the first place?

I asked this question in the 2013 post: “Why are you doing this at all?” with a context of having some kind of strategic intent, a challenge, in mind.

If there isn’t a concrete challenge or objective in place, this quickly turns into a “What could we improve?” exercise followed by a calculation about whether it is even worth going through that effort or might be cheaper to just outsource the entire thing to a “low wage country.”

But there is another, more tactical, reason to ask this question.

If your step was “Make a value stream map,” then “What do you expect as a result of taking that step?”

I have heard responses such as “I expect the leaders to see what they need to fix.” That, actually, is a testable outcome if you do so with intent. But if you are frustrated that, time after time, a current state process gets mapped and then nothing else happens, then it might be time to ask “What am I learning?”

This kind of brings us back to the importance of that overall strategic intent, because that is what drives the necessity to then build a possible future state map that, if we can operate that way, will deliver the results we need. From that we can establish challenges for individual local leaders and work with them (coach them) toward reaching those challenges.

Again – this is all a lot of work. And it is hard. Thus it is equally important to understand that the higher level goal here is to build capability and competence within your organization. If you forget that part, then it is all to easy to just outsource the mapping (see the beginning of this post) or, worse, outsource your entire value-add chain.

*The title of that post, and this one, is based on a groundbreaking book by Mike Rother and John Shook, Learning to See. Published in 1999, it introduced the term “value stream map” into the vernacular. And it was the first significant publication of the then newly-formed Lean Enterprise Institute. I think Learning to See actually had the impact of establishing a genre – practical application workbooks that sent beyond just discussing benchmark examples and general principles.

Posted on

Signs of a Failing Lean “Implementation”

Let me profile a company – I have an actual company in mind, but this one is only a concrete example.

This company has been engaged with continuous improvement since at least 1998. Yet, just a few weeks ago, they posted an opening for a Continuous Improvement Director. And this isn’t the first time. I have seen this position posted by this company every couple of years.

The posting explicitly calls out this C.I. director’s responsibility to “champion” their “[Corporate Name] Business System.” That at least implies that the [Corporate Name] Business System is something aspirational that must be internally championed by others rather than the way they simply do business every day. Indeed, they feel the need to hire someone from outside the company to champion their [Corporate Name] Business System to their own leaders. This is pretty strong evidence that the actual Business System within the company is something radically different than [Corporate Name] Business System.

This is not a sign of success over the past quarter century. Quite the opposite. We have a company with people on the payroll who were not even born when the C.I. effort was initiated. If senior leaders have come up through the company ranks, they have been exposed to the tenants of the [Corporate Name] Business System their entire careers.

Yet it is still necessary for a dedicated person to advocate for it.

If this company might be you… here are some questions to think about:

How much actual cultural change has taken hold in the day-to-day operations since you have been engaging in kaizen activities?

Is the daily activity of your line leaders – the team leaders, supervisors, first line managers – reflective of something other than your [Corporate Name] Business System? If so, why? What forces are at work to push those activities in a different direction than the one you say you want? For example, are there metrics or line management expectations that run counter to moving continuously toward 1:1 production at takt? What policies or expectations are in place that systematically undo the results of a kaizen event?

How much daily kaizen is done by your line leaders? Your supervisors? Do your first-line leaders coach your supervisors on improvement? Are they qualified to do so? If yes, do those improvement activities tier up through line management toward the higher-level goals of the company?

Do your manufacturing supervisors have the basic industrial engineering skills? Can they fluently talk about takt time, cycle time, flow, work balance, etc? Are those skills represented in the way they run their day-to-day operations?

If the answers to these questions are largely in the negative — if you have been at this for two decades+ and they are still in the negative, then I think I can safely say that this isn’t just some kind of fluke. What you have been doing is not working. If you are looking to do more of what you have been doing, maybe consider trying something else.

That being said, don’t give up. It isn’t that this stuff doesn’t work, it is that your approach to embed it into the organization has, up to this point, been ineffective.

Consider an approach where the primary focus is on the patterns of day-to-day interactions between people, working toward having them engage in effective problem solving and learning on a daily basis. If improvement only happens as an event, then it is, by definition, not “continuous.”

I believe that structuring those day-to-day interactions is the purpose of all of the so-called “lean tools” (and all of the other “tools” called out by other packages such as TQM, xSigma, TOC, etc). But unless those tools are deployed with that purpose in mind, it is all too easy to put in the mechanics without creating any shift in the culture.

And it is the culture that actually matters.

So ultimately my question is this: Do you have the continuous culture that you want today? If your [Corporate Name] Business System is actually in place, congratulations. But if that culture is still aspirational, and if you are trying to, yet again, hire someone from outside to champion that culture, what is everyone in charge doing?

Posted on

Another Tale from the Past

This all happened nearly three decades ago. Since then the company has been through a series of mergers and acquisitions. Thus, the only thing I can be certain of is that things are different today – at least I hope so.

It was Tuesday afternoon of a traditional five-day kaizen event. Monday morning had been spent training the team on the basics of “JIT” including some fundamental principles and a 1:1 flow simulation just to demonstrate some of the possibilities.

Beginning mid-afternoon on Monday and continuing into Tuesday morning was “walk the process” – mainly looking at material flow, where things bunched up, and things that wasted people’s time (there was no shortage of that). By Tuesday afternoon the team was being guided through the process of developing a “vision” – a fairly idealized version of what would be possible with some changes.

The team I was assisting with was focused on flow through an annealing oven. This was near the end of the process, and was perceived as a bottleneck. It was designed as a long tunnel, individual plates of material could be placed on a conveyer at one end, and would come out the other having spent enough time in the oven for the process to work. It was ideal for 1:1 flow, and that is what we were advocating.

The current process, however, was to accumulate material in front of the oven until it was a pretty significant pile. Then stacks of material would be put on the conveyer – which now had to be slowed down because there was so much solid mass to heat up.

Math was on our side. It was easy to demonstrate that the oven actually had plenty of capacity, and could easily meet the need by operating it as it was designed. The problem-behind-the-problem was that nobody was assigned to load the oven, and it was kind of like that sink of dishes an apartment with four roommates.

Still, the team, composed primarily of front-line workers and a supervisor, was warming up to the idea that it was actually easier to load one piece at a time.

Part of the ritual was for the team to present their concept to the assembled management team for a green light. They did a pretty good job.

After that presentation, though, John came in. (I’m calling him John at least.)

John was dressed in his black slacks, white shirt and tie. He was the manager of “Industrial Engineering” and was adamant that this scheme would tank the metrics of the company. The oven was the bottleneck, you see. Unless it was heavily batch loaded, then it would throttle the output of the plant.

I stood up to engage him – and keep him from derailing the rest of the team, and slowly moved the conversation out of the room. I was dressed in heavy work clothes, metatarsal protective boots, carrying a hard hat under my arm, heavy gloves inside it. I didn’t work there.

John showed me his pages of printouts to prove that the current output of the oven was inadequate, to make the case that anything that slowed it down would be disastrous. Those printouts, of course, only showed output.

My response: “John, I have been here for two days. I walk past that oven every time I go into and leave the plant. I have, not once, seen anyone working there. The reason the oven is a bottleneck is because nobody loads it.”

This was not a function of machine capacity. I had that math too – and at the time was surprised that he didn’t. I was still new at this. Today I would not be surprised if management didn’t know theoretical or expected capacity. But the bottom line was simple: There isn’t going to be any output if there is no input.

I got the impression he couldn’t respond because he rarely, if ever, ventured into the actual plant. It was some distance from the office building, and it was loud, unheated in the winter (and COLD), hot in the summer. Simply put, he wasn’t dressed to go out there.

There were a lot of headwinds here, but nearly all of them came from the head office. Their top level metrics conspired against them – they measured success as the amount of material the pushed through the START of their value stream. The individual operations were isolated from one another physically, in both space and time with weeks and months of WIP separating them. The workers contract had heavy piece rate incentives. (I wasn’t smart enough at the time to ask if there was a differential piece rate for hitting a higher goal – vestige, of Frederick Taylor – but it would not have surprised me.) Needless to say, the concept of making operations dependent on one another with flow was a tough sell.

Even worse – and this just occurred to me – because there was no fixed crew for loading the annealing oven, the people being tasked to load it would be taken away from their piece-rate tasks, and actually reduce their pay to feed what management believed was the constraint to output.

Interestingly, though, we were back on the site a couple of months later. As I was walking through the shop, one of the workers pointed and shouted my name. He didn’t look happy, so I was thinking, “Oh, oh, I’m going to get an earful. “

And an earful I got. But it wasn’t about the concept. It was about management apparently not doing anything with the proposed changes. And I knew this guy – he was on the first team because he was a pretty influential informal leader among his peers. His opinion was important. He was willing to give all of this a try, but was frustrated that management seemed to be leaving them out to dry.

I’ve seen this before. The pushback from the shop floor has often been less of “we don’t believe this will work” and more of “We don’t believe management will support us as we try to make it work.”

I was pretty new at all of this. We were partnered with consultants that we paid for with the idea of eventually learning to lead these events on our own. What I was supposed to be learning was how to find opportunities, plan, and facilitate kaizen events.

But even then, I was starting to question whether kaizen events alone, no matter how many or how quickly they were run, would actually create long-term significant change. We need to work on the culture, and the things that drive the culture.

As an aside – I have been in a lot of industrial facilities. This is the only one where I actually felt in danger. I kept my head on a swivel at all times. Perhaps another symptom of management pretty much staying in their offices.