Menu: Reference

A living document

How a tree is reviewed, updated, and eventually retired.

A tree changes with its problem space

Most problem-mapping exercises produce a snapshot that is filed away after a few weeks. A Tree of Influence can do more. When a problem space persists across planning cycles, the group brings the tree back, updates it, and keeps using it.

Each version describes the present. Resolved problems are deleted, not marked done, and history lives in saved copies of earlier versions.

The onboarding tree in April 9 nodes and 8 arrows: 5 root / problem, 2 action / intervention, 2 desired state / outcome. A text version follows the diagram. [P]Documentation isout of date [P]Each teamonboardsdifferently [P]Setting up alaptop takes aweek [P]Senior peoplehave no time tomentor [A]Automate laptopsetup [P]New hires areafraid to askquestions [A]Assign each newhire a buddy [O]New hires shipsomething intheir firstmonth [O]New hires feelwelcome andconfident Legend [P] Root / Problem [A] Action / Intervention [O] Desired State / Outcome Flow: roots (bottom) → outcomes (top). Context: onboarding, April 2026.
April: the tree as the group first built it.
Diagram as text: The onboarding tree in April

Nodes:

  • Root / Problem: "Documentation is out of date"
  • Root / Problem: "Each team onboards differently"
  • Root / Problem: "Setting up a laptop takes a week"
  • Root / Problem: "Senior people have no time to mentor"
  • Root / Problem: "New hires are afraid to ask questions"
  • Action / Intervention: "Automate laptop setup"
  • Action / Intervention: "Assign each new hire a buddy"
  • Desired State / Outcome: "New hires ship something in their first month"
  • Desired State / Outcome: "New hires feel welcome and confident"

Arrows:

  • "Each team onboards differently" influences "Documentation is out of date"
  • "Setting up a laptop takes a week" influences "Automate laptop setup"
  • "Senior people have no time to mentor" influences "New hires are afraid to ask questions"
  • "Senior people have no time to mentor" influences "Assign each new hire a buddy"
  • "Documentation is out of date" influences "New hires ship something in their first month"
  • "Automate laptop setup" influences "New hires ship something in their first month"
  • "New hires are afraid to ask questions" influences "New hires feel welcome and confident"
  • "Assign each new hire a buddy" influences "New hires feel welcome and confident"
The onboarding tree in October 8 nodes and 8 arrows: 5 root / problem, 1 action / intervention, 2 desired state / outcome. A text version follows the diagram. [P]Each teamonboardsdifferently [P]Documentation isout of date [P]New hires waitweeks for systemaccess [P]Senior peoplehave no time tomentor [P]New hires areafraid to askquestions [A]Assign each newhire a buddy [O]New hires shipsomething intheir firstmonth [O]New hires feelwelcome andconfident Legend [P] Root / Problem [A] Action / Intervention [O] Desired State / Outcome Flow: roots (bottom) → outcomes (top). Context: onboarding, October 2026. Previous version saved as "April 2026".
October: laptop setup is solved and gone. System access is a new problem. The buddy program turned out to help new hires ship, so a new arrow appeared. Mentoring time is still the deepest root.
Diagram as text: The onboarding tree in October

Nodes:

  • Root / Problem: "Each team onboards differently"
  • Root / Problem: "Documentation is out of date"
  • Root / Problem: "New hires wait weeks for system access"
  • Root / Problem: "Senior people have no time to mentor"
  • Root / Problem: "New hires are afraid to ask questions"
  • Action / Intervention: "Assign each new hire a buddy"
  • Desired State / Outcome: "New hires ship something in their first month"
  • Desired State / Outcome: "New hires feel welcome and confident"

Arrows:

  • "Each team onboards differently" influences "Documentation is out of date"
  • "New hires wait weeks for system access" influences "New hires ship something in their first month"
  • "Senior people have no time to mentor" influences "New hires are afraid to ask questions"
  • "Senior people have no time to mentor" influences "Assign each new hire a buddy"
  • "Documentation is out of date" influences "New hires ship something in their first month"
  • "New hires are afraid to ask questions" influences "New hires feel welcome and confident"
  • "Assign each new hire a buddy" influences "New hires feel welcome and confident"
  • "Assign each new hire a buddy" influences "New hires ship something in their first month"

What changes between versions

An update can change a tree in 3 ways:

What does not change is just as informative. "Senior people have no time to mentor" is still the deepest root.

The value of continuity

The lineage between versions shows what persisted, what was resolved, and what emerged:

For example, if a tree mapped a product line's technical debt over 2 years and most of its problems persisted from the first year to the second, it tells us as much about the nature of deep problems as about the work done in between.

Saving versions

Save a copy of the tree before every major update, labeled with its date or planning cycle: "Onboarding tree, April 2026." That is all the version control a tree needs.

Removal needs attention

In practice, resolved problems tend to linger. Comparing observed trees across years showed very few nodes removed between versions. Some problems truly persist, but others stayed simply because nobody went looking for them.

Make removal a deliberate step of every update. Walk every problem node and ask: "Is this still true?"

The vocabulary can grow too

A tree's notation may get richer as the group gets more experienced. In one long-lived tree, the attacks relationship appeared in the second year, once the group had started mapping artifacts. That kind of growth is healthy when it comes from need. Update the legend whenever it happens.

When to update

Bring the tree back:

There is no need to update continuously. A tree is reviewed deliberately, not maintained constantly. For running the update with a group, see evolving the tree.

When a tree is done

Not every tree lives for years. Many are built for one purpose, deliver enough understanding for people to act, and then fade. That is the natural lifecycle, not a failure.

Signs a tree has finished its work:

Archive the final version instead of deleting it. If the problem space comes back, so can the tree.