I spend a lot of time in the software development industry, and in that industry there exists a practice called a retrospective (or a retro). A retro is a meeting held after a project (or a phase of a project) is complete. During the meeting, the team involved in the project looks back to examine what went well and what went wrong. The team then uses that information to make decisions for the benefit of its future.
One tool often used during these meetings is called 5 Whys. The practice starts by identifying a problem (something that went wrong during the project). To that problem, the team asks Why?. Then, to the answer, the team asks why again. Asking why enough will eventually lead to a root cause of the problem. The team can then focus its solution on addressing the cause of the problem, rendering it more effective.
Let's walk through an example: I'm in one of these retro meetings and I say, "Dan was a real dick during the last phase of the project." The team would ask Why? until we get to the root cause. It might go something like this:
Voila! Now the team knows my sentiment about Dan was misdirected. Sure, Dan may still be a dick, but now we have a root cause to a problem we saw during the project. And we can use that root cause to adjust our behavior in such a way that projects move more smoothly in the future.
The 5 Whys don't have to be reserved for retrospective situations or for examining problems. This useful tool can be put to work for nearly any scenario. You could use it to help figure out if you've chosen to travel to the right destination for your next vacation. Ask yourself why you're going to the spot you've chosen until you get to the real reason you want to go to there. Then ask yourself if that's a good enough reason, or if it makes more sense to adjust your travel plans toward something more meaningful to you.
I should also mention that the number five doesn't really mean anything. It's based on the experience of observing that it typically takes about five whys to get to the root. But everything situation is different from the next -- some may find their root in three questions, or maybe seven. The practice is more about recognizing when you've reach the root. In the retro example above, my team could have kept going, but we would have been asking why the client missed their deadline and that doesn't matter to the problem we were addressing. That means we were as far as we could effectively go with that scenario, and thus had reached the root.
So, take this practice and apply it anywhere it makes sense in your life. You will find yourself creating more effective solutions to your problems and failures, or even your potential actions.
Want to receive approximately one email every month with new articles, tools, and references I've discovered? Sign up below.