Introduction
When you discuss something, what kind of structure do you imagine underneath the discussion?
I suspect many people naturally assume a tree with a limited scope. There is a root topic, branches beneath it, and the discussion proceeds inside one branch at a time. When the conversation drifts, someone says "let's come back to the topic." When another branch appears, someone cuts it off as "a separate issue."
This attitude is generally preferred in practice. It appears to keep the discussion under control, and it appears to make meetings easier to time-box. People often say that, when explaining something, it is kinder to reduce it to a tree.
But I do not like that premise at all. More strongly, I think it is wrong to proceed with a discussion as a tree.
The essential structure of information is a graph, and a tree is only a partial structure inside it. To proceed with a discussion as a tree is often to drop edges that were really there, then treat that missing structure as the official one.
And those dropped edges come back later under the name "insufficient consideration."
Trees Are Wrong
Borrowing the language of graph theory, a tree can roughly be understood as a connected graph with no cycles. In other words, a tree is a special kind of graph. The graph comes first; the tree is what you get after imposing strong constraints on it.
I think the same relationship holds for information. It is not that there is information that naturally belongs in a tree. It is that information simple enough to fit in a tree can sometimes be treated as a tree. And discussions are almost never that simple.
One piece of information does not necessarily have only one parent. One issue does not necessarily belong under only one root. One piece of evidence does not necessarily complete itself inside a single branch.
Even the file system shows this problem immediately. Should a file live under "work," under "personal research," under "2026," or under a specific project? The answer is usually just a convenience of the moment. Once you pick a single parent, you lose the naturalness of the other contexts. That is why we use search, tags, links, shortcuts, and things like symbolic links as escape hatches.
This is not merely a UI preference. Forcing information into a tree places a strong, and often wrong, assumption on the shape of that information.
This problem is old. In As We May Think, published in 1945, Vannevar Bush imagined a future for mechanically handling records and described ideas like associative trails through related records. In today's language, that imagination is deeply hypertextual and graph-like.
You can see the same direction in modern tools. Obsidian's Graph view visualizes notes as nodes and internal links as edges. Scrapbox was renamed Helpfeel Cosense in 2024, but its spirit of growing knowledge through loosely linked pages is much closer to a graph than to a tree.
What these examples show is the obvious fact that information cannot be handled by parent-child relationships alone. I want to be just as strict about this in discussion.
Why People Prefer Trees
So why do people prefer tree-shaped discussions so much?
The reason is simple: human working memory is limited.
George A. Miller's famous paper The Magical Number Seven, Plus or Minus Two is a classic reference point for the limits of human information processing capacity. But the number "seven" should not be worshiped too casually. In The magical number 4 in short-term memory, Nelson Cowan reframes short-term memory capacity as a smaller problem, roughly three to five chunks.
Cognitive Load Theory also describes how, in complex tasks, too many interacting information elements can overwhelm capacity-limited working memory.
So it is natural for people to feel, "please make this simpler," "please narrow the issue," or "let's only talk about this for now." That is not evil. In many cases, it is an important form of care toward the listener.
But there is one thing we must not confuse.
The fact that humans can handle only a small amount of information at once and the claim that the problem itself can be represented as a small tree are completely different.
The former is a limitation of the receiver. The latter is a claim about the structure of the object. Mixing them up is dangerous.
Trees are preferred not because they are correct. They feel comfortable only because the human processing system is narrow.
Comfort and correctness are different things.
Wrong Tree-Shaking
When working with people, evaluations like "smart person" or "clear communicator" are often given to people who can reduce and simplify information to the necessary and sufficient amount for the moment.
I understand that evaluation. Someone who can adjust the order of explanation to match the listener is genuinely strong.
But adjusting the order of speech and transforming the structure of the discussion into a tree are different things. The former is choosing a traversal over a graph. The latter is deleting edges from the graph.
Very few people can actually do the latter correctly.
To decide what can be dropped, you already need to see the whole graph. Whether an edge is unnecessary for the current explanation, or whether it is an important dependency that will later overturn the decision, cannot be judged by looking only at a tree-shaped slice.
In many cases, people are not performing necessary and sufficient simplification. They are simply dropping the edges they cannot process. This is wrong tree-shaking.
They think they are removing unused code, but they are actually deleting an import with side effects. The same thing happens in discussion.
Treating something as "not the current topic" when it was actually a precondition
Treating something as "a detail" when it actually determines feasibility
Treating something as "another team's problem" when it actually defines the responsibility boundary
Treating something as "emotional" when it is actually a signal that consensus is about to fail
Then, later, things mysteriously do not work. Understanding mysteriously diverges. The specification mysteriously flips.
That happens because an edge that mattered was dropped during the discussion.
Focus Is Also a Graph Operation
Of course, I am not saying that you must say all information out loud at once. Humans do not have that much working memory, and speech and writing both have order.
The important thing is not to treat focus as deletion.
Focus is a viewport over a graph. You choose the node to center, choose the depth, and look at that range. But you do not pretend that everything outside the viewport does not exist. This is not a tree. You are still looking at the graph as a graph; you are only changing the center and radius of the view.
When someone says "let's only discuss this for now," what they should mean is:
We are looking at this node with depth 1 for now.
When someone says "that is a separate issue," what they should mean is:
This is a different node, but the edge remains.
When someone says "we will discuss that later," what they should mean is:
This edge is not closed, so we will come back to it.
But in actual discussions, the word "focus" is often used to mean "let's pretend this does not exist." That is bad.
There are times when we only look at part of the graph. But the object we are looking at remains a graph until the end. Do not transform the graph into a tree.
Discussion Is a Dependency Graph
The graph I am talking about here is not an undirected graph where everything is scattered equally. Discussions have fairly strong directionality.
To claim A, B is required.
If C is true, D becomes weaker.
E is a concrete example of F.
G depends on the definition of H.
I constrains the feasibility of J.
K may break consensus around L.
These edges exist. In other words, discussion is a dependency graph more than a parent-child relationship.
When you force this dependency graph into a tree, you are forced to make an unnatural choice about what the parent should be. And that parent is usually decided by the meeting organizer, the document heading, the ticket size, the org chart, or the power dynamics of the moment.
But information dependencies do not obey such things.
So I am not saying graphs have no direction. I am saying that treating them as one-way parent-child relationships is wrong. Discussion should proceed as a dependency graph. You can be conscious of which edge you are following right now, but you must not say "there is nothing outside this branch."
Externalize It
To proceed with discussion as a graph, you do not need to rely only on the human brain. In fact, trying to process everything only inside the brain is exactly what makes people want to fold things into trees.
If the bottleneck is human working memory, the thing to solve is not "make the problem look smaller." It is externalize the graph.
In that sense, attempts to treat discussion as a map are important. For example, Dialog Mapping is described as a way to record the questions, ideas, and pro/con arguments that arise in a conversation as a shared network-like map. The IBIS background behind it is also close to the idea of treating discussion not as a mere bullet list, but as relationships among questions, proposals, and reasons.
Of course, you do not need a dedicated tool every time. What matters is that the graph visible during the discussion is preserved somewhere.
For example:
Name issues as nodes
Give edges types
Treat "we will come back to this later" not as a verbal promise, but as an unresolved edge
Treat "separate issue" not as deletion, but as a link
At the end of the discussion, check whether any edges were dropped
Even that much changes a lot.
We do not need to fear complexity itself so much. If something complex looks complex, that may be the correct display. What we should fear is making a complex thing look simple and deleting important dependencies in the process.
Do Not Confuse Reading Order with Structure
At least as the internal representation of a discussion, I want to say: throw away the tree.
When writing an article, giving a presentation, or onboarding someone, order becomes necessary. Headings become necessary. You need to decide where to start reading and where to go next.
But that is not a tree. That is a traversal order over a graph.
A genuinely good explainer keeps the graph as a graph, then chooses the path to follow at that moment. That is why, when the listener asks a different question, they can move to another path. When the premise changes, they can change the traversal. When an edge was temporarily outside the view, they can bring it back as soon as it becomes necessary.
A bad explanation, by contrast, mistakes the path for the structure. It drops edges that were not followed, forgets that it dropped them, and eventually starts believing that the order of explanation is the world itself.
That is dangerous.
What we need is the ability to keep the graph as a graph while choosing how to walk through it. And if that ability is not strong enough yet, we should preserve the graph itself before simplifying the walk.
Conclusion
Proceed with the discussion as a graph.
Of course, human working memory is limited. So viewports are necessary, and order is necessary.
But those are graph operations. They are not transformations into a tree.
The essential structure of information is a graph. A tree is only a partial structure inside it. Every time you fold a discussion into a tree, edges drop. When edges drop, dependencies drop. When dependencies drop, judgment fails.
If the bottleneck that prevents us from handling discussion as a graph is on the human side, I would rather work on extending the human side than carve the problem into pieces.
Externalize it. Link it. Preserve unresolved edges. Even when looking locally, do not stop treating it as a graph.
Keep the discussion as a graph. That does not mean "talk about everything at once." It means: do not pretend that edges you cannot currently see do not exist.