|How Solution is Developed
|Toyota / “Lean”
|Very specific – guided and directed.
|Given / Directed
|Not specified, left to “empowered” employee.
When confronted with a problem, “traditional” managers have been taught to direct a solution, and leave details of putting it into place unspecified – “empowering” people to find the best way to work the details, solve the problems, and get it done.
“Toyota” or “Lean” managers, on the other hand, (if they are following the kata model – rare outside of Toyota I think), are going to be quite open about the solution, but very specific about the method used to develop and deploy that solution.
The two populations learn quite different things.
One learns to bypass obstacles, put the directed solution into place quickly.. git-r-done.
The other learns, through repetition, a thorough, adaptable, reliable and universal process for diagnosing a situation, seeing the root cause, and developing countermeasures that sustain.
The line I circled in my notes is “Kata must be content free.” meaning that if the method is carried out correctly, the solution will work to deal with the issue at hand. It is not necessary to specify a solution, only to hold the “true north” of what constitutes improvement and ensure that the process to develop the solution is carried out correctly.
An unworkable solution is a sign that the problem solving process was not applied correctly, not a flaw in the process itself.
OK – that all sounds good. What is the “ah-ha?”
How have many of us been “implementing lean” and “engaging people” by giving them targets in the form of specific tools to implement, and then leaving it to the “engaged team” to work out the details of how it will function in their situation? Which of the above two models am I using if I do that?
If I were to set an appropriate target, that takes the process closer to one-by-one, etc. and then to correctly guide the team through the process of understanding the current state, evaluating what problem(s) are blocking progress in that position, and methodically solve them they might or might not arrive at the tool I have in mind as the answer. Just to be clear – this approach is a lot tougher because there is another skill involved than just knowing how to make kanban work, or set up a u-shaped work cell.
There is a fine line as well between giving the team the solution and advising them on some things to try that will help them reveal more issues.
But in the end, if their solution works to close the gap, but uses a totally different approach, I have to be open to that possibility.
We lean “experts” have to play by our own rulebook.
Otherwise I am simply holding a wrench and looking for a screw to pound.