Root cause works brilliantly in IT. Humans are a little more complicated.

In technology, we look for the root cause. A system stops working. What happened? Where did the failure occur? What caused it? How do we remove the cause? How do we stop it happening again? Five whys and off we go. I genuinely like this way of working. The problem begins when a human starts treating themselves like a production incident.

“Why am I like this?”

That question can be useful. It can also create an infinite loop. Why can’t I say no? Because I am afraid of the reaction. Why am I afraid of the reaction? Because I want people to approve of me. Why does approval matter so much? Because… We can keep digging. And sometimes that depth matters. But not every conversation needs an archaeological excavation. Sometimes understanding the past is useful. Sometimes a more relevant question becomes: “Now that you can see it, what do you want to do?”

Root cause assumes that something is wrong

That is the first important difference. In a system, an error message tells us that reality differs from the expected state. We have an expected result. We have an actual result. There is a gap. We investigate the cause. But who defines the expected result for a human being? Family? A manager? Organisational culture? The person I was ten years ago? The person I am comparing myself to? What exactly does: “I should be more confident” mean? More confident than now? As confident as somebody else? In every situation? And how do we know lack of confidence is actually the problem?

Sometimes the problem has been named incorrectly

We know this from IT too. The ticket says:

“Power BI is slow.” An hour later, Power BI has been acquitted of all charges. The issue is elsewhere. Something similar happens with people. A client arrives saying: “I need to be more productive.” And the conversation reveals: “I don’t actually want to do half the things I’m trying to motivate myself to do.” Or: “I need better time management.” Underneath: “I don’t know how to say no.” Or: “I don’t know how to make this decision.” A little later: “Actually, I do know. I just don’t like the price of the decision.” Those are very different problems.

Diagnosis ≠ awareness

In technology, diagnosis is often exactly what we need. In coaching, awareness may matter more than a label. I do not necessarily need to establish: “What is your problem?” I can be curious about: “What are you noticing?” I do not need to decide: “Why do you behave like this?” I can ask: “What happens for you in this situation?” I do not need to determine: “What is the right solution?” I can ask: “What matters to you here?” The difference looks small. But it changes who owns the process.

Debugging humans has another problem

Every developer knows the experience of fixing one bug and discovering three more. 😉 Something similar can happen when we try to “fix” people. We fix lack of confidence. And accidentally remove the caution that protected someone from impulsive decisions. We fix perfectionism. And throw away the precision and standards that were also a major strength. We fix the need for harmony. And lose the ability to understand multiple perspectives. So I prefer another question: How can you have access to your strength without being automatically controlled by it? It is a question I particularly like in work involving leadership and the Enneagram.

Perhaps we do not need the root cause

Sometimes it absolutely matters where something came from. But coaching does not always need an answer to: “What broke me?” Perhaps it needs: “What is happening here?” “What does this mean to me?” “What matters?” “What options do I have?” “What do I want to choose?” In technology, I want systems to behave predictably. From human beings, I hope for almost the opposite. The capacity to learn. To change. To surprise themselves. To see something they could not see before. So I will happily keep looking for root causes in technology. I would rather not debug the human.

Explore how I use different perspectives in coaching →