Is Your Technical Person a Technical Problem or a People Problem ...?
Picking up from last week, which was picking up from previous discussions ...
We had a couple of technical glitches in the middle of our "Forward to Fundamentals" webinar. A technician from the webinar company broke in to apologize. I made a quick joke about "... speaking of 'technical' problems ..." Hence the question, "Is your technical host a technical or social problem?"
Very good question, posed in yes-no or either-or fashion. The answer, of course, is "yes."
I've often remarked over the years about how problems that appear to be purely technical are found -- after a series of effective five why questions (it may take more like ten whys to get this far) -- to have a social root cause. Take Ohno’s famous "five whys" example (Toyota Production System, Productivity Press, p.17):
1. Why did the machine stop?
There was an overload and the fuse blew.
2. Why was there an overload?
The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently?
The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently?
The shaft of the pump was worn and rattling.
5. Why was the shaft worn out?
There was no strainer attached and metal scrap got in.
If you've read this simple example closely you've recognized that Ohno could have easily taken the why exploration even deeper. "Why was no strainer attached?" He stopped, no doubt, to illustrate five whys, but also because he traced the cause to its root technical cause. So, that's deep enough to develop a direct and clear technical countermeasure -- an actionable point of cause.
But, if we've learned anything from the failure of many lean initiatives -- whether at the macro or micro level -- it is that the technical solution is necessary but not sufficient. Behind the technical problem there is almost always a social problem and accompanying our technical solution we have to give equal consideration to the social solution.
Why was no strainer attached?
Maybe the standard work for the maintenance worker or machine operator didn't go far enough. Or maybe the standard work did specify changing the strainer but the worker failed to observe the standard. How was the standard developed, how was it communicated and trained? How easy was it to "forget" to change the strainer?
Another why might reveal, for example, that there was confusion between Jack and Jill as to who was supposed to make sure the darned machine was sufficiently lubricated. A social root to an apparent technical problem. I’ve seen it and I’ll bet you’ve seen it happen amongst engineers time and time again.
Which brings us back to the question about the technical problem that occurred during the webinar and the explanation/apology by the technician. I forget now exactly what happened. I think it appeared that we lost sound and slides wouldn't advance for a few moments. The problem cleared itself up in a matter of seconds (although it felt much longer knowing that a couple thousand people were listening in). A few seconds later the technician broke in to state that we had experienced a technical problem.
If a pilot or co-pilot fails to complete his checklist prior to a flight, and an electro-mechanical failure occurs with one of the items he missed, is that a technical problem or a social problem?
You could answer that it depends on the final why of a five-why chain. You could also answer that it is both a social and a technical problem. There was a problem in the design of the work that allowed the purely technical problem (lost signal?) to get through.
Well-designed standardized work will recognize all the social factors that go into producing good quality in a repeatable way. Poor design of the work could easily have led to the mistake by the worker and the subsequent quality failure. The work design must produce the required output, as defined by the technical requirements, the specifications, and as specified by the engineering design of the product. That comes first. But, the work design must also include the "human factors" considerations that make it possible to do the job the right way, and even difficult to do it the wrong way.
Which brings us back to the thesis that the technical/process side and the socio/people sides of the equation are equally important. At the end of the day, can you even separate them? Would you even want to try?
Lean Enterprise Institute, Inc.
Lean Enterprise Institute Responds to The Wall Street Journal's Mischaracterization of Just-in-Time
A message from LEI to the Lean Community
How the A3 Process Developed to Help Build Better Managers, Part Two
In this second of two articles, Isao Yoshino and John Shook explore how A3 emerged as powerful practice at Toyota for developing better managers.
How the A3 Process Developed to Help Build Better Managers
One of the hallmarks of a successfully executed A3 process is that it is a collaborative activity--a learning process for everyone involved: for learner and teacher, senpai and kohai, sensei and deshi, say authors Isao Yoshino and John Shook. Here's the first of two articles tracing the development of A3 thinking at Toyota.