Every hero is a bug.
A strong team isn’t the one with the best individuals. It’s the one that would barely notice losing any single person.
The idea, sharpened
A strong team isn’t about how many people you have, how talented they are, or how clever the org chart looks. It’s about one thing: how much of your important work depends on a single point — and that point doesn’t have to be a person.
A team where only one person can deploy, only one person understands billing, and only one person holds the CEO’s trust looks strong — but it’s fragile, wearing a strong team’s clothes. And the same is true of a team where only the AI model can explain the code, or only the low-code platform knows what a change will touch. A team at level 1 runs on heroes — human or otherwise. A team at level 5 runs on roles, and can lose any single person, tool, or vendor without losing the ability to get the work done.
So the leader’s job is not to hire stars or to talk people into caring more. It’s to find, one by one, the weak spots that everything depends on, and fix them. Every “only Priya can do that” is not proof of a valuable employee. It’s one weak spot everything depends on — a flaw with a person’s name on it.
A role is not a person with a title. It’s a piece of work pulled out of the one person who does it — written down, backed up, handed to others — so the person can be replaced and the work keeps going.
The hero doesn’t have to be human
This is the version of the problem most teams are building right now. Teams hand whole jobs to an AI (“the model handles that”) or to a platform (“the low-code tool does that for us”) — and feel like they’ve solved their hero problem. They haven’t. They’ve swapped a hero with a name for a hero with a logo. If nobody on the team can explain how the system works without asking the model, the knowledge monopoly is still there — it has just moved somewhere you can’t train, back up, or promote.
“Only the model knows” is level 1, the same as “only Priya knows.” A person’s knowledge can be written down and spread; a platform’s opacity is a term of service.
The right way to use AI in this column: AI’s best job is helping the team learn — not doing the work for them. Point it at writing the material down, generating the onboarding path, producing the explanation on demand. Use the AI as the tutor that gets understanding into more heads — never as the only head that has it.
The two questions that sort any job
- 1 How many people can do it — one, two, or many?
- 2 How much breaks if that person isn’t there?
The whole game: move important jobs out of the top-right box.
The runbook
Make “two people, minimum” the default — in writing.
No important job may rest on a single person. If you don’t write the rule down, the default quietly becomes “whoever knows it, owns it forever.”
Build the things that spread the work out.
Runbooks and architecture docs; pairing and shadowing; on-call rotations; clear roles with real authority; named, practising backups; written onboarding. This is the investment.
Keep the “can’t-replace-them” list short — treat each name as a bug.
There will always be a few one-of-a-kind people. Name them out loud, and keep an active plan to make the list shorter.
Spread out the say-so, not just the knowledge.
Sharing knowledge while keeping all the decisions to yourself just moves the bottleneck. Give roles the clear power to decide within their area.
Measure the team itself.
How many people could do each important job (should rise); how much runs through your best people (should fall); how long a new hire takes to work unaided (should fall).
The numbers worth watching
The strongest teams aren’t the ones with the best individuals. They’re the ones that would barely notice losing any single person.