Questions Matter
For years I have given younger systems engineers the same advice: ask questions! And then ask more still. Keep asking until it becomes clearer what is driving the situation.
That advice is not so much about being thorough; it is about creating understanding. Developing a good system depends on shared clarity about what success actually looks like, because the things that matter are seldom obvious at first.
Among all the questions an engineer can ask, one seems to come up more than any other: Why? Entire problem-solving approaches have been built around it, including the “Five Whys”, a method associated with Taiichi Ohno and Toyota. The principle is simple: don’t stop at the first answer. Keep asking why, until a deeper understanding of the problem, and perhaps its solution, begin to emerge.
Here, why takes us beneath the visible problem to something more fundamental.
The machine did not stop by chance. It stopped because maintenance had been neglected. Why helped uncover something real beneath the visible fault.
I agree completely with the instinct behind this. Resist the superficial explanation; try to understand what lies beneath the visible problem. That instinct is powerful, and it matches my advice to systems engineers.
Over time, though, I have grown more cautious about asking why. I still want the digging. But I have become increasingly skeptical of why as a question, because while it can reveal something important, it can also quietly pull us in the wrong direction.
Limits of Why
To show the limits of Why, we can extend the Toyota example. At first, the logic feels reassuring. Something happened, so there must be a cause. We dig, and our understanding improves. The machine stopped because maintenance had been missed.
But what happens if we keep asking why?
The nature of the answer begins to change. It is no longer so clear. Perhaps the maintenance was simply forgotten. Perhaps production pressure repeatedly won out over downtime. Perhaps responsibility for maintenance had gradually become unclear as teams changed.
Somewhere along the chain of questions, the ground shifted. We are no longer looking at a mechanism. We have moved into a situation shaped by people, priorities, constraints, and organisational decisions, and the trade-offs they involve.
Early on, why traced fairly direct relationships. A few steps later, it leads us into uncertainty, competing priorities, and human judgement. The question still sounds as simple as before. The situation no longer is.
What Changes in Complexity?
This is where we move into complexity. A complex situation behaves differently from a simple chain of cause and effect. Outcomes emerge through many interacting influences, so the cause no longer sits in any single place. The maintenance problem may have emerged through several things coming together: production pressure, changing teams, and unclear ownership.
The challenges of complexity become especially visible in the kinds of systems that engineers actually work in, particularly socio-technical ones, where technical systems, organisations, and people interact. Once people become part of the system, complexity rises. Humans and their interactions, after all, are rarely simple.
In these systems, why begins to struggle. The trouble is not that the question is wrong; it is that it becomes underdefined. Why sounds as though there should be a clear explanation waiting to be found, but in complex situations there is rarely a single explanation to point to.
When Questions Become Social
Once people are involved, questions stop being purely informational. We rarely hear them only for their literal content; we read intention into them as well.
Why are you late? Let’s take that as a plain example. On its face this question is almost factual; perhaps there was traffic. Yet most of us hear something underneath it. Perhaps “is something wrong?” or even “you seem unreliable, can I count on you?”
In our answers, we respond not only to the words themselves but to what we believe the question is really about. Frustration and blame feel different from curiosity, honest concern different from evaluation. Before answering, we make a quick, often half-conscious sense of what the other person actually wants, and that shapes our response.
If we feel understood, we tend to explain openly. If we feel judged, we become more careful.
On top of this, we ourselves may not fully understand what produced an outcome, and there may be no room in the moment for a fuller account. So we simplify. We defend, we deflect, and we tell a story that is cleaner than the situation itself.
Complexity Needs Different Questions
The limitations of why become especially visible when something goes wrong: a project runs late, a policy fails, or an outcome drifts somewhere no one intended.
Faced with uncertainty, we want to understand what happened, and preferably in a way that feels clear and manageable. These are the moments when the reflex to ask why becomes strongest. Why was the project late? Why did the policy fail? Why is this happening here?
Yet these are often highly complex situations. Projects rarely run late for a single reason.
And this is exactly where why begins to pull us in the wrong direction. The question invites cleaner answers than the situation can support. And so what we learn becomes: Requirements changed. Communication was poor. Leadership failed. The supplier did not deliver.
The problem is not that these explanations are false. Each usually contains part of the truth. The problem is that they are incomplete.
Once we settle on an explanation, it quietly narrows where we look. We begin acting on the simplification, often long before we understand the broader situation.
We schedule more meetings to improve communication, while leaving teams without enough authority to act. We replace a supplier, rather than strengthening our own systems understanding and integration capability.
Sometimes, we even make things worse, because the wish for a clear explanation pulled us toward a story that was simpler than the reality we were facing.
What Questions Work Better?
If why can pull us toward explanations that are too simple for the situation, we need questions that help us understand more of what is actually going on.
Take a question like: Why did the integration fail? It sounds clear, yet it quietly packs several possible questions into one. Was it a technical problem? A lack of alignment between teams? An organisational setup that made collaboration difficult? Several of them?
For this reason, I found myself becoming more careful with why. When I notice myself reaching for it, I try to pause and ask: what am I actually trying to understand here?
This reflection matters, because it should shape the question. If I am vague about what I am after, I should not be surprised if the answer does little to help. But if I can be more specific, I am more likely to understand what was actually going on.
Maybe the better question becomes:
- What made this technically difficult?
- Where did understanding diverge between teams?
- What in the organisational setup made collaboration difficult?
Questions like these tend to bring more of the system behind the outcome into view.
In human situations, the question can matter even more. Return to the example of arriving late. Asked without explanation, Why are you late? is easily heard as frustration, criticism, or blame.
Ask instead: What happened this morning? and something shifts. The question opens space for a fuller account. Suddenly there is room for the child who would not get ready, and for the possibility that the situation may be more complicated than it first appeared.
Here too, asking ourselves what we are actually trying to understand, and making our intention visible, can open different kinds of conversations. Without it, people are left to guess at the purpose behind the question. When we make our intention visible, we allow the other person to respond to the kind of conversation we actually want to have.
Better questions do not avoid complexity. They help us stay with it long enough to understand what actually shaped the outcome.
Final Thought
I began by saying that I still encourage younger systems engineers to keep asking questions, and I still believe in that advice.
But experience has taught me that understanding improves not only by asking more questions. It improves when we become more deliberate about which questions we ask, clearer about what we are trying to understand, and more open about the intention behind our questions.
Sometimes, a small change in the question changes far more than we expect, not because the situation changed, but because we finally begin to see more of it.