If your team performs well when you are present and something quietly stops when you are not, this piece is for you. The fragility isn’t a temporary state. It is a structural feature of a system that concentrated capacity in one node and never named it. The fix is not a contingency plan. It is a design principle.
The scenario is hypothetical but the planning conversation is real.
Before any serious technical climb, there is a conversation that experienced expedition leaders have and inexperienced ones skip: what happens if I am incapacitated? Not in the abstract. Specifically. If I am the most experienced person on this rope and I cannot lead, what does this team do?
The question is uncomfortable because it requires the leader to name something most leaders prefer not to name. The degree to which the team’s navigational capacity is concentrated in a single person. The leader who cannot answer specifically, who says “the team would figure it out” or “someone else would step up,” has just disclosed something important about the fragility of the system they have built.
The team that can answer specifically, the next lead is named, the anchor manager is named, the decision to continue or descend is made by group consensus with a defined tiebreaker, has built something different. Not just a team with a backup plan. A team with distributed navigational capacity. A system that can route around damage.
The mycelium network works because there is no central node. Information travels through the network via whatever path is available. When one node fails, the network routes around it. The system is resilient precisely because it was never dependent on any single point.
Most organizational teams are the opposite of mycelium. They are hub-and-spoke systems with the leader at the hub, whether or not anyone has named it that way.
The concentration problem
The Liability of the Lead Climber piece in this library named the pattern. The most experienced person on the team accumulates knowledge, relationships, and decision authority in ways that make the team’s capability conditional on their continued presence. This happens naturally, without malice, as a consequence of being genuinely useful.
The result is a team that performs well under normal conditions and becomes suddenly, surprisingly fragile when the leader is unavailable. Sick, traveling, departed, promoted. The fragility was always there. The normal conditions concealed it.
In a technical climbing environment, leader incapacitation is not a theoretical contingency. It is a realistic scenario that every serious team plans for. The organizational equivalent is stranded in a different way, but stranded nonetheless. The team that cannot make significant decisions without the leader, cannot navigate client relationships without the leader, cannot access institutional knowledge that lives only in the leader’s head.
“The fragility was always there. The normal conditions concealed it.”
What distributed capacity actually looks like
The mycelium network is not a leaderless system. It has no center, but it has structure. Distributed nodes, each capable of routing information, each connected to multiple others, none of which is the single point through which everything must pass.
The organizational equivalent is not flat hierarchy or consensus decision-making. It is the deliberate distribution of three specific capacities that most organizations concentrate in the leader by default.
The first is navigational knowledge. The understanding of where the team is going and why, precise enough that any team member could explain it accurately to someone outside the team. Most organizations fail this test. When the leader is unavailable, the team cannot navigate because the map lives in one head.
The second is relationship capital. The connections to the people and systems outside the team that the team depends on. In most organizations these connections route through the leader. When the leader is unavailable, the team cannot access the external network because the leader is the network.
The third is decision authority. The explicit permission to make specific categories of decision without escalation. Most teams have this only at the trivial level. When the leader is unavailable, significant decisions queue. The queue costs time the organization may not have.
Distributed capacity means each of these three is deliberately spread across the team before it becomes necessary. Not as a contingency plan but as a design principle.
Building the network
The expedition practice is specific and transferable. Before a serious climb, the experienced leader does three things that most organizational leaders never do.
They narrate their reasoning out loud, specifically to the people who will need to replicate it. Not “here is the decision” but “here is what I am looking at, here is what I am weighing, here is what would change my conclusion.” The narration is not for the current decision. It is to build the decision-making model in the heads of the people who will make decisions when the leader cannot.
They create redundant relationships deliberately. The client has a relationship with at least one other team member. The executive sponsor knows at least one other person on the team by name. The cross-functional counterpart has a direct connection to someone other than the leader. The network is not a wheel. It is a mesh.
They make explicit the decision boundaries. The specific categories of decision that any team member can make without escalation, the ones that require consultation, and the ones that require the leader specifically. And then they practice it. They remove themselves from decisions they could make, specifically so the team builds the muscle of making them.
This is not delegation in the conventional sense. It is network building. The deliberate construction of a system that routes around the absence of any single node, including the leader.
“This is not delegation in the conventional sense. It is network building. The deliberate construction of a system that routes around the absence of any single node, including the leader.”
The question most leaders don’t ask
If you were unavailable for three weeks starting tomorrow, not reachable, genuinely out, what would happen to your team?
Not to the work in general. Specifically: which decisions would queue? Which client relationships would go cold? Which institutional knowledge would become inaccessible? Which navigational questions would go unanswered?
The answers to those questions are the single points of failure in your team’s architecture. Each one is a node that has no redundancy. Each one is the lead climber’s knowledge, uncopied.
The mycelium network has survived for hundreds of millions of years because it never evolved a central node. The leader in a mycelium-structured team is not the hub through which everything passes. They are one node in a network that can function without them.
That team can answer the question before the climb. Can yours?
THE TEAM TEST
Tomorrow, without warning, you are unavailable for three weeks.
Name the three decisions that would queue waiting for you. Now ask: what would it take for someone else on the team to make each of those decisions confidently and correctly? What knowledge would they need? What relationships? What explicit permission?
Name the two client or stakeholder relationships that would go cold. Who else on the team knows those people well enough to maintain continuity? If the answer is nobody, you have a single point of failure in your external network.
Name the institutional knowledge that only you hold. The reasoning behind a key decision, the history of a relationship, the understanding of a constraint that isn’t written down anywhere. When did you last narrate that knowledge out loud, specifically so that someone else could carry it?
The lead climber who falls and takes the team’s navigational capacity with them is not the leader who planned poorly. They are the leader who never asked what happens when they fall.
Ask it now, while the weather is good.
