Is Your Problem Technical or Adaptive?

Back in the early 1990s I was an avid skier, putting in 40+ days on the slopes every season. I was part of a group that did days in local (to Seattle) ski areas; annual trips to Whistler, BC (my favorite place); Mount Hood and Mount Bachelor in Oregon; and a semi-fateful trip to Red Mountain in Trail, British Columbia in March of 1993. Red Mountain is known for its challenging terrain.

March 13, 1993: Mark and the Red Mountain ski patrol

I was a pretty good skier, though not an expert. There were places where I would be in over my head. And I followed some expert skier friends into one of those places. To cut to the chase, I ended up learning how to spell “anterior cruciate ligament” and later on how to spell “arthroscope.”

My torn ACL was a technical problem, but not one I was (or am) qualified to fix. I outsourced the solution to a technical expert – an orthopedic surgeon and his team. They did a great job. Today that knee is better than the original equipment.

But the surgical, technical repair did not address the root cause of the problem. I could not outsource that. The work was mine, and mine alone, to do. Dealing with the root cause required me to change my own behavior. I had a few choices:

  • I could give up skiing entirely. Nope, too much fun.
  • I could take fewer risks, though that would mean plateauing my own learning.
  • I could work deliberately* to become a better skier so I can take on more challenging terrain with reduced risk of serious injury.**

No matter which of those courses of action I chose, they are not things I can assign to someone else to do for me. I have to do the work myself. Solving the problem requires a change in my own behavior.

I believe it was Ron Heifetz at Harvard who coined the term “adaptive leadership” to describe leading for behavior changes vs. simply guiding technical solutions. If you are a change agent, you are (or need to be) engaging in adaptive leadership.

In the context of continuous improvement, we are talking about the culture change that has to accompany any technical implementations if they are to stick for more than a few months.

Trying Technical Solutions on Adaptive Problems

An organization had a culture of working around their ERP / MRP system. If production fell behind, they extended lead times in the system (which is the worst thing you can do in this case). They would schedule “hot” orders in the past to force them to the top of the queue, driving material shortages for later orders – repeating the cycle.

They all believed that the computer system itself wasn’t up to the task of managing their “complex requirements.” (Which actually weren’t that complex at all – everyone seems to think their production portfolio is more complicated than everyone else’s.)

The new system, though, would fix all of this.

When the new system went into place, though, things got worse. Much worse. They doubled down on the same things they had done in the past, which made things worse again.

This wasn’t a problem with the computer systems. It was a problem with the way the team members worked together, a problem with their understanding of how their computer systems responded to their manipulations. It was a problem that no changes to the I.T. systems could solve.

Not surprisingly the same organization had tried kanban in the past. And not surprisingly they had worked around the system to “solve” perceived problems, and not surprisingly they had blamed the system for the failures.

It would not matter what technical system they had, their results would ultimately be shortages, expediting, scrambling to rush late shipments out the door. It was not the technical systems that produced those results, it was their behavior.

What Kind of Change Do You Have to Make?

This is adapted from material published by the Kansas Leadership Center, see more below under Further Information and Reading. The expansion, examples and explanations are my interpretation.

What kind of problem are you facing?

Is the problem clearly defined (like my torn ACL)? Or do you have to begin work to learn what actual problem(s) you are facing? If the later, you are dealing with adaptive, culture change work.

What kind of solution can be applied?

If there is a clear solution, or one can be researched, then you are dealing with a technical problem. But if the solution must be learned, then more likely it is adaptive. One key indicator – if you have put in a technical solution (like “standard work” or “5S” for example), but then seen it erode, then you are probably in adaptive territory. You have to learn what unseen factors are driving how people respond.

What kind of work is involved to apply the solution?

If you can just implement, like buying or upgrading a machine, then you are in technical territory. But if you have to diagnose, experiment, learn about things like the organizational dynamics then you are dealing with people’s behavior – an adaptive problem. Like above, I have seen many cases where a technical solution was implemented only to have that surface all kinds of adaptive and leadership issues. A new ERP system is a prime example. The software is the easy part. Beware of someone selling a “solution” by the way.

Whose Work Is It?

Even though this is a header, I bolded it, because this is The Critical Question. If technical experts or authority can just tell you what to do, then it is a technical problem.

But most meaningful change requires the stakeholders – the people responsible for the system and the results – to actually do the work themselves. This is the difference between fixing my torn ACL and the work I had to do.

In other words, if you put in “lean tools” (or complete a “black belt project”) only to see the results quickly eroding, then the technical tools, no matter how well you see them work elsewhere, are not going to help you. The organizations where you see them working have fundamentally different systems of leadership, and that is where the change must occur of the tools are going to work as promised.

What Timeline Should You Expect?

Technical solutions can be put in quickly. Anyone who has been though a classic “kaizen event” knows this. But changing people’s default thinking and behavior takes time because it takes practice and correction. And the default thinking and behavior is what created the technical systems you are trying to adjust. Eventually your kaizen blitz rocket runs out of fuel, and things fall back to Earth because gravity pulls them there.

What Are Your Expectations?

This is a tricky one. The whole reason to do any of this is to change results, change outcomes in some way. Technical solutions can do that pretty directly.

But when you are in adaptive territory, learning you way in, then you need to celebrate making progress and learn to trust the process – the results will come. Impatience does not serve us here.

Required Mindset

For technical solutions, skill and confidence are enough. You can hire someone with that. But if you are seeking to make real, meaningful change then you are better served with curiosity.

Further Information and Reading

If you want to learn more about Adaptive Leadership, here are some sources you can start with. Of course you can also leave a comment or click on “Contact Mark” in the right sidebar and ask me if any of this is interesting to you.

(Books are Amazon affiliate links, I get a small kickback at no cost to you if you buy through them.)

Best starter book: Your Leadership Edge by Ed O’Malley. This is also the text for a course by the same name taught by the Kansas Leadership Center.

Teaching Leadership by Chris Green and Julia Fabris McBride, who are also affiliated with the KLC, is more technical and more advanced. It is targeted more at people who understand the basics, and have practiced a bit, who now want to begin to coach others.

The Practice of Adaptive Leadership by Ron Heifetz, Marty Linsky and Alexander Grashow is what I would call the baseline reference. The books above are geared toward developing your practice. This book is more about the underlying principles. It is also a heavier read, just so you know.


*Note the word deliberately. This meant taking lessons specifically targeting my skill gap. Simply putting in more hours skiing would not be deliberate practice, I would simply be reinforcing the habits I already had. In other words – get a coach.

**Some of my more astute – probably younger – readers may question my judgement about not wearing a helmet. At that time, helmets were pretty uncommon for recreational skiing. Thankfully that has changed in more recent times. And yes, today I wear one.

The Key to Innovation is Iterate and Test

Key points from this great TED talk by Joi Ito, the director of the MIT Media Lab.

You can’t plan the path, you can only set the direction. He talks about the “compass” guiding a project that followed a route which was totally unpredictable. There was no way to plan out the path to success from the beginning.

Instead, at each step, they asked “Where are we now?”

“What do we need to do next?”

“What’s in the way of doing that?”

“How do we deal with that?”

I’m paraphrasing here, of course, but the key is that once again we have an instance the Improvement Kata pattern in the wild.

KataCon 2020: Ninja Kata and Kata in Secret

Clipped from Steven Kane’s presentation

In his level-set / coaching demonstration, Steven Kane talked extensively about obscuring the jargon of Toyota Kata to defuse pushback.

Tracy Defoe had a separate brief presentation titled “Kata in Secret” – and this has been a topic of discussion in the weekly Cascadia Kata Coaches call that Tracy hosts.

The two cases were a little different. In Steven’s case, he was (I think) talking about an organized effort. Lots of companies trying something new need to alter the jargon a bit. On a broader scale, there are quite a few companies where Japanese jargon will create an immediate wall of resistance, so why create the problem? Just change the words.

And I’ve certainly encountered cases where there was resistance to the very idea of any structure at all. Dealing with that took regressing away from the Coaching Kata and back to the more informal conversation that the Coaching Kata is teaching us to have.

Tracy’s cases are a little different. She is collecting stories from often solo practitioners who are practicing Toyota Kata under the radar because they are perceiving career risks if they are overt. In one cases a leader was explicitly told not to use Toyota Kata because it ran counter to the corporate lean program. She did anyway.

While I find these stories interesting, I am not surprised by them. I have seen, and even advocated, this for a long time. I call it “camouflage.” My principle is this:

Do the right thing, but make it look like what they expect to see.

In other words, there is no point getting dogmatic about something unless doing so advances your cause in come way. In still other words, don’t let “being right” get in the way of what you are trying to get done.

For example – one company I have worked with for a long time got hard pushback from their corporate continuous improvement mafia office. “We don’t have obstacle parking lots. We have kaizen newspapers.” OK, fine. They labeled the obstacle sheet “kaizen newspaper” and just call it “improvement coaching” and everybody is happy.

The key is this: Don’t dilute what you are trying to do. If you start moving away from developing a pattern of scientific thinking in the people you are helping, then you are letting the tools take precedence.

The Cancer of Fear

File:Nandu River Iron Bridge corrosion - 03.jpg

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

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

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

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

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

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

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

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

Asking for help? An admission of failure or incompetence.

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

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

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

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

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

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

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

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

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

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

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

And people are sending out resumes and talking to recruiters.

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

Five Characteristics of Fear Based Leaders

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

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

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

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

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

My interpretation of her baseline would be summarized:

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

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

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

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

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

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

The Breakdown of Trust

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

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

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

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

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

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

– VitalSmarts via Rich Sheridan

LEI Book: Getting Home

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

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

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

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

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

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

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

What They Achieved

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

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

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

How They Achieved It

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

“We don’t actually know.”

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

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

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

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

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

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

 

It Isn’t About the Specific Tools

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

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

Information as a Social Lever

The project started revolving around the ahead/behind board.

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

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

Beyond Rote Implementation

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

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

Summary

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

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

 

 

———-

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

That Broken Bolt is Speaking to You

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.

image

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.

If You Think “We Can’t Please Our Customers” You’ll Be Right

The center of the B Concourse at O’Hare Airport in Chicago is dominated by a Brachiosaur skeleton, part of the Field Museum exhibit for their store there.

IMG_20131206_215236_938

As a reminder for those of you over the age of 14, the Brachiosaurus was 70 feet long, 30 feet tall, weighed in at around 60 tons.* It had a brain the size of an avocado. It wasn’t smart. It wasn’t fast. Its main defense against predators was that it was simply too big to catch and eat.

In the shadow of the Brachiosaurus is United Airlines’ main customer service desk for their headquarters hub.

Back in June, Chris Matyszczyk published some really interesting commentary on Inc. Magazine’s site: The CEO of United Airlines Says He Can’t Really Make Passengers Happy

In his article, he quotes from an interview Oscar Munoz, the CEO of United Airlines, gave to ABC. From the interview:

“It’s become so stressful,” he said, “from when you leave, wherever you live, to get into traffic, to find a parking spot, to get through security.”

“Frankly,” Munoz added, “by the time you sit on one of our aircraft … you’re just pissed at the world,” and improving the flying experience won’t ultimately depend on “what coffee or cookie I give you.”

My interpretation? “We have given up trying to please our customers.”

That was the interpretation of Ed Bastian, Munoz’s counterpart at Delta Airlines:

…when Munoz’s views were put to Delta CEO Ed Bastian by Marketplace.

His response was, well, quite direct:

“I disagree. Those certainly aren’t Delta customers he is speaking to.”

My Perspective as a Frequent Flyer

Just so you know my perspective: In the course of my work, I typically purchase between 10 and 20 thousand dollars worth of airfare a year. While this isn’t anywhere near the highest, I think I am the kind of customer an airline wants to get and retain.

Further, I know the system. I know what to expect, can quickly distinguish “abnormal” from “normal” and know how to maneuver to get out in front of issues I see developing. I pay attention to weather and other events that might disrupt the system, and contingency plan accordingly. I know, generally, how to arrange my stuff to get through TSA smoothly (though they can be arbitrary).

And I have the perks of a heavy frequent flier, which buffers me from a lot of the “stuff” that casual travelers have to contend with.

Munoz used some words that really identify the problem: …by the time you sit in one of our aircraft…”

This casual statement, which correlates with my experience as a former United Airlines customer** implies a belief that the customer service experience begins once you are on the plane. This isn’t where United’s reputation is created. Once you are on the plane, the customer experience of all of the major airlines is pretty similar.

My experience reflects that it is what happens on the ground that differentiates one airline from another.

Assumptions About Customers Come True

The assumption that customers are just “pissed off at the world” and there is nothing we can do about it is a self-fulfilling prophecy.

If that is the attitude from the top, then it lets the entire system off the hook for making any effort at all to understand the things that might take some of the sharp edges off the experience.

On the other hand, if the attitude is “We are responsible for the experience of our customers – even if we aren’t” then the effort can get focused on understanding exactly what kind of experience we want our customers to have, and engineering a system that delivers it to the best of our ability. That, in turn, allows reflection when we miss, and improvement for the next time.

One is a victim attitude. “We’ll get better customer satisfaction when our customers are better at understanding how hard it is.”

The other is empowering – “Even if our customers *are* pissed off at the world, we will own it and work to understand what we can do.

How Does Your System Respond to Stress?

This in my mind, is what really differentiates a good system from a broken one. Like I said, it’s easy when everything is flowing smoothly. But what happens when the system is disrupted?

Is there a mad scramble of figuring out what to do – like it is the very first time a maintenance issue has caused a flight to be cancelled? What are we going to do with all of these passengers? Process them through two people? (See the line in my photo above!)

Or is there a clear process that gets engaged to get people rebooked – leaving the true difficult cases for the in-person agents?

Ironically, the major airline with one of the very best on-time schedule records also has one of the best recovery processes. Go figure.

Then there are little gestures, like snacks or even pizza for those suffering through a long delay.

“It’s not our fault” easily leads to “you’re on your own.”

“We’re going to own it, even if we don’t” leads to “let’s see if we can help.”

Now… to be clear, the entire airline industry has a long way to go on this stuff. But my point is that some are making the effort, while others have given up.

What Experience Have You Designed for YOUR Customers?

That, ultimately, is the question I am posing here. If you start with the experience you want your customer to have – a standard – then you have a point of comparison.

Did we deliver that experience? If so, then could we do it more efficiently?

If not, what got in our way, how do we close the gap?

Without a standard to strive for, there can be no improvement – and I think this is what Taiichi Ohno actually meant.

——

* Estimates of the weight vary quite a bit.

Rough metric equivalents would be around 20 meters long, 9 meters high,  50 tons. About the weight of mid-cold war era tank.

——

** With one exception that was booked for me, I haven’t flown on United since mid 2014 after an experience that could not have been better designed to tell the customer “We don’t work as a team or talk to each other.”

I cashed in my frequent flier miles for a camera about a year later.

Ambitious Growth Plans? Your Customers Will Right-Size You

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.

If the student hasn’t learned…

… the teacher hasn’t taught.

Do you regard the structure of problem solving as dogma, or as an experiment with a predicted outcome?

If the learner struggles to master the structure, sometimes it is more valuable to find a different structure than to double down on what clearly isn’t giving the predicted result.

The Problem

Early this year I started work with a new client. They were trying to “implement A3,” and as I began to work with them, especially the new-in-the-position C.I. manager, I found they were struggling with what to write in the blocks of the “form.”

Of course there isn’t an A3 “form.” The A3 takes many configurations as the problem solver sets out to share the narrative with her coach. Nevertheless, beginners tend to find a format online, and work to put the right information in the various blocks.

In this case, my impression was that the blocks were getting in the way. “What should go in here?”  “What goes in the next block?” I didn’t really make a deliberate decision here, but I’ll tell you what I ended up doing:

What I Tried

First I tried the Toyota Kata format. He really liked that approach, but ultimately in this case we ran into the same kind of struggle. “Getting the structure right” seemed to be obscuring the bigger picture of the underlying thinking.

So I tried something more drastic: I let go of the format and the structure. Instead, let’s work on solving problems.

Like all organizations, there was no shortage of problems to practice on. So we just picked one.

Without the form, I had him map out the basic process steps. Then what happens, then what happens. What, exactly, is happening here. “The part is dropping off the conveyor.”

“OK, that’s the outcome, but what, exactly, is the mechanism that causes it to drop?” Describe what is happening. Draw it. Write it down. Show me.

After working to see process steps, we took on some pervasive quality issues.

“How is it even possible to produce this defect?” What are the steps involved to make a defective product? Yes – making defective product is a process, just like making a good product is a process. It is just a different process. What is actually happening here?

There were trials, experiments, measurements all with the goal of learning more, digging deeper, until the mechanism of the failure could be described. “This is what is happening.”

OK – how could that happen? Always forcing the discussion toward what is actually happening vs. what is not happening. If there was more than one possible mechanism to cause the problem, then “Based on the evidence we have, which of those can we rule out, and why?” Look at what’s left as a possible cause.

Of those, what trial can we run to see if we can rule that one out, or keep it in play.

At the end of a few of these, his language started to shift. He started speaking to others differently. He was learning to coach in different ways. He started asking different questions, boring in on the details with the intent of inquiry and dialog vs. “showing what I know.”

Oh – and he cracked a couple of chronic problems.

Then when the Corporate C.I. guy started insisting on “using A3” it was a pretty simple transition – it is just a way to describe what you know, what you do not know, and what steps you are taking to deepen your understanding because…

“The root cause of all problems is ignorance.”

– Steven Spear

What I Learned:

A core prerequisite to continuous improvement is good daily management of problem solving that applies solid scientific thinking to find the answers.

Once that thinking structure is in place, it can be expressed many ways, and A3 is but one of them. It isn’t the only one. As the level of scientific thinking deepens, the more the various tools and structures simply become fluid extensions to make it easier to express.

Sometimes I have found that if I try to force a particular format into place, I can end up having a container without any content.

Now… to be clear, there are many instances where the structure facilitates learning. It is just that in this particular case, the structure got in the way.

Asking whether learning is actually taking place, rather than trying to force a specific structure into place, may well be the difference between trying to teach by rote vs. staying focused on what the student is actually learning.

A Period of Reflection and Learning

Some of you have commented in back-channels that I have been pretty quiet for a while – both here as well as in regular correspondence. I’ve been in pretty heavy reflective mode for quite a while. I described it to someone as “I am learning faster than I can write it down right now – by the time I write something, I understand it in a different way and start over.”

A lot of that reflection has been around consolidating what I learned at from Rich Sheridan, James Goebel and all of the other Menlonians that I have the privilege to know now.

That work was punctuated, though not completed, by my keynote at KataCon last February (2018) where I followed Rich Sheridan and described my interpretation of the underlying meta-patterns that exist in pretty much any organization that we would call exceptionally good at what they do.

At the same time, another client (Thank you, Tomas!) introduced me to Ronald Heifetz and Martin Linsky’s body of work under the umbrella of “Adaptive Leadership.” From their model I think I picked out a fundamental failure mode of what we like to call “change initiatives” regardless of what tool set of operational models we are trying to deploy.

To learn more about this, I read (Note – these are Amazon affiliate links. If you choose to buy the book, I get a (very) small kickback at no cost to you.)

The Practice of Adaptive Leadership

Leadership on the Line

Leadership Can Be Taught

Teaching Leadership

Your Leadership Edge

and every paper and article I could find on the topic or about people’s experience. While doing this, I have tried out many of the teaching and coaching processes as well as applying the observation, interpretation and intervention skills in the course of my work. Those of you who participated in the Experiential Workshop that Craig Stritar and I put on at KataCon early this year were seeing the outcomes of this work up to that point.

My latest step was taking a three day seminar Your Leadership Edge from the Kansas Leadership Center in Wichita the 2nd week of August. The KLC’s model and methods are built on the Adaptive Leadership model. My intended outcome was to consolidate some of my understanding by getting the external perspective and participating within their structure.

The number one frustration of “change agents” out there is some form of “How to I get buy-in?” I know I have experienced that myself. It is easy when all of the constituencies and factions within the organization are well aligned on purpose and values. Not so easy when there are conflicts. I think the Adaptive Leadership model gives us an approach we can learn by practicing. It also mirrors the steps of problem solving / continuous improvement that are outlined in Mike Rother’s Toyota Kata. The context for action is different, but the process is the same: Learning what works through experimentation. That is the “adaptive” part of Adaptive Leadership.

This post is just some background around why I am pursuing this line of thought. As always, I write about things like this to force myself to improve my own understanding by having to explain them in the simplest possible terms. I am happy to have any of you along the journey with me, so subscribe or check-in or whatever and let’s see what we can learn.

Mark