Author: Mark

Posted on

Thoughts and Notes from KataCon 2020

This is the first in series of posts I am drafting about what I saw, heard, learned at KataCon6 in Austin.

I was originally writing this up in huge chunks, maybe two posts. But when I bounced the “Part 1” draft off Craig Stritar, I got some good advice – there are a lot of topics here, and it might be more useful to break these up into smaller pieces, so that is what I am doing.

My intent is to generate discussion – so I would like to explicitly invite comments, questions and especially take-aways from others. In other words – let’s continue the great conversations that were taking place in Austin.

Day -1 and Day 0

Lean Frontiers traditionally runs the TWI Summit and KataCon back-to-back in the same week, alternating which comes first. This year the TWI Summit was Monday and Tuesday, and KataCon was officially Thursday and Friday.

Both conferences, though, have semi-formal activities and get-togethers prior to the first official day. Since there are things going on Wednesday, some people begin to arrive Tuesday evening. And because I was already on site from the TWI Summit, Tuesday evening is really when things got started for me.

Something I have observed in the past is that each KataCon seems to take on an informal theme of its own – a common thread or feeling that is established more by the participants than the presenters. Where the first KataCon was the excited buzz of a community coming together for the first time, this one seemed to me to be like a reunion. To be clear – it was a welcoming reunion. Unlike other conferences I have attended, there is nothing “clique-ish” about this one.

With that reunion theme, I want to give a shout out to Beth Carrington. She is a vital member in the fabric of this community and this is the first KataCon she has missed. I think I can speak for all of the regulars when I say “we missed you.” Those who do not know you still felt your presence and influence through your impact on the rest of us.

The other thing (for me) that was cool was just how much of the conversation took place after hours in the hotel lobby bar. There were long-time regulars catching up, and there were first-timers and newbies getting rich tutorials and insights from the veterans. That is why I titled this section starting with day “-1.” Those conversations were happening on Tuesday afternoon and evening as people started to arrive.

This is a community of sharing. Many of us are consultants and nominally competitors in an increasingly crowded market. Yet nothing was held back. We build on each other’s stuff, and pretty much everyone shares what they are thinking with everyone else. That’s pretty cool in my estimation.

The Kata Geek Meetup

Kata Geek Button from KataCon 1

The Kata Geek Meetup started at the first KataCon. At the time it was an informal mailing list invitation to attend a get-together before the conference started. Everyone got a “Kata Geek” button to wear with the idea that the other conference participants could identify those with a bit more experience under their belt if they wanted to ask questions, etc. The event wasn’t publicized on the conference agenda.

Over the years this has morphed into a mini-preconference that is open to all who can attend. People share brief presentations – maybe something they want to try out for an audience, maybe a rhetorical question, maybe a “what we are learning.” The pacing is much more flexible than the actual conference, and there is time for lively discussion and Q&A. Sometimes tough, challenging questions get asked – though always in the spirit of curiosity rather than trying to one-up anyone.

As I get into the actual content, I want to clarify my purpose in writing what I do. When I listen to presentations, I am more likely to take down notes of what thoughts or insights I take away than the actual content. These things are often a fusion of key points the presenter is making, or the way they are saying something, and my own paradigms and listening framework. That is what I am writing about here. I am not making any attempt to “cover” the presentations as a reporter or reviewer would or be complete in mentioning everything that was said.

PLEASE contribute in comments if something I didn’t mention resonated with you, or something written here sparked another thought for you.

Dorsey Sherman made a simple point: All coaching is not the same. It depends on your intention (as a coach).

Thinking about it a bit, the classic TWI Job Relations is coaching – usually (in its original form) to fix or change behavior in some way. TWI Job Instruction is coaching – in this case to teach / coach for skill. At a deeper level, the classes themselves are designed to give novice coaches a structure they can practice.

The Improvement Kata framework itself is a pretty universal structure that I can pour a lot of different intentions into and test ideas that I think will move me in a particular direction. I think all coaching is a process of exploring and experimentation simply for the fact that we are dealing with other people. We may begin with assumptions about what they think, know, feel but if we don’t take deliberate steps to test those assumptions we are just guessing in the dark.

Hugh Alley

Hugh is a friend from neighboring beautiful British Columbia. I recall telling an audience in British Columbia that Canada represents that nice couple living quietly in an apartment over a rowdy biker bar. 😉

A couple of take-aways I noted down as Hugh was speaking:

  • The storyboard represents a picture of the learner’s mindset – it is like an MRI.
  • Correction: Hugh informs me (see his comment below) that the MRI analogy came from Panos Eftsa.

I loved that analogy. When I look at the storyboard I am really seeing how organized the learner’s thinking is, how detailed, and whether or not they are connecting the dots of cause and effect from the levels of their target conditions to their metrics down to their experiments and predictions.

I thought of an image like this:

Public Domain: From Wikimedia Commons

Hugh was asking the audience about his situation of a client company that started up 13 storyboards at once. Some of the thoughts that came out:

  • Um… OK, you have already done that. *smile*
  • Establish a specific area of work for each board, each coach. Don’t try to bring them along all at once.
  • Work through each phase of the Coaching Kata, anchor success and mastery one-by-one rather than trying to batch everything through at once.

What was good about his client’s approach, though, is they are establishing a routine of people talking about why the work is the way it is – and that is awesome.

Toyota Kata Level-Set

At this point I am letting go of trying to write in the sequence of the agenda. There are topics I want to go deeper into, others I may combine.

Oscar Roche

The Toyota Kata Summit attracts people across a wide spectrum of knowledge and experience with “Toyota Kata” itself. Balancing the conference can present a real challenge. There are people who have been practicing this in the trenches for a decade and are pushing the boundaries. There are people who might have read the book and are curious about learning more.

One of the countermeasures is a “level set” presentation at the beginning of the formal conference. This is a brief overview of the fundamental principles of Toyota Kata and I think it is a good grounding for the veterans as well – it is always good to pull us back to the basics now and again.

Traditionally Mike Rother has done the “level set” presentation. This year, though, was a change and Oscar Roche stepped up. Oscar’s title slide drove home a critical point that we often miss:

  • “Kata is the a thing that helps you develop the a way”

His next slide answers the implied question:

Scientific thinking is a mental framework of continuous comparison between what we predict will happen next, and what actually happens, then adjusting our understanding based on the difference.
My thoughts – and a digression

A lot of practitioners get hung up on the idea that the way they know best is the best way, sometimes to the point of believing it is the only way. This is true for Toyota Kata practitioners, general “lean” practitioners, Six Sigmites, Theory of Constraints, TQM, you name it.

Sometimes I hear people make sweeping statements that dismiss an entire community, perhaps focusing in on one thing they perceive as flawed. “Lean addresses waste but not quality (or not variation).” “TOC doesn’t address flow.” “Six Sigma is only about big projects.” “Toyota Kata is only about the storyboard.” All of these statements are demonstrably false, but it is hard to have an open minded discussion that begins with an absolute.

All (credible) continuous improvement has a foundation of scientific thinking. Any approach you take has some basic “first moves” to get you started thinking that way. Toyota Kata is more explicit about that than most, but the underlying principles are the same across the board.

Oscar’s opening slide emphasized this point: Toyota Kata is a way, not the way. We can all learn to adapt vs. continuing to hammer on a nail that has hit a knot and is bending over.

Steven Kane

  • A teacher provides insight.
  • A coach pulls insight from the learner.
  • You may go back and forth between these two roles. Be crystal clear which role you are in at the moment.

I’ll probably write more about this in the future in a separate post. What I liked about this thought is that it is appropriate for the coach to provide direction or insight at times. My own presentation at KataCon kind of hinted at this – someone has to bring in the paradigm of what “really good” looks like.

Nevertheless, it is critical for the coach to drop into the “teacher” role only when necessary (which I think is a lot less often than we like to think it is), and then get back into true “coach” mode as quickly as possible. Why? Because unless I am in “curious” mode with my learner, I really have no way to know if my brilliant insights got any traction. 😉

Paraphrasing from Steven’s presentation, the question “What did you learn?” is there to see if there has been a moment of discovery.

  • The Power of Nothing

The most powerful follow-on question to “What did you learn?” is silence. If initial response is fluffy or vague, or you think there is more, just wait. Don’t try to say anything. The learner will instinctively fill in the awkward silence.

  • Target Condition vs. a Result

This came up a lot during the conference. Billy Taylor talked about the difference between “Key Activities” (KA) vs. “Key Indicators” (KI or KPI). What are the things that people have to do that will give us the result we are striving for? Leaders, all too often, push only on the outcome, and don’t ask whether the key activities are actually being carried out – or worse, don’t think about what activities are required (or the time and resources that will be required). I’m going dedicate a post on that topic.

And finally (and I am making this one bold so I remember it!) –

  • Don’t rob the leaner of their opportunity to make discoveries.

How often do we do that?

Michael Lombard

Michael had a brief presentation on “What we are learning” focused specifically into the health care field. His thoughts on medical students actually apply universally with anyone who perceives themselves as successful.

  • We need to de-stigmatize struggle. Productive struggle is part of deep learning. Medical students should not feel shame when they struggle to learn a new skill.

Why do they? Michael pointed out that the people who manage to get admitted to medical school are high-achievers. Things may well have come easily for them in high school and their undergraduate studies. Now they are in a group with other high-achievers, they don’t stand out from the crowd, and the concepts can be difficult to master.

We see the same things in other environments – a lot of people in senior positions of authority got there the same way. Many are ultra-competitive. Now we are asking them to master a skill that runs entirely counter to their paradigm of intuitive decision making. Note that that intuitive decision making has worked well for them in the past. But maybe they are at the limit of what they can do themselves, and have to find ways to engage others. I don’t know… there could be lots of scenarios that put them into completely unfamiliar territory.

Our challenge is how we de-stigmatize struggle.

Michael’s other key point touched one of the Wicked Problems in health care. I’m going to go into some more depth when I get to Tyson Ortiz’s presentation, but want to acknowledge the Great Question posed here:

  • “99% of activity needed to maintain wellness never involves a health system. Can we increase the striving capabilities and mental resilience of our patients, families, & communities so they can own their health journey?”

Amy Mervack

Amy tied our practice to the concept of “mindfulness.” One of her key points was learning to see that the pattern we are trying to teach may well be there in some form other than the explicit Improvement Kata.

She wrapped up with some guided practice of “being mindful” for the audience – which she said stretched her a bit as she had never done it with a group that large.

As a change agent, a mindfulness approach is critical. We have to learn to find everything about the way things are being done that we can leverage and extend. This means paying attention vs. the mindless approach of dismissing them out of hand with a single statement. Making people feel wrong may get attention focused on you, but it rarely helps make progress.

Experientials

The afternoon was “Experientials” – four hour breakout sessions that went deep into a particular topic. As Craig Stritar and I were hosting one, I didn’t attend any of the others. Always a downside of being up-front – I see more of my own stuff than the awesome things others bring.

As I mentioned above, I am going to be digging into some of the topics in more depth, and I want to keep those individual posts focused vs. trying to cover a rich diversity of discussions all at once. Hmmm… one-by-one vs. batching. That might be a concept. 😉

Posted on

Notes from the 2020 TWI Summit – Part 2

Tyson Ortiz

TWI Job Instruction Card

Tyson zeroed right in on one of the biggest problems with “training” – getting people to adopt the new process or method after we have taught it to them.

Compounding this was that, in his example, the training was TWI Job Instruction – how to train. Tyson took a quick show-of-hands poll and informally confirmed his hypothesis that most people who take the TWI Job Instruction 10 hour course are already engaged in training and teaching.

This means that they have to do more than learn a new habit – one which will feel awkward to them at first. They also have to unlearn their current way of doing things – a way that is likely comfortable and familiar to them. To paraphrase from a slide of mine that seems to keep coming up: This. Is. Hard.

Taking what he has learned from Toyota Kata, Tyson saw the 4 Step Method for what it is: A routine for practice, not the end-all. For that to work, there must be actual practice using the routine. The 10 hour class is telling them about it* – and telling alone is not enough!

What Tyson did was add structured follow-on practice with real work, but not real training where the participants can practice, make mistakes, and learn in a safe environment. Then they move to live environments, but are still being coached. Then they are graduated and put on their own.

Transition of a learner through Recruiting, the 10 hour JI Class, a "safe zone" practice, "real" practice, then graduation.
Clipped from Tyson’s presentation.

Another key is that passing each stage is based on performance, not a time line. It is up to the coach, since the coach is the teacher, and “If the student hasn’t learned, the teacher hasn’t taught.”

*Yes, the class includes demonstrating the four steps – but each participant typically only gets one repetition, hardly enough for us to know that they know.

Roger Bilas

Roger actually built on the theme that Tyson was developing – the process of getting Job Instruction incorporated into the daily routine of the organization.

We often call this “managing change” or more cynically “overcoming resistance” but I think both Roger and Tyson are operating at a much more fundamental and human level. It’s called paying attention to what is causing stress and fear and make sure you deal with it effectively and with empathy.

And it is empathy where Roger begins.

He used the Stanford design school model to experiment his way toward a solution that used the framework of Job Instruction in a way that worked for the particular situation. And isn’t that the whole idea?

The design thinking model steps: Empathize, Define, Ideate, Prototype, Test
Clipped from Roger’s presentation.

As I was listening, I scribbled a note in the margin: “this is Menlo’s model” – the design process that Menlo Innovations. It isn’t really – this model uses different words. But the structure, intent, purpose is the same and is followed by all robust design and product development processes.

Roger was operating in an environment that was unfriendly to paper, had lots of high-variety and low-volume tasks that people had to get right.

Once he understood that he had motivated people in a tough situation, they began working together to develop simple solutions that worked – starting with simple sketches and hand-written notes on laminated cards.

Iterating through, always asking “What small step can we take?” toward the goal, always asking “How can we test that assumption or idea?” they converged on a solution that worked really well.

Not surprisingly, it was very visual and simple, and captured “Key Points” from the Job Breakdown.

There was a lot more good stuff at the TWI Summit. I’ll cover my own keynote separately. And I missed the 3 hour “Experiential” sessions because I was presenting one. And for the afternoon of Day 2 I was attending Oscar Roche’s version of a Toyota Kata class that follows the 5 x 2 hour structure of the classic TWI JI, JR, JM classes.

Thus, the next big thing for me to report on will be KataCon – which will be my next post.

Posted on

Notes from the 2020 TWI Summit – Part 1

Photo by Michele Butcher of Lean Frontiers

Last week (February 17-20) I attended (and presented at) the TWI and Toyota Kata summits put on by my friends at Lean Frontiers. As always, I took a few notes and I would like to share some of those notes and thoughts with you here.

To be clear, what follows are my impressions and thoughts that were sparked by some of the presentations. I am not trying to be a reporter here, just catch my own reflections.

Martha Purrier

Martha Purrier, a Director of Nursing at Virginia Mason Medical Center in Seattle, talked about “auditing standard work,” though in reality I think her process was more about auditing the outcomes of standard work. More about that in a bit.

My interpretation of the problem: Traditional “audits” are infrequent, and tend to be time consuming for those doing them because there is an attempt to make them comprehensive.

Infrequent checks are not particularly effective at preventing drift from the standard. Instead they tend to find large gaps that need to be corrected. This can easily turn into a game of “gotcha” rather than a process of building habits. What we want to do is build habits.

Habits are built in small steps, each reinforced until it is anchored.

Make it Easy: Short and Simple Checklists

Martha’s organization created short checklists of critical “Key Points” (from TWI Job Instruction) that were critical to the standard they wanted to maintain.

Audit Check Card. Photo from Martha Purrier’s Presentation

As you can see, this is a quick and simple check to see if the contents and organization of a supply cart meets the standard.

But what really caught my attention was how they are triggering the audits.

The Key: Reliable Prompt for Action

This is a pretty typical work task board. There is a row for each person or team. In this case the columns look like they represent days, but they could just as easily represent blocks of time during the day, depending on how granular you want your tracking to be. At some point these start to become a heijunka box, which serves the same purpose.

You can see the yellow bordered audit cards on there. Martha said that when a task is complete, it is moved to a “Done” column that is out of frame to the right.

Here is what is awesome about this: It gives you the ability to “pull” checks according to need.

Do you have a new process that you want multiple people to check during the course of the week? Then put the check card for that task in multiple rows at staggered times.

Do you want to go broad over a group of related checks? Then put different checks on the board.

Who should do the checks? Whoever you assign it to. Totally flexible. Do you want to trigger a self-audit? Then assign the card to the person who does the task being checked, with the expectation that they self-correct.

Do you want to bring a new supervisor up to speed quickly? Assign multiple audits to her, then assign follow-up audits to someone else.

Making it Better: Follow-up Breakdowns

If we don’t want audits to simply become lists of stuff to fix, there has to be some process of following up on why something needed correction.

Martha’s organization introduced a simple check-form that lists “Barriers to Standard Work – (check all that apply)” and provides space to list countermeasures taken.

The lists includes the usual suspects such as:

  • Can’t find it
  • No longer relevant
  • Not enough detail
  • etc.

but also some that are often unspoken even though they happen in real life:

  • Lack of enthusiasm to continue or improve
  • Mutiny
  • Relaxed after training – drift

If a large part of the organization is pushing back on something (mutiny), then the leadership needs to dig in deep and understand why. To continue in our TWI theme, this is a great time to dig into your Job Relations process.

Standard Work vs. “Standards”

In my past post, Troubleshooting by Defining Standards, I made a distinction between defining the outcome you are trying to achieve and, among other things, the way the work must be done to accomplish that outcome.

When I think of “standard work” I am generally looking for a specification of the steps that must be performed, the order for those steps, usually the timing (when, how long) as well as the result. In other words, the standard for the work, not just the outcome or result.

To verify or audit “standard work” I have to watch the work as it is actually being performed, not simply check whether the machine was cleaned to spec.

Now, to be clear, I LOVE this simple audit process. It is an awesome way to quickly follow-up and make sure that something was done, and that the patient or customer-facing results are what we intend. It is flexible in that it can quickly and fluidly be adjusted to what we must pay attention to today.

I realize I am quibbling over words here. And every organization is free to have its own meanings for jargon terms. But when I hear the team “standard work” I am looking for the actual work flow as well as the result. YMMV.

This post got long enough that I am going to let it stand on its own. More to follow.

Posted on

Troubleshooting by Defining Standards

Sometimes I see people chasing their tails when trying to troubleshoot a process. This usually (though not always) follows a complaint or rejection of some kind.

A few years ago I posted Organize, Standardize, Stabilize, Optimize and talked in general terms about the sequence of thinking that gives reliable outcomes.

This is a series of questions that, if asked and addressed in sequence, can help you troubleshoot a process. The idea is that you have to have a very clear “YES” to every question above before proceeding to the next.

Question 1: Is there a clear standard for the outcome?

Why? Because if you don’t have a clear expectation of what “good” looks like then your definition of “not good” is subjective and varies depending on who, what, when things are being looked at.

If no, then define:

  • What are you trying to accomplish from the customer’s perspective? What does “good” look like? How do you know?
  • How does the team member performing the work know (and verify) that this expectation has been “met” or “not met” – each time.
  • This includes not only the physical quality expectations but the required timing.
  • What do you want the team member to do if she finds a problem? What is your process for escalation / response?

Question 2: Is there a clear standard for the method that will achieve the standard results?

Why? Because if you (as an organization) don’t know how to reliably achieve the standard you are relying on luck.

If no, then define:

  • What steps must be performed, in what order, to get the outcome you expect?
  • Content, Sequence, Timing to give the desired Outcome.
  • How will the team member doing the work know (and verify to themselves) that the method was either “applied” or “not applied” according to your standard – each time?
  • What do you want the team member to do is he can’t or didn’t carry out the process as defined? What is your process for escalation / response?

Question 3: Are the conditions required for success present?

Why? Because if the team member does not have the time, tools, materials, environment that are required to execute the process as designed they have to improvise and compromise.

If no, then define:

  • What conditions must exist for your standard method to work?
  • What conditions must exist to enable the team member to consistently execute to the standard with no work-arounds?
  • How will you assure that the conditions exist prior to process execution each time?
  • What stops the process from proceeding if the required conditions do not exist?

Question 4: Is there consistent execution of the standard method?

Why? If you have defined the method, and assured that the conditions required for success exist, then you must examine what other factors are causing process variation.

ACTIONS:

  • CONFIRM the standard conditions exist. Correct or restore. Check for process stability.
  • CHECK FOR other conditions which affect execution. Establish new standard conditions. Check for process stability.
  • CONFIRM clear understanding of the standard method. This would be a good time to engage TWI Job Instruction. Check for process stability.
  • For all of the above – verify all suspect process output vs. the standard for outcome and results.
  • If you discover an alternative work method that is clearly superior to the standard then Confirm, capture, verify. DEFINE a process for process improvement – how to alternatives get confirmed and incorporated vs. random mutations?
  • Define your mistake-proofing / poka-yoke at the point where process execution varied to increase stability.

Question 5: Was a standard method followed and the results were as expected or predicted?

Why? After we have verified process stability, then we can ask “Does the process that we specified actually work as we predicted?

  • REEXAMINE your standard method and conditions.
  • Identify process failure points and sources of variation.
  • Adjust the process to address those failure points and sources of variation.
  • Repeat until your process is capable and consistently performs to the standard.

Question 6: Does everything work OK, but you want or need to do better?

Only a stable baseline can tell you how well you are performing today. Then you can assess if you need changes. If so, then reset your standard for expectations. Return to the top.

Posted on

What Is Your Target Story?

One of the artifacts of Extreme Programming as practiced by Menlo Innovations is the Story Card. In the purest sense, a story card represents one unit of work that must be done by the developers to advance the work on the software project.

But the content and structure of the story card make it much more powerful than a simple task assignment. The story card is written in a way that engages the programming pair doing the work.

Before a story card is created the team works very hard to identify the primary persona that represents the human being who most benefits from their work. That persona gets a name, a face, a biography. She has wants, needs and aspirations.

Menlo primary persona
(c) Menlo Innovations. The primary persona is shown in the center of the target. There are two shown in the second ring, and three in the third ring.

Why? A couple of reasons.

First, it establishes priority of effort. In software development compromises must be made between optimizing the interface and workflows for various users. By identifying the primary persona, the team says “This person’s use of the software will be optimized.” Other users will certainly be accommodated, but any compromise will break in favor of the primary persona.

Menlo, for one, works very hard in the up-front design process to smoothly integrate the workflow created by their software into the larger context and workflow that their end-user is trying to carry out.

The other effect is more subtle. It humanizes the “user” as the developers are talking about what their code does, or does not, do.

Rather than simply set out a feature in an abstract way, the story card focuses on granting an ability to the main persona. The process of creating the personas, and developing the persona map humanizes the group of people that would traditionally be thought of as “the users.”*

Thus, the feature would be described something like this:

“Sara is able to select her choice of color from a pull-down menu of options.”

Then the developers write code that enables Sara to do this, quickly and easily.

This is a simplification, but it suffices to set up my main point.

Who Are You Optimizing Your Improvements For?

Let’s translate this thinking into our world of continuous improvement.

Who is your key persona? Who are you enabling with your process improvement? What will this person be able to do that, today, he cannot?

Rather than saying “The lowest repeatable time does not exceed 38 seconds” as a target condition, what if I said “John is able to routinely perform the work in 38 seconds when it is problem-free.”

I don’t know about you, but I feel a lot more emotionally engaged with the second phrasing. This is doubly true if John is an actual person actually doing the work.

What about scaling to other shifts, other operators?

Yup. I agree that at some point your target condition is going to shift to “Any trained team member” but what I tell people today when they are trying to go there first is this:

“If you can’t get it stable with one person, you are never going to get there with multiple people.”

You have to get it to work once first. Then introduce the next layer of complexity. Start simple. One step at a time. Control your variables.

I have been experimenting with this linguistic shift in my Toyota Kata classes and consulting.

If you are in R&D this is an even more direct application back to Menlo’s model.

Training = Giving People Ability

I also ran an experiment with a client HR team that was charged with developing a comprehensive on-boarding training process.

Rather than do the traditional thing, which is take the laundry list of topics they are supposed to try to cover, and trying to figure out how to stuff everything into the time they have been given (40 hours, which is really more like 35 hours), I asked them to experiment with the following:

For each skill they have been asked to train, write it on a separate 5×7 card in the form of “[The learner] is able to _________.” In other words, describe the skill as an ability that someone is able to demonstrate.

Then determine how they will test that skill. Do that before they even think about how they are going to teach it.

Then develop training experiences and exercises that they believe will allow the learner to pass the test.

Software developers will recognize this as “test driven development” – start with the unit test, then write the code.

Testing Your Target Condition

As in the example above, a target condition should also be testable. By stating what we will observe or measure when the target condition is met, we are constructing a “unit test” of sorts.

By stating what we will observe or measure first, we can separate “solved” from “the solution” and open up the possibilities of what solution(s) we will experiment with.

—————–

In the culture of many more traditional software development and I.T. organizations, “users” can be almost a derogatory term, with an implied, usually (but not always) silent “dumb” appended to the front. We write Books for Dummies so they can understand our brilliant systems.

Posted on

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

Posted on

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.

Posted on

It will feel worse because it’s getting better.

image

The line is starting to flow, or at least there is more time flowing than not flowing. The places where it isn’t flowing well are now much more evident.

Things are speeding up. That is placing more stress on the engineering and materials supply processes where, before, they were shielded by a rough start-up that was always behind schedule.

They are catching up on the backlog, closing in on “on schedule shipment.”

“John” forgot to send a batch of parts to an outside processor. Before that would have been no big deal, it would be a day or so before those things were actually needed. But this time it briefly stopped the line and forced a work-around.

When everything was a work-around, nobody noticed. This time it got on the radar. It feels worse because the system is sensitive to smaller problems now, and there are plenty of those.

It isn’t “John’s” fault. He is flooded with a constant flow of things he needs to react to. There isn’t a structure for him to work within. That is the next opportunity.

Thus, it is critically important to remember a Toyota mantra:

‘No problem’ is a big problem.

If problems are not coming up, then your system is hiding them, plain and simple. You have stopped learning, stopped improving, stopped growing.

It is an easy groove to get into because we get all kinds of feel-good brain chemicals when things are going smoothly. We want more of those, less of the ones that call us to action.

But it is those “call to action” things that drive us to get better.

Posted on

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.

Posted on

How Do You Know They Know?

TWI Job Instruction is built around a four step process titled “How to Instruct.”

image

Steps 2 and 3 are the core of the process.

  • Present the Operation
  • Try Out Performance

I want to discuss Step 3: Try Out Performance

Teaching Back as Learning

All too often I see “training” that looks like this:

  • Bring the team members into a room.
  • Read through the new procedure – or maybe even show some PowerPoints of the procedure.
  • Have them sign something that says they acknowledge they have been “trained.”

This places the burden of understanding upon the listener.

The TWI model reverses this paradigm with the mantra at the bottom of the pocket card which, though they vary from version to version, is some form of: If the student hasn’t learned, the teacher hasn’t taught.

Having the learner teach back to the instructor does two things:

  1. The learner has to understand it better to be able to explain it.
  2. It provides a verification check that the instruction has been effective.

Point two is important here. Instruction is a hypothesis: “If I teach these steps, in this way, my learner will be able to perform the process.”

Having them teach back is the testable outcome of this hypothesis. If the the learner struggles, then the instructor must re-instruct. But not simply by rewinding the script and playing it again… we know that didn’t work. Instead the instructor now has to get curious about which points are confusing the learner and why, and correct his instruction.

But that’s not what I came here to discuss. TWI is just a lead-in.

Learning to See – by Practicing

An operations manager who is learning fast was challenging my insistence on having a visual status board that showed the real-time location of product on the line.

In the same breath, he was saying that he wanted the leads and the supervisor to be able to “walk the trapline” and do better seeing issues coming before a train wreck. (Empty positions, overproduction, etc.)

My response was “Having them update the magnets on that board every time something moves forces them to practice seeing what is where.”

In other words, by making them teach you where things are, and demonstrate their knowledge, they have to learn how to see that bigger picture.

“That’s the best explanation I have ever heard.”

The operations manager can walk the line and see the status himself. He doesn’t need the board. In fact, he could see even better if he went up the mezzanine overlooking the line. It’s all there.

But the board isn’t for his benefit. It is a learning tool. It is structure for the leads and supervisors to have a joint conversation, facing the board instead of each other, and reach agreement about what is where.

It gives them a clear indication if they need to escalate a problem, and a way to be able to converse about when and how they might recover (or not).

In other words, it is “Grasp the Current Condition” continuously, in real time. This lets them compare the current condition with the target condition – the standard depicted on the board.

By seeing gaps quickly, they have a better chance at seeing what obstacle or problem prevented them from operating to the target.

That, in turn, gives the manager an opportunity – in invitation – to shape the conversation into one about improvement.

Back to Job Instruction

This is exactly the same process structure as having the learner demonstrate performance. It is a check, right after the operation (present the operation) was performed to see how well it worked.

Fine Grained Observation

All of this is about moving observations, evaluations, checks, verifications away from batching them at the end of a huge block of work and embedding them into one-by-one flow. It builds Ohno’s “chalk circle” into the work itself.