Managing a Toxic High-Performer
Final Prep · People Management — a technically brilliant, architecturally critical senior engineer has become toxic to the team’s culture and collaboration; how you address it without losing the team or the person.
This question tests your values under pressure — specifically, whether individual brilliance buys someone a pass on how they treat people. A weak answer tolerates the toxicity because the person is critical (“we needed them, so I managed around it”) or fires them impulsively and ignores the real architectural risk. A strong answer shows that you separate their impact from their behavior, give direct and specific feedback early, make clear that how they work is part of their performance, de-risk the team’s dependence on them so you’re not hostage to it, and then hold a real line — supporting genuine change but being decisive if it doesn’t come. Answer in CARL shape (Context, Actions, Results, Learnings), with most of your words on the actions.
What this question is really testing
Two things. First, your courage and values: will you have the hard conversation with your most powerful engineer, or will you protect yourself by tolerating behavior you’d never accept from someone more replaceable? The whole team is watching what you permit, and tolerating a “brilliant jerk” tells your best collaborators that culture is negotiable if you’re good enough. Second, your risk management: a good leader doesn’t let one person hold the team hostage through irreplaceability, so part of the answer is reducing the single-point dependency before it forces your hand. The classic failure is the manager who knows it’s a problem, keeps hoping it’ll resolve itself, and pays for it with the quiet attrition of everyone else.
How to answer- Separate impact from behavior. Be honest that the work is excellent and that the conduct is damaging — both are true, and the second doesn’t get erased by the first. Don’t let brilliance launder the toxicity.
- Give direct, specific feedback early. Name the behavior and its concrete effect — “in that review you dismissed X’s idea and two people stopped speaking up” — not a vague “be nicer.” Vague feedback to a literal-minded engineer changes nothing.
- Set a non-negotiable bar. Make it explicit that collaboration and respect are part of the job at their level, not optional extras — and that continued impact depends on both, with real consequences.
- Reduce the single-point risk. Spread the critical knowledge, document the architecture, and grow other owners — so the decision about their behavior is never distorted by fear of losing the system.
- Support change but be decisive. Give a genuine chance to change, with coaching and a clear window; if the behavior persists, act — and protect the team’s morale throughout, because inaction is itself a decision they can see.
- Refusing to let technical brilliance excuse toxic behavior.
- Direct, specific, early feedback rather than avoidance.
- Framing behavior as part of performance at a senior level.
- De-risking irreplaceability so you’re not held hostage.
- Decisiveness with a genuine chance to change, and care for the team.
A worked example (CARL)
Context. On the Ads Events storage team I had a senior engineer — genuinely one of the strongest system designers I’ve worked with, and the de facto owner of our most critical ingestion path. He was also becoming corrosive: dismissive in design reviews, quick to belittle ideas that weren’t his, and openly impatient with less-experienced engineers. I started noticing the second-order effects — two junior engineers had stopped proposing anything in his presence, a mid-level engineer told me in a 1:1 they were considering leaving, and people were routing decisions around him to avoid the friction, which is dangerous when he owned the most important system. I’d been slow to act because he was so critical, and I realized that hesitation was itself the problem.
Actions. I separated the two truths in my own head first, then said them plainly to him: your technical work is excellent and I value it, and your behavior is doing real damage to this team, and both of those are true at the same time. I didn’t soften it into “be more collaborative” — I gave him specific, recent examples: the review where he’d cut off a junior engineer, the pattern of two people who’d gone quiet, the decisions being routed around him. He was, as I half-expected, surprised — he saw himself as simply holding a high bar and hadn’t connected his behavior to its effect, which is common with literal-minded strong engineers. I made the bar non-negotiable and tied it to his own goals: at his level, multiplying the people around him is part of the job, and his impact and growth were now blocked not by his coding but by his conduct — senior scope requires senior behavior. In parallel, and deliberately, I reduced the team’s single-point dependence on him: I had him pair with and mentor two other engineers on the ingestion path, drove real documentation of the architecture, and started growing a second owner — partly for resilience, and partly so that neither he nor I would ever be making the behavior decision under the fear of losing the system. I gave him genuine support to change: concrete coaching on how to run a review that draws people out, direct in-the-moment feedback right after the next few reviews, and a clear window with checkpoints. Throughout, I protected the team — I reset the norm that everyone’s ideas got heard in reviews, I checked in with the two junior engineers and the flight-risk mid-level engineer, and I made clear by my actions that culture wasn’t up for negotiation regardless of how good someone was.
Results. He actually changed — more than I expected. The specificity of the feedback and the fact that it was tied to his own growth landed, and over the following couple of months the reviews visibly opened up; one of the junior engineers he’d shut down ended up co-owning a component with him. The de-risking paid off independently: the architecture was documented and a second owner emerged, so the ingestion path stopped being a single point of failure. The mid-level engineer who’d been considering leaving stayed. I’m clear-eyed that it doesn’t always end this way — if he hadn’t changed, I was prepared to act, and because I’d spread the knowledge I could have afforded to.
Learnings. My real mistake was the delay — I’d let his criticality buy him a pass for too long, and the team noticed. The lesson I carry: brilliance never buys a pass on behavior, and the fear of losing an irreplaceable person is a signal to reduce the irreplaceability, not to tolerate the toxicity. Specific feedback tied to the person’s own growth, plus a genuine chance to change backed by a real willingness to act, is what makes the hard conversation both fair and effective.
Common follow-ups
What if they’re truly irreplaceable and refuse to change?
How to answer- Treat irreplaceability as the risk to fix. Start spreading knowledge and growing owners immediately, so “we can’t lose them” stops being true.
- Count the real cost. One toxic person driving out several good engineers is a net loss, even if they’re your best individual contributor.
- Hold the line anyway. If the behavior persists after a genuine chance, acting protects the team; tolerating it tells everyone culture is for sale.
- Sequence it. De-risk first, then decide — so the decision is made on values, not under hostage pressure.
What if they don’t see the behavior as a problem?
How to answer- Use specific, recent examples. Replace “you’re dismissive” with the exact review and the exact effect — concrete evidence is harder to dismiss.
- Show the second-order impact. Point to the people who’ve gone quiet or are routing around them; make the cost visible.
- Tie it to their goals. Frame behavior as the thing now blocking their own growth and scope, not as a personality critique.
- Separate intent from impact. Acknowledge they may mean to hold a high bar, and be clear that impact is what the team experiences.
How do you protect the rest of the team while you work on this?
How to answer- Reset the norms openly. Re-establish that everyone’s ideas get heard, so people see the culture is being defended, not just discussed.
- Check on the affected. Talk to the people who went quiet or are flight risks; make sure they feel seen and supported.
- Don’t discuss the plan. Keep the individual’s coaching private, so the team trusts you’d handle anyone the same way.
- Act visibly enough. Your willingness to have the hard conversation is what tells the team their experience matters more than one person’s brilliance.
How is this different from managing an underperformer?
How to answer- The gap is behavior, not output. The work is strong; the problem is conduct, so the bar you set is about collaboration and respect.
- The risk is concentrated. A critical high-performer creates a dependency an underperformer doesn’t — de-risking is a first-class step.
- The stakes for the team are cultural. Tolerating it signals that values are negotiable, which erodes your best collaborators fastest.
- Same discipline, though. Specific feedback, a clear bar, a genuine chance, and decisiveness apply to both.
- 1:1 notes — pull the flight-risk signals from other engineers and the running feedback trail with the individual.
- Peer / 360 feedback — pull the collaboration and behavior signals that made the pattern objective, not just your read.
- Perf / calibration records — pull the framing of behavior as part of senior-level performance and impact.
- GSD / design reviews — pull the ownership concentration and the de-risking work (docs, second owner) on the critical path.
- Workplace / review threads — pull the review interactions that showed the behavior and, later, the more open collaboration.