Welcome to part eight of a series on Steven Spear’s 2009 book The High Velocity Edge. The series is finally coming to a close.
So far we’ve learned how complex systems fail through the story of Mrs. Grant. We’ve learned to design pull-based systems using kanban and applied Jidoka to include built-in checks that reveal problems each step way. Lastly, we’ve covered learn to apply disciplined problem solving to continuously improve our systems.
There are two of four remaining capabilities to discuss. The remaining two capabilities are simple. Capability three: share knowledge. Capability four: develop high velocity skills in others.
I like to explain it like this. First get the flow, feedback, fix loop going, then each others do to the same. This way of working and thinking is meant to spread. So if you can share, then do it and lead by example.
Here’s are the last two capabilities in action.
Toyota has a practice called jishuken. The literal translation is “self-study”, though it’s much deeper than that.
Jishuken’s goal is to transfer knowledge from those who have it to those who can use it. It’s way of collaborative problem solving that disperses knowledge across and organization and hones the skill of everyone involved. It’s intended to solve the difficult unsolved problems that cannot be overcome by just googling something.
The setup goes something like this. A team reaches the limit of their problem solving capacity. This implies they’ve conducted numerous experiments, made multiple improvements, and implemented and iterated on countermesures, yet the problem persists. This is the host team.
The guest team arrives to help the host team. The host brings the guest up-to-speed on everything they’ve done regarding the current condition and target condition. So now, there’s two teams both sharing an understanding of current and target condition.
Now the guest team starts probing into current condition. Recall the guest team is here because the host team has been unable to solve the problem. The guests pull threads by asking questions like: what was not looked at? What was not tried? What was not considered?
See, the guest team isn’t trying to specifically solve the problem. The guest team is trying to identify the problem in host’s problem solving process that prevents them from solving the problem.
Here the “problem” isn’t the target condition. The problem is host team’s inability to achieve the target condition given their current knowledge and process.
This approach only works if the host has done their homework, hence the term “self-study”. They really need to have tried everything and pushed themselves to their maximum.
Afterwards the guest team moves to the next team in the organization, continually making the rounds and improving problem solving processes across the organization. This exercise hits all four capabilities. Host teams must design systems to reveal their problems, so they themselves can swarm them and address them. They must share knowledge within their team and iterate on that process until they reach their maximum capacity. Bringing in new people offers a new perspective and a chance to share knowledge across disciplines about the problem itself and discipline of problem solving. It also puts everyone together where they can lead by example and develop the same skills in others.
Alright, there’s only one episode left in the series.