Why good systems survive average people

Organizations that survive long-term share a trait: their systems are designed for average people, not heroes.

The hero problem

Every organization has heroes. The person who knows the legacy system. The one who closes impossible deals. The engineer who ships miracles under pressure.

Heroes are valuable. They're also dangerous.

When an organization relies on heroes, it's not the heroes who are the problem. It's the dependence. Heroes burn out, leave, or get hit by buses. When they go, they take critical knowledge with them. And the organization stumbles.

This is why hero-driven organizations are fragile. They work brilliantly when the right people are in the right place. They collapse when those people aren't.

What good systems do

Good systems assume competence, not excellence. They're designed so that an average person, following the process, gets a reliable result.

Examples:

McDonald's — A teenager can make a burger that tastes identical to one made by a veteran. Not because the teenager is skilled, but because the system is robust.
Aviation checklists — Pilots use checklists not because they're forgetful, but because checklists reduce error under pressure.
Code reviews — A junior engineer can catch bugs in a senior's code. Not because they're smarter, but because the process creates accountability.

Notice what these have in common: the system does the heavy lifting. People execute, but the system ensures quality.

Why systems fail

Most systems fail because they're designed around heroes, not for average people.

A common pattern:

A hero solves a recurring problem brilliantly.
The organization says, "Great! Can you document that?"
The hero writes a guide.
The guide assumes the reader thinks like the hero.
Average people can't follow it.
The organization concludes, "People just don't follow process."

The problem isn't people. It's that the process was never designed for them. It was designed for someone exceptional, then handed to everyone else.

Designing for average

Designing for average doesn't mean dumbing things down. It means removing unnecessary complexity.

Ask:

Can this be a checklist? — If yes, make it one. Checklists don't require interpretation.
Can this be automated? — If yes, automate it. Automation doesn't forget.
Can this be constrained? — If there are ten ways to do something, and nine are wrong, remove the nine.
Can this be tested? — If someone follows the process, is there a way to verify they did it right?

The goal is to make the right thing easy and the wrong thing hard. Not through enforcement, but through design.

The excellence trap

Organizations often resist designing for average because it feels like settling. "We hire the best. Why design for mediocrity?"

Two reasons:

First, even excellent people have bad days. They're tired. Distracted. Under pressure. A good system supports them when they're not at their best.

Second, excellence scales poorly. You can't hire ten heroes. Or a hundred. At scale, you need systems that work with whoever shows up.

The paradox: the best people want good systems. Because good systems free them to focus on problems that actually require excellence, instead of wasting cognitive energy on things that should be routine.

What lasts

Organizations built on heroes don't last. When the hero leaves, the knowledge leaves. When the knowledge leaves, the capability leaves.

Organizations built on systems last. Not because the people are better, but because the system carries the knowledge. New people can step in. The machine keeps running.

This is why franchises outlast restaurants. Why open-source projects outlast individual developers. Why institutions outlast individuals.

It's not that people don't matter. It's that systems make people replaceable. And replaceability, counterintuitively, is what makes organizations resilient.

The right role for heroes

So where do heroes fit?

Heroes are system improvers, not system replacements. When a hero solves a problem, the next step shouldn't be "keep solving it." It should be "encode the solution so the next person doesn't need to be a hero."

This is the difference between organizations that grow and organizations that plateau. Growing organizations convert heroics into systems. Plateauing organizations rely on heroics indefinitely.

The test: if your best person quits tomorrow, does the work continue? If not, you don't have a system. You have a dependency.

Conclusion

Good systems survive average people. Great systems turn average people into reliable contributors. Exceptional systems free excellent people to work on things that matter.

Stop designing for the hero. Design for the person who shows up tired, distracted, and just trying to get through the day.

That's who actually runs your organization.