📝Five Whys

Five Whys is a method developed by Sakichi Toyoda and is a critical component of Toyota Production System. The methods helps to identify a root-cause of a problem.

You start with the problem statement and then ask the “Why?” question repeatedly.


  1. Form a team
  2. Assign a master (facilitator)
  3. Form a problem statement
  4. Ask “Why?” repeatedly until root cause is uncovered
  5. Decide on solution
  6. Assign responsible for solution


  • Do “Five Whys” analysis for every incident hitting production, breaking development process, etc.
  • Cross-functional teams may enable better perspective on the issue
  • There is usually a solution for each level of the “Why.” The deepest cause is not always the best to address.
  • Include the whole team into discussion, especially the person who has “caused” the bug. If the person is missing, there is a tendency to blame they. (“Why he didn’t wrote the test?”—“He never does.“) “Invite all affected” But if the person is present, they could provide an insight into their behavior. (“Why you didn’t write the test?”—“I don’t know how to use the testing framework” or “I tried, but it is too hard to write a test for this feature”–>“system is highly coupled”)
  • People are rarely to blame. Assume that people do their best and the problem is in the system, process, or organization. (“Asses the process, not people.“)
  • Do not jump to conclusion. Work through each level.
  • 5 is not a hard number. You may need more or less steps.
  • “Base our statements on facts and knowledge.”
  • At every level there can be multiple answers. Write them all down and explore.
  • You might also ask slightly different Whys on each level.
  • The method can be applied to anything:

    • Any problems (both production, job-related, and personal ones)
    • The Design of Everyday Things applies it to uncover design issues
    • If you want something, ask the Why question to uncover your deep motivation
    • You can use this to discover customer’s motivation (see Always ask “Why”)
  • Every task (ticket) should be traceable to business requirements (which is ultimately either increasing profits or cutting expenses)

Programming-related example:

Example with multiple possible questions:

  • Bob pushed to master directly

    • Why he did that?

      • He didn’t know the branching strategy
    • Why he was even able to do that?

      • master branch isn’t protected


Want to receive my 🖋 posts as I publish them?