Tag: People Development

Posted on

Blame vs. Accountability

Steve left a question on The Whiteboard that everyone thinks, but almost no one asks.

Is there a point at which the “blame game” is appropriate? You once mentioned the “5 who’s” I’m thinking that at some point this has to be processed. Like getting the right people on the bus (or off it). Or in cases of accountability.

This subject, of course, opens up an entire line of complex discussion. We are dealing with psychology and sociology here, not mechanical or industrial engineering.

The question is very general. And like most "big problems" I don’t think it is solvable at this level. Rather, the general problem is a symptom of small problems that are chronically not addressed. In simple terms, the answer is "it depends" and "it is a case-by-case issue."

My first frame of reference is the post just before this one – "No blame means no excuses." There are a couple of other related gems in Managing to Learn that I will be calling out in subsequent posts here.

But right now, I want to go back to 1944 and dig out the cheat pocket card that is part of the TWI Job Relations course.

At the top the card says

HOW TO HANDLE A PROBLEM

(In this context, it means a people problem.)

Right underneath that are the words everybody skips over:

DETERMINE OBJECTIVE

So let’s think about that a minute. Here is a person whose performance or behavior is something you find incompatible with the goals of the organization. But have you thought past your emotional response and really looked at, first, what the goals of the organization are in this context? If this problem is solved what outcome do you want?

Sometimes I hear "I want the person out of the organization."

OK. But that is a countermeasure, not an objective. What is the objective of the organization?

In the 1944 TWI context, it was generally to "help production." Certainly that was the main priority. But whatever your objective is, it is critical to understand it and I would suggest you write it down.

Then the card says:

STEP 1 – GET THE FACTS

In modern terms, this would translate to "Thoroughly understand the current situation." The odds are you have only second-hand information and complaints at this point. At best, you have only results of some underlying issue. The card says to "review the record" – what is the history here? Is this an ongoing issue that has a long history? Or is it a recent thing?

It says "Find out what rules and customs apply." Now – please remember that these words were written in a different era. One generation (half a generation) earlier, the USA had been a primarily agrarian economy with a growing manufacturing sector. Many manufacturing operations had more informal customs than actual rules. Many of those customs dictated the way people were expected to behave. Understanding, not just the rules, but the actual expectations of supervisors, peers, and the culture itself gives you the context that this person was working in.

In a world class organization, I would ask "What is the standard?" What is the expectation in this circumstance? What should be happening? If you are not crystal clear about that, then you have a case of vague expectations. Want to know the source of the problem? Look in the mirror.

The card goes on to advise:

"Talk with individuals concerned" and "Get opinions and feelings"

Go and see for yourself. Genchi genbutsu.

Do not rely on reports of others. That information is inherently biased.

If you start off with a couple of assumptions, your understanding can be much deeper.

  • This person is well meaning, and acting in his best understanding of what you expect.
  • This person is acting in a reasonable manner within the context he has around him.

These assumptions drive you to understand how expectations are interpreted, how priorities are understood, and the daily, working context of "normal" and "reasonable" within the work environment.

It is critical to understand this simple truth about all organizations: The written rules are over ridden by the daily working culture.

At the end, the card issues a caution:

"Be sure you have the whole story."

Once you understand the current situation, the next step on the card is:

STEP 2 – WEIGH AND DECIDE

"Fit the facts together"

"Consider their bearing on each other."

This is final reflection on the big picture and the context this person is operating in. What conflicts does he experience? How is he resolving them? Asking those questions in that way, again, frames the problem in terms of a person acting in a reasonable way to resolve conflicting priorities (work and personal) in the best way he can. If that priority conflict turns out to be a real or perceived difference between policies and expectations, that is your problem, not his.

Consider what message is sent by those two statements:"We never compromise safety for production." and "We need to do whatever it takes to get this done today."

Consider the actual consequences if all unsafe work in your operation halted. Now, in that light, consider the pressures this person might have been under when he got "written up" for a near-miss on a forktruck – as he was driving down a cluttered transportation aisle with a load that blocked his view that someone was impatiently calling him about.

The JR card goes on into executing your action plan, and then CHECK RESULTS.

The last question on it is:

DID YOU ACCOMPLISH YOUR OBJECTIVE

Did your countermeasure address the problem?

This was all pretty radical stuff in 1944. Unfortunately it is still pretty radical in a lot of places.

But – at the end of the game, it comes down to objectively considering what you are trying to accomplish; understanding the entire story; developing and applying countermeasures; and seeing if they work. Then lather, rinse, repeat.

As an adjunct to this, Jim left a comment after the book review of Managing to Learn where he reflected that a lot of his (lean manager) job seems to be psychology. He is right – but that is the job of any manager whose ultimate success is dependent on how well his people perform. Understanding what really motivates people vs. what you want to motivate them is a critical first step to deal with the world as it really is.

So, back to the original question.

Steve used an expression "getting the right people on the bus (or off it)." I first encountered this in Jim Collins‘ book Good to Great. He refers to a corporate transformation where it is important to have the right team, and have the players in the right positions. (The right people on the bus, and those people in the right seats). Before you decide to kick someone off the bus, it is critical to first understand if s/he is in the right seat; to understand if the past is the result of circumstances or true failure to perform. So unless (until) you are truly certain of what you expect, you are in no position to judge whether someone is, or is not, meeting expectations.

Here is how I look at it. If someone has to be let go, it is because I:

Failed to hire the right person.

Failed to make my expectations clear enough.

Failed to adequately assess or correct the reasons for not meeting those expectations.

And in the end, I had to concede that I had failed, not only this person, but my own objectives.

Are we going to get it right every time? Of course not. But "finally getting him out of here" should be reflected upon, not as a success, but as a desperate last resort when everything else has failed.

Caveat

No one has the resources to save people who are bent on destroying themselves or those around them.  Fortunately those people are actually few and far between. It is totally unfair (and not in your interest) to structure your operation as though anyone could be one of these people.

And finally, each of us is responsible for cutting our own path in the world. If I don’t like the results I am getting, I must acknowledge that those are results are the cumulative effect of every choice I have made up to this point. I may not get the results I want, but I get the results I have chosen.

Posted on

No Blame Requires No Excuses

This little gem is buried on page 54 of John Shook’s new book Managing to Learn, recently published by the Lean Enterprise Institute.

Although it is almost just a passing thought in the overall context, it really gets to the core of a people-supporting culture.

To me, the concept of “No blame requires no excuses” means that the organization has created a culture where excuses are not necessary.

Think about this: What is the purpose of an excuse but an attempt to shift blame from a person to something that person could not control.

So what would it take to remove the need to do this?

First of all, it requires an organizational culture where it is safe to accept responsibility. At that point, excuses are no longer required for survival. Then, and only then, can the team start to deal with the facts as they truly are, rather first working to spin them in a way that is acceptable.

Posted on

Managing To Learn (the book) – my first impressions

Managing to Learn bookManaging to Learn by John Shook is the latest in the classic series of books published by the Lean Enterprise Institute.

It is subtitled “Using the A3 management process to solve problems, gain agreement, mentor, and lead” and that pretty well sums it up.

Like many of the previous LEI books, it is built around a straightforward working example as a vehicle to demonstrate the basic principles. As such, it shares all of the strengths and shortcomings of its predecessors.

In my admittedly limited experience, I have seen a couple of companies try to embrace similar processes without real success. The main issue has been that the process quickly became “filling out a form.” Soon the form itself became (if you will pardon the term) a pro-forma exercise. Leadership did not directly engage in the process; and no one challenged a shortcut, jumping to a pet solution, or verified actual results (much less predicted them). Frankly, in these cases, it was either taught badly from the beginning, or (probably worse) the fad spread more quickly than the organization could learn how to do it well.

I must admit that with the recent flood of books and articles about the “A3” as the management and problem solving tool of lean, that we will see a macro- case of the same though throughout industry.

Managing to Learn tries to address this by devoting most of its emphasis on how the leader teaches by guiding and mentoring a team member through the problem solving process. The reader learns the process by following along with this experience, vs. just being told what to put in each block of the paper.

To illustrate this in action, the narrative is written in two tracks. One column describes the story from the problem solver’s viewpoint as he is guided through the process. He jumps to a conclusion, is pulled away from it, and gently but firmly directed through the process of truly understanding the situation; the underlying causes; developing possible countermeasures and implementing them.

Running parallel to that is another column which describes the thoughts of his teacher / manager.

Personally, found this difficult to follow and would prefer a linear narrative. I am perfectly fine with text that intersperses the thoughts and viewpoints of the characters with the shared actions. But given this alternative choice of format, I would have found it a lot easier to track if there had been clear synchronization points between the two story lines. I found myself flipping back and forth between pages, where sentences break from one page to the next in one column, but not the other, and it was difficult to tell at what point I was losing pace with the other column.

To be clear, Shook says in the introduction that the reader can read both at once (as I attempted to do), read one, then the other, or any other way that works. I tried, without personal success, to turn it into a linear narrative by reading a bit of one, then the other.

The presentation format not withstanding, Shook drives home a few crucially important points about this process.

  • It is not about filling out the form. It is a thought process. Trying to impose a structured form inevitably drives people’s focus toward filling out the form “correctly” rather than solving the problem with good thinking.
  • He emphasizes the leadership aspect of true problem solving. The leader / teacher may even have a good idea what the problem and solution are, but does not simply direct actions. Instead, the leader guides his team member through the process of discovering the situation for himself. This gets the problem solved, but also develops the people in the organization.

There are also a few real gems buried in the text – a few words, or a phrase in a paragraph on a page – that deserve to have attention called out to them. I am going to address those in separate posts over the next few days.

In the end this book can provide a glimpse of a future state for leadership in a true learning and problem solving culture. But if I were asked if the message is driven home in a way that passes the “sticky test” then I have to say, no. I wish it did, we need this kind of thinking throughout industry and the public and government sectors.

Thus, while this book is very worthwhile reading for the engaged practitioner to add to his insight and skill set, it is not a book I would give someone who was not otherwise enlightened and expect that he would have a major shift in his approach as a result of reading it.

The bottom line: If you are reading this in my site, you will probably find this book worthwhile, but don’t expect that having everyone read it will cause a change in the way your organization thinks and learns.

Posted on

Dealing With High Turnover

Jim left a great post on The Whiteboard way too long ago.

His problems seem to sum up to these statements:

Every valve is hand made one by one in batches through several processes.

…about a 10% turnover rate…Consequently we are always training new people…the supervisor needs to make sure the worker understands the job

My inclination is to somehow explain to the owners how their employee turnover rate is hurting their production and quality.

He titled his post  Hitting The Moving Train which seems appropriate on a number of levels.

Keeping in mind that I have not done my own "go and see" so I don’t have facts from the ground, only what is reported, a couple of immediate things come to mind. Other readers (especially the couple of dozen of you who never leave comments!), feel free to chime in here.

Short term: Stop the batching. Or, more specifically, flow the batches. The key point here is that just because you run batches doesn’t mean you can’t run one-piece-flow. (Pardon the double negative.)

What does that look like here? For each batch of valves, understand all of the assembly operations, set up an ad-hoc flow line that sequences all of the steps, then run them all through.

This does a couple of things, first and foremost, it gets them off the shop floor and shipped a hell of a lot quicker because now they are DONE. The downside is the supervisor needs to teach more than one person his particular sequence steps, but it eliminates all of the routing, traveler paperwork, tracking, prioritizing, and other stuff associated with having those 50 incomplete valves sitting out there. Scheduling becomes "Which jobs are we going to set up and assemble today?"

What about the parts? Don’t start assembling until you have all of the parts.

"Wait a minute, what about just-in-time?" One thing at a time. Let’s not launch a job until we have the capacity and capability of actually doing it for now.

Next, (Intermediate Term): is make the supervisor’s job a bit easier. I am assuming that, since he is training the workers, that he understands the tasks. But does he have formal training on how to break down work into steps and instruct in a way that someone remembers how to do it? Rather than reading a book about it, I would strongly suggest contacting the TWI Institute and getting, first, a handle on Job Instruction. This is, essentially, standard work on how to break down a job and teach someone to do it. The method has been taught unchanged since mid-1944. Not surprisingly, it is bread-and-butter at Toyota… and their material is pretty much verbatim from the 1944 material.. and it is the origin of standard work as we know it.

As jobs are broken down, the inherently critical tasks should emerge. These are the things which must be done a certain way or the thing just won’t go together (bad) or will go together, but won’t work (very, very bad). Those key points are where to start instituting mistake-proofing, successive checks, etc. This will start driving toward stomping out the quality issues.

For each quality issue that comes back to bite, take the time to really understand how it was even possible to make that mistake, and focus a problem solving effort on that key point to (1) incorporate it into the teaching and (2) mistake-proof and successive-check that particular attribute. Defects discovered in the plant are bad enough. Defects discovered by your customers are another story. Do what you must to keep the defects from escaping, then work on preventing them. Don’t cut out inspection just because it is muda.. unless you are 110% certain that your process is totally robust, and any problem that does occur will be caught and corrected immediately. Anyone who thinks Toyota "doesn’t do inspection" has never seen the last 60 or so positions on their assembly line… nor have they seen the checks that are continuously being made during assembly.

And finally – the turnover issue. A couple of things come to mind. First, with the right attitude and approach, the things described above can make this a lot more interesting place to work… especially if the Team Members are involved in finding the solutions to escaping quality issues, etc.

The same goes if supervisors continue to hone their leadership skills. Employee turnover is typically caused as much by the relationship with the first line supervisor and working conditions in general as it is by wages, etc. Southwest Airlines would not exist were that not true. Neither would a couple of other companies I can think of. Go look at "The 100 Best Places to Work" and see that relatively few of them cite "the highest pay and best benefits in the area." This isn’t to say that they do not offer fair, competitive compensation. But compensation, in general, is a relatively poor indicator of job satisfaction. Far more important is a daily demonstration that someone cares and is committed to the Team Member’s success.

If they really like TWI Job Instruction, they might be attracted to Job Relations – standard work for supervisors (first line leaders) for people issues. The TWI Institute has also just launched a new program called Job Safety. This isn’t one of the original TWI classes, but it was put together by experts I know and trust, and from what I have read, it follows the same reliable method format.

With all of that, perhaps the owners will be convinced that a competitive compensation program is a way to say "Thank you" to a great team that busts their butts to keep the customers happy.

Posted on

Who’s Your Coach?

In a few weeks, the best athletes in the world will assemble in Beijing for the 2008 Summer Olympics. Just being there means these individuals are performing at a level that the rest of us can only watch and appreciate.

Each of these world-class top performers has a coach.

Ironically, their coaches are not capable of performing at the same level as the athletes themselves. If they could, they would be competing, not coaching.

To be sure, some of the coaches are former world-class athletes. But most of them are “just” world class coaches. They have the skill to watch the athlete perform, to compare what they observe against a standard of perfection and to see very subtle things which might make a difference in the athlete’s performance.

World class athletes all know they only perform at a world class level because they have world class coaches. It is the coach who takes them from “very good” to “Olympic contender.”

A coaches credibility is based on his ability to observe and teach. His success is built on the success of the people he coaches.

For business leaders:
Do you believe you can perform at a world-class level on your own?
Is your insight into your own performance good enough to pick up nuance and detail that could make a huge difference?
Do you believe that, because you have more experience, that no one below your level could teach you anything?
Do you believe that, because you have been successful, only someone who has had more personal success could teach you anything?
Do you measure “competence” by hierarchy level?

Who is your coach?

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.