Here is an “ah-ha” or even one of those “oh s#!&” moments I had as Mike Rother was talking about his Toyota Kata research last week.
| Solution | How Solution is Developed | |
| Toyota / “Lean” | Left Open | Very specific – guided and directed. |
| Traditional Management | 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 result?
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.
I have a new role in my company to develop the technical team. I find this article is useful and thanks for your sharing!!!
Excellent post Mark. Do you think that those of us who lead continuous improvement with Lean or Six Sigma need our own kata to help us follow this kata?
Jeff –
I think we need to be masters of the coaching kata.
But more importantly, since in the real world, we often do not have anyone backing us up, we must apply the coaching kata to ourselves. We need to be asking ourselves the same questions our coach (if one was there) would be asking of us.
Have you ever considered Precision Questioning and Answering? It addresses the reality of information overload being combined with shorter and shorter windows to solve problems. It teaches a form of business communication that enables users to get to the heart of problems faster and ask the right questions to solve the problems more efficiently. Particularly popular with engineering teams, technology leaders, knowledge workers. it takes six sigma to the next level.
I am curious how it would differ in function from the “coaching kata” outlined in Mike Rother’s book.
I say that because I find that many companies who have a high level of organizational learning use some kind of formal structure to surface problems, explore them, and interact with each other about the process of solving them.
As Rother points out, his version is not canon, it is just what he has teased out of his research and what he is currently testing. The key is to have:
A structured process for solving problems that people learn thoroughly through deep practice.
A structured process for coaching that practice – usually also applying the problem solving process itself… a bit of a fractal structure.
If there is a vestige of those two things happening – even inconsistently, the capacity of the organization to solve problems that come their way improves dramatically.
For now, I am practicing Rother’s questions, or at least trying to rigorously follow the general form.