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.
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?
I can see where the promise of a rapid “lean transformation” is appealing. We shop around, listen to presentations, read proposals, and find someone with a good “solution.”
For the next few weeks, maybe a couple of months, things move in a flurry. Lines are connected, visual inventory controls are established, your team is taught about the lean tools with simulations demonstrating the power of flow. Thus convinced, the team is expected to buy into the changes being made.
At the end, with much hoopla and pizza, we are done, and the new system is running.
The Grass is Greener – For a While
Now let me tell another story. It isn’t my story, I heard it during a presentation by Jim Sorensen in Seattle. I’m sure he tells it much better than I will. Jim talks about his neighbor who has a fantastic, immaculate lawn. Jim recounts that, one day as he was chatting with his neighbor, shared a little envy – “I wish my lawn looked as good as yours.” The neighbor’s response was “Jim, if you had a lawn like mine, in three months it would look like your lawn does now.” His neighbor works on his lawn. The immaculate appearance was important to him. For Jim? He chose to spend his time doing different things, which is fine. But at the same time, he, we, shouldn’t expect an immaculate lawn to stay that way unless we are willing to do the work.
Likewise with these rapid implementations. To continue to metaphor, we rip out your old grass, put down beautiful fresh sod, take the photos, and move on to the next house. But if you don’t fundamentally change the way you maintain that new lawn, by the end of the year, it will look like your old one.
You Are Transforming Your Culture
Continuous improvement as “the way we do things” is a fundamental shift in the way people think, and the way they spend their time. There is no “set it and forget it.” Your processes are either improving or eroding. You must exert continuous active control by the people who are closest to the work just to keep up with the entropy. Their “buy in” is not even close to being enough to make it work. They need different leadership.
Many years ago I was interviewing at a Big Household Name Company that looking to accelerate their “lean deployment.” They already had a guy with incredible qualifications working very hard to teach the things they needed to understand.
Every person that talked to me asked “How can we go faster?” My reply was “Listen to what [your lean director] says and do it. He knows what he is talking about.” Unfortunately, he was telling them that there were no easy shortcuts, and that they had to begin thinking about production in a fundamentally different way. My feeling was they were looking for someone to tell them there was an easier way to do it.
I run into that a lot. An organization wants the results, they want the immaculate lawn, but they want someone else to do the work to make it that way, then they want the outcome.
The problem is you can’t outsource your own thinking.
I think whoever wrote this question is looking for something like 14 hours (840 minutes) / 185 units = 272 seconds / unit (more or less). But that’s an average, it isn’t a cycle time.
The Average Rate of Output is not “Cycle Time.”
The average doesn’t give you any more information than the original question. This is simply a rate of output: 185 units in 14 hours. Cycle time is the measured time to complete one cycle.
There might be a single cycle that produces a batch of 185 units. Let’s say, for example, in a cure oven process that takes 14 hours to load, run and unload. Then the cycle time is 14 hours.
If the pieces are moving in a sequence of operations, but in a lot (which is different from a batch), where Operations 1 is completed on all 185, then Operation 2 is completed on all 185, etc. and maybe that all takes 14 hours? I have no idea what the cycle time(s) for the operations are. Most of the time the units are waiting in queue for the other 184 items to be done at each operation.
If we have true one-by-one flow then I have at least 185 cycle times. Hopefully they are all about the same, but likely that isn’t the case.
Are we measuring exit cycles (the cadence of output at the end of the process), or operator or machine cycle times?
By taking the average we are obscuring all of this information. Calling the average the “cycle time” just makes it worse because it gives people the impression that they are the same.
Cycle time is not calculated. It is measured. You cannot determine cycle time by applying mathematical operations on numbers. You have to go observe with a stopwatch.
within each four hours worked, workers can take a total of 48 minutes in allowance (so allowance factor is based on workday). if the observed time is 6 minutes, and performance rating is 95%, what is the standard time (in minutes; give three significant digits after the decimal point)?
Even if I could understand the question, down to thousandths of a minute? Seriously?
Once again the search terms have revealed an interesting test question. Let’s parse it and see what we can learn.
2. the cycle time to complete a final step on an assembly line is normally distributed, with a mean of 4 minutes and a standard deviation of 1 minute.1) at the end of an 8-hour shift, how many units will have been assembled on average?
The question is about exit cycles – the cadence at the output of a production process of some kind, in this case an assembly line.
Measuring and plotting the variation of exit cycles at the customer end of your production process is a great way to get a handle on how much variation there is.
This question, however, reveals a level of simplistic understanding in the mind of the person who wrote the question of how these things work.
Answering the Question
First, we have to assume that this assembly line (which implies manual work) takes no breaks during their 8 hour shift. We have no information that suggests otherwise.
That means we have 8 hours x 60 minutes = 480 minutes of working time.
Intuitively, if the exit cycles are normally distributed (which implies the distribution is symmetric), with a mean of 4 minutes, then we should be able to simply divide to get the average number of units built during each shift.
480 / 4 = 120 units
Which in the long-haul is close, though it will take a lot of iterations to converge on that. Running about 65 iterations of a random number set with a mean of 4 and standard deviation of 1, I got an average daily production of 120.1, a high of 127 units, and a low of 115.
But Exit Cycle Times Aren’t Normally Distributed
This is a problem with a lot of the “statistics” I see being kicked around today.
This is a histogram of 36 actual exit cycle times from a real production line.
The “Cycle Time” bucket numbers on the horizontal axis represent the top of the range. So the high bar says there were 10 cycle times between 25 and 30 seconds.
The mean of the data set is 42, which is actually one of the less frequent values.
The first thing that jumps out is that this data set might have two peaks (be bimodal). I would want a lot more data before I drew this conclusion, however let’s assume it is for the discussion because this is quite common.
A bimodal distribution implies there are two different processes running. If we looked at a run chart of individual cycles, we would probably see one of two things:
Clusters of longer times spaced between clusters of shorter times. This would be the case if the line is running lots or batches, then switching over.
A repeating cadence like “short-short-short-long, short-short-short-long” which would indicate really good production leveling.
But all of that is a sidebar. The real issue I have with this “homework question” simple: Cycle times are (almost) never normally distributed.
There is a minimum time that can elapse between the completion of one unit and the completion of the next, but there is no theoretical limit on the length of delay. These distributions (almost) always have a tail to the right.
And this is my problem with questions like this on exams and homework, especially in classes that purport to be teaching how factories run. Even when using a distribution, the problems almost always default to a symmetric distribution when real world factory-related data sets are rarely symmetrically distributed.
You are teaching your students a simple solution that won’t work in the real world without explaining why.
Many organizations trying to deploy lean get great results for the first couple of years, then things tend to stall or plateau. This is in spite of continued effort from the “lean team.”
We Still Don’t Have a Lean Culture
This was the comment by the Continuous Improvement director of a pretty large corporation. They had been running improvement events for several years, everyone had pretty much been through one.
Each of the events had made pretty good strides during the week, but the behavior wasn’t changing. Things were eroding behind the events, even though everyone agreed things were better.
It was getting harder and harder to make more progress. They had hit the plateau.
What Causes the Lean Plateau?
While it might not be universal, what I have seen happen is this:
The implementation is led by a small group of dedicated technical experts. They are the ones who are looking for opportunities, organizing the kaizen event teams, leading workshops, and overseeing the implementation of lean techniques.
While this works in the short term, often the last implemented results begin to erode as soon as the lean experts shift their attention elsewhere.
At first, this isn’t noticed because the implementation is proceeding faster than the erosion.
However the more areas that are implemented, the faster the erosion becomes. There is simply more “surface area” of implemented areas.
At some point, the rate of erosion = the rate of implementation, and the lean team’s efforts start to shift from implementing new areas to going back and re-implementing areas that have eroded.
The lean team’s capacity becomes consumed re-implementing, and they spend less and less time going over new ground. They are spending all of their time “spinning the plates” and no time starting new ones.
Key Point: The lean plateau occurs when the level of implementation effort and the rate of erosion reach an equilibrium.
In the worst scenario, sooner or later financial pressures come into play. Management begins to question the expense of maintaining an improvement office if things aren’t getting significantly better on the bottom line. What they don’t see is that the office is keeping things from getting worse, but they aren’t called the “maintain what we have office” for a reason.
Breaking the Lean Plateau
When I was a lean director in a large company, we were confronting this very question. We had a meeting to talk about it, and quickly started blaming “lack of management commitment.”
Leaders Weren’t Stepping Up
In any given area, after education and planning, our last step was always to have a major effort to put flow production into place. Since the performance of the area would be substantially better, we expected the leaders to work hard to continue that performance.
What actually happened in an area was “implemented,” was the line leaders in that area – supervisors, managers, senior managers – weren’t working to look for erosion and correct it.
Instead, when a problem was encountered, they were making some kind of accommodation that compromised flow. The effect of the problem went away, but things had eroded a bit.
What we thought we learned: The weren’t “supporting the changes.”
What we really learned – though it was only realized in hindsight: This is the mechanism of “erosion.”
Flow production is specifically designed to surface small problems quickly. If there is no mechanism to detect those problems, respond, correct, and learn, then the only thing leaders can do is add a little inventory, add a little time, add an extra operation.
As Hirano put it so well decades ago:
All waste is cleverly disguised as useful work.
But Our Current Condition was Incomplete
There were outliers where it was working.
As we talked, we realized that each of us had experience with an outlier – one or two areas that were actually improving pretty steadily. Trying to understand what was different about these bright spots, we looked for what they all had in common. Surprisingly:
They were areas with no dedicated improvement teams.
They ran few, if any, 5-day kaizen events.
They were geographically close to one of us (senior “Directors”).
One of us had decent rapport with the area management team.
We each had an informal routine with them: We would drop by when we had time, and walk the work area with the area leader. We could discuss the challenges they were facing, how things were operating, go together to the operations concerned, and look at what was happening. We could ask questions designed to “sharpen the vision” of the leader. Sometimes they were leading questions. Most of the time they were from genuine curiosity.
By the time we left, there was generally some action or short term goal that the leader had set for himself.
Even though we “lean directors” had never worked together before, our stories were surprisingly consistent.
The Current Condition (Everywhere Else)
aka Dave’s Insight
The next logical question was “If that is what we do, what happens everywhere else? What do the lean staff people do?”
Now we were trying to understand the normal pattern of work, not simply the outcome of “the area erodes because the leaders don’t support the changes.”
Dave confidently stood up and grabbed the marker. He started outlining how he trained and certified his kaizen leaders. He worked through the list of skills he worked to develop:
Proficiently deliver the various topical training modules – Waste vs. Value Add; Standard Work; Jidoka; Kanban and Pull;
“Scan” an area to find improvement opportunities.
Establish the lean tools to be deployed.
Organize the workshop team.
Facilitate the “Vision”
Manage the “Kaizen Newspaper” items
and at some point through this detailed explanation he stopped in mid sentence and said something that brought all of us to reality (Please avert your eyes if you are offended by a language you won’t hear on network TV):
What we realized more or less simultaneously was this:
Management wasn’t engaged because our process wasn’t engaging them.
Instead, our experts were essentially pushing them aside and “fixing” things, then turning the newly “leaned” area over to the supervisors and first line managers who, at most, might have participated in the workshop and helped move things around.
Those critical front line leaders were, at best left with a to-do list of ideas (kaizen newspaper items) that hadn’t been implemented during the 5 days.
There was nothing in the structure to challenge them to meet a serious business objective beyond “Look at how much better everything runs now.” The amount of improvement was an after-the-fact measurement (or estimate) rather than a before-we-begin imperative.
So it really should be no surprise that come Monday morning, when the inevitable forces of entropy showed up, that things started to erode. The whole system couldn’t have been better designed for that outcome.
Why the Difference in Approach?
In retrospect, I don’t know. Each of us senior “lean directors” had been taught, or heavily influenced by, Toyota-experienced Japanese mentors, teachers, consultants.
On the other hand, what we were teaching our own people was modeled more on what western consultants were doing. Perhaps it is because it is easier to use forms and PowerPoint for structure than to teach the skills of the conversations we were having.
Implement by Experts or Coached by Leaders
That really is your choice. The expert implementation seems a lot easier.
Unfortunately the “rapid improvement event” (or whatever you call them) system has a really poor record of sustaining.
Perhaps our little group figured out why.
There are no guarantees. No approach will work every time. But a difficult approach that works some of the time is probably better than an easy path that almost never works.
Sometimes the searches that lead here give us interesting questions.
While simple on the surface, this question takes us in all kinds of interesting directions.
Actually the simplest answer is this: You can’t. Not from takt time alone.
Takt time is an expression of your customer’s requirement, leveled over the time you are producing the product or service. It says nothing about your ability to meet that requirement, nor does it say anything about the people, space or equipment required to do it.
Cycle time comes in many flavors, but ultimately it tells you how much time – people time, equipment time, transportation time – is required for one unit of production.
Takt time and cycle time together can help you determine the required capacity to meet the customer’s demand, however they don’t give you the entire story.
In the simplest scenario, we have a leveled production line with nothing but manual operations (or the machine operations are trivially short compared to the takt time).
If I were to measure the time required for each person on the line to perform their work on one unit of the product or service and add them up, then I have the total work required. This should be close to the time it would take one person to do the job from beginning to end.
Let’s say it takes 360 minutes of work to assemble the product.
If the takt time says I need a unit of output every 36 minutes, then I can do some simple math.
How long do I have to complete the next unit? 36 minutes. (the takt time)
How long does it take to complete one full unit? 360 minutes (the total manual cycle time)
(How long does it take) / (How long do I have) = how many people you need
360 minutes of total cycle time / 36 minutes takt time = 10 people.
But this isn’t your labor cost because that assumes the work can be perfectly balanced, and everything goes perfectly smoothly. Show me a factory like that… anywhere. They don’t exist.
So you need a bit more.
Planned Cycle Time (a.k.a. Operational Takt Time and “Actual Takt”)
How much more? That requires really understanding the sources of variation in your process. The more variation there is, the more extra people (and other stuff) you will need to absorb it.
If we don’t know, we can start (for experimental purposes) by planning to run the line about 15% faster than the takt time. Now we get a new calculation.
85% of the takt time = 0.85 x 36 minutes = ~31 minutes. (I am rounding)
Now we re-calculate the people required with the new number:
360 minutes required / 31 minutes available = 11.6 people which rounds to 12 people.
Those two extra people are the cost of uncontrolled variation. You need them to ensure you actually complete the required number of units every day.
“But that cost is too high.”
Getting to Cost
12 people is the result of math, simple division that any 3rd grader can do. If you don’t like the answer, there are two possible solutions.
Decide that 360 / 30 = something other than 11.6 (12). (or don’t do the math at all and just “decide” how many people are “appropriate” – perhaps based on some kind of load factor. This, in fact, is a pretty common approach. Unfortunately, it doesn’t work very well for some reason.
Work to improve your process and reduce the cycle time or the variation.
Some people suggest slowing down the process, but this doesn’t change your labor cost per unit. It only alters your output. It still requires 360 minutes of work to do one unit of assembly (plus the variation). Actually, unless you slow down by an increment of the cycle time, it will increase your labor cost per unit because you have to round up to get the people you actually need, and/or work overtime to make up the production shortfall that the variation is causing.
So, realistically, we have to look at option #2 above.
This becomes a challenge – a reason to work on improving the process.
Really Getting to Cost
Challenge: We need to get this output with 10 people.
Now we have something we can work with. We can do some more simple math and determine a couple of levers we can pull.
We can reverse the equation and solve for the target cycle time:
10 people x 30 minute planned cycle time-per-unit = 300 minutes total cycle time.
Thus, if we can get the total cycle time down to 300 minutes from 360, then the math suggests we can do this with 10 people:
But maybe we can work on the variation as well. Remember, we added a 15% pad by reducing the customer takt time of 36 minutes to a planned cycle time (or operational takt time, same thing, different words) of 30 minutes. Question: What sources of instability can we reduce so we can use a planned cycle time of 33 minutes rather than 30?
Then (after we reduce the variation) we can slow down the process a bit, and we could get by with a smaller reduction in the total cycle time:
(See how this is different than just slowing it down? If you don’t do anything about the variation first, all you are doing is kicking in overtime or shorting production.)
So which way to go?
We don’t know.
First we need to really study the current process and understand why it takes 360 minutes, and where the variation is coming from. Likely some other alternatives will show themselves when we do that.
Then we can take that information, and establish an initial target condition, and get to work.
You can’t use takt time alone to determine your labor cost. Your labor cost per unit is driven by the total manual cycle time and the process variation.
With that information, you can determine the total labor you need on the line with the takt time.
None of this should be considered an unalterable given. Rather, it should be a starting point for meeting the challenge.
And finally, if you just use this to reduce your total headcount in your operation, you will, at best, only see a fraction of the “savings” show up on your bottom line. You need to take a holistic approach and use these tools to grow your business rather than cut your costs. That is, in reality, the only way they actually reach anywhere near their potential.
Sometimes people fall into a trap of believing they understand a process if they can successfully predict it’s outcome. We see this in meetings. A problem or performance gap will be discussed, and an action item will be assigned to implement a solution.
Tonight those of us in the western USA saw the moon rise in partial eclipse.
We knew this would happen because our understanding of orbital mechanics allows us to predict these events… right?
Well, sort of. Except we have been predicting astronomical events like this for thousands of years, long before Newton, or even Copernicus.
The photo below is of a sophisticated computer that predicted lunar eclipses, solar eclipses, and other astronomical events in 1600BC (and earlier). Click through the photo for an explanation of how Stonehenge works:
Stonehenge represented a powerful descriptive theory. That is, a sufficient level of understanding to describe the phenomena the builders were observing. But they didn’t know why those phenomena occurred.
Let’s go to our understanding of processes.
The ability to predict the level of quality fallout does not indicate understanding of why it occurs. All it tells you is that you have made enough observations that you can conclude the process is stable, and will likely keep operating that way unless something materially changes. That is all statistical process control tells you.
Likewise, the ability to predict how long something takes does not indicate understanding of why. Obviously I could continue on this theme.
A lot of management processes, though, are quite content with the ability to predict. We create workforce plans based on past experience, without ever challenging the baseline. We create financial models and develop “required” levels of inventory based on past experience. And all of these models are useful for their intended purpose: Creating estimates of the future based on the past.
But they are inadequate for improvement or problem solving.
Let’s say your car has traditionally gotten 26 miles-per-gallon of fuel. That’s not bad. (For my non-US readers, that’s about 9 liters / 100 km.) You can use that information to predict how far a tank of fuel will get you, even if you have no idea how the car works.
If your tank holds 15 gallons of fuel, you’ll be looking to fill after driving about 300 miles.
But what if you need to get 30 miles-per-gallon?
Or what if all of a sudden you are only getting 20 miles-per-gallon?
If you are measuring, you will know the gap you need to close. In one case you will need to improve the operation of the vehicle in some way. In the other case, you will need to determine what has changed and restore the operation to the prior conditions.
In both of those cases, if you don’t know how the car operated to deliver 26 miles-per-gallon, it is going to be pretty tough. (It is a lot harder to figure out how something is supposed to work if it is broken before you start troubleshooting it.)
Here’s an even more frustrating scenario: On the last tank of fuel, you measured 30 miles per gallon, but have no idea why things improved! This kind of thing actually happens all of the time. We have a record month or quarter, it is clearly beyond random fluctuation, but we don’t know what happened.
The Message for Management:
If you are managing to KPIs only, and can’t explain the process mechanics behind the measurements you are getting, you are operating in the same neolithic process used by the builders of Stonehenge. No matter how thoroughly they understood what would happen, they did not understand why.
If your shipments are late, if your design process takes too long, if your quality or customer service is marginal, if the product doesn’t meet customer’s expectations, and you can’t explain the mechanisms that are causing these things (or the mechanisms of a process that operates reliably and acceptably) then you aren’t managing, you are simply directing people to make the eclipse happen on a different day.
“Seek first to understand.”
Dig in, go see for yourself. Let yourself be surprised by just how hard it is to get stuff done.
Another interesting homework question has shown up in the search terms. Let’s break it down:
23. if the slowest effective machine cycle time in a cell is 55 seconds and the total work content is 180 seconds, how many operator(s) should operate the cell so that labor utilization is at 100%?
I find this interesting on a couple of levels.
At a social level, the idea of cutting and pasting a homework question into Google hoping to find the answer is… interesting. Where is the thinking?
What are we teaching?
The question is asking “How many people do we need to run as fast as we can?” (as fast as the slowest machine). But how fast do they need to run? Maybe they only need a part every 95 seconds. If that is true, then I need fewer people, but I am going to run the slowest machine even slower.
In other words, “What is the takt time?” What does the customer need? How often must we provide it?
Then there is the “labor utilization” metric, with a target of 100%. Assuming the planned cycle time is actually 55 seconds (which it shouldn’t be!), we need 3.3 people in this work cell. (180 seconds of labor cycle time / 55 seconds planned cycle time: “How long does it take?” / “How long do you have?” = Minimum Required Capacity)
How about improvement? What do we need to do to get from 3.3 people to 3 people? We can solve for the labor cycle time. 55 seconds of planned cycle time * 3(people) = 165 seconds of total labor. So we need to get that 180 seconds down to a little less than 165 seconds.
Now we have a challenge. We need to save a bit over 15 seconds of cycle time. That might seem daunting. But we don’t have enough information (the current condition) to know where to begin. Then we can establish the next target condition and get started making things better.
These types of questions bother me because they imply all of these things are fixed, and they imply we run “as fast as we can” rather than “as fast as we must.”
Edit: Today I saw two more searches for:
total work content divided by slowest machine cycle time
so it looks like at least two others are working on the same assignment. 🙂
An interesting search landed someone on the site recently. Here it is:
a machine is producing 55 parts in one hour. what is the cycle time for each part.
Likely this is someone Googling his homework question, but I’d like to take apart the question and discuss it. If this is a homework question, I would contend that the likely “correct” answer is wrong.
Take a pause and think about it for a second. How would you reflexively answer this question?
Someone encountering this question is likely to simply divide the 55 parts of output into the 60 minutes of elapsed time. Doing that, we get something just over 65 seconds per part.
Which is interesting, but it isn’t the cycle time per part. It is the average rate of production, but it isn’t the cycle time.
I contend you don’t have enough information to answer the question. To really do that, you need to get your safety glasses and hearing protection, go down to the machine with a stopwatch (I’d suggest one with a lap function) and click off the elapsed time interval between each and every part as it come off the machine.
Well… let’s say that the machine is actually running at a cycle of 55 seconds / part when it is actually operating, but there are frequent jam-ups that the operator has to clear.
Isn’t that a completely different story than running smoothly with one part coming off every 65.45 seconds?
My thoughts: I’ve seen this a lot. It is magnified when the leaders are detached from the process.
Process improvement is messy, and if the leaders aren’t comfortable with that messy process, they develop unrealistic expectations of what “progress” looks like.
The people getting the work done, meanwhile, end up working hard to manage those expectations. They actually conceal problems from the boss, for fear of him misinterpreting problems-that-must-be-solved with my-people-don’t-know-what-to-do.*
Trying to layer Toyota Kata over the wrong organizational structure will overwhelm people.
The organizational structure follows necessity. This lines up with Steven Spear’s research.
The organizational structure must match the needs of the process, and the target condition for learning.
If your supervisor has 20 direct reports, it is unlikely he will have the time to work on improvement in a productive way. Toyota’s team leader structure is specifically engineered for improvement, development, and getting a car off the line every 58 seconds.
Improvement takes time and people.
This isn’t free, nor can you calculate an ROI ahead of time. Get over it.
Start with what you MUST accomplish and look at what is required to get there. It doesn’t work the other way around.
If you don’t continually strive, you die.
If you aren’t striving to go forward, you are going backward.
My thoughts: I make the following analogy: Continuous improvement is like a freezer. There is never a time when you can say “OK, it’s cold enough, I can unplug it now.” You must keep striving to improve. Without the continuous addition of intellectual energy, entropy takes over, and you won’t like the equilibrium point.
All of our failures have come to good things.
My thoughts: By deliberately reflecting and deliberately asking “What did we learn?” you can extract value from any experience. The way I put it is “You have already paid the tuition. You might as well get the education.”
We had sponsorship challenges as the leaders caught up with the people.
My thoughts: Yet another instance of the leaders falling behind the capability of their people. When the people become clear about what must be done, and just start doing it, the only thing an uninformed leader can do is either get out of the way or destructively interfere.
People don’t like uncertainty. Kata deliberately creates uncertainty to drive learning. You have to be OK with that.
My thoughts: Another expression of the same point from yesterday.
“Learning only” has a short shelf life.
“Cool and Interesting” is not equal to Relevant.
Those are the words I wrote down, rather than the words I heard. The key point is that you can, for a very short time, select processes to improve based on the learning opportunities alone. But this is extra work for people. The sooner you can make the results important the quicker people get on board.
A business crisis should not stop improvement or coaching. Does it?
My thoughts: This is a good acid test of how well you have embedded. When a crisis comes up, do people use PDCA to solve the problem, or do they drop “this improvement stuff” because they “don’t have time for it.” ?
A lot of companies try to do this in the interest of going faster. Don’t outrun your headlights. You can only go as fast as you can. Get help from someone experienced.
Just because you have gone a long way doesn’t mean you can’t slip back. You must continue to strive.
The “unplug the freezer” analogy applies here as well.
You don’t have to start doing this. But if you choose to start, you may not stop. You have to do it every day.
Don’t take this on as a casual commitment, and don’t think you can delegate getting your people “fixed.” (they aren’t broken)
Everybody gets it at the same level. Senior managers tend to lose it faster because there is no commitment to practice it every day at their level.
Awareness is a starting point, but not good enough. A 4 hour orientation, however, is not enough to make you an expert… any more than you can skim “Calculus and Analytic Geometry” and learn the subject.
Results do get attention.
“I’ll have what she’s having”
But don’t confuse results with method.
My challenges to the plant managers weren’t about P&L or service levels. They were about moving closer to 1:1 flow, immediate delivery, on demand.
Challenges must be in operational terms, not financial terms.
Move from “These are the measures, and oh by the way, here is the operational pattern” – to –> “This is the operational pattern I am striving for. and I predict it will deliver the performance we need.”
Gotta catch a plane. More later.
*When I was in the Army, we got a new Battalion Commander who listened to the logistics radio net, where the staff officers discussed all of the issues and problems that had to be solved. He would jump to a conclusion, and issue orders that, if carried out, would interfere with getting those problems solved.
Although he spoke of initiative and taking action, his actions revealed he wasn’t willing to trust us to let him know if there was a problem we couldn’t handle, and expected perfection in execution in situations that were chaotic and ambiguous.
We ended up finding an unused frequency, and encrypting our traffic with a key that only we shared, so the commander couldn’t hear us. Yup… we were using crypto gear, designed to keep the Soviets from hearing us, to keep our boss from hearing us.
As the information channels to him slowly choked off, he was less and less informed about what was actually happening, and his orders became more and more counter-productive, which in turn drove people to hide even more from him.
This, I think, is a working example of “getting bucked off the horse.”