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.
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"
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:
- Removal. Resolved problems are deleted. In the example, laptop setup was automated, so the problem and the action both left the tree.
- Addition. New problems, outcomes, actions, and artifacts appear. "New hires wait weeks for system access" was not on anyone's mind in April.
- Restructuring. Arrows are removed and redrawn as understanding shifts. The group learned that the buddy program also helps new hires ship, so a new arrow connects them. Sometimes the whole shape of the tree changes.
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:
- A problem that persists for 3 cycles is telling you something. It may be deeper than it looks, or the actions aimed at it may not be working.
- An outcome that stays blocked despite actions aimed at it is a signal to change approach.
- A wave of new problems may mean the problem space itself has shifted, and the tree's scope needs a fresh look.
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.
- Keep saved copies unchanged. Edit only the current version.
- Name the previous version in the current tree's legend, so readers know where to look for history.
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:
- At the start or end of a planning cycle
- When a significant problem has been resolved
- When a significant new problem has emerged that the tree does not show
- Before a consequential decision that the tree should inform
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:
- People act on what it showed them without needing to look at it.
- The problem space has settled, so an update would change little.
- The tree's value now lives in the plans, decisions, and strategies it informed.
Archive the final version instead of deleting it. If the problem space comes back, so can the tree.