Great engineers keep asking "Why?"

I’ve had some health issues in the last few months. Moving from one doctor to another made me realise something important. Great engineers, just like great doctors, keep asking “why?”.

This question is not only about curiosity. It’s a tool. When we go to a doctor, we expect a diagnosis, not stating the obvious. Cough, fever, stomach pain - these are not much different from timeouts, noisy logs, or odd metrics. In fact, naming observed symptoms is usually easy enough, to be done by the patient alone.

Solving the actual issue is a whole different story. A painkiller may help with a headache, but it won’t cure the brain tumor causing it. Increasing timeouts or heap size just because they got exceeded usually works the same way. It may give short-term relief, but it doesn’t address the real problem. Unfortunately, many doctors and engineers stop there… The great ones, however, go further. It requires a mix of stubbornness and experience to keep asking why, looking for the essence of the issue. To me, that’s a key part of being a craftsman.

How many “whys” are enough? Of course, it depends. Even the famous 5 Whys method, despite its name, doesn’t give a strict number. We should ask as long as it makes sense, until answers start repeating, or further digging doesn’t bring anything new. Experience and intuition help decide when to stop without harming the patient/project.

Asking why lets us verify if we’re solving the right problem at all. You can see this clearly during code reviews. The proposed change might look spotless - high quality, clean code, good tests, etc. But it’s all for nothing if it solves the wrong issue. It might be addressing the symptom instead of the actual cause - a problem that we shouldn’t need to face. It might be built based on the wrong assumption, or act against the architecture vision. The “why mindset” helps great engineers identify the real challenge and think about the solution in the wider context.

Asking “why?” can be a bit risky too. It may sound judgemental and even make people defensive. The Coaching Habit suggests some ways to avoid that. Instead of asking Why did you do it this way?, we can ask What made you choose this approach? Such a simple shift makes the tone more neutral and opens the conversation. It’s like “why” that is easier to digest. Finally, the book recommends taming our “Advice Monster”, favoring asking questions over giving advice. This also applies to advice that only feels like a question, like Why did you choose A instead of doing B? That’s a quick way to hijack the conversation. The goal should not be to make people do things our way, but to do the right things.

Asking why comes more naturally when the team/organization culture promotes problem-solving and curiosity over blaming. When there is a lack of trust, questions may have a whole different sense. Asking why could then be taken as questioning someone’s expertise. Our whys should never be an attack, but an invitation to think and learn together. That’s why we should also be eager to receive whys from others.

So… should you ask “why?” more often? What makes you think so?