Frog & Bike Thinkers

I few years ago I got to hear a Toyota MD talk about frog and bike thinkers. The MD in question was an Australian that was being coached by leadership in Japan. Here’s my summary of what he said…

There are two types of thinkers in the world, frog thinkers and bike thinkers. If we are given the task of optimising the way that a bike works we can take it to pieces and investigate all of the individual components of the bike. We can improve them or rebuild them to improve their efficiency and performance. We can then rebuild the bike and there is a good chance that the overall performance of the bike will be improved. Try to do the same thing with a frog!

Frogs are more complex systems, where modifying each ‘component’ has major effects on the rest of the system. This to me is the heart of systems thinking – not all systems, in fact most systems in my experience, behave like bikes.

I find it interesting to reflect on how this relates to problem solving techniques. We’re often taught to solve problems by top-down decomposition, that is to break the problem down into small chunks, solve them independently and then rebuild the whole. This may work for engineering a computer system but it’s less effective when we are solving problems in social-technical systems where humans and machinery are combined. Humans behave in often unpredictable and strange ways.

I see this played out in IT divisions on a daily basis. If you look at the structure of most IT divisions you’ll see the top-down decomposition process (bike thinking) played out. If you look at the software delivery organisation for example you’ll often see a test manager, BA manager, development manager and a project/programme office. Each of these managers is given the task of optimising their ‘space’, whether that be requirements management, testing and quality assurance, development capabilities or project management.

The challenge here of course is that they are completely interdependent; the way we gather requirements affects the way we test, the way we test affects the way we develop, the way we project manage affects everything. And of course each of the managers cannot control the other areas, they can only defend their own areas of control. We are dealing with a frog.

Thankfully I’m seeing a trend towards new structures that combine cross-functional skills into combined product teams that are aligned across the systems flow. This flow is generally product, feature or project related. The key change is that there is a single combined team who have control and accountability for the delivery of value to the customer and the business.

I think this concept relates directly to continuous improvement (kaizen). I was taught to separate point-kaizen from flow-kaizen. The frog and bike metaphor really helps me to think about the difference between the two. When I see continuous improvement activities and initiatives in most organisations they are often point-kaizen based. That is we take a component of the system and we optimise it without consideration for the system as a whole. This can cause unwanted side-affects upstream and downstream of the change and may actually reduce performance overall. What is often more important is flow kaizen. The Theory of Constraints (ToC) teaches us that we don’t need to resolve every problem at the same time, just our biggest constraint. If we understand our customer needs and the efficiency of flow through the system to our customer then our continuous improvement activities need only focus on the main constraint to flow. Once it’s resolved we can start work on the next constraint. And then the next.

So, next time you have a problem to solve I challenge you to ask yourself whether you’re dealing with a bike or a frog. Let me know if it affects your thinking. It’s changed mine…