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.)
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?”
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. ↩︎
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. ↩︎
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?
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.
I was going through some old files and came across a pocket card we handed out back in 2003 or so. It was used in conjunction with our “how to walk the gemba” coaching sessions that we did with the lean staff, and then taught them to do with leaders.
A lot has happened, a lot has been learned since then. Toyota Kata has been published, and that alone has focused my technique considerably (to say the least).
Nevertheless, I think the elements on these little cards are valuable things to keep in mind.
With that being said, a caveat: Lists like this run the risk of becoming dogma. They aren’t. There are lots of lists like this out there, and the vast majority are very good. The key here is something that a leader or team member can refer to as a reminder that may bias a decision in the right direction. It is the direction that matters, not the reminders.
Fundamentals
The fundamentals are based on the “Rules-in-Use” from Decoding the DNA of the Toyota Production System, a landmark HBR article by Steve Spear and H. Kent Bowen. The article, in turn, summarizes (and slightly updates) Spear’s findings from his PhD work studying Toyota.
A. All work highly specified as to content, sequence, timing, and outcome.
B. Every customer-supplier connection is simple and direct.
C. The path for every product is simple and direct.
D. All improvements are made using PDCA process.
What we left off, though, is that in each of those rules there is a second one: That all of these systems are set up to be “self diagnostic” – meaning there are clear indications that immediately alert the front line people if:
The work deviates from what was specified.
The connection between a customer and supplying process is anything other than specified.
The path a product follows deviates from the route specified.
Improvements are made outside of a rigorous PDCA (experimental) process.
In other words, the purpose of the rules is to be able to see when we break them, or cannot follow them, so we trigger action.
To put this into Toyota Kata-speak – every process is set up as a target condition that is being run as an experiment – even the process of improvement itself!
Every time there is a disruption – something that keeps the process from running the way it is supposed to – we have discovered an obstacle. That obstacle must first be contained to protect the team members and community (safety) and to protect the customer (quality). Then goes into the obstacle parking lot, and addressed in turn.
If you think about it, the Improvement Kata simply gives us much more rigor to (D).
This ties to the next sections.
Key Leadership Behaviors
Note that this is behaviors. These are things we want leaders to actually strive to do themselves, not just “support.” It was the job of the continuous improvement people to nudge, coach, assist the leaders to move in these directions. It was our job to teach our continuous improvement people how to do that coaching and assisting – beyond just running kaizen events that implement tools.
A. PDCA Thinking
Today we would use Toyota Kata to teach this. But the same structure drove our questioning back then.
B. Four Rules:
1. Safety First
Even though this should be obvious, it is much more common that people are tacitly, or even directly, asked to overlook safety issues for the sake of production. I remember walking through a facility with a group of managers on the way to the area we were going to see. Paul stopped dead in his tracks in front of a puddle on the floor. He was demonstrating just how easy it was for the leadership to walk right past things that should be attended to. And in doing so, they were sending the message – loud and clear in their silence – that having a puddle on the floor was OK.
2. Make a Rule, Keep a Rule
This is a more general instance of Rule #1. But the it is more subtle than it may seem on the surface. Most people immediately interpret this as enforcing organizational discipline, but in reality it is about managerial discipline.
Nearly every organization has a gap between “the rules” and how things really are day-to-day. Sometimes that gap is small. Sometimes it is huge.
Often “rules” are enforced arbitrarily, such as only cases where a violation led to a bigger problem of some kind. Here’s an example: Say your plant has a set of rules about how fork trucks are to be operated – speed limits, staying out of marked pedestrian lanes, etc. But in general the operators hurry, cut a corner now and then. And these violations are typically overlooked… until there is some kind of incident. Then the operator gets written up for “breaking the rules” that everyone breaks every day – and management tacitly encourages people to break every day by focusing on results rather than process.
When we say “make a rule / keep a rule” what we mean is if you aren’t willing to insist on a rule being followed consistently, then take the rule off the books. And if you are uncomfortable taking the rule off the books, then your only option is to develop something that you can stand behind. It might be simple mistake proofing, like physical barriers between forklift aisles and pedestrian aisles. But if you are going to make the rule, then find a way to keep the rule.
Do you have “standard work” documents that are rarely followed? Stop pretending you have standards or rules about how the work is done. Throw them away if you aren’t willing to train to them, mistake proof to them and reinforce following them.
3. Simple is Best
Simply, bias heavily toward the simplest solution that works. The fewest, simplest procedures. The simplest process flow. Complexity hides problems. “Telling people” by the way, is usually less simple than a physical change to the work environment that guides behavior. See above.
4. Small Steps
Again, Toyota Kata’s teaching covers this pretty well today. The key is that by taking small steps, verifying that they work, and anchoring them into practice before taking the next ensures that each step we take has a stable foundation under it.
The alternative would be to make many changes at once in the name of going faster.
We emphasized here that “small steps” does not equal “slow steps.” It is possible to take small steps quickly, and we found that in general doing so was faster than making big leaps. Getting big changes dialed in often required backing out and implementing one thing at a time anyway – just to troubleshoot! See “Gall’s Law” which states:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
John Gall, author of Systematics
and sums this up nicely.
C. Ask “Why, what, where, when, who, and how” in that order.
Here we borrowed the sequence from TWI Job Methods. The first two questions challenge whether a process step is even necessary: Why is it necessary? What is its purpose? To paraphrase Elon Musk, the greatest waste of time is improving something that shouldn’t even exist.
Then: Where is the best place? and When is the best time? These questions might nudge thinking about combining steps and further simplifying the process.
And finally we can ask Who is the best person? and “How” is the best method? The key point here is until we have the minimum possible steps in the simplest possible sequence, and understand the cycle times, it doesn’t make sense balance the work cycle or work on improving things.
Come to think about it – perhaps we should ask “How?” before we ask “Who” since improving the method will change the cycle times and may well inform out decisions about the work balance. Hmmm… I’ll have to think about that. Any thoughts from the TWI gurus?
D. Ask Why 5 Times
Honestly, this was a legacy of the times. Unfortunately it suggests that you can arrive at a root cause simply by repeatedly asking “Why?” and writing down the excuses answers that are generated. In reality problem solving involves multiple possible causes at each level, and each must be investigated. I talked about this in a post way back in 2008: Not Just Asking Why – Five Investigations.
E. Go and see.
Go and see for yourself. Taking this into today’s practice, I think it is something that the Toyota Kata community might emphasize a little more. We tend to ask the question “When can we go and see what we have learned…?” but all too often the answer to “What have you learned?” is a discussion at the board rather than actually going and observing. Hopefully the board is close to where the improvement work is being done. Key point for coaches: If the learner can’t show you and explain until you understand, it is likely the learner’s understanding could be deeper.
As You Walk The Workplace:
Check:
perhaps we should have said “Ask…” rather than “Check” but asking and observing are ways to “check.” All of the below are things that the leader walking the workplace must verify by testing the knowledge of the people doing the work.
A. How should the work be done? Content, Sequence, Timing, Outcome
This is another nod to the research of Steven Spear. The key point here is that before you can ask any of the following questions, you have to have a crisp and precise of what “good” looks like. In this paradigm, all processes are target conditions. And as the work is being done, we are actively searching for obstacles so we can work to make the work smoother and more consistent.
In other words, “What should be happening?” and “How do you know?”
Do the people doing the work understand the standard process as it should be done?
A few months ago I went into some depth on this here: Troubleshooting by Defining Standards. That probably isn’t the best title in retrospect, but there are too many links out there that I don’t want to break by changing it.
B. How do you know it is being done correctly?
Today I ask this question differently. I ask some version of “What is actually happening?” followed by “How can you tell?” We want to know if the people doing the work have a way to compare what they are actually doing against the standard.
C. How do you know the outcome is free of defects?
So, question B asks about consistency of the process, and question C asks about the outcome. Does the team member have a way to positively verify that the outcome is defect-free?
D. What do you do if you have a problem?
Again, we are checking if there is a defined process for escalating a problem. And we define “problem” as any deviation from the standard, or any ambiguity in what should be (or is) happening. We want someone to know, and act, on this, and the only way that is going to happen is to escalate the problem.
We want this process to be as rigorous and structured as the value-adding work.
And we want as much care put into designing production process as was put into designing the product itself. All too often great care and a lot of engineering time goes into product design, and only a casual pass is made at designing and testing the process.
Even better if these are done simultaneously where one informs the other.
For Abnormal Conditions:
ACT:
These are actions that the leader must take if she finds something that isn’t “as it should be” in the course of the CHECK questions above. Key Point: These are leadership actions. That doesn’t mean that the leaders personally carry them out, but the leaders are personally responsible for ensuring that these things are done – and checking again.
That is the only way I know of to prevent the process from continuing to erode.
A. Immediately follow up to restore the standard.
If it isn’t possible to get the intended standard into back place, then get a temporary countermeasure into place that ensures safety and quality.
B. Determine the cause of erosion.
We are talking about process erosion here, with the assumption that something knocked the process off its designed standard. Some obstacle has been discovered, we have to better understand what it is – at least enough to get it documented.
C. Develop and apply countermeasure.
Here we may have to run experiments against this newly discovered obstacle and figure out how to make the process more robust.
That is the end of the little card. But I want to point out that we didn’t just hand these out. You got one of these cards after time paired with a coach on the shop floor practicing answering and asking these questions. Only after you demonstrated the skill did you get the card – just as a reminder, not as a detailed reference. This exercise was inspired by a few of us who had experiences “in the chalk circle” especially with Japanese senseis who had been direct reports to Taiichi Ohno.
We piloted and developed this process on a very patient and willing senior executive – but that is another story for another day. (Thank you once again, Charlie. I learned more from you than you will probably ever realize.)
The factory is running complex automated equipment. At the morning meeting today we heard “machine x was down for broken bolts.” Actually “again.”
Background – the bolts in question resist pressure in molding equipment. The details of how the equipment works aren’t relevant here. This isn’t the first time I have heard of “broken bolts” being the source of downtime.
After the meeting, I saw the production manager on the shop floor. “So, tell me about the broken bolts.” We know each other, he is happy to.
We went to the machine in question. “How do bolts break?” (These days I ask “how?” rather than “why?” because I am interested in the mechanism of failure rather than whatever mistake is being made.
I am asking that question for a simple reason: Grade 8 bolts don’t “just break” in equipment that is properly engineered and assembled as designed. Something, somewhere, is stressing things beyond their limits.
Normalized Deviance
By accepting that “bolts break” and “shafts get stripped” and “hoses fail” we move into the realm of “normalized deviance” where we accept as OK something that actually is a sign of a serious problem.
This is no different than accepting that “o-rings burn through sometimes but it hasn’t caused a problem so it must be OK.”
How do Bolts Break?
A few possibilities came up.
The bolts might be just a bit too long allowing movement.
The might be loose.
“Why is a ‘too long’ bolt even needed in the plant?” – that is still an open question.
“What is the torque spec?”
“… I don’t know.”
Now we are getting somewhere.
Once we hit the threshold of knowledge, we know the next step.
I’ll call the title of this post “Dave’s Observation.”
He is reflecting his experience in varied industries that if a company grows beyond its ability to deliver quality product, on time, then order volume will drop until it reaches a point that performance returns.
The business literature is full of examples of this – companies who could not keep up with their own success, their performance deteriorates and, well, many of them go out of business.
I have seen more than a few companies with aggressive growth plans that outrun their ability to actually execute, and they get into trouble.
This also happens in mergers and acquisitions where one company is merged into another with the assumption that the combined company can execute and perform in ways neither company has ever done. Starry-eyed executives often look only at the financial models, maybe equipment capacity, and skip over the operational aspects of their due diligence.
In the end, though, if the operational capability is not there, then none of the plans actually matter. Your “synergy” or “economy of scale” will evaporate like an ice cube on the Moon until equilibrium is restored.
Bottom line: If you are engaged in an ambitious growth plan, then list everything that has to be different for your model to work.
By “different” I mean you are asking for or expecting some task execution or level of performance that does not exist today as a matter of mundane routine.
Then ask “What is our plan to close this gap?” – and run the same exercise on executing that plan. “Change” is really hard, and just telling people what needs to be different, no matter how pretty the PowerPoint slides are, no matter how slick the presentation is, won’t make anything change. (If anything, it often breeds cynicism because it is read as unrealistic.)
Change requires step-by-step, methodical, practice to anchor each small change into the system, then the next, then the next.
Toyota Kata offers a good pattern for this. Just don’t confuse the underlying pattern with the methods used to teach it.
The spring and summer of 2000 were a long time ago, but I learned some lessons during those months that have stayed with me. In fact, the learning from that experience is still happening as I continue to connect it to things I see today.
I was a member of a team working hard to stand up a new production line of a new product. The rate pressures were very high, the production, production control, and quality processes were immature.
At a high level, the parts flow was supposed to work like this:
Steel parts are fabricated and welded, based on the production schedule for various configurations.
Unit sets of parts were sent to outside paint. (We didn’t have our own paint system yet.) In reality, unit sets would be broken up as some parts went to sister plants, others went to outside vendors, each with their own lead times and flow times.
Parts return from outside paint. Because of the different vendors and lead times, different parts arrive on different days.
On assembly day, kits are built for the parts required at each entry point on the assembly line. Those kits are delivered based on a pull. The assembly line had a number of entry points and feeders, so for each takt time cycle, though only one “unit’s worth” of parts were actually delivered, those parts were for different units, as feeders had different lead times into the main line.
The innocuous challenge was to develop the kitting process (in red) that broke down the parts into kits and got them delivered to the line.
I got pulled in on Thursday of a “kaizen event” that was supposed to develop this process. What had actually happened, though, was analysis paralysis, a lot of theoretical discussions, a lot of drawings on a white board, but nothing had actually been tested or tried. My assignment was simple: Organize this and get it going on Monday.
I had four people working for me, though they were not officially direct reports. They were an eclectic mix of personalities and styles.
A few things became apparent very quickly:
The process of scheduling which parts needed to be fabricated and welded to be sent through painting on any particular day was broken. Result: What was needed wasn’t necessarily what got sent to paint.
The processes of keeping parts organized during the various outside paint operations was broken. Result: Unit sets got mixed together, parts went missing.
As a result this is what my days looked like:
I came in before a hint of dawn at 4:45am to prepare for the assembly line starting at 5:40. I would go out into the parts yard with the day’s production schedule and a flashlight. My goal was to answer a simple question:
What units on this list can I build with the parts that are here?
I would re-sequence the production schedule to front-load the units that looked like we had everything we needed. (This caused all kinds of problems with serial number sequences and engineering change control, but that is a different story.)
We would start pulling in those parts, and breaking them down into the kits. We set up FIFO lanes for each entry point on the assembly line, and worked as fast as we could to build up about a three hour backlog. Why? Because it took about three hours to expedite a missing part through paint. Once we had that queue built up, as we discovered shortages (or parts painted the wrong color!), we had a chance to get the situation corrected and have a shot at not creating a shortage on the line.
We were working 10 hour shifts, I was typically there for 12-14 hours. Even though I was a “lean guy” my daily work was orchestrating all of this chaos, expediting and delivering parts, and I spent at least six of those hours every day driving a forklift. I got really good at forktruck operation that summer.
At the end of the day, I might sit and chill for a little while, then would get in my truck, go home, and do it all again tomorrow. One of those days as I went to back out of the parking space, I hit the turn signal to put my stick-shift truck into reverse – because that’s how the forklift controls worked.
What I Learned
I actually continue to learn. But here are a few things that have stood out for me.
Shop Floor Production Supervisor is a really hard job. I wasn’t a supervisor, but I was doing many of the things that we asked supervisors to do. Making my people take their breaks. Slow down on the pallet jack. Listening to a frustrated guy who was ready to quit – understanding his paradigm, and helping him re-frame his experience. Constant radio calls to places in whatever building I wasn’t in at the time. Operating within a system that functions only with continuous intervention.
I totally knew how to set up a workable, stable process. I knew how to get all of these processes linked together to pull everything through. I knew how to build in effective quality checks.
What I was able to do was spend a few minutes at the end of my day, or during my lunch breaks (instead of eating) trying to implement some kind of simple visual control that mitigated against repeating a mistake we had just made. We attached a tag with a production sequence number (000 through 999, repeating) to each kit. That let us, and the people on the line, see if we had delivered something out of sequence.
Then, after I had delivered a yellow painted kit to go onto an otherwise blue painted unit (oops) we made a board with the production sequence numbers and the associated colors for the major components.
Then… after I had delivered (note the theme here) the wrong size of a major component to the line, we added that information to the board AND tagged those components so we could quickly distinguish one from the other.
But I was never able to address the upstream issues that were delivering short kits to us in the first place. All I could do was add steps, add time, add inventory to protect myself from those things and do my best to fix it before the main line got stopped.
We had a saying in the Army: “When you are up to your a$$ in alligators, it is hard to work on finding the best way to drain the swamp.”
Thus:
It is unreasonable to expect systems improvements when everyone is scrambling to make the system function at all. It isn’t that they don’t want to make improvements. It isn’t that they don’t know what to do. It is that there is barely time to breathe before the next problem needs to be stamped down.
And finally: A five person job requires five people. I had four people working for me. That wasn’t enough. Guess who had to fill in the rest of it? I tried my best to handle the problems so they could get into some kind of cadence on the stuff that wasn’t a problem. But (Routine+Problems) = (or greater than) 5 people in this case, and it took all of us just to navigate the rapids without dumping everyone out of the boat. If everything was running smoothly, it was probably a three person job. If we could have set up a sequenced pull from assembly all the way back through weld, it would have been a two or even one person job.
Reflection
That forklift key is still on the keyring in my pocket as a reminder of that time. What follows are some of the bigger-picture things that come to mind as I continue to construct, tear down and reconstruct my own thinking.
Attribution Error
There is a strong tendency among us humans to attribute our own failures to a poor environment, but to attribute other’s failings to individual character or capability. Yet in many cases, simply changing the venue or circumstances can allow a previously low-performer to blossom. We see this (and the opposite) all of the time in professional athletics.
Making this error is easy when we are talking about “they.” If only they… Why don’t they… They don’t get it… “They” are people who are likely doing the very best they can within the context of the system they are in. And, as I pointed out above, changing the system from the inside is hard.
Actually that isn’t quite accurate. Changing the system is hard work.
The Pace of Change
The organization I was describing above was experiencing circumstances at the time that outpaced their ability to experiment, reflect, and adapt. Every organization has a rate at which they are able to change.
Just to make things more complicated, it is possible to learn what must be done much faster than those things can be put into place. This frustrates a lot of change agents. They see the technical changes that must take place, but often struggle against cultural barriers and obstacles. These things take much longer, and it is pretty much impossible to put them on a fixed timeline or project plan. Thus, we frame them as “resistance to change.” We know what must be done, but “they” don’t do it.
Organizations Under Stress
When an organization is under stress, there is fear of complete breakdown. People become very conservative and avoid the uncertain and unfamiliar. If they become overwhelmed just trying to get their task done, they are going to shut out any information that isn’t relevant right now. Horizontal communications break down, and the feeling of isolation increases.
At this point, all coordination has to funnel upward and then downward through the vertical linkages, as cross-functional coordination largely isn’t happening.
Now the higher leader gets overwhelmed, feeling she has to micro-manage every detail- because she does. “Why don’t they talk to each other?” Well, the structures for that were probably very informal, and now have broken down.
This Isn’t About “Them”
As I mentioned above, it is really easy to attribute the perception of dysfunction to individuals. And as people become isolated within their own task-worlds, avoiding a mistake becomes the dominate motivation. This happens even in organizations with the most benign intentions.
If you are a leader, pay attention to the emotions. If people are snippy, are pushing back on ideas as “just more work” then that saturation point may well have been reached. Pushing harder isn’t going to make things go faster, it is going to slow them down.
In my last post, If the Student Hasn’t Learned…, I made the point (again) that sometimes trying too hard to impose a formal structure on a learner can impede their progress.
Since writing that, I have been doing a bit of reflection on my own development as a coach, and I need to give credit where it is due.
As any regular reader knows, I have been an enthusiastic student and practitioner of Mike Rother’s Toyota Kata since I first read the book. I have written extensively about it in this forum. And I have made my own modest contributions to the practice. It has been over this time, and countless cycles of guiding beginning (and intermediate, and expert) learners through The Five Questions that I can hold the structure in my own head while not imposing rigidity onto others.
I will always default to using the formal structure because I think, in the vast majority of cases, it sets a better foundation. And even in those cases where I have to let go of the structure, that is a temporary countermeasure.
Once my learner is comfortable with the meta-patterns, then the structure follows, and makes sense to them. Some people learn that way, and I have to be able to pick that up.
I may have been an OK coach before all of this, I likely overestimated my ability at the time. Today, though, thanks to the Toyota Kata structure, I am becoming more comfortable with… not letting go if it, for I hold it in my own mind, but maybe withholding the framework and letting the learner fill it in more fluidly.
As we are boring down on the 10th Anniversary of Toyota Kata, and the 5th KataCon, we have a great opportunity to look at how the pattern that Toyota Kata teaches reaches far beyond process improvement and problem solving.
I will be speaking on the topic of Developing Leaders for Continuous Improvement on Day 1, and yes, we can use the same meta-patterns. Craig Stritar and I will be taking a much deeper look into the same principles in our Experiential Workshop. If you want to get a hands-on, reflective look at meeting your challenges as a change agent, come join us there.
In reality, the teacher learns by sharing and swapping experiences with others. I am not going to try to list everyone you will, and should, meet at KataCon here because I would surely leave someone’s name off my list by accident. But look at the presenters and speakers. I know most of them and were I not presenting my own workshops and breakouts, I would be hard pressed to decide which ones to attend. You can’t make a mistake here.
One of the things Menlo does (and I am sure they are not the only ones in their business who do) is create user personas – a biographical profile of a fictional person who represents a category of potential user for the software they are developing.
In Joy, Inc, Rich Sheridan describes the often contentious process of then forcing the customer to pick a single persona as the primary user – the persona whose needs will drive all decisions about optimization. That person goes in the center of their three rings.
They allow two personas in the 2nd ring, and three in the 3rd ring.
As they make design decisions about their code and user interface, they always defer to the innermost rings. That doesn’t mean that someone in a ring further out won’t have their needs met, but they will meet those needs in ways that don’t compromise the process for personas closer to the center.
Persona Mapping for KataCon
In the spirit of being a temporary Menlonian, I worked paired with Craig (over the phone, and in a shared Google Doc) and we developed a persona map for KataCon. Of course, had we done this correctly we would have gone back in time to the previous KataCon, gotten the profiles from the attendees lists, interviewed people, and put together profiles for “typical” people who attend.
Since we couldn’t do that, we pushed past our threshold of knowledge and combined experience with a bit of speculation. I did confirm some of our assumptions via a phone call to Dwayne at Lean Frontiers who graciously answered my questions as he was driving across Indiana.
This process forced us to actually think about who was in the audience, and why they were there – what they were seeking from their participation in the conference. As Rich and I talked about his message, and later on as Craig and I worked on our “Experiential Workshop” we used the names of these “people” rather than generic terms like “participant” or “audience.” I found that really focused our conversations.
Who Do You Optimize Your Process For?
This really begs the general question: Who is your process optimized for?
Is it optimized for the person doing the work?
For the customer’s specific experience? And if so, who is the “customer persona” you are optimizing THAT for? For example, for an ideal retail experience, a mom with two kids in tow would be a different customer than a single guy. You likely get both, but if you have do something that slightly compromises one in order to optimize the other… who is in the center ring?
I have been telling everyone who will listen to read Rich Sheridan’s book Joy, Inc. ever since I came across and read it in the fall of 2015.
Fast forward to earlier this year when Lean Frontiers sent out their request for suggested keynote speakers for KataCon. I wrote to Mike Rother and asked him “Do you think we could get Rich Sheridan?”
Skip ahead a bit more, and I spent four days last week at Menlo Innovations in Ann Arbor – two days “in the chalk circle” paying close attention to the actual day-to-day work there, and two days working (pairing) with Rich Sheridan to work out the key beats for his KataCon keynote.
The “So What?” Test
Menlo is well known as a benchmark for a great working culture. But the question you may be asking (and, honestly I hope you ARE asking it) is “What does Menlo Innovations and agile software development have to do with Toyota Kata?”
If you visit Menlo (and I really hope you do!) here is what you won’t see:
Learner storyboards.
“5 Questions” coaching cycles.
Obstacle parking lots.
Experiment Records (PDCA Records)
In other words, you won’t see the explicit artifacts that characterize an organization using Toyota Kata to learn how to think about improvement scientifically. In that sense, Menlo isn’t a “Toyota Kata” benchmark.
OK… and?
You don’t see those things at Toyota either. You don’t go to Toyota to see “Toyota Kata.”
The Underlying Thinking Pattern
What you will see (and hear… if you pay attention) at Menlo Innovations is an underlying pattern of scientific thinking and safe problem solving in everything they do.
Let’s review what Toyota Kata is really all about.
Rather than re-writing something elegant here, I am going to quote from my part of an email exchange between Mike Rother, Rich Sheridan and me:
Going back to Mike’s original research premise, we knew that Toyota has this pretty awesome culture thing, but didn’t really understand the “secret sauce” of the exact structure of their interactions. Put another way, we saw and understood all of the artifacts, but copying the artifacts doesn’t copy the culture.
Mike’s research was really the first that dug deeper into the interactions that the artifacts support.
Once he extracted that “secret sauce” he then boiled off all of the other stuff, and what remained at the bottom of the pot was the Improvement Kata steps and the Coaching Kata steps.
In practice at Toyota, those things are deeply embedded in the artifacts. Sometimes they aren’t even spoken.
My informal hypothesis was that if I spent time paying attention to, not just the artifacts, but the way those artifacts guided interactions at Menlo, and then boiled off the other stuff, what would remain at the bottom of the Menlo pot would also be the Improvement Kata and Coaching Kata steps. And, though I didn’t do this formally, and yes, I had confirmation bias working here, I believe I can safely say “I have no evidence to contradict this hypothesis.”
For example:
In our conversation on Friday, Mike pushed back a bit on “just run the experiment,” [context clarification: Experiments to randomly try stuff, without a clear target condition rarely get you anywhere] but the reality I observed and heard was that “purpose” (challenge and direction) and “current condition” are deeply embedded in the day-to-day interactions, and “just run the experiment” is, indeed, working on a specific obstacle in the way of a target condition of some kind.
[…]
“What problem are you trying to solve?” is Menlo jargon that I overheard many times just listening to people talk.
Within Menlo, that term is contextual. Sometimes it is about the higher-level direction and challenge.
Sometimes it is about an intermediate target condition.
Sometimes it is about an immediate problem or obstacle.
As we say in Kata world, it is fractal. It is truly fractal at Menlo as well, to the point where the words don’t change at various levels.
The words DO change at various levels in Toyota Kata’s jargon, but we can’t get hung up on the terms, we have to look at the structure of problem solving.
Menlo’s co-founders already had this thinking pattern, and deliberately sought to embed it into the culture of the company they were starting. There wasn’t really any need to explicitly teach it because they weren’t trying to change the default behavior of an organization. New Menlonians learn the culture through the interviewing and on-boarding process and adopt very quickly because the very structure of the work environment drives the culture there.
In fact, spend any time there even just hanging out, and it is very difficult NOT to get pulled into The Menlo Way. Like everyone else, Rich and I were in the daily stand-up as pair-partners, reporting our work progress on his keynote.
What About Toyota Kata?
Menlo has had hundreds (thousands, actually) of visitors, and those who are “lean savvy” all ask if Menlo is “using lean” as their guideline. The answer is “no, we are just trying to solve problems.” While they have certainly incorporated most of the artifacts of “agile software production,” the purists push back that they aren’t “really doing it” because they didn’t copy those artifacts exactly. Nope. They used them as a baseline to solve Menlo’s problems.
When we see an awesome problem-solving culture, it is tempting to try to reverse engineer it by copying the physical mechanics, such as heijunka boxes (work authorization boards), kanban, “standard work” and the like.
But we have to dig down and look at the routines, the behavior that those artifacts and rituals support. When we do, we see the same patterns that Toyota Kata is intended to teach.
You need to begin with the thinking pattern. Use Toyota Kata to learn that.
As you do, take a look at your artifacts – the procedures, the policies, the control mechanics of your work. Reinforce the ones that are working to create the kind of culture you want. Challenge the ones that are getting in your way. Do both of those things as deliberate experiments toward a clear vision of the culture you want to create.
That is the benefit of studying companies like Menlo.
I hope to see you all at KataCon, hear what Rich has to say to our community, and establish a link between these two communities that have, up to now, been separate.
I am cleaning out some old notepads. One page has the notes I took during a 4pm production status meeting during my first “get to know you” visit to this company.
In a box on my notes page it says:
“More information is not going to help until you begin to define how you expect things to run.”
What I had observed is their focus on the previous 24 hours metrics, with lots of speculation about “what happened” to account for the lost production. They were focused on incidents and, honestly, assigning those incidents as causes. Where they came up short, they were seeking more information about lost production incidents.
But everything I have written is just to give you a little context for the scribbled box on my notes a few years ago.
Today? They fixed it. This was one of the most dramatic culture shifts – from “find who to blame” to “let’s solve the problem” I have ever witnessed.
Reflection:
What are your daily meetings like? Are they focused on the stuff that went wrong yesterday? Or are they focused on where you are trying to go in the near future?
