Efficiency assumes the future will resemble the past

Organizations are taught to be suspicious of redundancy. Two systems doing similar things? Consolidate them. Two people who understand the same process? Clarify ownership. Extra capacity? Improve utilization. A manual path beside an automated one? Eliminate it.

There are good reasons for this. Duplication can be expensive, confusing, and genuinely wasteful. But redundancy and waste are not the same thing. Treating them as though they are can make a system look more efficient at exactly the moment it is becoming more fragile.

Optimization works by learning what is unnecessary under known conditions. The problem begins when we mistake ‘not necessary under current conditions’ for ‘not valuable to the system.’ A second pathway looks unnecessary while the primary pathway works. Extra capacity looks idle until demand changes. Overlapping expertise looks inefficient until the person with singular knowledge leaves.

Efficiency asks how little a system needs to perform as expected. Resilience asks what the system needs when expectations stop being useful. Those are different design questions.

There is another function of redundancy that gets less attention: innovation requires more than one possibility to remain alive.

If every resource is committed to current execution, every role is fully utilized, every process has one approved path, and every technology must justify itself through immediate efficiency, where exactly is the new thing supposed to come from?

Real experimentation contains redundancy almost by definition. For a period of time, an old way and a new way may coexist. Two teams may approach the same question differently. Someone may investigate an idea that produces nothing useful. A prototype may duplicate functionality that already exists because the point is not yet efficiency; the point is learning.

Eventually some paths should disappear. Redundancy does not mean preserving everything forever. It means allowing multiple possibilities to exist long enough to discover which future is worth building.

Sometimes execution is really escalation

I see a particular pattern in organizations that have optimized away too many alternate paths: execution starts to depend on escalation.

The normal process works until something falls outside it. Then a manager resolves the exception. A director negotiates between teams. An executive makes a call because the system itself cannot. From the outside this can look like strong execution. Things keep moving. Leaders are responsive. Problems get solved.

Look more closely and the organization may be borrowing flexibility from hierarchy. If ordinary work repeatedly requires extraordinary intervention, escalation is not merely a leadership behavior. It is information about the architecture.

Capacity that looks unused may already be doing work

We tend to recognize capacity only when it is visibly producing something. But some capacity does its most important work by remaining available.

It absorbs an unexpected customer issue without derailing everything else. It gives someone time to notice a pattern rather than simply process the next task. It allows a team to help another team without abandoning its own commitments. It gives an organization somewhere to put an opportunity it did not predict.

Adaptation rarely announces itself as a planned project. It arrives as interruption. When every person, system, and process is optimized for maximum utilization, interruption has nowhere to go.

Ask what the redundancy is for

None of this means more redundancy is always better. Redundancy has costs. Multiple systems can create conflicting sources of truth. Unclear ownership can make accountability disappear. Too many paths can create cognitive load rather than resilience.

The useful question is not whether redundancy exists. It is what function it performs. Does it create a fallback? Distribute knowledge? Absorb variation? Preserve choice? Create room to experiment? Or is it simply duplication whose purpose disappeared years ago?

That leads to a different kind of optimization: decide deliberately where a system should be lean and where it should have room.

Sometimes what looks like excess is not excess at all. It is where resilience lives. It is where learning happens. It is where a system keeps enough possibility available to become something it has not been before.

Redundancy is also a way of knowing

I have written before that a system with no single point of failure needs overlapping knowledge: if there are two jobs that matter, two people need enough familiarity to cover them. The alternative is often one person doing two jobs, running from one broken thing to another while the organization calls that efficiency.

Standardization can create capacity. Automation can create capacity. But neither eliminates the need for slack. In a young team, clear standards can be one of the best gifts we give people because they reduce unnecessary cognitive load. The point is not to make every path identical. It is to make the stable parts stable enough that people have somewhere to stand when reality changes.

The person is not the database

Organizations often discover key-person dependency at the moment someone leaves. The response is usually documentation: write down the process, record the walkthrough, move files into the shared drive.

Documentation matters. It also captures only part of what the person was holding.

Knowledge includes judgment

Experienced people know which rule matters in which circumstance. They know when a dashboard is wrong, which customer exception is genuinely risky, who needs to be consulted before a change, and what happened the last time the organization tried something similar.

Much of that knowledge is relational and contextual. It cannot be transferred by listing steps alone.

Dependency is architecture information

A person becoming indispensable can be flattering to the person and dangerous to the system. Often it means several interfaces have collapsed into one human being.

They are not only doing their job. They are translating, remembering, routing, reconciling, and absorbing ambiguity for everyone around them.

The answer is not to make every person interchangeable. Expertise is valuable precisely because it is not generic.

The design goal is to make expertise legible enough that the system can learn around it: shared context, overlapping knowledge, explicit decision principles, relationships that extend beyond one person, and time for others to practice before the expert disappears.

If the organization stops working when one person leaves, the question is not only what that person knew. It is what the system had quietly asked them to become.

I once wrote a blunt version of this problem: no single point of failure. If you have two jobs, you need two people who know enough about each other's work to cover it. Instead, organizations often have one person doing two jobs, which works beautifully if everyone is fully staffed and nothing ever breaks.

Shared capacity does not mean making people interchangeable. It means allowing knowledge to cross-pollinate before a crisis forces the transfer. Rotations, paired work, shared relationships, and overlapping context can make an organization less dependent on heroic memory without erasing expertise.