Tag: Respect

Posted on

Visual Key Points

(Apologies for this post being “Password Protected” – I posted it from my smart phone, and obviously need to mistake-proof  something in the interface.) – MR

A key element of TWI Job Instruction is breaking down the job into important steps, key points, and reasons why.

An important step advances the work.
A key point is a critical aspect of the work that would:

  • injure the worker (or anyone else).
  • make or break the job.
  • make the job easier to do (a knack or technique that an experienced operator knows).

If it is worth making a key point over, it is worth putting a visual cue in the workplace.

If the key point is about something that would injure the worker, or make or break the job, you have a rich opportunity for mistake proofing.

In other words, a key point is something you are asking the team member to remember.

Help him out by reminding him or even better, engineering the work so that he doesn’t have to remember.

Posted on

Struggling to Learn

One of the challenges of teaching and consulting is resisting the temptation to give people the answers. Honestly, I like giving people the answers. It feels genuinely helpful, and it provides a nice ego boost.

But according to this article on Time’s “Time Ideas” site by Anne Murphy Paul titled “Why Floundering is Good,” that isn’t the best way to teach.

In fact, it can hinder learning.

The key point is summarized at the end:

… we need to “design [teaching] for productive failure” by building it into the learning process. Kapur has identified three conditions that promote this kind of beneficial struggle. First, choose problems to work on that “challenge but do not frustrate.” Second, provide learners with opportunities to explain and elaborate on what they’re doing. Third, give learners the chance to compare and contrast good and bad solutions to the problems.

Right now we are (hopefully) in the midst of a paradigm shift in how lean practitioners and teachers go about what we do.

Traditionally, a lot of us have simply given people the answers, or at least strong suggestions. Given the time constraints and overly ambitious targets of a typical 5 day event, that is understandable.

But now we are starting to see these events as skill building, which means learning, which means the teams need time to muddle through.

I have been structuring my approach quite differently for about a year now. I’ll be the first to admit that I, too, am figuring it out, reinforcing what works well, altering what needs to work better. These days I am far more comfortable letting things move through this struggle in order to set up deeper understanding once the light does come on.

The trick is to let them fail small, and not let them fail big. The problem has to have a solution that is within reach, or they will only come away frustrated.

Thus, teaching is becoming a matter of judging the knowledge and skill threshold and making sure they don’t take on too much at once. That is part of respect for people.

One problem at a time. Single factor experiments.

A great deal of the power in the “Coaching Kata” is turning out to be the question “Which *one* [obstacle] are you addressing now?” as it rules out working on everything at once.

Posted on

Decisions, Decisions

How many “If-Then” steps do your team members have to deal with in the course of their routine work?

Every one of those branch points is a decision. It is a point where the team member must memorize decision criteria and the correct choice(s).

Each “If-Then” in the process flow potentially doubles the number of possible paths the process can take.

Each decision is an opportunity to make a mistake.

The more complex a process, the more time and experience the team member requires to master it.

Mental bandwidth is limited.

The more attention they must expend to do it right, the less they can devote to thinking about how it could be done better.

How complicated a world do you create for people trying to do the work?

The more “flexible” your human interface with the process, the more complicated it is for the person who has to use it.

Do they have to enter ad-hoc query criteria into computers to pull information they routinely need every day?

How many decision criteria are things that people “just know?”

How often does someone encounter a problem or new situation and get a verbal instruction from the supervisor on how to handle it? What happens then? Maybe a general announcement at the next team meeting, if you’re lucky?

Go down to your work area.

Watch how people interact with the routine work.

Each of those decision points is an opportunity to simplify your process flow and make life a little less stressful for all of you.