The Problem With Solving Problems Out of Order
Most meetings meant to solve a problem never actually work on the problem. They work on the sequence — badly.
Someone asks why the project is behind. Before anyone answers, someone else asks who’s responsible. Before that lands, a third person jumps to how they’ll fix it by Friday. Nobody has agreed on what the problem actually is, and now three people are debating three different questions as if they’re the same conversation.
This is not disagreement. It’s sequence collapse. And it produces a specific kind of exhaustion — the meeting that runs ninety minutes and ends exactly where it started, except now everyone’s irritated.
The discipline is not “ask the right questions.” It’s ask them in order, and finish each one before you drop a level.
Why → What → How → Who/Where/When is not a checklist. It’s a hierarchy. Each question has to be closed — not perfectly, but sufficiently — before the next one is allowed to open. Skip that, and you’re not solving the problem faster. You’re just relocating the confusion to a different question.
Take a real pattern from ERP programs, because it shows this cleanly. A steering committee is told a module isn’t working. Within minutes:
- Someone asks who configured it (Who, prematurely)
- Someone asks what the vendor’s contract says (What, but the wrong What — process, not problem)
- Someone asks how to escalate (How, before anyone has agreed what’s actually broken)
Forty minutes later, the room has generated three action items and zero clarity. Nobody asked why the module needed to do what it was supposed to do in the first place — the actual purpose the configuration was meant to serve. Without that, “who configured it” is just looking for someone to blame for a target nobody re-confirmed.
The fix isn’t more meetings. It’s holding the line at each level until it’s actually answered.
A simple framework:
- Why — What standard or outcome is actually at stake here? Not “why is this broken” yet — why does it matter that it’s broken. Confirm this before diagnosing.
- What — Name the actual problem, in one sentence a stranger could understand. If you can’t, you’re not ready to leave this step.
- How — Now the options. Not before.
- Who / Where / When — Execution. This is where most rooms want to start, because it feels productive. It is the least useful place to start.
The test for whether you’re allowed to move down: can you say the current level’s answer in one sentence, and does the room agree with it? If not, you’re still there, whether you feel like it or not.
Exceptions — because discipline without judgment is its own kind of drift:
- Crisis work. When something is actively bleeding, you don’t get Why first. You stabilise Who and What immediately, and you trace Why in the retrospective, not the emergency.
- Authority gaps. Sometimes the diagnosis is right and nobody with standing is in the room to act on it. In that case, Who has to be resolved before Why can go anywhere — not because it matters more, but because it’s the gate the answer has to pass through.
- Settled problems. If the Why is already agreed and everyone in the room knows it, re-litigating it every time isn’t rigor. It’s ritual. Move straight to What.
Most organisations don’t fail to solve problems because they lack intelligence in the room. They fail because everyone in the room is answering a different question at the same time, and mistaking the noise for progress.
What level is your last meeting actually stuck at — and does anyone in the room know?
