Nobody Knows Which Part of the Problem Is Theirs

Part 3 of a series on structured problem-solving and senior-level communication.

Reading time: about 9 minutes.

---

Your garden looks ugly. You go outside to work out why, and here is what you come back with: the grass is too long, there are ants everywhere, the fence paint has come off, and there are weeds all over.

Four real problems. Every one of them true.

Now answer this: what do you do on Saturday?

You cannot say. And that is the whole failure. Four items, no order, no sense of which one is actually making the garden ugly. So you paint the fence, because painting is satisfying, and on Sunday the garden still looks ugly.

What This Article Answers

• What is an issue tree, in plain terms? (A problem cut into a few questions you can go and check, instead of a list of things you noticed.)
• Why does listing causes feel productive and change nothing?
• What is the one question that turns a list into a tree?
• Where do I make the first cut, when several look reasonable?
• How do I know a branch is finished and ready to hand to someone?
• What do I do with a branch nobody can test?
• How deep should the tree go?

TL;DR

Do not start from what you noticed. Start by asking what causes this kind of problem in general, before you look at your own case. That gives you three or four boxes. Your noticed items then fall into the boxes, and the ones that do not fit were noise. Then you go and measure each box, and most of them die.

• A list is what caught your eye. It is biased toward whatever is visible and annoying, not whatever is causing the problem.
• The move is to leave your problem for a minute and ask what makes any problem of this type happen. Answer that first, then come back.
• A tree is for killing branches. If nothing dies, you did not build a tree, you rearranged your list.
• Every bottom branch needs three things: one owner, a check you can actually run, and an action if it turns out to be the big one.
• Stop when a branch is checkable, not when the tree looks thorough.

The same garden, twice. First as four things you noticed, then as three boxes you can go and measure. The second version is not longer. It is cut at a different angle.

First, You Try It

Before reading on, take the garden problem and break it down properly. Give it thirty seconds. Write down how you would split "why does my garden look ugly" into parts.

Most people, and this is worth being honest about, write down some version of this:

• Grass is too long
• Ants everywhere
• Fence needs paint
• Weeds everywhere

If that is roughly what you wrote, nothing is wrong with you. That is what breaking down a problem feels like from the inside. You looked at the problem and reported what you saw.

But look at what that list actually is. It is four things that caught your eye. The ants made the list because ants are irritating, not because ants are why the garden looks ugly. Nobody has ever looked at a garden and thought "ugly" because of ants. Meanwhile the list has no idea whether the weeds cover one corner or half the lawn, because you never asked.

A list is a record of your attention. Your attention is drawn to what is annoying and visible, which is not the same as what is causing the problem.

The Move: Stop Looking at Your Garden

Here is the question that does the work, and it is going to feel like a detour:

Forget your garden. What makes any garden look ugly?

Not yours. Any of them. Think it through and there are only three ways it can happen:

1. Something is there that should not be. Weeds, dead leaves, rubbish.
2. Something is missing that should be there. Bare patches, no colour, paint gone.
3. Something is there but out of control. Grass too long, hedge overgrown, a bush eating the path.

Three boxes. Notice they cover everything, and nothing sits in two boxes at once, which is the no overlaps, no gaps test from part 2 doing its job here.

Now go back to your four items and drop each one into a box. Weeds go in box 1. Fence paint goes in box 2. Long grass goes in box 3.

And the ants? They do not fit anywhere. Ants are not why the garden looks ugly. They are a separate problem, a real one, but not this one. The structure just deleted an item from your list, which the list itself could never have done.

That is the whole technique. You did not think harder about your garden. You asked what causes this class of problem, got the boxes, and then sorted.

Four items, all true, all equally urgent-looking, three weekends gone, and the garden unchanged.

Now Go and Measure, and Watch Branches Die

The boxes are not the answer. They are three questions you can now go and answer, one walk around the garden each:

• Box 1, things that should not be there: how much of the garden is covered? Weeds are over half the lawn.
• Box 2, things missing: how much is bare or unpainted? One side of the fence. That is it.
• Box 3, things out of control: how overgrown? Grass is long. One hour with a mower.

Saturday is decided. Half the lawn is weeds, and nothing else is close.

The fence branch just died: one afternoon of pleasant work that changes almost nothing about how the garden looks. The grass is an hour, worth doing, not the reason. The ants left earlier.

That is a tree working. Four things that looked equally important became one that matters and three that do not. If you run this and nothing dies, you did not build a tree. You reorganised your list.

The Same Move, at Work

Now the version that pays. Your project is not delivering on time. Six people in a room, and the list comes out:

• We do not have enough people
• The requirements keep changing
• The tooling is slow
• Too many meetings

Same shape as the garden. Four true things that caught someone's eye, no way to rank them, and each one has a person in the room who will argue for it. Two weeks later there is a deck with four sections and no answer.

So make the move. Forget your project. Why is any task late? There are only three possibilities:

1. It never started. It sat waiting on a decision, an approval, another team.
2. It started but took longer than expected. The estimate was wrong, or the scope grew while it was being built.
3. It finished, then got redone. It was wrong the first time.

Three boxes. Now go and measure, exactly like the garden. Pull the last forty tasks and sort them into the three piles. This takes an afternoon and it does not require anyone's opinion.

Say thirty of the forty sat blocked, waiting on someone else. The headcount debate is over. Adding people to a team where work sits waiting makes the waiting worse, and you know it from the tasks rather than from whoever argued hardest.

Note what happened to "too many meetings" and "the tooling is slow." Neither is a box. They might explain why box 2 is big, but they sit underneath a box. Your list mixed causes and symptoms at different levels, which is the other thing a list quietly does.

The same problem cut two ways. The top cut sorts work into piles that each need more digging. The bottom cut ends in numbers you already have.

Where This Goes Wrong

One failure looks professional, which is why it survives: you cut by container instead of by cause. Rather than "never started, took too long, got redone," you split the project by team. Platform, frontend, data. Tidy, non-overlapping, and it explains nothing. One team will come out worst, but the team is not causing the lateness. They have more dependencies, or worse requirements coming in. In the garden it is splitting by area: the back garden is worst, so what, you still have to go and look again.

The tell: ask what you would do if that branch were the big one. If the answer is "look into that one more closely," it is a container. If it is "pull the weeds" or "fix the approval queue," it is a cause. A container always needs one more round of digging, which is how a tidy tree generates six weeks of work and no conclusion.

The other failure is a branch nobody can check. "The team lacks motivation" sounds like a cause, cannot be measured, and if true, nothing follows. So a branch is finished when three things hold: one person can own it, they can check it with data they can actually get, and you know what changes if it comes back true. That first one is the same test that governs handing over any work, since you cannot delegate a thing you cannot describe.

One real cost, worth naming. Checkable branches are narrower than the problem, so you can answer three easy questions while the actual cause hides in a fourth that is hard to pin down. Keep that one on the tree, labelled as uncheckable, instead of dropping it for tidiness. A branch that stays visible can be argued about. A deleted one cannot.

Depth works the same way. Stop when the branch is checkable. Five levels where three would do is not more rigorous, just slower to hand out.

Three branches from the same tree, checked against the three questions. Only one is ready to hand to someone.

Do This Tomorrow, in Fifteen Minutes

Take a problem you are carrying that is still a sentence, not a plan. "The rollout is behind." "The client is unhappy." "Nobody uses the new tool."

Write your list first. Everything you noticed. You need it, just not as your structure.

Then put it aside and ask the general question. Not "why is my rollout behind" but "why is any rollout behind?" Answer that with three or four boxes that do not overlap. This is the step everyone skips and the only one that matters.

Sort your list into the boxes. Anything that fits nowhere was noise, like the ants. Anything sitting under a box rather than being one, like the meetings, drops a level.

Then pick one box and write the single question someone could answer this week. Name the person. Name the data. If you cannot name either, that branch is not ready, and finding that out on a page today is much cheaper than finding it out in a status meeting in two weeks.

The Point

Breaking a problem into what you noticed is not breaking down the problem. It is writing down your attention.

The real move takes one question, asked before you look at your own case: what causes this kind of problem at all? Answer that, sort your observations into it, then go and measure. Most of what worried you dies in the measuring, which is the point. Four equal-looking problems become one that matters.

A branch you cannot check is not a branch, it is a topic. Topics do not get resolved, they get discussed again.

Coming Up in This Series

A tree is only as good as the question at the top of it. Cut up the wrong question rigorously and you get a clean, well-owned answer to something nobody needed to know. The most senior person in the room usually spends their effort on that top line, which reads as slowness right up until it saves the engagement. Next: framing the problem before solving it, and why the time spent defining the question is the cheapest time in the project.

---

This is part of a series on structured problem-solving and senior-level communication.