5 whys – dwell on the subject

In the book “Lean Startup” Eric Ries describes the 5 Whys technique. Frankly, it sounds trivially and obvious, however, I guess only a few has managed to implement it successfully in a team/company.

This method, from which you can draw handfuls of ground-breaking management techniques, was created and implemented by Sakichi Toyoda, the founder of Toyota Industries.

Pic. Sakichi Toyoda – the founder of Toyota Industries

The principles of the method are extremely simple. Can anyone imagine a 5-year-old child endlessly asking “why”?

– Grandmother is sick.
– Why is she sick?
– Because she didn’t wear a hat.
– Why didn’t she wear a hat?
– Because she had to chase grandfather, who had forgotten his breakfast.
– Why had he forgotten his breakfast?
– Because he has sclerosis.

Maybe the scene is exaggerated, but it shows how we come from the general problem to the hidden one. Besides knowing that grandmother is sick, we realize that grandfather has problem with his memory.

How does it transfer to project management?

Eric Ries presents following example in his book:

– A new release broke a key feature for customers.
– Why?
– Because a particular server failed.
– Why did the server fail?
– Because an obscure subsystem was used in the wrong way.
– Why was it used in the wrong way?
– The engineer who used it didn’t know how to use it properly.
– Why didn’t he know?
– Because he was never trained.
– Why wasn’t he trained?
– Because his manager doesn’t believe in training new engineers, because they are “too busy”.

Having asked 5 questions it turned out that the problem lies much deeper. If the leader of the project had asked only one question “why did the server fail?” and had received information concerning its misuse, he would have probably come to the conclusion that the blame should be placed on the person implementing that new feature. However, having a few questions, it turned out that lack of trainings and belief in their legitimacy was the problem. After the first question a recovery plan would be nothing but to reprove the new engineer. In case of a larger number of questions at IMVU (a company co-founded by Ries), the management decided to introduce a recovery plan at each level, i.e.:

1) Fix the server
2) Change the subsystem to make it less error-prone
3) Educate the engineer
4) Have a conversation with the manager

Additionally, it has been decided to implement a training system in the company. According to the Lean notion, we should act step by step, in an iterative way, on a small scale. As a result, they started working on trainings and improved them iteratively.

The above mentioned method isn’t a remarkable discovery and sometimes is used unknowingly. Unfortunately, I didn’t have opportunity to fully test it live, but I hope that sooner or later I will have;) In addition, you should be careful not to offend a person you’re talking to. Before implementing this method in your team, you should remember to inform them and explain that it isn’t used to torment them but to get to the heart of the matter. It is just a confirmation that communication in a team is incredibly important and can’t be avoided.

Does anyone work this way?