Your High Performers Are Leaving Because You're Punishing Competence
Month 3
Your payment gateway crashes on a Friday evening. You know who to call. She's the only one who understands the legacy integration well enough to diagnose it under pressure. She fixed it last time, too.
By Saturday morning, it's resolved. Monday standup, you thank her publicly. "Went above and beyond this weekend." The VP sends a Slack message. Heart emoji.
You don't file a post-mortem. There's nothing to post-mortem: the system went down, she fixed it, the release shipped. You make a mental note that she's reliable. You move on to the next sprint.
What you don't do: ask why a single person was the only one who could fix it. Invest in having someone else learn the integration. Question why the migration was approved without a rollback path. These don't occur to you, because from your perspective the system is working. She fixed it. The metrics are green.
Her git log has commits at 11 PM on Saturday. Her timesheet shows eight hours. The sprint review says "above and beyond." No record exists of the structural failure that required it.
Year 1
She asks about the new product team. She's interested in the domain. She's been on the payment gateway for eight months and she'd like to grow.
You understand. But the timing is wrong. The legacy integration has a major upgrade coming. She's the only one who knows the codebase well enough. Moving her now would put the project at risk. You tell her: "Maybe next quarter. Let's get through the migration first."
This is a rational decision. The risk of moving her is visible and immediate. The risk of keeping her is invisible and long-term.
Her development review mentions "deepening expertise in payment systems." You approve a conference registration. She comes back knowing more about a domain she already knows better than the conference speakers.
The developers who are competent but not exceptional rotate to new projects, learn new technologies, build broader skills. Their careers develop. She watches this from inside the payment gateway.
The bus factor is still 1. It has been 1 for a year now. No investment has been made in developing a second person, because there's never a good time: she's always in the middle of something critical. Nobody flags this as a risk, because she's still there. It looks like stability.
Year 3
She hands in her notice. You are genuinely surprised.
Her exit interview says "career growth opportunity." You process this through the only machinery available: retention analysis. Maybe the salary wasn't competitive. Maybe the benefits need updating. You briefly consider a counteroffer.
The actual reason is simpler. She has been fixing the same system for three years. Every quarter, you said "maybe next quarter." The work stopped being interesting two years ago. The salary was fine. The conditions were fine. But when the only thing missing is growth, everything else starts to feel like compensation for a cage.
You hire two people to replace her. This confirms what the structure already knew: one person was doing the work of two.
The two replacements take six months to reach productivity. During that time, the legacy system is fragile, incidents take longer to resolve, and you wonder what happened to your team culture.
Nothing happened to your culture. Your culture was always the output of your structure. One person absorbed the overcommitment. When she stopped absorbing, the structure became visible.
What you just watched
Three snapshots. One trap.
You made a rational decision to assign the best person to the hardest problem. The decision created a dependency. The dependency made the next rational decision (keep her there) even more rational. Each quarter, the cost of moving her grew. The investment in alternatives never happened. The longer she stayed, the harder she was to move.
Nobody designed this. No one sat in a room and decided to lock the best engineer into her current role. The structure decided. The review template rewards deep expertise. Capacity planning assumes stable assignments. The risk calculus can see the cost of moving her but not the cost of keeping her. You made individually defensible decisions. The system assembled them into a cage.
Deming named the mechanism sixty years ago as Disease 3: "One gets a good rating for fighting a fire. If you do it right the first time, you are invisible." The system makes prevention invisible and heroic rescue visible. So it optimizes for rescue.
The most capable of her two replacements will gradually become the new critical person. The trap will start forming again. In three years, you will express the same surprise at the same resignation.
The person you're thinking of right now
You already know who this is. The person on your team who would cause the most disruption if they resigned tomorrow. The one everybody calls critical. The one who fixed the thing last time.
Four questions.
How long have they been in their current role, and did they choose it or drift into it?
If they wanted to transfer tomorrow, could they? Or would the answer be "we'd need to find a replacement first"?
In their last development conversation, was a structural change discussed (new role, new domain, expanded authority) or just more depth in the current role?
What is the bus factor for their capability? If it's 1, how long has it been 1, and what has been invested in developing a second person?
If the answers make you uncomfortable, the trap is already built. The exit interview hasn't been written yet. The question is whether you dismantle it now, or read the resignation and call it a retention problem.