Category: Culture

Posted on

Reflections and Lessons From 1997

MONDAY: 2 PERS 1 MACHINE. TODAY: 1 PERSON 2 MACHINES

On a Thursday afternoon in the summer of 1997 I sent that pager message (remember pagers?) to Rick from the factory where I had spent a week working with Mr. Shimura of Shingijutsu and Reiko, his interpreter.

I knew that Rick would be wrapping up a class teaching the basics of kaizen events to a group of suppliers and if I were lucky, he would see the pager message and use it as a reinforcement to the participants. Rick and I usually alternated teaching that class, sometimes we taught it together. We were good work partners, finishing each others’ sentences and the mutual respect was very high.

I was on-site at another supplier. We were there to help them take some first steps toward “lean production.” Our goal, at least the idea, was that we would work through the process of making significant improvements with the thought that they would learn enough to try it themselves.

This was not my first visit – the episode with Mr. Iwata that I relate in my third post to this blog had happened there a couple of months earlier, and that visit had resulted in my company offering up Mr. Shimura’s time on our dime.

This may well have been “an offer they couldn’t refuse” and I’m not sure everyone there saw it as help. We were from their 800 pound gorilla customer, they had trouble making on-time deliveries, and sometimes that isn’t the kind of help that you want. From their perspective their biggest customer had people who knew their way around a factory spending days on their shop floor and, most certainly, ascertaining how much more productivity was possible if only, well, the buyers squeezed them hard enough. It didn’t really work that way, but it had worked that way in the past, so who could blame the suppliers for thinking this was a more sophisticated way to audit them?

Anyway, we had worked through the week to carefully look at the tasks involved to unload, load, and machine a single part on a large linear milling machine. Mr. Shimura was there asking questions, not so much from curiosity but to direct my eyes. I’m sure he already knew the answers. As we dug into the timing, it became clear that there was enough operator waiting time as the part was being milled that a single operator could, theoretically, unload and load an adjacent machine – operating two of them at once.

So we carefully worked out the chorography required to make it work, and on Thursday mid-day it all came together. The work was flowing, the parts were flowing. It was really a thing of beauty.

Friday morning we would report out the week to management, and Friday afternoon I would head to the airport to go home to Seattle.

But I had some worries as well. Although the company President, and the VP of Operations were supportive, their support was along the lines of welcoming everyone into the plant, making it clear they were happy to see us, attending the final report-out and endorsing our efforts.

I was still pretty knew at this. I was making the transition from teaching classes and running simulations to making real change in real factories (that weren’t mine!). I was really fortunate to have a lot of 1:1 time with Mr. Shimura and Reiko. I asked questions, he patiently taught me how to use the standard work combination sheet, and other nuances of kaizen and flow production. I got a lot more out of that week than the supplier did simply because I was there spending time with Mr. Shimura and taking advantage of every second I could. I had 1:1 time because none of the supplier’s managers were seeking him out to learn from his vast experience.

Some quotes I will never forget: “If I see something is hand written, then I know at least one person has read it.”

“If parts that are in tolerance don’t fit, it is a problem with the tolerances.”

(Walking through the shop) “Does this company lose a lot of money?” Reply: “No, they are very profitable.” “Then their prices are too high.”

In the end, though, I am equally certain that come Monday morning the work sequence we had so carefully worked out – at great expense to my company for my time, my travel, Mr. Shimura, his interpreter, and others – was never repeated again.

Why not?

Well, we can all blame “management commitment” because that is really easy to do. But I put equal weight on our paradigm of improvement at the time. The idea that, in 4 working days we could institute a change that flew straight against the operational and cultural norms of the company and expect it to last any longer than until we were out the door was, well, ludicrous.

Why should we expect anything different?

It is ludicrous in any company, whether this work is being brought in from outside or internally generated.

The people who have to manage the daily work, whether they were involved in this exercise or not, have no paradigm for dealing with the myriad of issues that are bound to be surfaced after we pulled all of the buffers out of the material and the time. Yes, it can work, IF we understand the conditions required for success, and IF we pick up right away when those conditions aren’t there and IF we respond to fix it very fast. Then, yes, it can work.

It will be more time and trouble than it was before, though, unless the next things are also done.

For at least some of those issues – maybe not all of them, but always working against a couple of them – seeking out why those issues happened and dealing with the causes.

Just to keep this tiny two-machine “work cell” operating in this large factory would have eventually engaged every support system they had.

That’s the whole point, actually, of a model line. It isn’t building the model line. It is what you have to fix in your systems to keep it going.

Many years later I spent a week on another company’s shop floor with their internal kaizen team and getting an andon / escalation process up and running was the only thing we were working on that week. That process is just as important, if not more, than the baseline work of flow. Because without it, your flow will fall apart.

This is the part of the process that engages people. Putting in the baseline process is the easy part. Fielding the problems that flow surfaces – that takes changing the day-to-day routine in the workplace, and is a lot harder. That is where the culture change comes into play. Actually it is more than engaging people. It engages specific people: This is the part that must engage the leaders. They must lead, guide and coach process of working through all of the issues so stability can be reestablished. Then challenge the team to get to the next level.

But all of that is what I know now. I had the knowledge back then, but not the deep understanding.

So – I am thankful for that week because my understanding of what I had been teaching for months easily doubled… twice in those few days.

I was back there a few more times, they even gave me a badge (which I still have somewhere) so I could let myself in. One time I spent two straight weeks there. They were good people.

But we were applying work to the technical systems, and never really dealing with their default responses to problems, their culture, the way they went managing their daily work.

I know so much more today it is actually humbling to write this. And I still have a lot to learn. We all do.

The company I was working in? They were sold, and sold again. I think they are still in business, but I wouldn’t know anyone there.

Posted on

A Lean Leadership Pocket Card

I was going through some old files and came across a pocket card we handed out back in 2003 or so. It was used in conjunction with our “how to walk the gemba” coaching sessions that we did with the lean staff, and then taught them to do with leaders.

There is a pretty long backstory, some of it is summarized in Earl’s recollection on this old post: Genchi Genbutsu in a Warehouse as well as here: The Chalk Circle – Continued.

A lot has happened, a lot has been learned since then. Toyota Kata has been published, and that alone has focused my technique considerably (to say the least).

Nevertheless, I think the elements on these little cards are valuable things to keep in mind.

With that being said, a caveat: Lists like this run the risk of becoming dogma. They aren’t. There are lots of lists like this out there, and the vast majority are very good. The key here is something that a leader or team member can refer to as a reminder that may bias a decision in the right direction. It is the direction that matters, not the reminders.

Fundamentals

The fundamentals are based on the “Rules-in-Use” from Decoding the DNA of the Toyota Production System, a landmark HBR article by Steve Spear and H. Kent Bowen. The article, in turn, summarizes (and slightly updates) Spear’s findings from his PhD work studying Toyota.

A. All work highly specified as to content, sequence, timing, and outcome.

B. Every customer-supplier connection is simple and direct.

C. The path for every product is simple and direct.

D. All improvements are made using PDCA process.

What we left off, though, is that in each of those rules there is a second one: That all of these systems are set up to be “self diagnostic” – meaning there are clear indications that immediately alert the front line people if:

  • The work deviates from what was specified.
  • The connection between a customer and supplying process is anything other than specified.
  • The path a product follows deviates from the route specified.
  • Improvements are made outside of a rigorous PDCA (experimental) process.

In other words, the purpose of the rules is to be able to see when we break them, or cannot follow them, so we trigger action.

To put this into Toyota Kata-speak – every process is set up as a target condition that is being run as an experiment – even the process of improvement itself!

Every time there is a disruption – something that keeps the process from running the way it is supposed to – we have discovered an obstacle. That obstacle must first be contained to protect the team members and community (safety) and to protect the customer (quality). Then goes into the obstacle parking lot, and addressed in turn.

If you think about it, the Improvement Kata simply gives us much more rigor to (D).

This ties to the next sections.

Key Leadership Behaviors

Note that this is behaviors. These are things we want leaders to actually strive to do themselves, not just “support.” It was the job of the continuous improvement people to nudge, coach, assist the leaders to move in these directions. It was our job to teach our continuous improvement people how to do that coaching and assisting – beyond just running kaizen events that implement tools.

A. PDCA Thinking

Today we would use Toyota Kata to teach this. But the same structure drove our questioning back then.

B. Four Rules:

1. Safety First

Even though this should be obvious, it is much more common that people are tacitly, or even directly, asked to overlook safety issues for the sake of production. I remember walking through a facility with a group of managers on the way to the area we were going to see. Paul stopped dead in his tracks in front of a puddle on the floor. He was demonstrating just how easy it was for the leadership to walk right past things that should be attended to. And in doing so, they were sending the message – loud and clear in their silence – that having a puddle on the floor was OK.

2. Make a Rule, Keep a Rule

This is a more general instance of Rule #1. But the it is more subtle than it may seem on the surface. Most people immediately interpret this as enforcing organizational discipline, but in reality it is about managerial discipline.

Nearly every organization has a gap between “the rules” and how things really are day-to-day. Sometimes that gap is small. Sometimes it is huge.

Often “rules” are enforced arbitrarily, such as only cases where a violation led to a bigger problem of some kind. Here’s an example: Say your plant has a set of rules about how fork trucks are to be operated – speed limits, staying out of marked pedestrian lanes, etc. But in general the operators hurry, cut a corner now and then. And these violations are typically overlooked… until there is some kind of incident. Then the operator gets written up for “breaking the rules” that everyone breaks every day – and management tacitly encourages people to break every day by focusing on results rather than process.

When we say “make a rule / keep a rule” what we mean is if you aren’t willing to insist on a rule being followed consistently, then take the rule off the books. And if you are uncomfortable taking the rule off the books, then your only option is to develop something that you can stand behind. It might be simple mistake proofing, like physical barriers between forklift aisles and pedestrian aisles. But if you are going to make the rule, then find a way to keep the rule.

Do you have “standard work” documents that are rarely followed? Stop pretending you have standards or rules about how the work is done. Throw them away if you aren’t willing to train to them, mistake proof to them and reinforce following them.

3. Simple is Best

Simply, bias heavily toward the simplest solution that works. The fewest, simplest procedures. The simplest process flow. Complexity hides problems. “Telling people” by the way, is usually less simple than a physical change to the work environment that guides behavior. See above.

4. Small Steps

Again, Toyota Kata’s teaching covers this pretty well today. The key is that by taking small steps, verifying that they work, and anchoring them into practice before taking the next ensures that each step we take has a stable foundation under it.

The alternative would be to make many changes at once in the name of going faster.

We emphasized here that “small steps” does not equal “slow steps.” It is possible to take small steps quickly, and we found that in general doing so was faster than making big leaps. Getting big changes dialed in often required backing out and implementing one thing at a time anyway – just to troubleshoot! See “Gall’s Law” which states:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

John Gall, author of Systematics

and sums this up nicely.

C. Ask “Why, what, where, when, who, and how” in that order.

Here we borrowed the sequence from TWI Job Methods. The first two questions challenge whether a process step is even necessary: Why is it necessary? What is its purpose? To paraphrase Elon Musk, the greatest waste of time is improving something that shouldn’t even exist.

Then: Where is the best place? and When is the best time? These questions might nudge thinking about combining steps and further simplifying the process.

And finally we can ask Who is the best person? and “How” is the best method? The key point here is until we have the minimum possible steps in the simplest possible sequence, and understand the cycle times, it doesn’t make sense balance the work cycle or work on improving things.

Come to think about it – perhaps we should ask “How?” before we ask “Who” since improving the method will change the cycle times and may well inform out decisions about the work balance. Hmmm… I’ll have to think about that. Any thoughts from the TWI gurus?

D. Ask Why 5 Times

Honestly, this was a legacy of the times. Unfortunately it suggests that you can arrive at a root cause simply by repeatedly asking “Why?” and writing down the excuses answers that are generated. In reality problem solving involves multiple possible causes at each level, and each must be investigated. I talked about this in a post way back in 2008: Not Just Asking Why – Five Investigations.

E. Go and see.

Go and see for yourself. Taking this into today’s practice, I think it is something that the Toyota Kata community might emphasize a little more. We tend to ask the question “When can we go and see what we have learned…?” but all too often the answer to “What have you learned?” is a discussion at the board rather than actually going and observing. Hopefully the board is close to where the improvement work is being done. Key point for coaches: If the learner can’t show you and explain until you understand, it is likely the learner’s understanding could be deeper.

As You Walk The Workplace:

Check:

perhaps we should have said “Ask…” rather than “Check” but asking and observing are ways to “check.” All of the below are things that the leader walking the workplace must verify by testing the knowledge of the people doing the work.

A. How should the work be done? Content, Sequence, Timing, Outcome

This is another nod to the research of Steven Spear. The key point here is that before you can ask any of the following questions, you have to have a crisp and precise of what “good” looks like. In this paradigm, all processes are target conditions. And as the work is being done, we are actively searching for obstacles so we can work to make the work smoother and more consistent.

In other words, “What should be happening?” and “How do you know?”

Do the people doing the work understand the standard process as it should be done?

A few months ago I went into some depth on this here: Troubleshooting by Defining Standards. That probably isn’t the best title in retrospect, but there are too many links out there that I don’t want to break by changing it.

B. How do you know it is being done correctly?

Today I ask this question differently. I ask some version of “What is actually happening?” followed by “How can you tell?” We want to know if the people doing the work have a way to compare what they are actually doing against the standard.

C. How do you know the outcome is free of defects?

So, question B asks about consistency of the process, and question C asks about the outcome. Does the team member have a way to positively verify that the outcome is defect-free?

D. What do you do if you have a problem?

Again, we are checking if there is a defined process for escalating a problem. And we define “problem” as any deviation from the standard, or any ambiguity in what should be (or is) happening. We want someone to know, and act, on this, and the only way that is going to happen is to escalate the problem.

We want this process to be as rigorous and structured as the value-adding work.

And we want as much care put into designing production process as was put into designing the product itself. All too often great care and a lot of engineering time goes into product design, and only a casual pass is made at designing and testing the process.

Even better if these are done simultaneously where one informs the other.

For Abnormal Conditions:

ACT:

These are actions that the leader must take if she finds something that isn’t “as it should be” in the course of the CHECK questions above. Key Point: These are leadership actions. That doesn’t mean that the leaders personally carry them out, but the leaders are personally responsible for ensuring that these things are done – and checking again.

That is the only way I know of to prevent the process from continuing to erode.

A. Immediately follow up to restore the standard.

If it isn’t possible to get the intended standard into back place, then get a temporary countermeasure into place that ensures safety and quality.

B. Determine the cause of erosion.

We are talking about process erosion here, with the assumption that something knocked the process off its designed standard. Some obstacle has been discovered, we have to better understand what it is – at least enough to get it documented.

C. Develop and apply countermeasure.

Here we may have to run experiments against this newly discovered obstacle and figure out how to make the process more robust.

That is the end of the little card. But I want to point out that we didn’t just hand these out. You got one of these cards after time paired with a coach on the shop floor practicing answering and asking these questions. Only after you demonstrated the skill did you get the card – just as a reminder, not as a detailed reference. This exercise was inspired by a few of us who had experiences “in the chalk circle” especially with Japanese senseis who had been direct reports to Taiichi Ohno.

We piloted and developed this process on a very patient and willing senior executive – but that is another story for another day. (Thank you once again, Charlie. I learned more from you than you will probably ever realize.)

Posted on

More About Mistake-Proofing

After yesterday’s post about trucks crashing into the famous 11foot8 bridge and mistake proofing, I got the feeling I should drive home my key point that the problem isn’t with the driver, it is with the environment.

As of this writing,  Jürgen has recorded 154 crashes of overheight vehicles into the bridge.

And I’ll put even money that if all of the data were known, this process would pass any test for statistical control and we are getting what we should expect from a stable system. It might not be what we want, but it is what we should expect. (All images are copyright  Jürgen Henn, 11foot8.com)

So addressing the individual incidents probably isn’t a solution. In any case, it is unlikely that any driver will repeat the mistake.* For the TWI folks – this isn’t really a Job Relations type of problem. It might feel like it is, but it isn’t.

In the Factory

I was working with a company with a similar problem. Their inspectors kept missing defects. The response was often to say “I don’t see how she could have missed that!” and even write them up for failure to do something that wasn’t particularly well specified.

But the fact on the ground was, like the bridge, the misses weren’t confined to any particular individuals, any particular shift, any particular anything. People missed things all of the time because the expectations greatly exceeded the limitations of what humans can do for 12 hours (or even one hour). It isn’t an inspection problem. (The reliance on inspection vs. upstream controls is another topic for another day.)

People Work Within a System

It is all too easy to fall into the “bad apple” fallacy and seek out someone who was negligent. It feels good, like we did something about the problem. But the problem will happen again, with someone else. Then I hear frustrated managers start to make disparaging comments about their entire workforce that “doesn’t care” about quality.

I challenged a quality manager to do that inspection job for two hours – not even a complete shift – under the watchful eye of the inspector whose job he was trying to do. Funny – he was a lot slower to assign blame after that experience. He couldn’t keep up.

Deming was pretty clear about the ineffectiveness of exhortation as a way to get better performance. “Be more careful!” might well work for one individual for a short time. “Making an example of someone” might well work for a group for a short time. But there are norms, and the system will return to those norms very quickly. There are simple limits to what humans can focus on and for how long.

The Bridge is a Metaphor

To be clear, the bridge represents a working system, but it is different than what we would find in a company. This is public infrastructure, and the truck drivers that get featured on the videos are not part of a single organization.

This means that you have more control than the city engineers in Durham do. You can establish procedures, ask questions, train people, have them practice, alert them to the Gregson Street Bridge on their route. You can make sure your navigation system routes your trucks around the low bridges. You can support your people so they are less likely to even end up in the situation. All of these are system changes – and that is what it will take to change the outcome.

Change the System: Raising the Bridge

In late 2019 the city of Durham, in coordination with the railroad who owns the bridge, did actually raise the bridge by 8 inches. It is now 11 feet 16 inches (3.76m).

And that is a legitimate approach. Rather than trying to create infallible humans, what can we do to make the system less vulnerable to fallible humans.

While that likely reduced the number of trucks that hit the bridge…

*Caveat: There is one video where a truck seems to avoid the bridge, then circle back around and hit it. And another video where a truck that hit this bridge then proceeded to run into another low bridge with the damaged truck.

Posted on

Meta-Patterns: Thoughts for Discussion

I’ll be sending out the Zoom meeting link this (Wednesday) afternoon (May 6, 2020) for the Thursday (11 am Pacific) open discussion on the Meta-Patterns of Innovation.

1901 Wright Glider
Wright Brothers’ Experiments with the 1901 Glider

For those who only got email on the original post, this is a direct link to the video I was referencing: https://videopress.com/v/geNgzN4e

There are still lots of spots for anyone who is interested. Click Here to open the Contact Page, and let me know your email address and I’ll add you to the list.

Hugh asked a really good question in his email that relates to how to put these concepts (that are somewhat abstract and philosophical) into practical application in an organization.

I think that is a really good starting off point for a discussion, especially among change agents.

Posted on

KataCon4 Keynote: The Meta-Patterns of Innovation

Yes – the title isn’t a typo. This goes back to KataCon 4 in Atlanta. Though I had attended all of them, this was the first time I actually spoke at one. My task was to follow Rich Sheridan and share why I thought his message was a powerful one for an audience of Kata Geeks even if he wasn’t specifically talking about Toyota Kata in his company.

As an experiment, I took the sound recording from my talk and synchronized it with the slide deck. (That is harder that it sounds, by the way.) As another experiment I am sharing it via hosting on WordPress (the back-end of this site) rather than YouTube or a similar host. It is a little over 13 minutes long, and there is another experiment below it.

Posted on

Simon Sinek – Remote Teaming Tips

How Remote Teams Can Connect Meaningfully – Simon Sinek – March 20, 2020

We are all being pushed into the zone beyond our knowledge base right now – having to rapidly adapt and adjust to different ways of working together.

This morning Craig Stritar forwarded a cool little video to me from Simon Sinek’s YouTube channel. In it Steve Shedletzky, a member of Simon’s team, introduces their weekly huddle – a way that this team, which has been working remotely for years, maintains their connection to one another.

One of the keys here is that this meeting is not a conversation about the business at hand. There are other meetings for that. This one is intended to strengthen the social bonds of the group.

They dedicate 75 minutes a week to this task. The video is a condensed version to give us a taste of their structure.

And it is structure that makes it work. It is structure that makes sure no individual dominates the conversation, and structure that keeps it from becoming the kind of wide-ranging conversation that happens over beer and pizza.

It is structure that gives them the freedom to hear and be heard.

With that – here is the video.

For those who can’t see the embedded video, here is the YouTube link: https://youtu.be/tKEtm3HCrsw

Posted on

Ghost Victories – an excerpt from Upstream by Dan Heath

Amazon affiliate link to book listing for Upstream by Dan Heath
The link to the image takes you to the Amazon listing for the book. If you happen to order it, I get a small kickback, no cost to you, Just FYI.

Dan Heath has just published a new book, Upstream: The Quest to Solve Problems Before They Happen.

I just got the book, and am reading it now. I think there is going to be a lot of good material to discuss here.

But this post is about a marketing email with an excerpt really resonated with me, and I want to discuss that. I wrote to Dan Heath, and got his permission to use pieces of the excerpt here. (Thank you, Dan)

Management By Measurement = “Ghost Victories”

I have talked about what I call “management by measurement” in the past. In that post I told a true story of a company that placed very heavy emphasis on reducing inventory levels without digging into how that performance was achieved. The net result was a an embarrassed CEO during a quarterly analyst’s call. Not good.

Dan Heath talks about the same thing in Upstream. He calls it “ghost victories.”

[when] there is a separation between (a) the way we’re measuring success and (b) the actual results we want to see in the world, we run the risk of a “ghost victory”: a superficial success that cloaks failure.

The most destructive form of ghost victory is when your measures become the mission. Because, in those situations, it’s possible to ace your measures while undermining your mission.

He goes on to describe a case in the U.K. where the Department of Health established penalties for wait times longer than four hours in the Emergency Departments. And it worked. Wait times were reduced – at least on paper. Then the facts began to emerge:

 In some hospitals, patients had been left in ambulances parked outside the hospital—up until the point when the staffers believed they could be seen within the prescribed four-hour window. Then they wheeled the patients inside.

In the old post I referenced above, I said:

If making the numbers (or the sky) look good is all that matters, the numbers will look good. As my friend Skip puts it so well, this can be done in one of three ways:

  • Distort the numbers.
  • Distort the process.
  • Change the process (to deliver better results).

The third option is a lot harder than the other two. But it is the only one that works in the long haul.

All of this ties very well to Billy Taylor’s keynote at KataCon6 where he talked about the difference between “Key Activities” and “Key Indicators.” It is only when we can get down to the observable actions and understand the cause-and-effect relationship between those actions and the needle we are trying to move that we will have any effect.

To avoid the “Ghost Victory” trap, Dan recommends “pre-gaming” your metrics and thinking of all of the ways it would be possible to hit the numbers while simultaneously damaging the organization. In other words, get ahead of the problem and solve it before it happens.

He proposes three tests which force us to apply different assumptions to our thinking.

The lazy bureaucrat test

Imagine the easiest possible way to hit the numbers – with the least amount of change to the status quo. The story I cited above about inventory levels is a great example.

I can make my defect rates improve by altering the definition of “defect.”

There are lots of accounting games that can be played.

This is one to borrow from Skip’s list – How can the underlying numbers be distorted to make this one look good when it really isn’t?

The “rising tides” test

What external factors would have a significant impact on this metric? For example, I was working at a large company where a significant part of their product cost was a commodity raw material. As the market price went down, “costs” went down, and bonuses all around. But when the market price went up, “costs” went up and careers were threatened and bad reviews issued.

Those shifts in commodity prices had nothing to do with how those managers were doing their jobs, the tide rose and fell, and their fortunes with it.

The question in my mind is “What things would make this number look good, or bad, without any effort or change in the process we are trying to measure?”

The defiling-the-mission test

Hmmm. This is a tough one. (not really)

And it is a really common problem in our world of quarterly and annual expectations. In what ways could meeting these numbers in the short term ultimately hurt our reputation, our business, in the long term?

For example, I can think of an ongoing story of a product development project that hit its cost and schedule milestones (what was being measured). But they did so at the cost of destroying their reputation with customers, their Federal regulators and the public (and, to a large extent, their employees). They now have a new CEO, but the deeper problem has origins in the late 1990s.

How long will it take them to recover? That story is still playing out.

In another case I was in a meeting with a team that was discussing a customer complaint. The ultimate cause was a decision to substitute a cheaper material to reduce production costs. But this is a premium brand. There was a great question asked there: “Which of our values did we violate here?” – so the introspection was awesome.

Next step? Ask that question before the decision is made: “Is this decision consistent with our values?” If that makes you uncomfortable, then time to look in the mirror.

Then there is this little incident from 2010:

Picture of burning Deepwater Horizon oil platform
BP Deepwater Horizon fire – Photo by USCG

The metric was cost and schedule. Which makes sense. But the behavior that was driven was cutting corners on safety.

Getting Ahead of Problems

The book’s subtitle says it is about getting ahead of problems. I am looking forward to reading it and writing something more comprehensive.

Posted on

KataCon 2020: Billy Taylor on Leadership

Photo by Michele Bucher / Lean Frontiers

Continuing my breakdown of Billy Taylor’s opening keynote at KataCon…

Key Bullet Points

  • People follow what you do before they follow what you say.
  • If you (as a leader) think you are above the process…
  • Deliberate practice on your practice of leadership. Focus on one thing.
  • Break down your leadership style [into elements]. Practice deliberately on one thing you want to reinforce or improve.

That second bullet is a real challenge for those of us who are in leadership positions (or even positions of influence). “If you think you are above the process…” – do you follow the standards and expectations you ask of others?

I think a good test would be “If a production worker corrected you, how would you respond?” If your internal emotional response (that initial feeling you have, not how you show yourself) is anything other than “Thank you for reminding me” then you are exempting yourself from the rules.

The other take-away:

Throughout his presentation, Billy was tying together the idea of “deliberate practice” and “developing leadership skills.” Leadership is a process, and processes can be broken down into their constituent elements and practiced.

This ties back perfectly to a broad spectrum of leadership development models. In the end, what we can control are:

  • What we say.
  • How we say it.
  • Who we say it to.
  • The structure of the environment that either inhibits or encourages the behaviors we want.

All of these things can be developed through experimentation, and then practiced. This is what Toyota Kata is about.

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