Toxic high performer: when firing is cheaper than fixing

There's an engineer on the team everyone treats as irreplaceable. Their code is cleaner than anyone's, they see the architecture two years out, they catch the bugs in review that everyone else missed. And the same person stalls releases for months because "you can't ship that, it's a hack," rewrites other people's work without asking, and rolls their eyes in stand-up when the PM brings up deadlines. To them a business task is an annoying obstacle to clean architecture.

And you catch yourself on a thought you're ashamed to say out loud: what if the team would actually be better off without them?

I had exactly this engineer. The strongest on the team — and for almost six months I kept telling myself we couldn't manage without them. They wouldn't touch business tasks: saw them as dirt on top of the "right" architecture, rewrote other people's PRs, tore juniors apart in review until two of them stopped offering ideas at all. I held on because their code genuinely was the best on the team. I let them go — and a month later the team moved faster, not slower. That was my biggest lesson in the role: one person's clean code isn't worth everyone's speed.

Strong doesn't mean net positive

Here's the uncomfortable truth: a toxic high performer — the brilliant jerk — can produce brilliant code and still drag the team into the red. They stall other people's tasks, rewrite what already worked, turn every review into a battlefield. A team's speed isn't measured by its strongest member — it's measured by how much everyone else spends cleaning up after them and routing around them.

A star who chases perfect code at the expense of the goal isn't really about quality at all. It's about priorities that have drifted away from what the team is for. Product needs to test a hypothesis in two weeks; they spend six months building the "right" abstraction for load that doesn't exist and might never arrive. Clean code is a means — and they've made it the end.

The numbers almost nobody counts

The Harvard study by Housman and Minor (58,542 workers) put a number on it. Replacing one toxic worker costs roughly $12,500 — not "per month" or "per year," but a one-off turnover cost: people quit because of them, and hiring and onboarding the replacements costs money. And it's a floor — lawsuits, lost productivity and blown deadlines aren't even in it. For comparison, a top-1% superstar adds about $5,300 a year (though that's contribution, not turnover — the two figures aren't strictly comparable, and "toxic" there is defined more narrowly, as outright misconduct rather than perfectionism). You can argue the exact sum; the order of magnitude you can't: one person can cost the team more than its best one brings in. And a toxic high performer is often both at once.

When you keep one for the sake of their code, you pay a hidden price: the people who don't want to work with them leave quietly; juniors don't grow because they're scared to open a PR; you burn hours mediating instead of doing your own job. The bill just never arrives as a single number — it's smeared across quarters, which is exactly why it goes unnoticed.

Fix first, cut last

Firing isn't the first move, it's the last. Before you decide, give the person an honest shot:

• name the behavior directly — not "you're toxic," but "you've held the merge for three days over style, and that costs the team a sprint";
• spell out that business value is part of the job, not a betrayal of engineering;
• give a concrete, checkable plan and a deadline.

Sometimes the person simply didn't see how it read from the outside — and they change. Then you've kept a strong engineer, which is the best outcome. But if nothing moves after a direct talk and a plan, it's not a misunderstanding — it's that their values and the team's goal don't line up. And at that point "fixing" further is just deferring the inevitable at everyone else's expense.

How to let a strong one go — properly

The mechanics are the same as in any parting: no surprise, short, with dignity. But a star comes with two wrinkles of its own.

• Bus factor. They genuinely know things nobody else does. Don't announce the decision until you've pulled the critical knowledge into docs and pairing sessions — otherwise you're firing yourself an incident next week.
• The team's reaction. Half will exhale, half will panic: "they cut the best one — so who's safe?" Say it plainly: they didn't go for being strong, they went for how they worked with people. That matters — otherwise the team learns that strength gets punished, not behavior.

FAQ

What if they're genuinely irreplaceable? Nobody's irreplaceable — some people are just undocumented. If one person leaving topples the system, that's not their strength, it's your risk (the bus factor), and you have to defuse it either way — whether you keep the star or not.

Can't I just keep them with money or a promotion? If it's about behavior and values — no. Money buys a couple of months of quiet, then the same talk repeats, only pricier. A counter-offer fixes "I'm underpaid," not "I think business tasks are dirt."

What do I tell the team so they don't panic? Short and direct: they didn't go for being strong, they went for how they worked with people. No detail, no "leadership decided." Otherwise the team concludes that strength gets punished here.

How fast should I make the call? Not fast. A direct talk and a checkable plan with a deadline come first. The "cut" decision only holds if nothing moved after an honest chance. Speed matters later — in the knowledge handover, not in the verdict itself.

Bottom line

A strong engineer is not a free pass. If someone carries the code but wrecks the team and ignores the very thing the team exists for, sometimes it's both more honest and cheaper to part ways than to spend years fixing it. This isn't a call to swing the axe: a direct talk and a real chance come first. But once the chance is played out and nothing's changed, don't drag it — you're making it worse for everyone, yourself included.

And you can run this decision — and the talk itself — ahead of time, with no real team on the line.