The Fully Interconnected Graph Organization
Replace hierarchy with peer-to-peer routing by hiring nodes smart enough to self-organize
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 72%
Every organization is a communication network, and network topology is a design choice. The traditional answer to rising communication overhead is a tree: CEO, SVPs, VPs, middle managers. That keeps everyone marching in one direction but adds politics and makes it abnormal for a leader to speak to an engineer several levels down. The alternative topology is a fully interconnected graph: everyone talks to anyone, with a light hub-and-spoke overlay where one person holds the whole task in their head. The catch is a hard constraint on the inputs. In networking, a fully connected graph requires every node to be highly intelligent, so the org version requires hiring only people who can route themselves to whoever solves their problem. Coordination tooling largely disappears; direct conversation replaces it. The output is speed and low politics, bought at the cost of some chaos and a much narrower hiring filter.
Origin
Naval describes how his current company, Impossible, is actually run: a flat, hub-and-spoke structure with no Slack, no project management software, and people texting each other directly. He frames it explicitly as a computer-networking topology choice rather than a management philosophy.
Core principles
- 01Hierarchy is a response to size, not a virtue in itself.
- 02Communication overhead is the real constraint on org design.
- 03A fully connected network only works if every node is highly intelligent.
- 04Tools do not fix coordination; the right people routing themselves does.
- 05People who cannot navigate ambiguity belong in a hierarchy, not here.
How to run it
- 1
Name the topology you are actually running
Decide whether your team is a tree (hierarchy), a hub-and-spoke, or a fully connected graph. Most orgs drift into a tree by default because it is the standard answer to communication overhead.
Pro tip Ask how many hops a question takes to reach the person who can answer it. That number is your topology.
- 2
Keep the group small enough for full connectivity
The fully interconnected graph is only viable below the size where communication overhead swamps the work. Beyond that, hierarchy becomes a requirement of size rather than a choice.
Watch out Do not run this topology past the point where everyone can hold everyone else in their head. It degrades into chaos, not autonomy.
- 3
Install one light hub
Designate a single person, usually the CEO or lead product owner, who carries the whole task in their head and whom everyone can interface with. This is an overlay on the graph, not a reporting tree.
Pro tip The hub's job is holding context, not approving decisions. If it becomes an approval queue you have rebuilt the tree.
- 4
Hire only nodes that can self-route
Screen for people who will find the right colleague, start the conversation and navigate to a solution without being told. Intelligence and communication ability are the load-bearing requirements of the topology.
Pro tip In interviews, describe an ambiguous cross-team problem and watch whether the candidate asks who owns it or starts solving it.
- 5
Strip the coordination tooling
Remove the chat and project-management layers that exist to route information the network can route itself. Keep only what the work genuinely needs, such as a code host.
Pro tip Removing a tool is a diagnostic: whatever breaks was being held together by process, not by people.
Watch out Do not strip tooling first and hope the culture follows. The hiring bar has to be in place before the scaffolding comes off.
- 6
Treat mis-fit as a routing problem and act on it
If someone cannot navigate their way to the person they need or cannot cooperate directly with peers, they do not belong in this structure. The honest move is to help them find a hierarchical organization where they will be more comfortable.
Watch out Keeping one non-routing node forces the rest of the network to build process around them, which is how the tree grows back.
In the wild
Naval's current company keeps a very flat structure with his co-founder as the single hub, one product manager holding the whole task in his head. There is no Slack and no project-management software; the only shared tool is GitHub. When people need each other, they text directly and talk one-on-one. It is sometimes chaotic and people have to navigate their own way to a resolution, but he treats that navigation as part of the required skill set rather than as a failure of process.
→ A small team of independent contributors ships a hardware-plus-software product without an explicit coordination layer.
In a conventional hierarchy, a CEO talking to an engineer two or three levels down is treated as a notable act requiring a special mode of leadership. Naval points at this as sarcastic proof of the cost of the topology: the tree keeps everyone marching in one direction, but it makes the most ordinary useful conversation in a company into an exception that needs a name. In a fully connected graph, the same conversation is the default and needs no permission.
→ Direct leader-to-builder contact becomes routine rather than a celebrated intervention.
Common mistakes
Removing hierarchy without raising the hiring bar
The topology assumes every node is highly intelligent and self-routing. Flattening a team of people who need escalation paths produces stalled work, not autonomy.
Letting the hub become an approval bottleneck
The single person in the middle exists to hold context, not to gate decisions. Once everything routes through them for sign-off, you have rebuilt the tree with one fewer layer.
Running the graph past its size limit
Hierarchy is a requirement of size. Past the point where communication overhead dominates, insisting on full connectivity produces chaos rather than speed.
Is it for you?
Best for
Small teams of highly capable independent contributors building something technically hard.
Not ideal for
Large organizations, or teams staffed with people who need explicit process and escalation paths to function.
From the transcript
“Instead, I like the fully interconnected graph.”
“The thing about a fully interconnected graph in networking is that every node has to be highly intelligent.”
“We keep a very flat structure. We try to push people to communicate with each other directly. We don't even use Slack if that gives…”
From the episode
'Nothing Ever Happens' Is Over