The ‘Why’ drill

What can organizations learn from curious youngsters?

I have a thing for catastrophes. Not because I like to watch the world burn or anything, but because I’m a true believer in learning. The best opportunities for learning and growth are when something went completely sideways. This is when the team can look back and figure out what it has been doing wrong and how to not let it happen again.

There’s a lot to learn from success as well, but that would be the story of another post. This post is going to be about how to learn from failure in a way that allows you to really evolve and grow as a team, and it starts with children.

Parents reading this can probably relate to those hilariously exhausting conversations with your young ones, when they don’t accept anything as given and challenge you to deeper and deeper answers. Take this real-life example:

Me: Ella, we’re going out. Please put sunscreen on.

Ella (3 yo): Why?

Me: Because it’s very sunny out there.

Ella: Why?

Me: Because it’s summer time.

Ella: Mmm… Why?

Me: Because the earth’s axis is tilted when orbiting the sun?

Ella: Why?

Me: Ok, I’m out.

This natural curiosity about the world is actually pretty charming and is something organizations and businesses are adopting for their RCA (root-cause analysis) processes. In the IDF Officers’ Course they called this (loosely translated): The ‘Why’ Drill.

The basic concept is this — take the question you are looking to root-cause. Start answering it, and keep questioning your answers, until you get to an insight meaningful enough to learn from. That’s why it’s called a root-cause analysis. The essence is found only if you can arrive at the root.

Many RCA processes are only scratching the surface, as while the question being asked is good and the answer to it is technically correct, if it’s not elementary enough, it does not allow the team to grow and revise its ways.

Take this classic example —

• The team has discovered a bug in production.
• A question often asked is: “why did we not catch that bug sooner (in dev environment, preferably)?”
• A common answer could be that “we don’t have enough tests”.
• The conclusion would be to add more tests. You then close the ticket and move on.
• But did we learn anything to help the team grow? What’s stopping us from forgetting to add tests next time?

That’s why you must ask those questions to get to the root-cause of the problem. For example, ask “why did we not have enough tests?”. An answer can be that “there was no time”. Ok, then “why was there no time?”. “Because we had to meet the deadline for the project at any cost” the answer would be. “Really? Why would the dev think that it’s more important to meet deadlines than test your code? Is this a message we’re sending?” And also, “Why are our devs so stressed? Are our effort estimations wrong? Are we not pushing back hard enough on extra work?”.

This can go deeper and deeper, until you start questioning elements in the team’s culture or processes that may have been the cause to this issue.

This is when you can draw your conclusions. In this made-up ping-pong conversation, one can possibly realize they need to work on better planning, or on improving their relationship with PM team to commit to less work and leave more buffers, or maybe on aligning the team on their core engineering priorities (such as ‘quality over deadlines’).

Wherever this tunnel gets you in the end, I assure you that if you drill deep enough, you’ll find the best opportunities for learning and growing your team.