Posts

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.

Posted on

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.

Posted on

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.

Posted on

If You Aren’t Being Heard, Then Listen

I was sitting in on a conversation between a Continuous Improvement Manager and the Operations Manager the other day.

The Operations Manager was asking for help developing good leader standard work.

The C.I. manager was responding that she had already developed it for the Value Stream Manager, the Supervisor.

The Operations Manager said he thought right now, they needed to focus on the Team Leads, the first line of leadership.

The C.I. manager reiterated that she had already prepared standard work for the Value Stream Manager and the Supervisor.

The Operations Manager reiterated that he wanted, right now, to focus on the Team Leads.

This went back and forth three or four times, and the Operations Manager moved on to something else.

The C.I. Manager seemed frustrated and even a little angry.

My Working Hypothesis

The C.I. manager was frustrated because the work she had already done had not been implemented or acknowledged.

The Operations Manager was frustrated because his immediate need was not being acknowledged.

So they were each reiterating, again, what they had said before, neither of them acknowledging what the other was trying to say.

Being Heard as a Change Agent

When you say something, and the other person responds by reiterating what they have already said, this is a Big Red Flag for you. They are not going to hear anything you say until they feel you have heard them.

The cool part is that either of these parties can break the cycle of repetition by shifting into listening mode. I am going to take this from the perspective of the C.I. Manager / change agent since most of you reading this are more likely to be in that position.

Book cover: Never Split the DifferenceThere are lots of classes and materials out there about “active listening” but I really like a simple techniques that Chris Voss shares in his awesome book Never Split the Difference.*

At least they seem simple. But they require a lot of deliberate practice to master as they require breaking long standing unconscious habits. At least I know I’m still working on it.

The Goal: Hear “That’s Right”

The first step to listening is to listen!

Is the other person simply reiterating what they have said before in response to your message? Are you even aware of that? (or are you waiting them to stop talking so you can reiterate your message?) Take responsibility for breaking the cycle. Pay attention to their body language. Try to read how they are feeling right now.

Then test your hypothesis.

Instead of reiterating your message, repeat theirs back to them. Even better if you acknowledge the emotions behind their message.

“It sounds like you are really concerned that the leads don’t know what to do.”

Critical: In the words of Chris Voss, this requires that “late night FM DJ voice.”

NO sarcasm. NO implied judgement. You must come from a position of being curious about what they are trying to communicate, and what they are feeling.

You are trying to learn. You are not trying to make them wrong. You are not trying to make a point. You are not trying to be right.

If you are trying to do any of those things, you are not listening. You are, instead, trying to collect ammunition for your next salvo.

You will get one of two responses:

  • The other person will correct you.
  • The other person will give you some version of “Yeah, that’s right.” Those are the magic words you are trying to hear.

Let’s parse that sentence.

“It sounds like…”  (or “It seems like…”). You are not telling them what they are saying. You are telling them what you are hearing and sensing.

This invites correction. “No, that’s not it.” or “No, that’s not what I’m saying.”

They may be frustrated. That is why you must remain the calming influence.

(By the way – this is MUCH easier if you don’t have a stake in the conversation, and the process of being listened to really helps the other person clarify their own position. That is a good place to practice before you are in a high-stakes situation.)

“… you are really concerned…”

Acknowledge how you sense they are feeling. Again, this is inviting correction, clarification or agreement. In either case, you are getting more information.

“… that the leads don’t know what to do.”

This part of the sentence communicates your understanding of what you think is causing the emotion in the other person. Again, this is just an acknowledgment. It doesn’t mean that you agree that this issue should trigger this emotion, you are just acknowledging that it does.

If you don’t get “that’s right” then it is time to humbly and sincerely ask for correction. You have to do so in a way that makes it clear you really care about understanding. (“Seek first to understand.”)

Ideally the other person will attempt to clarify what they are trying to say. Cycle through this until they agree that what you are saying back is what they are trying to convey to you.

Trap: “You’re Right”

Voss points out a trap in this process: The critical difference between “that’s right” and “you’re right.”

First, if you hear “you’re right” that is an indication that the other person perceives you are trying to make your case vs. hearing them. Were you adding to the information? Were you passing judgement?

Next – In this context, “You’re right” often translates as “I’m tired of trying to talk about this.” There isn’t agreement yet. “You’re right” is about you. “That’s right” is about what you were saying. Very different things.

Which leads us to:

Don’t let “being right” about something get in the way of getting what you want or need.

The C.I. manager was right that she had prepared leader standard work for the value stream manager and the supervisor. And she was right that it hadn’t been acted upon.

But by sticking to her guns about that, the Operations Manager was left with the impression that she was refusing to help develop standard work for the team leaders, so he gave up on the conversation.

Here is what happens. Her frustration comes through. His brain (all of our brains) contains “mirror neurons” that invoke in him the emotions he is seeing across the table, which elevates his frustration without him even knowing it.

This is why that calming demeanor is so critical. If the other person picks up sarcasm, negativity, dismissiveness in your voice or body language, that will be reflected right back at you, and amplify everything the wrong way.

After (AFTER!!) getting an acknowledgment that he felt the main priority right now was the Team Leads, the C.I. manager might have created an opening –

State your facts: “I worked really hard on standard work for the value stream leader and supervisor.”

Own your own feelings: “I am feeling frustrated that none of that work was acted upon.” (Avoid victim language like “that makes me feel” or “you make me feel” statements.)

State what you need right now: “I’ll work on the standard work for the leads, but I would like to review the work I have already done and what happened with it so I can avoid the same situation with the leads. Can we do that?”

Finally…

There is no guarantee this works every time. But it works more often than escalating the emotion which probably never works.

_________________

*Why am I touting a book about negotiating? Because change agents must be able to reach agreements with others. And negotiating is a process of agreement creation. Chris Voss is a former FBI hostage negotiator. His job was to create agreements with terrorists, kidnappers, bank robbers. If his techniques work there, they probably work for a change agent in a company.