How do you talk to a strong engineer who hurts the team?

A strong engineer who hurts the team should hear that delivery and collaboration are one performance standard, not two scores that cancel each other. Name the excellent engineering result and the specific damage caused while producing it. Require a behavior change, offer relevant support, and state the consequence if the pattern continues. Brilliant code does not buy permission to make the team less capable.

What evidence shows both sides of performance?

Bring the real delivery strengths: the engineer resolved a scaling limit, reduced latency, and saved a launch. Then bring the cost: they rewrote a teammate's service without discussion, mocked review concerns, and caused two engineers to stop proposing changes in that area. Accuracy matters because denying their strengths makes the rest of your feedback easier to dismiss.

Do not rely on a stack of anonymous complaints. Use behavior you observed, review artifacts, decision history, and specific work effects. Protect people from retaliation, but avoid turning the conversation into “the team says you are toxic.” The engineer needs actions they can change and a standard the manager will enforce.

How do you say delivery does not cancel damage?

Say: “Your performance improvement was technically excellent and materially helped the launch. During that work, you replaced Eli's implementation without speaking to him and wrote that his approach was amateur in the review. He stopped owning the service, and the team lost context. I assess both the result and how your work affects team capability.”

Do not sandwich the concern until it disappears inside praise. The strength and damage belong in the same statement because the role requires both. A strong engineer may have been rewarded for rescue for years. Your clarity should end the bargain that extraordinary output purchases exceptions from ordinary conduct.

What team damage should you name?

Describe what became harder: fewer people can work in the service, design risk goes unchallenged, incidents depend on one person, or peers avoid raising bad news. These are engineering consequences. A team that looks fast because everyone defers to one brilliant person is fragile and often slower over a longer horizon.

Name people impact without speculating about intent. You can say two engineers withdrew their proposals after public ridicule. You do not need to claim the strong engineer wanted them silent. The work result is enough to require change.

What behavior change should you require?

Choose one or two actions tied to the pattern. Require the engineer to review without status attacks, discuss ownership before replacing work, and let the named owner present the next design. Avoid asking them to be nicer. The request must be visible in ordinary engineering work.

Set a near date. “For the next two reviews through October 24, comments must name technical risk and requested change without judging competence. Before altering another owner's service, get explicit agreement in the shared design note.” Ask them to restate the standard and identify any situation where they believe it cannot apply.

How should performance be assessed?

Do not average the dimensions into a misleading total. Severe conduct can make strong output unsustainable. Explain how your level expectations combine results and team effect. If your organization has formal conduct or performance rules, use them consistently rather than inventing a special deal for a valuable person.

What conversation sequence keeps the standard clear?

1. Name the strong result accurately.
2. Describe the harmful behavior precisely.
3. Connect it to team and system cost.
4. Ask for context without debating dignity.
5. State the required change.
6. Offer support that preserves responsibility.
7. Name the check date and real consequence.

A consequence is not a threat delivered for effect. It is the truthful next process if behavior continues, such as removal from a lead role or formal performance action under company policy. Consult the proper owner before promising a consequence. Empty warnings teach the engineer that delivery still wins.

What support is appropriate?

Offer help translating technical concern into useful review language, planning ownership before urgent work, or noticing when frustration rises. A coach or trusted senior peer may help if the engineer accepts the purpose. Support should improve behavior, not require teammates to absorb more harm while the star experiments.

Reduce conditions that reward rescue. Clarify ownership, protect review time, and stop celebrating solo heroics. The engineer remains responsible for their choices. The manager remains responsible for a system that may have promoted those choices for years.

How do you handle claims of exceptional standards?

If the engineer says others cannot meet their bar, inspect the technical claim. Raise team training or quality where needed. Then return to conduct: high standards require explanations, tests, and clear decisions, not contempt. A valid defect does not validate an attack on the person who wrote it.

Ask whether their method leaves the system stronger after they step away. If every result requires them to rewrite the work, their approach does not scale. Senior performance includes raising the quality and judgment around them. That is a harder standard than personally producing the best code.

What should happen at the follow up?

Review actual comments, ownership decisions, and teammate capability on the agreed date. Recognize both preserved technical rigor and changed behavior. Ask whether risks were still raised and whether named owners remained engaged. A quieter room is not success if everyone simply avoids the engineer.

If harm continues, act on the consequence you stated. Delaying because the engineer has another important deadline tells the team that the standard was optional. Protect delivery through transition planning, but do not make vulnerable teammates pay indefinitely for code only one person can produce.

How can you protect the team while change is being tested?

Do not leave the strong engineer as the sole reviewer or owner in the area where harm occurs. Add a second reviewer, clarify service ownership, and give teammates another route for urgent questions. These are sensible controls while behavior is uncertain. Explain role changes in work terms and avoid sharing private performance details.

Check privately with people who were directly affected, but do not ask them to coach the engineer for you. Ask whether current reviews are usable, whether ownership is respected, and whether any new event needs attention. Protect them from retaliation and follow the company's process when the behavior raises a formal conduct concern.

Keep important technical work moving through more than one person. Pair on the specialist area, record design decisions, and transfer operational access. This is not punishment. Any system that depends on one person is risky, and dependence makes managers more likely to tolerate harm. Reducing that dependence improves both engineering resilience and managerial judgment.

Watch for compliance that shifts damage into less visible channels. The engineer may write polite comments but block peers through private messages, withhold context, or seize work before review. Use artifacts and ownership outcomes rather than tone alone. The required result is a team that can contribute and challenge safely, not merely cleaner vocabulary.

Recognize changed behavior without declaring trust fully restored after one week. Say that the last two reviews named risk clearly and left the owner in control. Continue the agreed observation period. People who experienced the old pattern need repeated evidence before they will take technical risks around the engineer again.

If the engineer asks whether their job is at risk, answer truthfully within the process you actually control. Do not reassure them simply to calm the meeting, and do not invent consequences. State the expectation, the evidence window, available support, and what the applicable process says. Clarity is especially important when prior exceptional treatment made boundaries uncertain.

What if leaders want to make an exception?

Bring the full cost and the written standard to those leaders. Explain the delivery the engineer provides, the observed behavior, the effect on retention, ownership, review quality, and operational dependence, and the action already requested. Do not argue only from principle. Show why the exception weakens engineering results that matter to the business. Ask leaders to state explicitly which standard they propose changing and who will carry the resulting risk. If they decide to retain the engineer during a critical transition, require a bounded plan with protections, dates, and accountable owners. An indefinite exception is not a plan. Continue documenting facts and following applicable policy. Do not tell the team that leadership values delivery more than people, even if you are frustrated. Protect confidentiality, create alternate review and reporting routes, and communicate the work changes people need. If you are still expected to manage the engineer, give consistent feedback rather than becoming silent because senior leaders hesitated. Escalate through proper channels when conduct or safety requires it. The manager may not control every employment decision, but they do control whether harm is named accurately, whether teammates receive practical protection, and whether exceptional output is allowed to hide its real production cost.

What are common questions?

Related: having a difficult conversation with an engineer, talk to someone who treats junior engineers poorly, talk to someone who puts themselves first.

Prefer prepared conversations over memory alone? Explore iSilta features or try the product demo.