The client organization was working to incorporate the Toyota Kata mindset – scientific thinking / systematic problem solving – into their daily routines. This was early on in my journey as well, we were all learning.
The company had a structure for how they wanted to go about it. My role was to advise, coach, and be “the expert” in the room. After some initial awareness training and exercises, they set up storyboards and started trying to apply the concepts to actual challenges.
Learning groups of three would practice by doing round-robin coaching, with one in the role of the learner, one in the role of the coach, and one in the role of the 2nd coach.
I would spend about a week a month working with them to help them stay between the guard rails. As long as they were serious about their reflections, and kept the mindset that they were all working to learn something unfamiliar, it worked pretty well.
Then something really cool happened.
One of the managers related that he had used the Coaching Kata to work with one of his employees who was on a PIP.
For those who don’t know, PIP stands for “Performance Improvement Program” and, bluntly, is usually a pro-forma process that ends with the person being fired. The idea is that they are told what changes they must make in their behavior and given a deadline to make them. There are lots of ways to do this in ways that the victim, I mean subject, simply cannot succeed. In general, I consider the entire process disingenuous.
But that’s not what happened in this case. Rather than laying out a checklist of criteria, the manager started coaching.
He took his employee through “Grasping the Current Condition” and had him describe the behaviors(s) that were getting him into trouble. The employee was asked to begin keeping track of those things during his day.
Rather than telling him what must be changed, the manager asked the employee about a Target Condition: What are you working on now? What obstacles do you see that are in the way?
They met every day and reviewed what the employee intended to do, what he expected, what actually happened, and what he learned in the process. Every. Single. Day.
At the end of the 90 day process the guy had changed – to the point of being a totally different person at work. He kept his job, and became a real contributor to the team.
What really impressed me was that this was a novice coach, he had been exposed to Toyota Kata a few months before. And, honestly, it was a low-risk situation for practice (at least for the manager) – they had already written this employee off. But this manager, instead, made a commitment to do the hard work beyond just being critical and documenting every transgression. He had his employee doing the documenting and reflecting as he went.
While we are fond of saying things like, “If the student hasn’t learned, the teacher hasn’t taught,” the truth is that it is only the “student” who can learn, and learning requires an intrinsic motivation to do so. If the motivation isn’t intrinsic you may gain compliance, but that is the best you are going to do.
The coach in the story above created an environment where his Team Member was the one who had to understand the current condition, had to make decisions about what he wanted to change, and had to decide how he was going to try to make those changes.
It wasn’t a case of telling him what to do. There is a big difference between being told, “You need to…” and saying out loud, “I want to…” The coach gave his team member the opportunity to turn that “need to” into a “want to” and then provided structure for doing it.
At the same time, the coach was willing to put in the work to hold that structure in a way that created safe space for the team member to reflect on his own behavior and learn.
This Is the Improvement Kata
And finally – my title is misleading. This is the Improvement Kata. The only difference is in context. Rather than working to improve a process as an outside observer, the Team Member was working to improve the process of his own behavior. The fundamental steps are exactly the same:
Agree on the overall challenge.
Reach agreement on the current condition, including cause and effect.
Establish a concrete goal (Target Condition) and identify obstacles.
Engage in experiments, with discrete learning and feedback, to overcome the obstacles.
Have you had cases where you have used a similar process to help someone through real change? I’d love to hear about them.
(Click on the coaching cards below to download your own if you want.)
Last fall I got to spend another week hanging out with the awesome team at Menlo Innovations in Ann Arbor. My last visit there was scheduled for early April 2020… but we probably all know what happened back then.
I am saying all of that because I am going to use their project management system as a benchmark in this article, and I am most assuredly not an unbiased observer. Maybe I was the first time I spent time there, but today they are friends.
What makes Menlo’s project management system stand out to me is captured in the title of this post: Their project management system and their daily management system are one-in-the-same. In retrospect, I can’t think of any other way that project management would be effective.
Getting Stuff Done
In spite of the wishes of some business leaders, there are only so many hours in a week, and there are only so many people available to get things done.
People are busy on stuff. Giving them more to do means something else is not going to get done. The very foundation of Menlo’s culture is making absolutely sure these conflicts are resolved by removing all ambiguity around what is the next most important thing at any given moment.
The other thing their process accomplishes is absolutely eliminating informal scope creep. Rich Sheridan calls this “hallway project management.” It sounds like this, “Hey Mark, I know you’re busy, but do you think you might be able to do this thing for me?” If I answer with an open “Yes,” I have just signed up to do something I may, or may not, have time for. It is now up to me to decide whether it is more important than other things I need to get done. Ultimately that means I have to decide what is not going to get done today.
Who makes that decision in your organization? The decision of what doesn’t get done? The decision of what gets done instead of working on the Main Thing? If that is left to the individual software developer, the individual design engineer, then does management later second-guess that decision? If so, this is the very opposite of “Respect for People.”
Another fundamental principle is that a person cannot actually work on more than one task at any given time. What we call “multitasking” is actually quick steps of starting, stopping, figuring out what task to work on next, starting that, etc. I can’t simultaneously work on this post and pay attention to someone else.
There is a non-trivial time and attention overhead involved every time continuity must be regained. That discontinuity also creates potential for quality issues like leaving things out.
Having a pile of tasks to work on all at once also makes it easy for a task to keep getting pushed off until the time left to do it is insufficient, and can conceal problems that get in the way of the work going smoothly
Menlo’s System
(At least my interpretation of their system.)
Like any project management system, Menlo’s up-front planning process breaks down the overall project into individual tasks, things that need to get done to make progress. They document those tasks on “Story Cards” which are physical cards that each represent a single feature to build into the software. One story card represents one task that advances the project.
One key feature of a story card is that there is little ambiguity. Adding to that, it is a core part of Menlo’s culture that if someone does encounter ambiguity the response is asking, not guessing.
Here is a “live” story card I photographed (with their permission) last fall:
Estimating Time
In the upper right corner of a story card is the estimate in hours. Both of the above examples happen to be 16 hours.
There are two critical keys here.
The people who are going to do the work are the ones who make the estimates.
Those estimates are not second-guessed or adjusted by others.
These estimates are based on, “Once we start on this, how long will it take to get it done.” The assumption is that there is no multi-tasking. This isn’t “When can I finish it.” It is “How much time must I spend to do it.” That may be different from what you are used to in your projects, but it is critical to make this work.
Estimates Are Wrong
Menlo generally does a pretty good job with this because they collect “actual actuals” as they are working. That gives them a good reference library of analogous work they have done in the past.
But, that being said, the estimate is made when the actual knowledge of what will be required is at its lowest. This is true for ANY time estimate, no matter where or who you are.
In many organizations a time estimate becomes a firm commitment and, worse, there are negative consequences if the task ends up taking longer than estimated. This inevitably leads to people padding the estimate, which then leads to the game of project managers cutting the time allotted. That does not happen at Menlo. Rich Sheridan tells the story of why that does not happen there far better than I can in this clip from a talk he gave some years ago. (Link here for the entire talk)
(As an aside, the first time I visited Menlo (for a week), I actually witnessed some fairly bad news get shared in the daily standup. The response was a quick huddle, lasting a couple of minutes, between the developers and the project manager immediately after the daily standup to discuss communication with the customer. Then everyone got back to work.)
Time Bounded Work Planning
Menlo’s basic project management cycle is a work week (typically 5 days). Menlo calls this an “iteration,” but the jargon doesn’t matter. Each week they:
Review the cards (tasks) that have been completed.
Decide with the customer what cards will be scheduled for the next week.
This is irrelevant to you at the moment, but Menlo’s developers work in pairs. One pair working for one week is the basic unit of capacity for planning purposes.
There are 32 productive hours in their week, plus 8 hours of overhead such as standing meetings, project support tasks, reviews with the customer. Thus, for one pair, they can schedule 32 hours worth of cards. No more.
The process they use is ludicrously simple. They call it “planning origami.”
For each pair of developers (what you might call a “resource” in traditional project management terms), there is a physical sheet that is sized to represent 32 hours.
Using photocopies of the story cards – the size of one card represents 16 hours.
If the card is estimated at 8 hours, they fold the card in half. A 4 hour card is folded in half again.
A 32 hour card is taped to a full sheet of paper that takes up the entire 32 hour space.
At Menlo the customer is the one making the decision about what gets done, and what does not get done, this week. THEY must choose the cards (with help from the Menlo, obviously) and fit them into the planning sheets which represent the resource capacity available to them.
If someone (the customer) insists on adding something, something else has to come off. The capacity is fixed. What gets done with that capacity is entirely up to the customer.
THIS IS THE ONLY WAY WORK GETS INTO THE “TO DO” QUEUE.
Thus, everyone knows what is expected to get done and, more importantly, what we are NOT going to work on this week.
Now… sometimes things go really well. The customer can prioritize “pull ahead” cards in case things go faster than expected (underrun the estimates), and there is additional capacity.
Daily Management
All of this was to set up the daily management system.
At the start of each week, the planned cards are placed, in order, on the “work authorization board” which is a tack board on the wall. The name is literal. This is the work that is authorized to be done this week.
But this is more than a task list. The work authorization board is a live reflection of what is actually happening vs. what was planned.
Each column on the board represents one unit of capacity, in their case one week of work for one programming pair team.
The developers work on the cards from top to bottom, in order.
When they start work on a card they put a yellow dot on it.
When they think they are done, they put an orange dot over the yellow dot. This signals the Quality Advocate to verify that the code accomplishes the intended function. If it passes, the card gets a green dot and the developers start on the next card.
If something is stopping progress, the card gets a red dot (and the Project Manager is informed).
Each day’s estimated work is clearly identified. There is a piece of yarn across the board that is moved down each day. Thus, if there are incomplete cards above the yarn, they are behind. If there are completed cards below the yarn, they are ahead.
Nobody has to ask a pair what they are working on. It is the card with the yellow dot on it. Status is clear to all.
If you were to visit Menlo with the above information, you would be able to grasp the status of all of their projects just by walking around the perimeter of the work area.
It. Is. That. Simple.
This process manages the project at a low level of tasks rather than more abstract “milestones.” Yes, there are milestones, but the level of management is every day. This allows the people who are doing to the work to tightly manage the progress of their work. The Project Manager is freed up from trying to keep track of everything simply because it is insanely easy for anyone to see the status in real-time during the course of any given week.
Accountability
There are two basic rules for accountability here. Rich goes through them in the video embedded above.
The developers will never, ever, get any negative feedback, real or implied, for reporting that they blew an estimate and just discovered something is going to take a lot longer than they thought. This is accountability from management, which MUST come before asking for accountability from anyone else.
The developers must inform the Project Manager immediately when they realize something will take longer than they thought.
Rule 2 will not work without Rule 1 because otherwise people would pad estimates, not report bad news, or otherwise try to protect themselves.
This measures TASKS, not milestone dates. If the tasks get done, we will hit the milestones. Missing a milestone is too late to recover.
There are still milestones, but they day-to-day work is reality, and milestones may well be adjusted to reflect reality as everyone learns more. Remember, project milestones are established when we know the LEAST about what work is actually entailed! That is true for ANY project management system.
Handling Emergent Work
If someone approaches a developer with a “can you just do this too” kind of task, the developers have a practiced, rehearsed, response: “Yes, absolutely. Let’s get it on a card and estimated so we can get it into the schedule.”
Thus, if something is going to be added, something else has to come off. The work authorization board only holds 32 hours of cards / week for each programming pair.
More Management Accountability
Management is accountable to stand behind the system. This, again, is demonstrating respect for people. Management refuses to override “just this time,” There is not time for “just one more little thing.”
Weekly Cadence
At the end of each week, the developers and the customer meet to review progress. Menlo typically has the customer demonstrate software features back to the developers. This gives the developers better feedback on whether or not the customer’s needs are being met. It also validates the design decisions about how intuitive the user interface is.
Then the Planning Game repeats.
So based on what is actually done and what is actually remaining, the weekly planning process is repeated for the next week.
Back to the Title: Project Management IS Daily Management
What this system does is tightly link project management to actual, daily, task execution. This is the key to making it work.
The only way to hit the long-term goals is to track execution at a level of granularity that allows you to see problems and delays while they are small enough to deal with, and have a robust system for actually dealing with them.
If your project tasks have vague definitions of “done” and estimates based on completion dates you are inviting additional work to creep in unnoticed.
Menlo’s system acknowledges the one thing that is hard: There is only so much capacity to get things done, and we must plan to that limitation.
Doing that requires management discipline to the process, and that generally is the hardest part.
Further Reading for Context
I highly recommend reading Rich Sheridan’s book Joy, Inc for the back-story of why it was important to create this process in the first place. (The link as an Amazon affiliate link, if you choose to buy the book I’ll get a small kickback, no cost to you.)
Question for YOU
How does your project management process stack up against this benchmark? Leave a comment – let’s get a discussion going, there are a couple of thousand of you out there subscribed to these posts.
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.
In the early morning of March 23, 2022 a leaked email with the subject “Why gas increase is good for hiring” surfaced on Reddit. (Click the hot link to see the actual post.)
The email in question was sent by the Executive Director of Operations of Apple Central LLC, a major franchisee of Applebees restaurants. He was describing the “opportunity” presented by higher gas prices, increasing prices and increased cost pressure on smaller restaurants. Quoting a couple of key lines:
“The advantage [of higher gas prices] has for us is that it will increase application flow and has the potential to lower our average wage”
He continues:
“Any increase in gas price cuts into [our employees] disposable income […] that means more hours employees will need to work to maintain their current level of living.”
Now, to his credit, after saying “besides hiring employees in at lower wages to decrease our labor cost” he closes with the advice to “Do the things to make sure you are the employer of choice” But this means “Get schedules completed early so they can plan their other jobs around yours.” though he does close with “have the culture and environment that will attract people.”
According to reports in the local newspaper, the manager in the Lawrenceville, Kansas Applebee’s was so angered by the content and tone of this message that he made copies of the email, distributed it to the employees, and he and two other managers quit on the spot in protest forcing the store to close for at least a day. One of those copies ended up being scanned and uploaded.
Blowback
Within an hour of the posting on Reddit, the thread was picked up on Twitter by Rob Gill. There were tens of thousands of forwards, retweets, views.
To Applebee's franchise executive Wayne Pankratz, surging gas prices are an opportunity for his business, rather than a downside – because it'll "force people back into the work force" https://t.co/6jmCXgVpeo
There are more. Many more. Just search for “Wayne Pankratz” email and you will turn up lots of hits.
OK – so what can we learn here?
I didn’t write about this just to pile on to the story. The mainstream business press has done more than I can ever do. Rather, I want to explore some of the deeper implications, not just for Applebee’s and Apple Central LLC, but for our own organizations.
First the obvious. This was a potential public relations disaster. There was a lot of damage to be sure. At the same time, the story was quickly buried by the ongoing news about the Ukrainians’ fight for their very existence as a nation, and juicier national political stories coming out of Washington D.C. Had this been a slow news period, this story is the type that can get legs under it and reverberate for weeks. That didn’t happen in this case.
Once the story hit the mainstream press, we had P.R. responses like:
Kevin Carroll, COO of Applebee’s: “This is the opinion of an individual, not Applebee’s. This issue is being addressed internally by the franchisee who employs this individual and who owns and operates the restaurants in this market. Our team members are the lifeblood of our restaurants, and our franchisees are always looking to reward and incentivize team members, new and current, to remain within the Applebee’s family.”
And from Apple Central LLC, the company where the email originated: “The main message here is that this in absolutely no way, shape, or form speaks to our policies or our culture, or anything like that with our brand.”
And ultimately Mr. Pankratz lost his job. End of story, a rogue employee, a bad apple (pardon the pun) if you will. Maybe.
Looking Deeper
Still, I have some questions – and that is all they are, just questions. I know nothing about the culture of Apple Central LLC, the company that owns the franchises where the email originated.
But the email was written on March 9. This story broke two weeks later, and the response was a few days after that – once reporters started calling the company.
What happened in those two weeks?
There is a hint in the email itself. Or more specifically the forwarding chain. Someone in the store in Springfield (Springfield-8289) responds to the original email: “Great message Sir!” and right away we see that maybe this message isn’t so rogue.
It is then forwarded again by a redacted user with the message: “Words of wisdom from wayne!!!”
It was sent to [redacted] Distribution List – that implies a lot of people saw it. It was sent in the evening of March 9. What happened on March 10th? Those are the actions that would tell us if this was a break from the way business is normally done.
The Questions for Everyone
The more subtle story seems to be about the difference between espoused vs. actual values.
Simply, it is the internally triggered response, not the response to outside inquiries, that reflects the actual values of this company.
Was there any effort at all to repair the employee relationships that were damaged? Is there evidence that anyone objected, retracted, or attempted internal damage control with the employees who saw the message before it blew up in online in the press?
Would this story have even happened if someone from Apple Central LLC immediately got in touch with everyone on the distribution list and even visited the Lawrenceville restaurant in person to make amends?
In the face of this kind of blowback, wouldn’t that be something a company would highlight in press releases? None of the press releases or statements said anything about efforts to repair the damaged relationships with employees. None of them said anything about actions being taken immediately. Simply put, there isn’t any evidence of alarms about breaking with the policies, culture or brand until reporters start asking about it two weeks later.
Nor is there any evidence that the individuals who enthusiastically forwarded the message along were acting outside of the cultural bounds of the company.
Quite the opposite.
What Problem Were They Trying to Solve?
Based on all indications it seems this was managed as apublic relations problem. It was not managed as a culture problem.
All of the messaging says “Our culture is fine.” Just this guy, who happens to have the title Executive Director of Operations, but we are told he doesn’t make hiring policy.
A Question for You
Let’s even take email out of it. If someone made this case in your company’s leadership meeting, what would the response be from around the table?
Would anyone push back? Would anyone say “Wait, we don’t talk about our people that way.” “We don’t look to trap them in the job here.” “No! That isn’t who we are!”
Maybe there would be an awkward silence until someone changed the subject, but nothing else said.
Or would head nod in tacit agreement, good point, next topic?
Or would there be “Great point!” with nods and smiles?
Or… would there be a discussion about actual ways to take advantage of this so-called opportunity?
Your leadership values are not what is printed on the posters in your hallways. Nor are they what your public relations people tell the reporters when there is an adverse story.
Your leadership values are reflected in what you do, what you say, how you respond day-in and day-out.
If you want to know your values, just listen to what people, especially those in authority, say when they “can talk freely.” Listen to things people say that get no pushback or objection. Those are the values that are driving policy and decisions.
Listen to yourselves. Listen to your values. Own them. If the public face is different from everyday discussions ask yourselves why, especially if the word “integrity” shows up anywhere in your values statement.
A few years ago I was working with a company that was ramping up a complex highly-automated production process.
A group of technicians had an idea for an improvement. The nature of what they were trying to improve, or their idea is irrelevant here.
They brought their idea to the plant manager, carefully explained it, and then a bit of awesomeness happened.
Instead of being critical or asking a lot of leading “What about…?” questions, he borrowed and paraphrased a question from David Marquet:
“What things do you think might concern me about this?”
The technicians were stumped. So the plant manager then said “That’s OK, how about getting back to me tomorrow with what you think?”
The next day the technicians had revised their idea to deal with potential problems the plant manager hadn’t even thought of. Which makes sense because they knew a lot more about how things worked than he did.
By asking that question he pushed them to think of the higher level systems implications, to think like the plant manager who has customers and constituents he has to please above and beyond the scope of the shop floor itself.
How do you respond when someone presents an idea? Do you critique it? Do you try to come up with scenarios that break it? Or do you challenge people to go back and think a little more deeply about the what if’s?
Many years ago I wrote an article for SME called The Essence of Jidoka. In that article I described a four step process designed to improve productivity and drive continuous improvement. Since then these four steps have been picked up and incorporated into the training materials of many consultants, used to write the Wikipedia article on jidoka (which I most assuredly did not author), and even found their way into some academic papers. Sometimes with attribution back to my article, may times without.
In that article, “jidoka” was described as a four step process:
Detect a problem.
Stop.
Fix or correct the problem.
Find the root cause and implement a permanent countermeasure.
But I would like to take a hard look at the first step: Detect the problem. This is where, I believe, most organizations actually fall down. And in doing so, they also fall down on respect for people.
The key question is: “What do you consider a problem?”
Most organizations do not see a problem until the symptoms are bad enough that they are compelled to do something about it. This means people have been struggling with issues for some time already. The machine isn’t reliably producing good parts. Or someone is having to rework material. Or the supplies cabinet is always short, and the nurses have to launch a safari to find what they need.
Contrast this with a company like Toyota. Every Toyota-trained leader I have ever dealt with is very consistent. A problem is any deviation from the standard. More importantly, a deviation from the standard (1) forces people to improvise and (2) is an opportunity to learn.
Spear’s research concluded there were four tacit rules for how activities, information connections, flow paths, and improvements were designed and executed in Toyota operations. Each of those rules describes:
Any deviation from the standard triggers some kind of alert that gets someone’s attention. And whose attention is explicitly defined – That is a standard as well.
As I look at a work area, I often see a lot of 5S type of activity. Things and their intended locations are marked and labeled. These are standards. They establish what should be where. But the question to ask is “What happens if something is out of place?”
That is a deviation from the standard. It is a problem.
Stop
Fix or Correct (put it back – restore the standard condition)
Investigate the root cause
“What’s going on with the air wrench today?”
“Actually it is an extra one.”
“Really? Where did it come from?”
“I borrowed it from the Team Member in work zone 3.”
“Ah, OK. Why did you need his?”
“The regular one isn’t working.”
“Hey – thanks for letting me know. I’ll get it to maintenance.”
“Thanks”
“Did you tell anyone about the problem before now?”
“No, I just borrowed the wrench. I just needed to get this job done, then forgot. It’s no big deal, it’s easier to just borrow Scott’s wrench.”
And in that exchange, what have you discovered about your daily management system by simply being curious about a trivial deviation from a 5S standard?
Is this the Team Member’s fault?
Probably not. What is your standard? What is he supposed to do if the wrench stops working? Is there an escalation process and a response for this kind of small stoppage? Or are your Team Members just expected to find a way to work through the issue? Which of those responses is more respectful of the Team Member who spends her time trying to create value for you?
Often times there is no standard.
But without a standard you have no way to tell if there is a problem (other than a feeling that something isn’t right). And if you are sure there is a problem, without a standard you can’t really define what “fixed” is.
So start with defining the standard. First, go back to Decoding the DNA of the Toyota Production System. You can get an idea of the kinds of things you should standardize.
As you think of standards, consider a standard for your standard:
Express it from the viewpoint of the process customer.
Define it in a way that can be verified as “met” or “not met.” No gray zones. You can quantify the magnitude of a problem, but not whether you have one.
There is a visual or other control tells the appropriate person, right away, if there is a deviation from your standard?
Is there a standard that triggers a response to clear the problem?
5S is nothing more than the first step of setting standards. Many people say to start there, but don’t say why. The point is to practice setting standards and holding them. Taiichi Ohno is quoted as saying:
“If there is no standard, there can be no kaizen.”
Any deviation from the standard is a problem.
Your choice, as a leader, is how to handle that problem.
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.
Besides being a great source of schadenfreude, Jürgen Henn’s website, 11foot8.com offers some great insight in the difficulty of effective mistake-proofing.
Background
The clearance between the road and the railroad bridge at 201 Gregson Street in Durham, North Carolina is officially 11 feet 8 inches (3.55 meters).
A typical rental box truck is about 12 feet high (3.65 meters).
The result:
The more astute of you may have noticed the “OVERHEIGHT MUST TURN” sign just above the smashed truck.
Well before the truck approaches the intersection, it passes under a height sensor. If the vehicle is overheight, the OVERHEIGHT MUST TURN sign comes on and starts to flash, and the traffic lights turn red.
While this effort did mitigate the problem, obviously there are drivers who simply do not notice. Lots of them. Jürgen has cameras trained on the intersection and captures over a dozen crashes in a typical year. As a result, his website has attracted international attention. See the short documentary here: http://11foot8.com/about/the-documentary/
Familiar Tasks = “In the Zone”
The human brain is an amazing thing. It also works by deceiving us. It creates the illusion of complete awareness of the things around us when, in reality, we are simply aware of a model our brains have constructed of what we perceive to be there.
It is also an amazing engine at engaging actions based on pattern matching. For example –
In sessions I facilitate, I routinely ask people if they can recall a time when they arrived home after work but realized they didn’t remember driving the route. Nearly every hand in the room goes up. That is pretty amazing because driving is an incredibly complex task. But, assuming you get a license in your mid-teens, by the time you are in your early 20s, most people don’t give it much thought. (There is a reason your insurance rates drop when you turn 25.)
It has become a hard-wired neural pattern, a series of habits, a programmed set of responses that are operating below below the conscious and deliberate thinking part of the brain. This is really good because this process is much faster and more responsive than the alternative. Think about how it felt to be driving when you were just learning – or how it feels to be doing anything new when you are just learning.
The downside to this amazing programming is that things that don’t jar us into consciousness often go unnoticed.
And the more familiar, the more expert, we are with the task at hand, the more likely this will happen.
Levels of Mistake Proofing
I like to talk about three levels of mistake-proofing. Four actually, if you count Zero as a level.
Level 0 – the task must be performed correctly from memory.
Level 1 – there is a discrete task of checking build into the job.
Level 2 – there is an active indication when a mistake is about to be made (or has just been made and there is still time to correct without consequences).
Level 3 – there is active prevention that gets in the way of making the mistake.
The OVERHEIGHT MUST TURN sign is a Level 2. The driver has already passed signs informing him of the bridge clearance about 100m before the bridge.
The height sensors are on the poles just past the speed limit signs.
Low clearance signs about 100m before the bridge. (Google Street View)
Then in the next block, there is another sign telling the driver to turn:
Approaching the last intersection (Google Street View)
And finally the light changes and the OVERHEIGHT MUST TURN sign illuminates.
And still they miss it.
(Direct YouTube link for the email readers: https://youtu.be/I0BJmC6u7MU)
To be clear, the vast majority of truck drivers don’t hit the bridge. But over a dozen a year do. (There were more before the flashing sign was put in.)
“Pay Attention!” = Fundamental Attribution Error
As we watch Jürgen’s videos it is easy to assign character attributes to the drivers who hit the bridge. If only they were better drivers. (The vast majority people who are asked to rate their driving skill will say they are “above average” by the way. Think about that.)
But it is human nature to get lulled into a bit of complacency when engaging a routine task- and driving is a routine task in spite of the complexity.
Now – think about the people in your organization. How many opportunities to they have to make a mistake every day… every hour… in the course of their work? How many of those possible mistakes have serious or expensive consequences?
They are experts at what they do. And they don’t make many mistakes. And they usually catch themselves before there is a problem. But the Law of Large Numbers says “Given enough opportunities, the unlikely is inevitable.”
Can anyone reading this honestly say they have never inadvertently run a stop sign? Yet accidents rarely occur. Now and then there is some panic braking, and rarely there is a collision.
Yet it is really easy to single out the person who:
Performs the work the same way, in the same conditions as everyone else.
Makes the same mistakes, just as often, as everyone else.
Just like everyone else, usually they are caught in time, or other conditions aren’t present for a bad outcome.
But this time everything lined up and BANG – the defective product got missed, or the leak wasn’t noticed before the sump went dry.
Then that person gets singled out for “not following procedure” when nobody follows procedure.
Job Instruction “Key Points” = Opportunity
In a Job Breakdown for TWI Job Instruction we assign a “Key Point” as something the learner must remember specifically because it:
Might result in a hazard – injure the worker or someone else.
“Make or break the job” – if something isn’t done a specific way, the task fails.
Is a “knack” or technique that makes it easier to do.
Those first two are red flags. You are asking your team member to memorize critical to safety and critical to quality tasks. My challenge: How many of those key points can you “mistake proof” out of the job breakdown?
Finally – rather than the sensors and flashing lit signs, there is this approach from “somewhere on the Internet.”
That is awesome because even if the driver doesn’t see the sign, the BANG! may get his attention in time for it to register and stop. In the Durham, NC example above, apparently this wouldn’t work because there are legitimate reasons for trucks to come down the street up to the intersection just before the bridge. After that, it is really too late unless the driver is already aware that he has to turn.
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.
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.
