Every team I have managed or assessed in fifteen years of commerce engineering has had one. The person who moves fastest. The person who holds the most context. The person everyone routes questions to because they always have the answer. The person you would describe in a performance review as indispensable.
That word should scare you.
Indispensable is not a compliment. It is a risk statement. It means your team cannot function at full capacity without a specific individual. And you are probably rewarding the exact behavior that makes the problem worse.
How it happens
Strong performers accumulate context naturally. They ship faster, so they get assigned more complex work. They are reliable, so they become the default owner of critical-path items. They understand the system deeply, so other team members route questions through them instead of reading the docs (which may not exist, because the strong performer moves too fast to write them).
None of this is malicious. It is rational behavior at every step. The developer is not hoarding knowledge. The manager is not being negligent. The system is producing a local optimum that is a global risk.
The strong performer becomes load-bearing infrastructure. And like all load-bearing infrastructure, the failure mode is not gradual degradation. It is sudden collapse when the single point disappears.
What the collapse looks like
It rarely looks like the person quitting, though that happens. More commonly:
They take two weeks of PTO and three workstreams stall. Not because the work is hard. Because nobody else has the credentials, the context, or the relationships with the adjacent teams to unblock the next step.
They get pulled onto an emergency on another project and the current project loses a week of velocity while the rest of the team figures out what they were doing.
They burn out. Quietly. The person carrying the most load is the last person to complain about it and the first person to start interviewing somewhere else.
In each case, the organization acts surprised. It should not be. The risk was visible. It was just wearing the costume of high performance.
The management failure
The failure is not hiring a strong performer. The failure is optimizing around them instead of distributing what they know.
Here is what optimizing around them looks like:
- Assigning them the hardest work because they will ship it fastest.
- Not pairing them with junior developers because pairing slows them down.
- Not requiring documentation because they are “always available to answer questions.”
- Celebrating their output in standups without asking who else could do what they do.
Here is what distributing what they know looks like:
- Rotating them off a workstream after two sprints, even if they are the fastest person on it.
- Pairing them with someone else on every complex integration, even when it costs velocity this sprint.
- Making documentation a deliverable, not a courtesy. If it is not written down, it is not done.
- Running a quarterly exercise: “If this person left tomorrow, what would we not be able to do?” Then fixing the top three items on that list.
The first approach produces better short-term output and higher long-term risk. The second produces slightly lower throughput and a team that survives contact with reality.
Why this is hard to fix
Three reasons.
First, the strong performer often resists distribution. Not out of ego (usually). Out of efficiency. Teaching someone else takes longer than doing it themselves. They are right, in the short term. But “I will just do it myself” is the sentence that builds single points of failure.
Second, the manager is measured on output, not on resilience. Nobody gets promoted for “reduced knowledge concentration risk on the checkout integration workstream.” They get promoted for shipping on time. So the incentive is to let the strong performer run.
Third, the organization conflates the person with the capability. “We need to retain Sarah” when what they actually mean is “we need three people who understand the OMS integration, and right now Sarah is the only one.” Those are different problems with different solutions. One is a compensation conversation. The other is a knowledge management conversation.
The test
Pick the strongest performer on your team. Ask yourself: if they gave two weeks notice on Friday, which of the following would you lose?
- Access to critical systems or environments
- Understanding of a key integration’s behavior under edge cases
- Relationships with an adjacent team or vendor that the rest of your team does not have
- The ability to debug a specific subsystem in production
- Context on why a design decision was made (not what it is, but why)
If the answer is more than one of these, you do not have a retention problem. You have a distribution problem. And the time to fix it is while the person is still on your team, not after they leave.
The strongest performer on your team is doing great work. Your job is to make sure the team can do great work without them.