More About Mistake-Proofing

After yesterday’s post about trucks crashing into the famous 11foot8 bridge and mistake proofing, I got the feeling I should drive home my key point that the problem isn’t with the driver, it is with the environment.

As of this writing,  Jürgen has recorded 154 crashes of overheight vehicles into the bridge.

And I’ll put even money that if all of the data were known, this process would pass any test for statistical control and we are getting what we should expect from a stable system. It might not be what we want, but it is what we should expect. (All images are copyright  Jürgen Henn, 11foot8.com)

So addressing the individual incidents probably isn’t a solution. In any case, it is unlikely that any driver will repeat the mistake.* For the TWI folks – this isn’t really a Job Relations type of problem. It might feel like it is, but it isn’t.

In the Factory

I was working with a company with a similar problem. Their inspectors kept missing defects. The response was often to say “I don’t see how she could have missed that!” and even write them up for failure to do something that wasn’t particularly well specified.

But the fact on the ground was, like the bridge, the misses weren’t confined to any particular individuals, any particular shift, any particular anything. People missed things all of the time because the expectations greatly exceeded the limitations of what humans can do for 12 hours (or even one hour). It isn’t an inspection problem. (The reliance on inspection vs. upstream controls is another topic for another day.)

People Work Within a System

It is all too easy to fall into the “bad apple” fallacy and seek out someone who was negligent. It feels good, like we did something about the problem. But the problem will happen again, with someone else. Then I hear frustrated managers start to make disparaging comments about their entire workforce that “doesn’t care” about quality.

I challenged a quality manager to do that inspection job for two hours – not even a complete shift – under the watchful eye of the inspector whose job he was trying to do. Funny – he was a lot slower to assign blame after that experience. He couldn’t keep up.

Deming was pretty clear about the ineffectiveness of exhortation as a way to get better performance. “Be more careful!” might well work for one individual for a short time. “Making an example of someone” might well work for a group for a short time. But there are norms, and the system will return to those norms very quickly. There are simple limits to what humans can focus on and for how long.

The Bridge is a Metaphor

To be clear, the bridge represents a working system, but it is different than what we would find in a company. This is public infrastructure, and the truck drivers that get featured on the videos are not part of a single organization.

This means that you have more control than the city engineers in Durham do. You can establish procedures, ask questions, train people, have them practice, alert them to the Gregson Street Bridge on their route. You can make sure your navigation system routes your trucks around the low bridges. You can support your people so they are less likely to even end up in the situation. All of these are system changes – and that is what it will take to change the outcome.

Change the System: Raising the Bridge

In late 2019 the city of Durham, in coordination with the railroad who owns the bridge, did actually raise the bridge by 8 inches. It is now 11 feet 16 inches (3.76m).

And that is a legitimate approach. Rather than trying to create infallible humans, what can we do to make the system less vulnerable to fallible humans.

While that likely reduced the number of trucks that hit the bridge…


*Caveat: There is one video where a truck seems to avoid the bridge, then circle back around and hit it. And another video where a truck that hit this bridge then proceeded to run into another low bridge with the damaged truck.

Meta-Patterns: Thoughts for Discussion

I’ll be sending out the Zoom meeting link this (Wednesday) afternoon (May 6, 2020) for the Thursday (11 am Pacific) open discussion on the Meta-Patterns of Innovation.

1901 Wright Glider
Wright Brothers’ Experiments with the 1901 Glider

For those who only got email on the original post, this is a direct link to the video I was referencing: https://videopress.com/v/geNgzN4e

There are still lots of spots for anyone who is interested. Click Here to open the Contact Page, and let me know your email address and I’ll add you to the list.

Hugh asked a really good question in his email that relates to how to put these concepts (that are somewhat abstract and philosophical) into practical application in an organization.

I think that is a really good starting off point for a discussion, especially among change agents.

KataCon4 Keynote: The Meta-Patterns of Innovation

Yes – the title isn’t a typo. This goes back to KataCon 4 in Atlanta. Though I had attended all of them, this was the first time I actually spoke at one. My task was to follow Rich Sheridan and share why I thought his message was a powerful one for an audience of Kata Geeks even if he wasn’t specifically talking about Toyota Kata in his company.

As an experiment, I took the sound recording from my talk and synchronized it with the slide deck. (That is harder that it sounds, by the way.) As another experiment I am sharing it via hosting on WordPress (the back-end of this site) rather than YouTube or a similar host. It is a little over 13 minutes long, and there is another experiment below it.

Simon Sinek – Remote Teaming Tips

How Remote Teams Can Connect Meaningfully – Simon Sinek – March 20, 2020

We are all being pushed into the zone beyond our knowledge base right now – having to rapidly adapt and adjust to different ways of working together.

This morning Craig Stritar forwarded a cool little video to me from Simon Sinek’s YouTube channel. In it Steve Shedletzky, a member of Simon’s team, introduces their weekly huddle – a way that this team, which has been working remotely for years, maintains their connection to one another.

One of the keys here is that this meeting is not a conversation about the business at hand. There are other meetings for that. This one is intended to strengthen the social bonds of the group.

They dedicate 75 minutes a week to this task. The video is a condensed version to give us a taste of their structure.

And it is structure that makes it work. It is structure that makes sure no individual dominates the conversation, and structure that keeps it from becoming the kind of wide-ranging conversation that happens over beer and pizza.

It is structure that gives them the freedom to hear and be heard.

With that – here is the video.

For those who can’t see the embedded video, here is the YouTube link: https://youtu.be/tKEtm3HCrsw

Ghost Victories – an excerpt from Upstream by Dan Heath

Amazon affiliate link to book listing for Upstream by Dan Heath
The link to the image takes you to the Amazon listing for the book. If you happen to order it, I get a small kickback, no cost to you, Just FYI.

Dan Heath has just published a new book, Upstream: The Quest to Solve Problems Before They Happen.

I just got the book, and am reading it now. I think there is going to be a lot of good material to discuss here.

But this post is about a marketing email with an excerpt really resonated with me, and I want to discuss that. I wrote to Dan Heath, and got his permission to use pieces of the excerpt here. (Thank you, Dan)

Management By Measurement = “Ghost Victories”

I have talked about what I call “management by measurement” in the past. In that post I told a true story of a company that placed very heavy emphasis on reducing inventory levels without digging into how that performance was achieved. The net result was a an embarrassed CEO during a quarterly analyst’s call. Not good.

Dan Heath talks about the same thing in Upstream. He calls it “ghost victories.”

[when] there is a separation between (a) the way we’re measuring success and (b) the actual results we want to see in the world, we run the risk of a “ghost victory”: a superficial success that cloaks failure.

The most destructive form of ghost victory is when your measures become the mission. Because, in those situations, it’s possible to ace your measures while undermining your mission.

He goes on to describe a case in the U.K. where the Department of Health established penalties for wait times longer than four hours in the Emergency Departments. And it worked. Wait times were reduced – at least on paper. Then the facts began to emerge:

 In some hospitals, patients had been left in ambulances parked outside the hospital—up until the point when the staffers believed they could be seen within the prescribed four-hour window. Then they wheeled the patients inside.

In the old post I referenced above, I said:

If making the numbers (or the sky) look good is all that matters, the numbers will look good. As my friend Skip puts it so well, this can be done in one of three ways:

  • Distort the numbers.
  • Distort the process.
  • Change the process (to deliver better results).

The third option is a lot harder than the other two. But it is the only one that works in the long haul.

All of this ties very well to Billy Taylor’s keynote at KataCon6 where he talked about the difference between “Key Activities” and “Key Indicators.” It is only when we can get down to the observable actions and understand the cause-and-effect relationship between those actions and the needle we are trying to move that we will have any effect.

To avoid the “Ghost Victory” trap, Dan recommends “pre-gaming” your metrics and thinking of all of the ways it would be possible to hit the numbers while simultaneously damaging the organization. In other words, get ahead of the problem and solve it before it happens.

He proposes three tests which force us to apply different assumptions to our thinking.

The lazy bureaucrat test

Imagine the easiest possible way to hit the numbers – with the least amount of change to the status quo. The story I cited above about inventory levels is a great example.

I can make my defect rates improve by altering the definition of “defect.”

There are lots of accounting games that can be played.

This is one to borrow from Skip’s list – How can the underlying numbers be distorted to make this one look good when it really isn’t?

The “rising tides” test

What external factors would have a significant impact on this metric? For example, I was working at a large company where a significant part of their product cost was a commodity raw material. As the market price went down, “costs” went down, and bonuses all around. But when the market price went up, “costs” went up and careers were threatened and bad reviews issued.

Those shifts in commodity prices had nothing to do with how those managers were doing their jobs, the tide rose and fell, and their fortunes with it.

The question in my mind is “What things would make this number look good, or bad, without any effort or change in the process we are trying to measure?”

The defiling-the-mission test

Hmmm. This is a tough one. (not really)

And it is a really common problem in our world of quarterly and annual expectations. In what ways could meeting these numbers in the short term ultimately hurt our reputation, our business, in the long term?

For example, I can think of an ongoing story of a product development project that hit its cost and schedule milestones (what was being measured). But they did so at the cost of destroying their reputation with customers, their Federal regulators and the public (and, to a large extent, their employees). They now have a new CEO, but the deeper problem has origins in the late 1990s.

How long will it take them to recover? That story is still playing out.

In another case I was in a meeting with a team that was discussing a customer complaint. The ultimate cause was a decision to substitute a cheaper material to reduce production costs. But this is a premium brand. There was a great question asked there: “Which of our values did we violate here?” – so the introspection was awesome.

Next step? Ask that question before the decision is made: “Is this decision consistent with our values?” If that makes you uncomfortable, then time to look in the mirror.

Then there is this little incident from 2010:

Picture of burning Deepwater Horizon oil platform
BP Deepwater Horizon fire – Photo by USCG

The metric was cost and schedule. Which makes sense. But the behavior that was driven was cutting corners on safety.

Getting Ahead of Problems

The book’s subtitle says it is about getting ahead of problems. I am looking forward to reading it and writing something more comprehensive.

KataCon 2020: Billy Taylor on Leadership

Photo by Michele Bucher / Lean Frontiers

Continuing my breakdown of Billy Taylor’s opening keynote at KataCon…

Key Bullet Points

  • People follow what you do before they follow what you say.
  • If you (as a leader) think you are above the process…
  • Deliberate practice on your practice of leadership. Focus on one thing.
  • Break down your leadership style [into elements]. Practice deliberately on one thing you want to reinforce or improve.

That second bullet is a real challenge for those of us who are in leadership positions (or even positions of influence). “If you think you are above the process…” – do you follow the standards and expectations you ask of others?

I think a good test would be “If a production worker corrected you, how would you respond?” If your internal emotional response (that initial feeling you have, not how you show yourself) is anything other than “Thank you for reminding me” then you are exempting yourself from the rules.

The other take-away:

Throughout his presentation, Billy was tying together the idea of “deliberate practice” and “developing leadership skills.” Leadership is a process, and processes can be broken down into their constituent elements and practiced.

This ties back perfectly to a broad spectrum of leadership development models. In the end, what we can control are:

  • What we say.
  • How we say it.
  • Who we say it to.
  • The structure of the environment that either inhibits or encourages the behaviors we want.

All of these things can be developed through experimentation, and then practiced. This is what Toyota Kata is about.

What Is Your Target Story?

One of the artifacts of Extreme Programming as practiced by Menlo Innovations is the Story Card. In the purest sense, a story card represents one unit of work that must be done by the developers to advance the work on the software project.

But the content and structure of the story card make it much more powerful than a simple task assignment. The story card is written in a way that engages the programming pair doing the work.

Before a story card is created the team works very hard to identify the primary persona that represents the human being who most benefits from their work. That persona gets a name, a face, a biography. She has wants, needs and aspirations.

Menlo primary persona
(c) Menlo Innovations. The primary persona is shown in the center of the target. There are two shown in the second ring, and three in the third ring.

Why? A couple of reasons.

First, it establishes priority of effort. In software development compromises must be made between optimizing the interface and workflows for various users. By identifying the primary persona, the team says “This person’s use of the software will be optimized.” Other users will certainly be accommodated, but any compromise will break in favor of the primary persona.

Menlo, for one, works very hard in the up-front design process to smoothly integrate the workflow created by their software into the larger context and workflow that their end-user is trying to carry out.

The other effect is more subtle. It humanizes the “user” as the developers are talking about what their code does, or does not, do.

Rather than simply set out a feature in an abstract way, the story card focuses on granting an ability to the main persona. The process of creating the personas, and developing the persona map humanizes the group of people that would traditionally be thought of as “the users.”*

Thus, the feature would be described something like this:

“Sara is able to select her choice of color from a pull-down menu of options.”

Then the developers write code that enables Sara to do this, quickly and easily.

This is a simplification, but it suffices to set up my main point.

Who Are You Optimizing Your Improvements For?

Let’s translate this thinking into our world of continuous improvement.

Who is your key persona? Who are you enabling with your process improvement? What will this person be able to do that, today, he cannot?

Rather than saying “The lowest repeatable time does not exceed 38 seconds” as a target condition, what if I said “John is able to routinely perform the work in 38 seconds when it is problem-free.”

I don’t know about you, but I feel a lot more emotionally engaged with the second phrasing. This is doubly true if John is an actual person actually doing the work.

What about scaling to other shifts, other operators?

Yup. I agree that at some point your target condition is going to shift to “Any trained team member” but what I tell people today when they are trying to go there first is this:

“If you can’t get it stable with one person, you are never going to get there with multiple people.”

You have to get it to work once first. Then introduce the next layer of complexity. Start simple. One step at a time. Control your variables.

I have been experimenting with this linguistic shift in my Toyota Kata classes and consulting.

If you are in R&D this is an even more direct application back to Menlo’s model.

Training = Giving People Ability

I also ran an experiment with a client HR team that was charged with developing a comprehensive on-boarding training process.

Rather than do the traditional thing, which is take the laundry list of topics they are supposed to try to cover, and trying to figure out how to stuff everything into the time they have been given (40 hours, which is really more like 35 hours), I asked them to experiment with the following:

For each skill they have been asked to train, write it on a separate 5×7 card in the form of “[The learner] is able to _________.” In other words, describe the skill as an ability that someone is able to demonstrate.

Then determine how they will test that skill. Do that before they even think about how they are going to teach it.

Then develop training experiences and exercises that they believe will allow the learner to pass the test.

Software developers will recognize this as “test driven development” – start with the unit test, then write the code.

Testing Your Target Condition

As in the example above, a target condition should also be testable. By stating what we will observe or measure when the target condition is met, we are constructing a “unit test” of sorts.

By stating what we will observe or measure first, we can separate “solved” from “the solution” and open up the possibilities of what solution(s) we will experiment with.

—————–

In the culture of many more traditional software development and I.T. organizations, “users” can be almost a derogatory term, with an implied, usually (but not always) silent “dumb” appended to the front. We write Books for Dummies so they can understand our brilliant systems.

The Cancer of Fear

File:Nandu River Iron Bridge corrosion - 03.jpg

I am sitting in on a daily production status meeting. The site has been in trouble meeting its schedule, and the division president is on the call.

The fact that a shipment of material hadn’t been loaded onto the truck to an outside process is brought up. The actual consequence was a small delay, with no impact on production.

The problem was brought up because bringing up process misses is how we learn what we need to work on.

The division president, taking the problem out of context, snaps and questions the competence of the entire organization. The room goes quiet, a few words are spoken in an attempt to just smooth over the current awkwardness. The call ends.

The conversation among those managers for the rest of that day, and the next, was more around how to carefully phrase what they say in the meeting, and less about how do we surface and solve problems.

This is understandable. The division president clearly didn’t want to hear about problems, failures, or the like. He expected perfect execution, and likely believed that by making that expectation loud and clear that he would get perfect execution.

That approach, in turn, now has an effect on every decision as the managers concern themselves with how things will look to the division president.

Problems are being discussed in hallways, in side conversations, but not written down. All of this is a unconscious but focused effort to present the illusion that things are progressing according to plan.

Asking for help? An admission of failure or incompetence.

This, of course, gets reflected in the conversations throughout the organization. At lower levels, problems are worked around, things are improvised, and things accumulate and fester until they cannot be ignored.

They the bubble up to the next level, and another layer of paint is plastered over the corrosion.

Until something breaks. And everyone is surprised – why didn’t you say anything? Because you didn’t want us to!

In a completely different organization, there were pre-meetings before the meeting with the chief of engineering. The purpose of these pre-meetings was to control what things would be brought up, and how they would be brought up.

The staff was concealing information from the boss because snap reaction decisions were derailing the effort to advance the project.

And in yet another organization they are getting long lists of “initiatives” from multiple senior people at the overseas corporate level. Time is being spent debating about whether a particular improvement should be credited to this-or-that scope. It this a “value improvement,” is it a “quality improvement,” is it a “continuous improvement” project?

Why? Because these senior level executives are competing with one another for how much “savings” they can show.

Result at the working level? People are so overwhelmed that they get much less done… and the site leader is accused of “not being committed” to this-or-that program because he is trying to juggle his list of 204 mandated improvement projects and manage the work of the half-a-dozen site people who are on the hook to get it all done.

And one final case study – an organization where the site leader berates people, directly calls them incompetent, diminishes their value… “I don’t know what you do all day”, one-ups any hint of expert opinion with some version of “I already know all of that better than you possibly could.”

In response? Well, I think it actually is fostering the staff to unite as a tight team, but perhaps not for the reasons he expects. They are working to support each other emotionally as well as running the plant as they know it should be run in spite of this behavior.

He is getting the response he expects – people are not offering thoughts (other than his) for improvements, though they are experimenting in stealth mode in a sort of continuous improvement underground.

And people are sending out resumes and talking to recruiters.

This is all the metastasized result of the cancer of fear.

Five Characteristics of Fear Based Leaders

Back in 2015 Liz Ryan wrote a piece in Forbes online called The Five Characteristics of Fear Based Leaders.

In her intro, Liz Ryan sets out her working hypothesis:

I don’t believe there’s a manager anywhere who would say “I manage my team through fear.”

They have no idea that they are fear-based managers — and no one around them will tell them the truth!

And I think, for the most part, this is true. If I type “how to lead with fear” into Google I get, not surprisingly, no hits that describe the importance of intimidation for a good leader – though there are clearly leaders (as my example above) who overtly say that intimidation is something they do.)

My interpretation of her baseline would be summarized:

People who use fear and intimidation from a position of authority are often tying their own self-esteem to their position within that bureaucratic structure. Their behavior extends from their need to reinforce their externally granted power, as they have very little power that comes from within them.

They are, themselves, afraid of being revealed as unqualified, or making mistakes, or uncertain, or needing help or advice.

I have probably extended a bit of my own feelings into this, but it is my take-away.

She then goes on to outline five characteristic behaviors she sees in these “leaders.” I’ll let you read the article and see if anything resonates.

Liz Ryan’s article is, I think, about how to spot these leaders and avoid taking jobs working for them.

This post is about how the organization responds to fear based leadership.

The Breakdown of Trust

A long time ago, I wrote a post about :The 3 Elements of “Safety First”. Today I would probably do a better and more nuanced job expressing myself, but here is my key point:

If a team member does not feel safe from emotional or professional repercussions, it means they do not trust you.

Fear based leadership systematically breaks down trust, which chokes off the truth from every conversation.

Here is my question: Do you want people to hide the truth?

If the answer is “No,” then the next question is “What forces in your organization encourage them to do so?” because:

Your organization is PERFECTLY designed to produce the BEHAVIORS you are currently experiencing.

– VitalSmarts via Rich Sheridan

LEI Book: Getting Home

“Are you ahead or behind?” seems an innocent enough question.

But when asked by a Toyota advisor, the simple process of becoming able to answer it launched Liz McCartney and Jack Rosenburg on a journey of finding consistency in things that were “never the same” and stability in things that “always changed.”

Getting Home is, first and foremost, a story. And, with the “business novel” being an almost worn-out genre, seeing a non-fiction story was refreshing. So when Chet Marchwinski from the LEI offered a review copy to me, I accepted.

For the story background, I’ll leave it to you to read the blurb on Amazon.* Better yet – read the book – and it is worth reading. I’ll say that right up front.

Yet with stories like this it is all too easy to dismiss them because they have different circumstances from “my” specific case and say “Yeah, it worked there, but won’t work here.”

I would contend, however, that in this case “it worked” in situations that are far more difficult than anything we are likely to encounter in most organizations.

What I want to do here is help pull their specific achievements into more general application – what lessons are here that anyone can take away and apply directly.

What They Achieved

I can’t think of a lot (any?) business circumstances that would have more built-in variability and sources of chaos than the process of rebuilding communities after a disaster such as a hurricane or flood.

Every client has different circumstances. The make, mix and skill levels of the volunteer workforce changes continuously. Every community has different bureaucratic processes – not to mention the various U.S. government agencies which can be, well, unpredictable in how and when they respond.

Yet they have to mobilize quickly, and build houses. This means securing funding, getting permits, mobilizing unskilled and skilled labor, and orchestrating everything to meet the specific needs of specific clients on a massive scale… fast.

How They Achieved It

When they first connected with their Toyota advisor, the simple question, “Are you ahead or behind?” prompted the response that drives all improvement, all scientific advancement, all innovation:

“We don’t actually know.”

Actually they did, kind of, but it was in very general, high-level terms.

And that is what I encounter everywhere. People have a sense of ahead or behind (usually behind), but they don’t have a firm grasp on the cause and effect relationship – what specific event triggered the first delay?

This little book drives home the cascading effect of ever deepening understanding that emerges from that vital shift from accepting things as they are to a mindset of incessant curiosity.

Being able to answer “Are you ahead or behind?” means you have to have a point of reference – what is supposed to happen, in what order, with what timing, with what result. If you don’t know those things, you can only get a general sense of “on track” or not.

They had to develop standards for training – what to train, how to train – volunteers! – , which meant challenging assumptions about what could, and could not, be “standardized.” (A lot more than you think.)

A standard, in turn, provides a point of reference – are we following it, or are we being pushed off it. That point of reference comes back to being able to know “Are we ahead or behind?”

 

It Isn’t About the Specific Tools

Yet it is. While it isn’t that important about whether this-or-that specific tool or approach is put into place, it is critical to understand what the tools you use are there to achieve.

As you read the book, look for some common underlying themes:

Information as a Social Lever

The project started revolving around the ahead/behind board.

In the “lean” world, we talk about “visual controls” a lot, and are generally fans of status boards on the wall. We see the same thing in agile project management (when it is done well).

These information radiators work to create conversations between people. If they aren’t creating those conversations, then they aren’t working. In Getting Home it was those conversations that resulted in challenging their assumptions.

Beyond Rote Implementation

Each tool surfaced more detail, which in turn, challenged the next level. This goes far beyond a checklist of tools to implement. Each technical change you make – each tool you try to put into place – is going to surface something that invites you to be curious.

It is the “Huh… what is happening here?” – the curiosity response – that actually makes continuous improvement happen. It isn’t the tools, it is the process of responding to what they reveal that is important.

Summary

Like the tools it describes, Getting Home is an invitation, and that is all, to think a little deeper than the surface telling of the story.

My challenge to you: If you choose to read this book (and I hope you do), go deeper. Parse it. Ask “What did they learn?” ask “What did this tool or question reveal to them, about them?” And then ask “What signals did they see that am I missing in my own organization?”

 

 

———-

*This is an affiliate link that give me a very small kickback if you happen to purchase the book – no cost to you.

How Do You Know They Know?

TWI Job Instruction is built around a four step process titled “How to Instruct.”

image

Steps 2 and 3 are the core of the process.

  • Present the Operation
  • Try Out Performance

I want to discuss Step 3: Try Out Performance

Teaching Back as Learning

All too often I see “training” that looks like this:

  • Bring the team members into a room.
  • Read through the new procedure – or maybe even show some PowerPoints of the procedure.
  • Have them sign something that says they acknowledge they have been “trained.”

This places the burden of understanding upon the listener.

The TWI model reverses this paradigm with the mantra at the bottom of the pocket card which, though they vary from version to version, is some form of: If the student hasn’t learned, the teacher hasn’t taught.

Having the learner teach back to the instructor does two things:

  1. The learner has to understand it better to be able to explain it.
  2. It provides a verification check that the instruction has been effective.

Point two is important here. Instruction is a hypothesis: “If I teach these steps, in this way, my learner will be able to perform the process.”

Having them teach back is the testable outcome of this hypothesis. If the the learner struggles, then the instructor must re-instruct. But not simply by rewinding the script and playing it again… we know that didn’t work. Instead the instructor now has to get curious about which points are confusing the learner and why, and correct his instruction.

But that’s not what I came here to discuss. TWI is just a lead-in.

Learning to See – by Practicing

An operations manager who is learning fast was challenging my insistence on having a visual status board that showed the real-time location of product on the line.

In the same breath, he was saying that he wanted the leads and the supervisor to be able to “walk the trapline” and do better seeing issues coming before a train wreck. (Empty positions, overproduction, etc.)

My response was “Having them update the magnets on that board every time something moves forces them to practice seeing what is where.”

In other words, by making them teach you where things are, and demonstrate their knowledge, they have to learn how to see that bigger picture.

“That’s the best explanation I have ever heard.”

The operations manager can walk the line and see the status himself. He doesn’t need the board. In fact, he could see even better if he went up the mezzanine overlooking the line. It’s all there.

But the board isn’t for his benefit. It is a learning tool. It is structure for the leads and supervisors to have a joint conversation, facing the board instead of each other, and reach agreement about what is where.

It gives them a clear indication if they need to escalate a problem, and a way to be able to converse about when and how they might recover (or not).

In other words, it is “Grasp the Current Condition” continuously, in real time. This lets them compare the current condition with the target condition – the standard depicted on the board.

By seeing gaps quickly, they have a better chance at seeing what obstacle or problem prevented them from operating to the target.

That, in turn, gives the manager an opportunity – in invitation – to shape the conversation into one about improvement.

Back to Job Instruction

This is exactly the same process structure as having the learner demonstrate performance. It is a check, right after the operation (present the operation) was performed to see how well it worked.

Fine Grained Observation

All of this is about moving observations, evaluations, checks, verifications away from batching them at the end of a huge block of work and embedding them into one-by-one flow. It builds Ohno’s “chalk circle” into the work itself.