In the past couple of decades, we went through an “empower your people” fad. We saw work teams in world class companies that were largely self directing, surprisingly well aligned with the overall goals of the organization, and getting things done.
“Well,” we thought, “since empowered teams are obviously more effective, we’ll empower our teams.”
They brandished their wand uttered some wizard’s chant, and bing! empowered their teams.
“What did you expect to happen?”
“We expected our newly empowered teams to self-organize, get the work done, plan all of their own vacations and breaks, and continuously improve their operations on their own.”
“What actually happened?”
“Work ground to a halt, people argued and squabbled, quality went to hell, and labor hours went up 20%”
“What did you learn?”
“That empowerment doesn’t work.”
Which is obviously not true, because there are plenty of examples where it does. Perhaps “Empowerment doesn’t work the way we went about it” might be a better answer. That at least opens the door to a bit more curiosity.
The last place I would expect an experiment in true empowerment would be onboard a U.S. Navy nuclear submarine.
Take a look at this video that Mike Rother sent around a couple of days ago, then come back.
A U.S. Navy submarine skipper isn’t generally inclined to swear off ever giving another order. It runs against everything he has been taught and trained to do since he was a Midshipman.
I’d like to cue in on a couple of things here and dissect what happened.
First is the general conditions. I think he could do this just a bit faster than normal because everyone involved was sealed inside a steel can for six months. Just a thought – groups in those conditions tend to have a lot of team cohesion.
But the mechanics are also critical. He didn’t just say “You are empowered.” Rather, this was a process of deliberate learning and practice.
What is key, and what most companies miss, are the crucial elements that Capt. Marquet points out must be built as the pillars of an empowered team.
Let’s put this in Lean Thinker’s terms.
As the Toyota Kata wave begins to sweep over everyone, there is a rush to transition managers into coaches.
“What obstacles do you think are now in the way of reaching the target?”
See the illustration above.
Competence and clarity.
I am going to start with the second one.
Clarity
Or… where the hell are we trying to go?
Capt. Marquet points out the critical element of commander’s intent. I learned this during my decade or so as a military officer (U.S. Army). When preparing operations orders, I had to clarify the overall commander’s intent. Why? So that when everything went to hell in a handcart, everyone knew what we were trying to get done even if the how to do itentirely broke down.
What that means in the lean thinking world is “What is the business imperative” or “What is the challenge we are trying to achieve?” If nobody knows “why,” then all they can know is “what” and that comes down to “implement the tools,” which, in turn, comes down to “because I said so” or “Because we need a 3 on the lean audit.”
Doesn’t work. Never has.
But I’m beating that topic to death right now, so I want to move the pillar on the left.
Competence
In my book, that means “The leader has a good idea how to do it.”
What does that mean in practical terms? In Capt. Marquet’s world, it means that, fundamentally, the crew knows how to operate a nuclear submarine. Additionally, it means they understand the ramifications of the actions they are taking on the overall system, and therefore, the contribution they are making to achieving the intent.
It doesn’t matter how clearly anyone understands what they are trying to get done if they have no idea how to do it.
In Lean Thinking world, competence means a few things.
The leader knows how to “do the math.” She understands the overall flow, the impact of her decisions on the system and the overall system.
The leader / coach has a good understanding of at least the fundamentals of flow production, and why we are striving to move in that direction.
While these things can be taught through skillful coaching, that implies that the coach has enough competence to do that teaching.
But if the coach doesn’t fundamentally grasp the True North, or doesn’t consistently bias every single conversation and decision in that direction, then Clarity is lost, and Competence is never built.
We end up with pokes and tweaks on the current condition, but no real breakthrough progress.
Day to day, this means you are on the shop floor interacting with supervisors and front line managers. You are asking the questions, and guiding their thinking until they grok that one-by-one flow @ takt is where they are striving to go.
In my Lean Director role in a previous company, I recall three distinct stages I went through with people calling me for “what to do” advice.
First, I gave them answers and explanations.
Then I transitioned to first asking them what they thought I would give as an answer.
Then they transitioned to “This is the situation, this is the target, this is what we propose, this is why we think it will work, what do you think?”
“Captain, I propose we submerge the boat.”
“What do you think I am thinking?”
“Um… you would want to know if it is safe?”
“How would you know it is safe?”
In other words…
What are you trying to achieve here? How will you know?
So here is a challenge.
If you are a line leader, especially a plant manager, take one week and utterly refuse to issue direction to anyone. Ask questions. Force them to learn the answers. Test their knowledge. Have them teach you so they must learn.
You will learn a lot about the competence of your team. You will learn a lot about your own clarity of intent. Try it on. No matter what, you will learn a lot.
The tenor of what “lean” is about is shifting, at least in some places, toward the line leader as improver, teacher and coach. Successfully adopting that role requires a qualification that I wish I saw more of as I work with industrial clients – curiosity.
To succeed in this role, a supervisor must be intently curious about, not only the minute-by-minute performance, but what things are affecting it, or could affect it.
Even if he is just walking by, his eyes must be checking – is there excess inventory piling up? Are all of the standard WIP spots filled? Is anyone struggling with the job? Are the carts in the right places? Pressures and temperatures OK? Kanbans circulating correctly? Workers all wearing PPE? Safety glasses? Ear plugs? Does the fork truck driver have his seatbelt fastened?
Though there should also be deliberate checks as part of his standard work, a leader needs to be intently curious about what is happening all of the time.
To improve things requires even more curiosity. “What obstacles do you think are now keeping you from reaching the target?” is not a question that should be answered casually. Rather, the preparation to answer it properly requires careful study – being curious – about what operational conditions must be changed to reach the target.
Sadly, though, my experience is that true curiosity is a pretty rare commodity. A plant manager that can spout off a barrage of facts and figures about how things have to be, but is surprised every time the math doesn’t reflect his view of reality doesn’t impress me much.
Niwa-sensai said once (probably many times) “A visual control that doesn’t trigger action is just a decoration.”
You have to be curious about what those visual controls are telling you. What good is a gage if it is supposed to read between 4 and 6, but drops to 0 and nobody notices?
That supervisor walking through the area needs to be visually sweeping those gages, looking for leaks, anything unusual or abnormal, and taking action.
“How did that stain get here?” Run the trap line. The process, as designed, shouldn’t let anything leak. Why did it? What is really happening?
All we practitioners can do is patiently, again and again, walk the line with them, ask what they see, stand in the chalk circle with them, and do our best to teach them to see what we do.
Show them the system, show them the future consequences of letting this little thing slide – how second shift is going to be brought to their knees because the work isn’t being processed according to the FIFO rules.
I suspect, though, that at least a few leaders get promoted and somehow believe they reach a level where they are exempt from checking and teaching. That’s someone else’s job.
But if not them, who? And how do they know it is getting done?
Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?
OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)
Can you predict what will happen, more likely sooner than later?
It doesn’t matter how “stable” your car is.
There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)
I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.
But your process is going to encounter random chatter, and when it does, what typically happens?
In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.
They will clean up the spilled coolant, catch the leaking oil.
They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.
In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.
“Waste is often disguised as useful work.”
All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.
How do we stop the cycle?
The point of intervention is in the last paragraph… “All of this goes unnoticed.”
It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.
Here are some fundamental questions to ask yourself:
Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.
If the team member doesn’t have everything needed exactly what do you want him to do?
Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?
If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?
How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?
Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!
An Active Control System
Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”
I alluded a little to this above, but let’s go a bit deeper.
On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.
But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.
The hard part is what is supposed to happen next?
Now we are back to the original questions because the andon is nothing more than a trigger for another process.
Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?
What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?
When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.
How much intervention can the first responder make before being required to escalate the problem to the next level?
As a minimum
As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.
This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.
Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”
Reuters reports the death of Eiji Toyoda today, 3 days after his 100th birthday.
In the late 1940’s, the fledgling Toyota Motor Company was in financial difficulties, and was forced to lay off workers. As part of the agreement, Kiichiro Toyoda resigned in 1950 and turned the helm of the company over to his cousin, Eiji.
Kiichiro had developed the early concepts of Just In Time production, and his father, Sakichi, had developed the early concepts of stopping a process that was having quality issues (jidoka).
Eiji had to deal with a turnaround situation, and challenged the company to reach U.S. levels of productivity on a very short timeframe. As part of that effort, he assigned Taiichi Ohno, a machine shop manager, to make it all work. The result was what we today call “The Toyota Way.”
Though there were obviously many people involved, Eiji has a huge share of the credit for creating “The Machine that Changed the World.”
When operations or steps get omitted, a common countermeasure is to establish a checklist.
A typical checklist has a list of items or questions – sometimes even written in the past tense.
“Was the _______?”
There are a couple of common problems with this approach.
First, the time to actually, physically make the checks is not included in the planned cycle time. This implies we are expecting the team member to review the checklist and remember what she did.
The second issue is that the team member often does remember doing it even if it wasn’t done.
This is human nature, it isn’t a fault or flaw in the individual. It is impossible to maintain continuous conscious vigilance for any length of time. There are techniques that help, however they require some discipline from leaders.
Overall, a checklist that asks “Did you___?” in the past tense is mostly ineffective in practice.
We make things worse when the checklist is used as a punitive tool and we “write up” the team member for signing off on something that, actually, didn’t get done. Most of the time it does get done, but everyone in this system occasionally misses something. Sometimes those errors get caught. This kind of “accountability” is arbitrary at best.
Where checklists work is in “what to do next” mode – referring to the check list, doing one item, checking off that it was done, then referring to the next item on the list. This is how it works in an airplane cockpit.*
CAPTAIN: okay, taxi check.
FIRST OFFICER: departure briefing, FMS.
CAPTAIN: reviewed runway four.
FIRST OFFICER: flaps verify. two planned, two indicated.
CAPTAIN: two planned, two indicated.
FIRST OFFICER: um. takeoff data verify… one forty, one forty five, one forty nine, TOGA.
CAPTAIN: one forty, one forty five, one forty nine, TOGA.
FIRST OFFICER: the uh weight verify, one fifty two point two.
CAPTAIN: one fifty two point two.
FIRST OFFICER: flight controls verify checked.
CAPTAIN: check.
FIRST OFFICER: stab and trim verify, thirty one point one percent…and zero.
CAPTAIN: thirty one point one percent, zero.
FIRST OFFICER: the uh…. engine anti-ice.
CAPTAIN: is off.
FIRST OFFICER: ECAM verify takeoff, no blue, status checked.
CAPTAIN: takeoff, no blue, status checked.
FIRST OFFICER ON PA: ladies and gentlemen at this time we’re number one for takeoff, flight attendants please be seated.
FIRST OFFICER: takeoff min fuel quantity verify. nineteen thousand pounds required we got twenty one point eight on board.
CAPTAIN: nineteen thousand pounds required, twenty one eight on board.
FIRST OFFICER: flight attendants notified, engine mode is normal, the taxi checklist is complete sir.
(This is also how it works when assembling a nuclear warhead, but I can’t tell you that.)
This is also very effective for troubleshooting. For example, I was working with a team in a food processing plant. The obstacle being addressed was the long (and variable) time required to change over a high-speed labeling machine and get it “dialed in” and running at full speed without stops and jams.
Some operators were much better at this than others. We worked to capture an effective process of returning the machine’s settings to a known starting point, then systematically adjusting it for the specific bottle, label, etc. It worked when they were able to slow down enough to use it. That was an instance of “Slow is smooth; smooth is fast.”
The act of reading out load, performing the action, and verbally confirming is very effective when it is actually done that way. Even so, people who are very familiar with the procedure will often take shortcuts. They don’t “need” the checklist… until they do.
Still, you have a sequence of operations, and it is critical that they are all performed, in a specific order, in a specific way.
What works?
I’d say look around.
If you are reading this, you likely have been at least dabbling, and hopefully trying to apply “lean” stuff for a while.
What is a basic shadow board? It is a “checklist” of the tools to confirm they are all there – and a lot faster because missing items can be spotted at a glance. At a more advanced level, companies move away from shadow boards and to having the visual controls outlining what should be where to perform the work.
If you kit parts, you can set them out in a sequence – a “checklist” that cues the team member what order they should be installed.
I could continue to cite examples, but here’s the point.
When things are being left out, there is a high temptation to say “Let’s make a checklist” and sometimes make it worse by saying “…and we’ll have the worker sign it off for accountability.” That is more often than not simply a “feel good” solution. You feel like you have done something, and I’ve even heard “Well, it’s better than nothing.” I’m not sure it IS better than nothing – at least not in very specific conditions.
Instead, you need to study the actual work. Don’t try to ask questions, just stand and watch for a while. (Explain what you are doing to the team member first, otherwise this is creepy. “Hi – I’m just trying to understand some of the things that might get in your way. Do you mind if I just watch for a while without bothering you?”)
What cues the team member which step to perform next? Does he have to know it from memory? Or is there something built into the way the workplace is organized?
Does he end up going back and doing things he forgot?
Does he set out parts and tools in order on his own so he doesn’t forget?
Does he get interrupted, by anyone or anything, that takes him out of his mental zone?
(I go through airport TSA security checkpoints at least twice a week. I have a routine. When the TSA agent tries to “help” by talking to me, my routine gets broken, and that is when I forget stuff.)
If you are coaching someone, it helps if you go there with them, help the see the details by spotting these things and “asking” about them; then taking them to another area and challenging them to see as many of these issues as they can. See who can spot more of them.
What you are seeing are obstacles that impact the team member’s ability to do quality work.
Checklists don’t help remove those obstacles.
___________________
*The checklist transcript here is a cleaned up version of the Cockpit Voice Recorder transcript from Cactus 1549, the US Airways A320 that successfully landed in the Hudson River after multiple bird strikes knocked out both engines. I used it here because it is authentic, and the accident was one where everything went right and no one was seriously injured.
Recently, a team was trying to understand a seeming anomalous message (or lack of one, actually) in their complex computer transaction system. (Complex Computer Transaction System is abbreviated “E.R.P.”)
They discussed possible causes, settled in the likely culprit, constructed an experiment to try to replicate the issue and… everything worked perfectly. Meaning that the cause they were testing wasn’t the cause at all.
They worked to reconstruct the timeline from initial data entry to the point where the message should have been issued, and did a better job looking at what along the way could have suppressed the message.
After a series of trials, they found the culprit. It had originated in a data entry omission in a sister plant. They were able to turn the problem on and off at will with that one field.
They had actually discussed this possibility in their original discussion. But they had talked past it, and ended up focusing elsewhere.
There was a great learning here.
If you are discussing possible causes to a problem, write them down. All of them.
Get methodical. Be certain what evidence you either have in hand, or need to get, to eliminate a potential suspect from the list.
It feels slower, but it works better than faster approaches that don’t work.
The idea that “you always start with 5S”, for better or worse, has been deeply ingrained in the “lean culture” since the late 1980’s. A lot of companies start their improvement efforts by launching a big 5S campaign.
Often, however, these 5S efforts are focused on striving for an audit score rather than focusing on a tangible operational objective.
It is, though, very possible to help bridge the gap by putting the process improvement in 5S terms. By using a language the team already understands, and building an analogy, I have taken a few teams through a level of insight.
For example –
We are trying to develop a consistent and stable work process.
Sort
Rather than introduce something totally new, we looked at the process steps and identified those that were truly necessary to advance the work – the necessary. The team then worked to avoid doing as many of the unnecessary steps as possible. In their version of 5S, this mapped well to “Sort.”
Now we know the necessary content of the work that must be done.
Set in Order
Once they knew what steps they needed to perform, it was then a matter of working out the best sequence to perform them. “Set in order.”
Now we’ve got a standard work sequence.
Sweep or Shine
The next S is typically translated as something like “Sweep” or “Shine” and interpreted as having a process to continuously check, and restore the intended 5S condition.
Here is where a lot of pure 5S efforts stall, and become “shop cleanup” times at the end of the shift, for example. And it is where supervisors become frustrated that team members “don’t clean up after themselves or “won’t work to the standard.”
In the case of process, this means having enough visual controls in place to guide the work content and sequence, and ideally you can tell if the actual work matches the intended work. A deviation from the intended process is the same as something being “out of place.” Then, analogous to cleaning up the mess, you restore the intended pattern of work.
One powerful indicator is how long the task takes. Knowing the planned cycle time, and pacing the job somehow tells you very quickly if the work isn’t proceeding according to plan. This is one of the reasons a moving assembly line is so effective at spotting problems.
Now we have work content, sequence and maybe timing, or at the very least a way to check if the work is progressing as intended. Plan, Do and Check.
I believe it is difficult or impossible to get past this point unless your cleanup or correction activities become diagnostic.
Standardize
The 4th S is typically “Standardize”
Interesting that it comes fourth. After all, haven’t we already defined a standard?
Kind of. But a “standard” in our world is different. It isn’t a static definition that you audit to. Rather, it is what you are striving to achieve.
Now, rather than simply correcting the situation, you are getting to the root cause of WHY the mess, or the process deviation happened.
In pure 5S terms, you start asking “How did this unintended stuff show up here?”
The most extreme example I can recall was during a visit to an aerospace machine shop in Korea many, many years ago. The floors were spotless. As we were walking with the plant manager, he suddenly took several strides ahead of us, bent down, and picked up….. a chip.
One tiny chip of aluminum.
He started looking around to try to see if he could tell how it got there.
They didn’t do daily cleanup, because every time a chip landed on the floor, they sought to understand what about their chip containment had failed.
Think about that 15 or 20 minutes a day, adding up to over an hour per week, per employee, doing routine cleanup.
If you see a departure from the intended work sequence, you want to understand why it happened. What compelled the team member to do something else?
Likely there was something about what had to be done that was not completely understood. Or, in the case of many companies, the supervisor, for his own reasons, directed some other work content or sequence.
That is actually OK when the circumstances demand it, but the moment the specified process is overridden, the person who did the override now OWNS getting the normal pattern restored. What doesn’t work is making an ad-hoc decision, and not acknowledging that this was an exception.
Once you are actively seeking to understand the reasons behind departure from your specification, and actively dealing with the causes of those departures, then, and only then, are you standardizing. Until that point, you are making lists of what you would like people to do.
This is the “Act” in Plan-Do-Check-Act.
Self Discipline or Sustaining
One thing I find interesting is that early stuff out of Toyota talks about four S. They didn’t explicitly call out discipline or sustaining. If you think about it, there isn’t any need if you are actively seeking to understand, and addressing, causes in the previous step.
The discipline, then, isn’t about the worker’s discipline. It is about management and leadership discipline to stick with their own standards, and use them as a baseline for their own self-development and learning more about how things really work where the work is done.
That is when the big mirror drops out of the ceiling to let them know who is responsible for how the shop actually runs.
A key theme in the early part of Spear’s presentation was about a company that realized a need to be able to cope with ever accelerating changes. My notes captured this as:
We no longer do high volume manufacturing..
We do high volume engineering.
The design process is on a ramp-up.
In other words, in the context of this product development cycle, they needed to shift their thinking. They are mass-producing designs, not products. They need to be able to not only get the designs out, but get those designs into production and to the market with faster and faster transitions from one product to the next.
This meant that they were never in a steady state. Rather, the normal state was transition.
Everything in our world is accelerating. Our organizations must become very quick at adopting to new products, new technology, and process changes as a matter of routine.
We are living in a world where it isn’t so much what we know that gives us an edge, but how fast we can figure out the meaning of what is new.
This idea of faster and faster transients is not new to me, and I wanted to share some thoughts and background from a previous line of work that is technically out of the realm of “lean.”
Transient back in time: Korea: MiG Alley – 1952
Flying a MiG-15 in the Korean War was a very dangerous business indeed. The front line U.S. fighter was the F-86, and they were shooting down MiG-15s in a 10:1 ratio.
“North Korean” MiG-15s during the Korean War
But that statistic beguiled analysis. By nearly all objective measures, the MiG-15 has a decisive advantage in a dogfight. It was lighter and more nimble. It could fly faster, out climb, out gun, and out-turn an F-86.
Fighter pilots being what they are, the original assessment was better piloting skills. And, overall, that was likely true. U.S. pilots, at least the more senior ones, were combat veterans from WWII. But many MiG pilots were combat veterans as well – especially the Russian ones.
No, while piloting skill could account for some of the difference, the mystery remained.
John R. Boyd
John Boyd (1927-1997) was a fighter pilot with no aerial victories. Yet he is acknowledged as one of the greatest fighter pilots in history. His contributions to the theory of aerial warfare are the anchor for training every fighter pilot in the world today. His theories are used to evaluate every fighter aircraft design.
As he was developing his breakthrough Energy-Maneuverability Theory, the MiG-15 / F-86 victory ratio did not fit his equations. In other words, he was faced with observation that did not fit his theory.
What was the advantage held by the F-86 that made it so formidable?
Though the MiG is physically smaller, the two aircraft are actually very similar looking. But there are some crucial differences in the design.
US F-86 fighters over Korea during the Korean War
The F-86 has a large bubble canopy. Pilot visibility is unobstructed, superb. The MiG-15’s canopy is more conventional. It has frames, is smaller, and does not extend as low as its F-86 counterpart. This translates to the F-86 pilot being able to see more, see better. He is less likely to miss a spec that is behind a canopy frame. He can see better beneath him, and to his rear. Thus, he can begin to set up his next move just a little sooner than his opponent in a MiG-15.
The F-86 has hydraulically boosted controls. The F-86 pilot does not have to use his muscle power against the aerodynamic forces on the control surfaces. He can effortlessly move the stick, and the elevators and ailerons respond.
The MiG-15, on the other hand, requires muscle power. It is physically harder to move the controls, and the pilot must continuously fight, and overcome, the air pressures on the control surfaces.
Thus, the F-86 pilot can transition from one maneuver to another with less effort.
An aerial dogfight is not a steady state affair. The dynamics are continuously changing as each combatant tries to gain an advantage.
With these seeming small advantages, the F-86 pilot could gain situational awareness a touch more quickly, and change his maneuver a touch more quickly than his North Korean counterpart.
Even if the MiG could turn inside the F-86, this is a steady-state advantage. It only holds while both planes are in a constant turn. The F-86 pilot, though, could change directions more quickly and easily than his opponent.
As the maneuvers progressed, the MiG pilot would be lagging further and further behind the developing situation. Eventually he would be countering the last maneuver of the F-86, while the F-86 is already doing something else.
In other words, the F-86 pilot could gain the initiative by executing fast transients – changes in the tactical situation that forced his opponent to respond; or he could respond more quickly than his opponent could change things up.
Gun camera photos of a MiG-15 pilot ejecting
The gun camera films showed that often the MiG pilots would either use their superior speed to break off the engagement (which leaves the F-86s in local control); or if the situation was hopeless, sometimes would bail out before the F-86 even fired his guns. He was defeated psychologically before physically.
From this analysis, Boyd developed a model of situational awareness, analysis and response that is known today as the OODA loop.
Observe – the process of physically sensing the outside world.
Orient – interpreting what was observed, and forming a picture of the situation. This process engages in some hypothesis testing as well – checking what is actually happening against what should be happening if the conclusion is correct.
Decide – Based on the situational awareness, decide the next action to take to gain advantage.
Act – Carry out the action.
Act carries with it a prediction. “If I carry out this action, this is what I anticipate will happen next.”
Act is the only thing which physically affects the outside world.
As the action is carried out, Observation is made to determine the actual impact, maintain situational awareness, and adjust accordingly.
Orient is an interpretation process. It carries all of the biases and assumptions that are inherent in human nature. There is a heavy bias toward seeing what is believed vs. seeing what is. This is the weakest point in the process, and the point where deception exploits the opponent by presenting something they expect or want to see.
After developing this theory for aerial combat, Boyd went on to develop it into a general theory. He was a student of military strategy, some have likened him to a modern Sun Tzu.
Boyd studied other cases in history where one side or the other had a clear advantage, and asked “What do these things have in common?”
He took the specific instance of aerial combat in the Korean War, searched seemingly unrelated experiences, and teased out a common pattern: The ability to execute fast transients – to change up the situation more quickly than the opponent can get a handle on what is happening; and to respond to changes quickly and routinely – gives a decisive edge. Modern maneuver warfare is built around Boyd’s theories.
According to Boyd, defeat was more about the opponent becoming so confused and disoriented that they became totally demoralized and lost command cohesion. They were no longer functioning as a team.
A poorly led army has a very rigid and centralized command structure. There is a detailed plan, every unit has specific instructions they are to carry out. Though this approach is appealing, it only works until first contact is made.
In this high-control environment, any unit needing to deviate from the plan must report the situation upwards, and wait for a decision and instructions. This takes time. In this time, an opposing unit who can execute more quickly can quickly gain an advantage. Our (U.S.) military calls this “getting inside the enemy’s decision cycle.” It means changing things up faster than they can react.
In the mid 1970’s, Boyd developed a two day briefing titled “A Discourse on Winning and Losing” and presented it to packed rooms at the Pentagon.
Later on, Boyd became interested in the Toyota Production System as he saw this system as increasing the ability of a company to quickly respond to challenges – execute fast transients – through its central direction / local execution model.
Normandy, June 5, 1944
On the night of June 5/6 1944, thousands of paratroopers were dropped on the Normandy peninsula. The U.S. 82nd and 101st Airborne Divisions were scattered all over the countryside. Very few troopers ended up on their intended drop zones.
But each trooper knew the overall mission, and they got together with whoever they could find, and banded together into whatever units they could assemble. The ranking man took charge, and they set out to get things done. They didn’t (and couldn’t) call in and get permission to carry out the new mission. They knew what was supposed to be done, and found a way to do it.
This was not the first time this had happened. The experience in Sicily in 1943 was similar. In both cases, what is known today as “The Rule of LGOPs (Little Groups of Paratroopers)” comes into play:
After the demise of the best Airborne plan, a most terrifying effect occurs on the battlefield. This effect is known as the rule of the LGOPs. This is, in its purest form, small groups of pissed-off 19 year old American paratroopers. They are well-trained, armed to the teeth and lack serious adult supervision. They collectively remember the Commander’s intent as “March to the sound of the guns and kill anyone who is not dressed like you…” or something like that.
Even when things do not go horribly wrong, a key element of modern command and control is centralized direction and decentralized execution. This means that the higher level commander sets the direction, the objective for the operation. They establish boundaries, priorities, overall intent, and ensure that everyone knows what needs to get done.
As a sub-unit encounters an opportunity or a problem, they respond and report. But the reporting in this case is not to seek permission to do something, but rather, to report what initiative is being taken. The purpose is so the higher level headquarters can coordinate support from other units to deal with the developing situation. In this way, there is no need to tightly coordinate each individual unit, only to ensure that the right resources are being applied in the right place to exploit opportunities and deal with threats.
What makes this work is every sub-unit knows the situation, the mission, and the overall intent of the plan. Thus, even if the exact details don’t work, they can quickly devise, and execute, actions that further the overall goal. This allows them to maintain overall direction while quickly exploiting opportunities and dealing with emergent threats.
Birds
A large flock of birds in flight looks like a fine chorography of fluid motion. But, of course, there is no bird-in-charge coordinating everyone and saying “Turn left… now.”
In 1986, Craig Reynolds studied how this complex behavior emerged from groups of individual “agents” that, individually, show none of the complex characteristics of the flocking behavior. He developed a computer simulation called “Boids” that implemented three simple rules for each “boid” in the network.
Those rules defined how each “boid” responded to the other “boids” in its immediate neighborhood. Based on these simple rules, the complex, fluid, rapid response to changing external conditions emerges.
We see similar patterns throughout nature. Ant foraging behavior is based on simple rules for following pheromone trails. Indeed, there is nothing inherent in a neuron that suggests the complexity of the human brain.
A flock of birds, though, exhibits very complex, fluid behavior. They can collectively respond very quickly to changes of direction, threats and opportunities. In other words, the flock, as a whole, can transition quickly from one state to another.
What Does It All Mean?
Back in 1970, Alvin Toffler published a best selling book Future Shock. He (and his uncredited wife, Heidi) set out a premise that, as the pace of technology development accelerated, we would be faced with making ever quicker transitions from one base of understanding to another. In other words:
“The illiterate of the future will not be the person who cannot read. It will be the person who does not know how to learn.
Putting all of this into context, our success will become increasingly dependent on our ability to see emerging opportunities, necessities, problems, threats; assess them; understand what must be done; solve the underlying problems; implement, then do it all again… at ever accelerating rates.
The competitive advantage will come to the organizations that can organize around fast transitions from one structure to another, all within the context of a well aligned direction.
What I see is that our developing understanding of “lean” as a process for developing and coordinating fast cycles of learning is exactly what we are all needing to become.
But the classic model of “lean” is too static. It relies on a hand full of professional implementers working hard to install pre-defined systems that strive to copy the mechanics from the mid 1980’s. While these installations may pride themselves on speed, they routinely do not leave behind an organization that is capable of nimble adaption and transition in the face of emerging issues.
Regular readers (or those who choose to wade through the past posts) know I write a lot about “lean” being more about a culture shift than the mechanics.
That culture is one where ad-hoc groups can quickly come together under a common alignment and direction; work to a robust, simple set of pre-existing rules for local interaction; and fluidly adapt to changing situations.
Those teams might be putting together a production line that is only in existence for a few weeks or months before quickly transitioning to another. There won’t be time to wring out the bugs, it will have to come up operational and undergo rapid improvement throughout its existence- passing what was learned to the next iteration.
The innovations will come from the user community. Proprietary ideas may be too slow. Rather, those who can quickly exploit public ideas, then grab the next one once the fast-followers catch up will be the organizations that stay ahead.
It is going to be about fast transients.
What we have to get very good at executing is learning and discovery.
How Do We Learn to Learn?
Saying “you have to do something” is the way of too many consultants and authors. The real question is “How do you do it?”
As I continue to strive to teach the principles in Toyota Kata in diverse organizations, I am building a model of how the organization actually functions.
If there is a common structure and framework that aligns how people think and interact with one another about problems, I see an analogy to the structural rules that govern swarms, like flocks of birds. (Kanban follows the same pattern, by the way, but that is a different topic.)
Not having to take the time to develop problem solving skills and norms would allow teams to come together and quickly get to work. Having good alignment on the direction and challenge up front would prevent a lot of rototilling that many teams go through when they try to tackle a problem they haven’t defined first.
“What are we trying to achieve, and how will we know? followed by “Where are we now? and “How do we know?” are questions that are rarely asked in many organizations. And when they are asked, my experience is the questions are regarded as a waste of time, because “everybody knows” or “it’s obvious” – except that they don’t and it isn’t.
But to answer the question in the header – “How do we learn to learn?” the answer is the same as for “How do I get to Carnegie Hall?” Practice.
Practice means you likely won’t be very good at it at first, and the results may be slow in coming. You will have to work on simpler systems at first, because they are easier to improve. It will feel like you aren’t tackling “real problems” – but in reality, you will see issues that have been adding friction to your systems for years.
Practice means you don’t try to play like Mozart before you can play notes without thinking about where your fingers are going.
The good news is that if you decide to actually take on the struggle and do the work, you will develop a basic proficiency pretty quickly. On the other hand, if you are fighting the utter necessity to learn, then you will never progress beyond going through the mechanics.
InThe Leader’s Journey, I highlighted the struggle with escalating challenges as a core driver of growth in both our fictional heroes and real-life developing leaders.
This week I was essentially doing 2nd level coaching with a client I have been working with for quite a while. One of the things we did was have a brief session where we reviewed and reflected the ideal state of a coaching / problem solving culture (thanks in large part to Gerd Aulinger and Mike Rother). We reviewed the principles of what a coach and the coaching chain is striving to achieve, and the mechanics of doing it.
Combining that review with the shop-floor 2nd level coaching, a couple of my participants commented on how much better they “got” what they were trying to do. They started to move from rote to the higher-level understanding.
I am still digesting why this week had this kind of breakthrough when we have been working on the same key things for months. Nothing we went over was new information. What was different this time around?
My thought right now is that they have been in the struggle trying to understand this stuff, and finally reached the point where the additional theory snapped things into place. I told them “if you hadn’t been struggling with this, you wouldn’t have had the insights you got this week.”
I really think that is the case. We can give people all of the answers. But I am realizing if they haven’t, first, been struggling to find those answers on their own – if they haven’t been trying hard to figure it out – then the additional information would have far less (or little) impact. It is only after they have challenged themselves that the externally supplied insights have any meaning or context.
At least that is where I am right now. Time for a couple of additional experiments.
I want to tack a similar issue onto yesterday’s post about normal operating mode vs. recovery mode.
Listening to a team trying to understand a complex issue, I noticed three different threads intertwining in their conversation.
They would discuss the actions needed to work through the issue and get the product to the customer. This is appropriate and necessary, but not in a meeting to discuss cause and countermeasure of the issue itself. This topic is habitual because it is the mode the group normally operates in. They are working to change that, but until they do, they’ll have to do what is necessary to meet the requirement… just not in this meeting.
They would discuss the actions required to understand the next level of the cause – the investigation itself.
They would discuss possible preventive countermeasures.
We’ve already said #1 should be taken off line. As you listen to the conversation in your problem-solving meetings, watch for this one because it can be very distracting as it is often confused with finding the cause.
#3 – discussing possible preventive countermeasures – often takes place before the root cause is understood. Though it is certainly appropriate to discuss (and experiment with) preventive countermeasures once the root cause it known, it is simply an exercise in idle speculation to do so before that.
In fact, doing so can be dangerous. You could put in a “countermeasure,” followed by an intermittent problem “going away” or the symptoms disappearing for a random reason, and end up with a powerful superstitious belief that you HAVE to operate that particular screen with the mouse in your left hand, or it won’t work.
The best course of action is to follow a methodical series of experiments to rule out possible causes.
This is harder than it looks. This week a team had an epiphany when they discovered that an unlikely cause they had talked themselves out of early on turned out to be the actual issue. The lesson they learned was don’t eliminate a possible cause without hard evidence. The more certain you are, the more you need to get that evidence.
Ask yourself “What would I have to prove to eliminate this as a possible factor?”
They brandished their wand uttered some wizard’s chant, and bing! empowered their teams.
. He (and his uncredited wife, Heidi) set out a premise that, as the pace of technology development accelerated, we would be faced with making ever quicker transitions from one base of understanding to another. In other words: