Core principles

The ideas behind every rule in this reference.

Every rule on this site follows from a handful of principles. When a situation is not covered by a rule, these are what to reason from.

The principles at a glance

Purpose

• Understand before you solve.
• The conversation is the product.
• The tree ends at understanding.

Building

• Capture first, categorize later.
• Start from what people already know.
• Every arrow has a direction.
• A node's type comes from its role, not its wording.
• Keep the vocabulary small.

Reading and living

• Every tree carries its legend.
• Adapt the conventions, and say so.
• The tree describes the present.
• A tree is alive while it is useful.

Purpose

Understand before you solve

A Tree of Influence is a tool for understanding a problem space, not for detailing what to do about it. It can contain actions and artifacts, but it treats them as part of the situation being mapped, not as immutable conclusions.

Groups under pressure rush to solutions. A tree built that way only confirms what people already believed, and gives them false confidence on top. It takes discipline to map what is actually going on first, so the answers that follow are aimed at real causes.

In practice:

• When a solution lands on the board, ask "what problem does that solve?" and map that problem too.
• Expect to learn. A tree that tells the group nothing new has not done its job.
• Watch for solution-dumping and the shortcut, the two most common ways a tree slides from understanding into planning.

The conversation is the product

The value of a Tree of Influence is created while people build it: when someone sees that their local problem is caused by something three teams away, or that five people have been fighting symptoms of the same cause. The diagram remains as a result of that conversation, so the understanding does not evaporate when everyone goes back to their desks.

In practice:

• Build the tree with the people who hold the knowledge. A tree drawn alone and presented to a group skips the part that matters most.
• Messy is fine. A tree is a thinking tool, not a polished publication. Spend effort on the conversation, not on the layout.
• A tree can be built by one person thinking through a problem. The principle still holds, as the value lies in the thinking the tree provokes.

The tree ends at understanding

The tree's job ends when the group understands the problem space well enough to act. Assigning owners, planning projects, estimating effort, and tracking progress all come after, and they take the tree as input.

A Tree of Influence is not a project plan, a backlog, a decision record, or a status tracker. It can feed all of them. Asking it to be one of them overloads it and blurs what it is for.

In practice:

• When the conversation turns to who does what and by when, the tree has done its job. Move to the tool built for that.
• Do not add owners, dates, or status markers to nodes. See what it is and is not.

Building

Capture first, categorize later

Building a tree has 2 modes. During construction, anything goes: any idea, in any wording, with any kind of influence. During refinement, the group sorts, types, and sharpens what is there. Mixing the two kills the volume and honesty that construction needs.

In practice:

• When participants ask what "influences" means, the answer is: whatever kind of influence you have in mind.
• Leave nodes uncolored until their type is clear. A white node means "not decided yet," and that is valid.
• Defer disagreements during construction: "We're capturing now, refining later."

Start from what people already know

A blank board stalls a room. Before a session, the facilitator places what is already known: obvious problems, stated goals, work already underway. These seeds are a catalyst, not a constraint. Participants must feel free to challenge, reword, or ignore them.

There is no required starting point. Groups seed with problems, goals, actions, observations, or all of them at once. Some start from 2 separate lists, problems and outcomes, and discover everything in between.

In practice:

• Pre-seed 5 to 10 problems and 3 to 5 outcomes, and tell the group they are hypotheses.
• Draw seeds from anywhere: interviews, bug reports, strategy documents, retrospectives.
• Do not prescribe what kind of node comes first.

Every arrow has a direction

Arrows mean "this influences that," and every one points from source to target. Direction is the one thing that is never loose: an undirected web of sticky notes is not a Tree of Influence.

In practice:

• Draw one head per arrow. No two-headed arrows and no plain lines.
• If two nodes seem to influence each other, look for the hidden cause between them. See cycles and graph shape.

A node's type comes from its role, not its wording

A node is a problem, an action, an outcome, or an artifact because of where it sits in the tree and where its arrows go, not because of its grammar. A problem can be a crisp statement or a hard number.

In practice:

• Do not reword nodes to fit a type. Type them by their role during refinement.
• Expect different groups to use different vocabulary for the same role. An "initiative," a "half-way problem," and an "action" can all be action / intervention nodes.

Keep the vocabulary small

The notation is deliberately small: 4 node types, 1 default arrow, and 2 optional refined arrows. Every extra distinction costs attention, and attention spent classifying the diagram is attention not spent understanding the problem.

For relationships, a rule of thumb: one arrow style is fine. Two means something real surfaced. Three means you are probably classifying instead of understanding.

In practice:

• Add a distinction only when the group raises it and agrees that it would change what they do.
• Grow the vocabulary out of need, never in advance. The attacks arrow appeared only after a group had been mapping artifacts for a while.
• Do not invent a fifth color. Raise the need as an open question instead.

Reading and living

Every tree carries its legend

A legend takes seconds to make and saves every future reader from guessing, including the people who built the tree, two months later. With a legend, a stranger can read the tree. Without one, someone has to be in the room to explain it.

In practice:

• Create the legend before the first node, and update it whenever the tree's meaning changes.
• List only what the tree uses, plus the flow direction and the context: what, who, and when. See the legend.

Adapt the conventions, and say so

The colors, orientation, and arrow styles on this site are what practitioners converge on naturally, because they make trees readable. Follow them by default. When a problem space needs something different, adapt, and record the difference in the legend.

The Tree of Influence offers structure without rigidity. Rules exist so trees can be read by anyone. They do not exist to stop a group from drawing what it knows matters.

In practice:

• If your tool lacks a color, use the closest one. Consistency within a tree matters more than exact matches across trees.
• If a deep dive needs a node type or arrow style the full tree does not have, use it and explain it in the deep dive's own legend.
• If a group knows a relationship matters, draw it, whatever kinds of nodes it connects.

The tree describes the present

A tree is a map of the problem space as it is now. When a problem is resolved, delete it. Do not mark it done. History should live in saved copies of earlier versions, not in the current tree.

In practice:

• Save a copy before every major update, labeled with its date or planning cycle. No other version control is needed.
• Schedule a deliberate removal pass when updating. In practice, resolved problems linger unless someone looks for them.
• Read the differences between versions. A problem that persists for 3 cycles is telling you something.

A tree is alive while it is useful

A tree does not need perpetual maintenance. It is alive while it is generating understanding. When people stop returning to it because they are busy acting on what they learned, the tree has done its job. That is success, not abandonment.

A tree is a mind map, not a monument. Some trees live for a single session. Others are revived at every planning cycle for years.

In practice:

• Do not maintain a tree for its own sake.
• Bring a tree back when the problem space persists and a new planning cycle begins. See a living document.
• Archive the final version instead of deleting it.