I was taught (thanks to my coach Roberto) that the why question, when trying to understand a problem during a communication process, is something that should be used carefully.

It automatically put your counterpart in a defense mode: when we year the magic sound of why our brain try to justify the problem/behavior with the effect of enforcing it. It’s natural, our brain look for the quickest solution to avoid pain!

At first sight, this is NOT true when we talk about technical stuff. When a technical problem occurs, it’s usually important not only to solve it but also to understand why it happened (route cause). In fact, the typical technical manager (often, in my experience, an High C), asks her team: why did it happen?

But I think that, also in this case, the why should be avoided. Because, in any case, it leads the team to find a justification more then a real cause.

So I’d probably (try to) substitute the why with a ‘what can we do to avoid the problem in the future?’, ‘how can we approach this stuff differently?’ ‘what can we do to understand the problem?’ …

In fact you are not looking for the cause just to know it, you are looking for it because you want to avoid it in the future.