How Do I Lead Change Without Discouraging Employee Engagement?
Dear Gemba Coach,
How do you balance the sometime conflicting practices of gaining employee engagement while ensuring that everyone remains faithful to known lean tools and principles? In other words, when a kaizen team arrives at a solution that you know to be flawed with respect to the overall value stream or lean principles, how do you get them on the right path quickly without sending the message that you are not listening to them nor do you truly value their input and ownership of the problem?
That’s a tricky question, and undoubtedly an uncomfortable position to be in. It’s a very good question because the two pillars of the Toyota Way, continuous improvement and respect for people, are not always immediately compatible. In this case, the need for continuous improvement demands that the group move in the right direction with the right kind of solution. Their engagement, however, is linked to how much autonomy they have in running and improving their own workspace. Your job is to find the sweet spot where the ideas of the kaizen team reflect a deeper lean principle and the solutions are both pragmatic and useful to “lean” the process further.
The underlying question here is how to define a successful kaizen exercise. Ask yourself: what kind of solution is satisfactory? What sort of team interaction is sought? One of the key tenets of lean thinking is not to start spelling out solutions until a standard and a test method has been defined. What is it that allows you to see the solution is flawed but not the group? This discrepancy reflects the fact that your standard and test method differs from theirs, which, in turn, means they were not clearly defined at the outset.
One of the key aims of any kaizen workshop is to get people to practice PDCA in real life. The kaizen event, in itself, is also part of a PDCA cycle. There is a Plan phase before the event, then a Do phase (the event itself), a Check phase (right after the event, one week, three weeks after, etc.) and an Act phase: what have we learned from doing this kaizen event, and what can we adopt for the future. Typically, getting bogged down in the Do phase reflects a weakness at the phase: Plan.
How should one prepare for a kaizen event? Well, to be honest, one should have realized most of the work already, in defining the scope of the problem, picking the group and so on. The leader of the event should already have a good idea of what the problem is and some idea of a solution (can’t help himself or herself, that’s the way the mind works). So, to avoid either forcing a solution on participants, or asking too open questions, the trick is to define the Check at the Plan phase. Having done Plan, one should be able to formulate quickly the standard, and the test method for the kind of solutions sought. The role of the workshop is to get people to understand the problem in detail (often not what the preparation had highlighted) and to come up with solutions that pass the Check test defined during preparation.
Pre-defining the test method should avoid too great a divergence between the solutions the group is likely to invent and the “correct” solution in the facilitator’s mind. If the group comes up with something clearly inappropriate, the facilitator’s work is to bring the discussion back to better clarifying the problem or testing whether this idea would fit the test method (no, purchasing a new press doesn’t fit with the “no investment” requirement for this kaizen exercise).
Still some groups do go off in weird directions, confusing the act of inventing a workaround for the problem with looking for a fundamental solution. As you correctly note, being too heavy handed in imposing your solution will lead to either (1) the team closing ranks against the facilitator, and reaching a deadlock or (2) the team nodding on without buy-in: fine, if that’s what you want, I’ll rubber stamp it, but it’s not my solution so don’t expect me to stand by it
As a facilitator, we’re often as much part of the problem as part of the solution. I personally believe that most conflicts stem from a mix of misunderstandings and hot tempers. By the time the facilitator defends his or her solution to the team, the odds are that (1) the problem is not shared and that (2) tempers are running high. The difficulty, as a facilitator, is to recognize the adversity early, and not steam-roll it. Many facilitators end up in hot water because of their over-reliance on the process: they want to get ahead, and to move the group on towards a solution. However, if something is stalling the group, chances are a deeper problem is lurking there which has not been identified, and pushing the group along will end-up precisely where we don’t want to be, with the “wrong” kind of solution.
It’s important to recognize this form of adversity early on and to spend the time it takes to surface the underlying beliefs held by the participants. At this stage, although it may not be part of the formal agenda, one might want to drop the team discussions and send every one back to the Gemba to do some more observations. The key thing is to accept that the misalignment is mostly created by the facilitator failing to realize that the group was moving into an adversarial position, and not taking the time to make beliefs explicit and then comparing them to actual facts derived from direct observation.
Beliefs are never idle – in people’s minds, they’re often indistinguishable from consequences. We constantly visualize a mix of our beliefs and their (exaggerated) impacts on the situation – hence the sometimes bizarre dead-ends that a group can wander into. To avoid this, you essentially need to develop a set of special skills as a facilitator: (1) feel adversity when it starts to happen; (2) get to the bottom of the beliefs that create this adversity and (3) make explicit the consequences participants expect from these beliefs. When you are able to specify what is at stake, what can happen, beliefs can be attacked by Gemba observation and consequences can be questioned and disputed until the group re-frames its thinking and reaches more reasonable conclusions.
As a kaizen facilitator, I believe this should be a large part of the “Act” of the PDCA cycle: during the event, which misconceptions emerged? Are participants better aware of their wrong-headed beliefs? Will new beliefs now guide them to more relevant actions – and hence leaner processes? This, as much as the real “physical” change on the Gemba, is an important outcome to seek. If you’ve moved some equipment around but not changed the people’s beliefs about how this equipment is to be used effectively, you’ll find out that the change won’t last very long and won’t have the hoped for effects.
Pull the Cord
To sum up, it’s at the preparation phase of the kaizen events that important questions such as “how will I see that the workshop has been successful?” and “what is the main point I want them to figure out in this area?” have to be stated clearly, so that you can walk into the workshop with a clear standard (the lean principle relevant to this situation) and test method (what are the characteristics required from any “solution”).
Secondly, as a facilitator it’s important to develop one’s sensitivity to adversity (feeling when the group is not behaving as it should), and then pull the andon chord: hang the agenda, let’s reexamine our assumptions (mostly by going back to the Gemba) to surface beliefs and expectations, until people have agreed on how they see the problem. Don’t let yourself be drawn into a discussion about solutions until you’ve reached an agreement on the nature of the problem.
Where can I find information about visual management?
Dear Gemba Coach,
I can’t find much written about visual management although it seems an important part of lean – any idea where to look?
Is my crazy new boss right that applying standardized work is the foundation of lean?
Dear Gemba Coach,
My new boss is a lean fanatic crazy about standards. He’s created a new team to audit standards and is telling us that applying standardized work is the foundation of lean. It’s creating a lot of resistance, and I don’t know what to make of it.
Can 5S apply to coding?
Dear Gemba Coach,
We’re exploring lean in software development. Can 5S apply to coding?