The Hire That Almost Broke the Team

What you actually need to know

• Technical skill and collaboration skill are independent variables. The engineer who is a 9 on technical skill and a 3 on collaboration can be net negative to team output.
• The early warning signs of a culturally damaging hire are visible in the first 30 days if you are looking for them. Most managers miss them because the technical contribution is positive.
• Direct behavioral feedback with specific examples is the intervention. Character-based feedback ("you are dismissive") produces defensiveness; behavior-specific feedback ("in PR #234, you wrote X, which had Y effect") produces a change or a clear decision.
• The decision to part ways is often delayed too long. The team pays the cost of each additional month in reduced psychological safety and increased attrition risk.
• The rebuild after a damaging hire requires explicit acknowledgment, not just removal. Teams need to hear that leadership saw what happened.

The core argument

The engineer I am describing -- technically excellent, terrible collaborator -- is not a hypothetical. They are a real pattern that engineering managers encounter often enough to have a name for in some engineering circles: the brilliant jerk. The term is overused and sometimes applied to engineers who are merely direct or demanding in ways that are unfamiliar to a team. The pattern I am describing is more specific: an engineer whose interaction style systematically reduces the psychological safety and collaborative capacity of the team around them.

The reason this hire is so damaging is the attribution problem. The damage is felt individually and attributed individually. The engineer who receives a dismissive code review attributes the discomfort to their own code quality. The engineer who is passed over for credit in a team communication attributes it to their own visibility. The junior who does not get mentorship attributes it to not asking for it often enough. Each person experiences the damage in isolation and does not connect it to a pattern of behavior from a single source.

The manager who has visibility into the whole team -- who hears the code review feedback, who sees the team communication, who notices the junior who has gone quiet in retrospectives -- can see the pattern that no individual team member can see. This is the manager's responsibility: to see the systemic impact of individual behaviors, not just the individual performances.

I have seen this pattern play out on engineering teams I was part of as a collaborator and on teams I was brought in to assess after the damage was already done. The common thread: the warning signs were present in the first month and were not acted on because the technical contribution was positive and the cultural damage was not yet visible as a systemic issue.

What the warning signs look like in practice

Dismissive code reviews are the most common early signal. The engineer leaves comments like "this is wrong," "terrible naming," "why would you do this," or "this code is unreadable" without explaining the specific problem or suggesting an alternative. These comments are not useful feedback -- they do not tell the author what to change or why. They are signals of a review style that prioritizes expressing judgment over improving the code.

A single dismissive comment is not a pattern. Three dismissive comments in the first two weeks, with no subsequent correction after the first occurrence is brought to the engineer's attention, is a pattern.

Absence of questions is a subtler signal. Engineers who are new to a codebase have questions about design decisions, conventions, and context. The engineer who arrives and makes confident changes without asking questions is either extraordinarily good at reading codebases or is not checking their assumptions. Usually the latter, which produces changes that are confidently wrong in ways that are only visible after the change is in production.

Attribution in communications is a social pattern that requires attention to team communications to notice. The engineer who describes team accomplishments to leadership in first-person ("I shipped the new API design") when the work was collaborative is either unaware of how it sounds or is deliberately shaping the narrative. Either way, the team members who were part of the work feel the attribution asymmetry.

The feedback conversation

The feedback conversation that is most likely to produce a behavior change is specific, behavioral, and non-judgmental about character. The structure:

"In the code review for PR #234 on Tuesday, you wrote 'this function is terrible.' Sarah spent two hours trying to understand what the problem was and revised the function three times before asking me what you meant. She still is not sure she addressed the issue.

"Here is what I need from code reviews: specific feedback that names the problem and ideally suggests a direction. 'This function is doing X and Y, which makes it hard to test. Consider extracting X into its own function' is the level of specificity that helps.

"Is there anything preventing you from giving feedback at that level of specificity?"

The question at the end is important. It leaves room for the engineer to identify a barrier (they are working too fast in reviews, they are uncertain how direct to be) rather than interpreting the feedback as a personal attack. The barrier, if it exists, can be addressed. The behavior, if it does not change after the feedback and a reasonable period, is the basis for a serious performance conversation.

The decision to part ways

The decision to part ways with a technically strong, culturally damaging engineer is one of the most difficult management decisions because the technical contribution is visible and the cultural damage is not. The engineer is delivering features. The team is shipping less because psychological safety is reduced, but this reduction is invisible unless you measure it.

The measurement: track code review participation (are engineers reviewing each other's code, or are reviews only coming from one person?), track junior engineers' contribution over time (are they growing, or are they going quiet?), and track 1-1 conversations for references to the specific engineer. The pattern in this data -- reduced participation, junior stagnation, repeated references to a specific person in contexts that signal discomfort -- is the evidence that the cultural damage is real and compounding.

The decision threshold: the behavioral feedback has been given specifically, a clear expectation was set, a reasonable improvement period was given (4-8 weeks), and the behavior has not changed in a sustained way. At this threshold, the parting is justified regardless of the technical contribution, because the technical contribution is being offset by cultural damage that is reducing the output of the entire team.

Common mistakes managers make with this pattern

1. Waiting too long before giving specific behavioral feedback. The first instance of dismissive code review behavior should produce a specific feedback conversation within the week. Waiting for a pattern to become undeniable before addressing the first instance allows the pattern to become harder to reverse.
2. Giving character-based feedback instead of behavior-based feedback. "You are dismissive" produces defensiveness. "In PR #234, you wrote X, which had Y effect" produces a behavior change or a clear decision.
3. Not protecting the team from the damage while managing the behavior. The engineers who are being affected need to know that the behavior is being addressed without details of the performance management conversation. A simple "I am aware of the feedback patterns and am working on it" reduces the team's sense of powerlessness.
4. Attributing the team's reduced output to other causes. The team that has a culturally damaging engineer will be less productive than a team that does not, and this productivity reduction will appear in velocity metrics. If velocity has declined since a specific hire, the connection should be investigated.
5. Not acknowledging the damage explicitly after the hire is no longer on the team. The team that went through this experience needs to hear that it was recognized, not just that it ended.

Where to start: a 3-step cultural damage assessment

Step 1: Review the last 30 days of code review comments from each engineer on the team. Look for comments that are adjective-heavy ("terrible," "messy," "wrong") versus behavior-specific. The engineer whose reviews are consistently adjective-heavy without specifics is providing feedback that demoralizes rather than improves.

Step 2: Ask each team member individually in their next 1-1: "Are there any team dynamics that are affecting your work?" The question is broad enough to be non-accusatory but specific enough to surface the pattern if it exists. The same name appearing across multiple 1-1s is a diagnostic signal.

Step 3: If the pattern is confirmed, conduct the behavioral feedback conversation within a week. Do not wait for more examples. The conversation should include the specific examples you have already observed, the clear expectation for future behavior, and the explicit statement that a change is expected.

The Team That Rebuilt

Yashveer Singh. Founder of Yashveer Labs. I have been on both sides of this pattern -- as a team member who experienced the reduced psychological safety and as a collaborator brought in after the resolution to assess what happened. The teams that recovered most fully were the ones where leadership acknowledged the dynamic explicitly in a team conversation, named the impact it had on individuals, and asked what would have been helpful. The acknowledgment gave team members permission to name their experience rather than carrying it privately. The teams that did not have that conversation took significantly longer to rebuild the trust that the hire had damaged.

Related reading

• The Engineering Hiring Bar: How to Set and Hold It
• The First Thirty Days: Setting a New Developer Up for Success
• The Engineering Performance Review That Engineers Find Useful
• The Engineering Values That Survive Hyper-Growth