Carrot or Tree? Choose the Right Tool

Before you ask 'why', ask 'how often'.

Stop treating every problem as a one-time event. Rare problems have one root. Recurring problems have a root system.

The team gathers around the table. You need to solve a problem. Someone suggests 5 Whys. You start digging.

But after 20 minutes you're stuck. You can't find a clear root cause. The discussion goes in circles.

Or the opposite scenario:

A machine stopped. You create a detailed process map. Chart all the variables. Analyze the system. Three hours later you realize: Someone forgot to add oil.

Both situations are about the same thing: Wrong tool for the wrong type of problem.

Summary

Situation: A company chooses tools based on habit, not on the nature of the problem.

Insight: Problems that occur rarely have one clear cause. Problems that occur frequently are systemic and require understanding of the process.

Signs to watch for: 5 Whys that leads nowhere. Over-analysis of one-time events. Recurring problems that are never permanently solved.

Next step: Ask the question "How often does this happen?" before choosing your tool.

Two types of problems require two types of tools

Think of a carrot. When you pull it from the ground, you see one clear root going straight down. A linear cause-effect chain. This represents problems that occur rarely.

Now think of a tree. What does the root system look like? A large, complex network with many branches intertwining. No single root causes the problem. It's the interaction between many factors built into the system itself.

This is not just a metaphor. It's a principle from Statistical Process Control, developed by Shewhart and later Deming. They discovered that separating special variation from common variation is essential for effective problem solving.

Use the wrong approach, and it becomes difficult to achieve lasting solutions.

How to distinguish "carrot" from "tree"

What this is about: The problem type determines the tool. "Carrot" problems have one identifiable cause. "Tree" problems are systemic with multiple interacting factors.

Why it happens: We treat all problems the same because we don't ask the right question first. We jump straight to the tool we know best, without considering whether it fits the problem.

How to recognize it:

"Carrot" problem (rare, less than 1 in 100 cases):

• Unexpected event

• Something specific was different today

• Clear trigger you can identify

• Tool: 5 Whys, Fishbone

"Tree" problem (frequent, more than 1 in 100 cases):

• The problem repeats itself

• It's the "system" producing the error

• Multiple factors interact to create the result

• Tool: Process Mapping, SPC

When you use 5 Whys on a "tree" problem, you often end up with a scapegoat. "The operator needs to be more careful" or "We need better training." But the real problem is that the process contains too much uncontrolled variation. You're blaming people for system failures.

What happens when you choose the wrong strategy

A technician had a machine with a high scrap rate. Labels landed outside the allowed area. He adjusted. And adjusted. And adjusted.

The scrap rate only increased.

The problem? Too much common variation. The label was almost as large as the allowed space. Each adjustment changed where the machine aimed, but the spread remained the same. More adjustments created more scrap.

The solution wasn't better aiming. It was reducing the variation. We switched to laser printing directly on the product instead of applying labels. Zero scrap.

The lesson: Machine adjustments fix centering. Not variation.

This is a classic example of treating a tree problem as a carrot problem. The technician was looking for ONE cause he could fix. But the problem was systemic. The design itself created the variation.

Do you recognize this?

Maybe you don't work with labeling machines. But I bet you recognize the dynamic:

• Using 5 Whys on a recurring problem and getting nowhere

• Creating complex process maps for one-time events and wasting time on over-analysis

• Implementing "solutions" that work for a week, then the problem returns

• Management asks "Why is this happening again?" and the team has no answer

• Blaming operators when it's actually the process that's failing

The consequence is that resources are spent on measures that don't solve the underlying problem. The same fires are fought again and again.

What you can do about this

Step 1: Start with "How often does this happen?"

Next time the team needs to solve a problem, start with the question: "How often does this happen?" If it's the first time or very rare (less than 1 in 100), you probably have a "carrot." If it happens regularly, you have a "tree."

Step 2: Choose tool based on answer

"Carrot": Use 5 Whys, preferably in combination with Fishbone, to trace the linear cause-effect chain. "Tree": Use process mapping to see the whole picture and identify which variables are driving the problem.

Step 3: Test if you have the right type

If 5 Whys doesn't give a clear root cause, stop. You probably have a "tree" problem. Switch to process mapping. Conversely: If the problem happened once and has a clear trigger, don't waste time on complex system analysis.

Frequently asked questions

How do I know if the problem occurs often enough to be a "tree"?

A rule of thumb from statistical process control: If something happens more than 3 times per 1000 opportunities (0.3%), it's likely part of common variation in the system, not a special event. This corresponds to approximately 3 standard deviations from the mean.

What if I'm unsure whether it's a "carrot" or "tree"?

Start by asking: "Have we seen this before?" If yes, treat it as a "tree." If no, start with a "carrot" approach, but be open to switching if you don't find a clear cause quickly.

Can the same problem be both "carrot" and "tree"?

Yes. A system has both special and common variation. Example: The machine usually stops 2 times per week ("tree" problem, systemic). But today it stopped because someone disconnected the power ("carrot" problem, special event). Treat them separately.

Why does 5 Whys fail on "tree" problems?

Because 5 Whys looks for one linear cause-effect chain. But "tree" problems don't have one root, they have many interacting factors. You end up blaming people instead of fixing the system.

Want to learn more about effective problem solving?

This article is based on principles from Statistical Process Control and structured problem solving.

Want more stories like this? We send out weekly newsletters with experiences from the real world. Short stories for those who want to solve problems at the root and achieve measurable, lasting value creation.

Sign up for our newsletter: