Tree of InfluenceEvolving the tree
When and how to review and update a tree across planning cycles.
This page covers the review session: the session that brings an existing tree back to a group and updates it. It explains when to hold one, how to prepare it, how to run it, and how to tell that a tree needs no more reviews. For what changes between versions of a tree and why that matters, see a living document.
When to review
A tree is reviewed deliberately, not maintained constantly. Hold a review:
- When a planning cycle begins or ends.
- 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.
The date of the first review is agreed during Close, along with the owner of the tree. The owner calls the review.
Before the review
- Save a copy of the tree, labeled with its date or planning cycle: "Renewals tree, September 2026." It is the only version control a tree needs. Keep the copy unchanged.
- Invite the group that built the tree, and anyone who has joined the problem space since. A new participant reads the tree with fresh eyes.
- Gather what happened since the last version: actions finished, numbers that moved, deep dives held, decisions made.
- Send the saved tree with the invitation, so participants read it before the session.
Running the review
A review is likely to be shorter than the session that built the tree, because the board starts full. The order of the steps is important, and you should ensure to run the removal before any addition.
- Go through every problem and ask whether it is still true, changed, or resolved. Nothing new goes on the board yet. This is the evolution pattern. Execute the steps detailed in the pattern.
- Restructure. Remove arrows that are not current, and draw new ones the group now sees. Some relationships will have changed, and sometimes the whole shape of the tree shifts.
- Vote again if the tree changed enough. The ranking from the previous cycle may no longer match the tree. See Prioritize.
- Close as in any session: read the tree back, update the legend with the new date and the name of the previous version, save the board, and agree on the next review.
What to look for
The comparison between 2 versions is a result in itself. Before the review closes, read it with the group:
| What you see | What it may mean |
|---|---|
| A problem still true for a second or third cycle | It is deeper than it looks, or the actions aimed at it are not working |
| An outcome still blocked, although its actions are finished | The actions were aimed at the wrong cause. Change the approach |
| Many new problems at once | The problem space has shifted, and the scope needs a fresh look |
| Almost nothing changed | The tree may have finished its work |
When to stop
Not every tree needs a next review. A tree is alive while it produces understanding. When people act on what it showed them and no longer come back to it, it has done its job.
Stop reviewing when:
- People act on the tree's priorities without needing to look at it.
- The problem space has settled, and a review 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. See a living document.
Example
See the evolution pattern.
Step 1 of 4. The releases and reliability corner, as saved in September.
Step 2 of 4. Removal. The morning peak is now load-tested every week, so the problem and its action leave the tree.
Step 3 of 4. Addition. The cause found in the deep-dive session joins the full tree, with its action.
Step 4 of 4. Restructuring. Ignored alerts do not start outages. They delay the moment the company notices one, so the arrow now points at how customers find out.
Diagram as text: The releases and reliability corner of the renewals tree, from September to December
Steps:
- Step 1: The releases and reliability corner, as saved in September.
- Step 2: Removal. The morning peak is now load-tested every week, so the problem and its action leave the tree. Changes: removed "Nobody has load-tested the morning peak", "Load-test the morning peak every week". arrows removed: "Nobody has load-tested the morning peak" influences "Outages hit during the morning dispatch rush"; "Nobody has load-tested the morning peak" influences "Load-test the morning peak every week"; "Load-test the morning peak every week" influences "No outages during the morning rush".
- Step 3: Addition. The cause found in the deep-dive session joins the full tree, with its action. Changes: added "The scheduler locks the whole jobs table", "Lock one job at a time, not the table". new arrows: "The scheduler locks the whole jobs table" influences "Outages hit during the morning dispatch rush"; "The scheduler locks the whole jobs table" influences "Lock one job at a time, not the table"; "Lock one job at a time, not the table" influences "No outages during the morning rush".
- Step 4: Restructuring. Ignored alerts do not start outages. They delay the moment the company notices one, so the arrow now points at how customers find out. Changes: new arrows: "On-call ignores alerts because most are noise" influences "Customers hear about outages from their technicians". arrows removed: "On-call ignores alerts because most are noise" influences "Outages hit during the morning dispatch rush".
After the last step:
Nodes:
- Root / Problem: "The scheduler locks the whole jobs table"
- Root / Problem: "Releases ship in big monthly batches"
- Root / Problem: "On-call ignores alerts because most are noise"
- Root / Problem: "Outages hit during the morning dispatch rush"
- Root / Problem: "Customers hear about outages from their technicians"
- Action / Intervention: "Lock one job at a time, not the table"
- Action / Intervention: "Alert only on symptoms customers feel"
- Desired State / Outcome: "No outages during the morning rush"
Arrows:
- "The scheduler locks the whole jobs table" influences "Outages hit during the morning dispatch rush"
- "The scheduler locks the whole jobs table" influences "Lock one job at a time, not the table"
- "Lock one job at a time, not the table" influences "No outages during the morning rush"
- "Releases ship in big monthly batches" influences "Outages hit during the morning dispatch rush"
- "On-call ignores alerts because most are noise" influences "Alert only on symptoms customers feel"
- "Alert only on symptoms customers feel" influences "No outages during the morning rush"
- "Outages hit during the morning dispatch rush" influences "Customers hear about outages from their technicians"
- "On-call ignores alerts because most are noise" influences "Customers hear about outages from their technicians"
The addition came from the deep-dive session on outages. The scheduler lock had waited on the sub-tree since September, and the group agreed that it belonged on the full tree.
The restructuring came from a problem that should have been gone. Every incident had had a communications lead since October, yet customers still heard about outages from their technicians. An engineering lead explained it: on-call ignores noisy alerts, so the company itself learns of an outage late. The arrow from ignored alerts moved, and so did the group's idea of where to act.
The group then voted again, with 3 votes each. "Releases ship in big monthly batches" came first. In September, it had received no votes at all.
The facilitator updated the legend to "December 2025. Previous version: Renewals tree, September 2025," saved the board, and set the next review for March.