Addressing Harmful Behavior from High-Performing Engineers
How to distinguish respectful dissent from harmful conduct and respond with evidence, fairness, and appropriate accountability.
Student edition · understand, apply, verify
Address harmful workplace behavior with observable evidence and a fair process, even when technical results are strong.
What you should be able to do: Separate respectful dissent from documented harm, protect affected people, and follow appropriate confidential accountability.
Context-dependent people-management guidance, not a universal HR/legal policy or verified autobiographical record. Work from observable behavior, explicit expectations, appropriate privacy, fair support/accommodations, and your organization's qualified process. Example outcomes are illustrative, not guaranteed.
Concepts explained in this guide
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
SBI feedback and observable behavior
Situation–Behavior–Impact frames feedback around context, observed action, and its effect. Ask for perspective and agree a concrete change.
Example. 'In Tuesday's review, you interrupted two explanations; we missed rollback discussion. What was happening, and how can we finish those discussions next time?'
A shared belief that asking questions, reporting mistakes, or disagreeing can happen without humiliation or retaliation. It supports learning alongside clear standards.
Example. A junior engineer reports a suspected fault early; the lead examines evidence instead of attacking the person.
Boundary. It does not mean universal comfort/agreement or no accountability. Power, incentives, and context shape who can speak safely.
Coaching, delegation, and expectations
Coaching develops reasoning through questions, practice, and feedback. Delegation transfers defined work/decision responsibility with support. Expectations make outcomes and behaviors explicit.
Example. Delegate a design decision with authority, constraints, check-in, and escalation trigger—not hidden standards.
Boundary. Match support to experience/risk. Performance policies and legal requirements vary; no universal PIP timeline or personality label is a fair diagnosis.
Outputs, outcomes, and measurement
Outputs are produced things; outcomes are changes for users/business/team. Useful metrics state definition, denominator, population, period, and attribution limits.
Example. 'Shipped a tool' is output. 'Median onboarding fell ten to six days in this cohort' is an outcome with sample/context caveats.
Boundary. Before/after does not prove sole causation. Avoid gaming, selection bias, hidden costs, and unlike-team comparisons.
Ownership, accountability, and decision rights
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
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.
The spine: separate impact from behavior → give direct, specific feedback → set a non-negotiable bar → reduce single-point risk → support change but be decisive → protect the team throughout.
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.
What the interviewer is looking for
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)
Practice draft: first-person narratives below are not independently verified autobiographical evidence. Use their structure, not their claimed results; replace with your genuine safe-to-share experience.
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.
Evidence to collect with your approved tools
A decision/review record with the problem, constraints, options, and your contribution.
Relevant tests, dashboards, or measurements with definitions, denominators, dates, and uncertainty.
Incident or delivery records showing actual outcomes and unresolved limitations.
Stakeholder agreements and follow-up actions with owners and review dates.
Only authorized, minimized, safe-to-share evidence. Do not copy confidential personnel notes into a public story.
Worked example: high output accompanies repeated intimidation
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
Sequence for this example. The table explains the evidence and decision at each step.
Step
Evidence, decision, and expected result
Document behavior, not a label
Use specific reported/observed incidents and context; do not call disagreement or cultural difference 'toxic'.
Protect safe reporting
Provide appropriate channels, confidentiality limits, and nonretaliation; follow qualified investigation procedures.
Set clear expectations and support
Explain unacceptable conduct and impact, hear the response, and follow organization policy.
Evaluate fairly
Technical output does not excuse harmful behavior. Decisions require evidence and approved process, not a manager's personal dislike.
Check your understanding: Should a 'culture fit' judgment replace behavior evidence?
No. Use specific job-relevant expectations, equitable standards, context, and qualified process.
Practice with your own situation
Write the expected outcome/behavior, observed evidence, context and alternative explanations, your agreed support/action, decision owner, review date, and evidence that would change the plan. Keep confidential personnel material out of public examples.
Use genuine, safe-to-share evidence. Example numbers here illustrate reasoning; they are not claims about your work or a guaranteed outcome.
