There’s a conversation that every engineering leader has at some point. It usually starts with something like: “Yeah, they’re difficult, but they’re the only person who understands the billing system.” Or: “I know people find them hard to work with, but their output is incredible.” You nod along, because you’ve probably said something similar yourself. I certainly have.

The brilliant jerk problem is one of those leadership challenges that feels genuinely hard the first time you face it, and blindingly obvious in hindsight. Someone on your team produces exceptional technical work, maybe they’re the fastest coder, the one who understands the gnarliest parts of the system, the person who can debug anything. But they also make people feel small. They dismiss ideas with contempt. They create an atmosphere where others are afraid to speak up, ask questions, or challenge anything.

And for far too long, in far too many engineering organisations, we’ve treated this as an acceptable trade-off.

The Shape of the Problem

The brilliant jerk doesn’t always look like a cartoon villain. Sometimes they’re charming in one-on-ones with leadership and brutal in code reviews. Sometimes they’re perfectly pleasant until someone disagrees with them. Sometimes they don’t shout at all, they just radiate a quiet contempt that makes everyone around them feel stupid.

Camille Fournier describes this archetype brilliantly in The Manager’s Path, someone who produces outsized results but is ego-driven, creates fear and dislike, and bullies others with their intellect. She also talks about the closely related “Alpha Geek” anti-pattern: the technically brilliant person who has to be right about everything, who creates a culture of fear around technical decisions, and who treats every disagreement as a challenge to their intelligence.

What I found interesting when I started really digging into this was how many different forms it takes. It’s not always the loud, aggressive engineer. Sometimes it’s the person who simply refuses to communicate, what some leadership literature calls the “Noncommunicator” pattern. They hoard knowledge, they don’t explain their decisions, they make themselves indispensable through opacity rather than collaboration. The fear they create isn’t from aggression; it’s from the implicit message that if you can’t keep up, that’s your problem.

The common thread is this: one person’s behaviour is making the rest of the team worse. And the leader knows it, but hasn’t acted on it.

Why We Tolerate It

Let’s be honest about why this happens, because I think understanding the reasons is important if you want to stop making the same mistake.

The first reason is fear. Fear that the brilliant jerk is genuinely irreplaceable. Fear that the system they built will collapse without them. Fear that the team won’t be able to ship without their output. I’ve felt this fear myself, and it’s powerful. When someone has made themselves the single point of failure for a critical system, the idea of losing them feels existential.

The second reason is that their output is visible and their damage is invisible, at least at first. You can see the pull requests, the features shipped, the bugs fixed. What you can’t easily see is the junior developer who stopped asking questions three months ago. The mid-level engineer who’s updating their CV because they dread coming to work. The ideas that never get raised because everyone knows they’ll be shot down. The candidates who turned down your offer because they picked up on the atmosphere during the interview.

The third reason, and this is the one I think we talk about least, is that tolerating brilliant jerks can feel like a sign of sophistication. There’s a narrative in tech culture, thankfully fading, that truly great engineers are supposed to be difficult. That managing them is part of the job. That if you can’t handle their personality, maybe you’re not cut out for engineering leadership. This is nonsense, but it’s persistent nonsense.

The Real Cost

The research on psychological safety is pretty clear on this. Amy Edmondson’s work, and the studies that followed it (including Google’s well-known Project Aristotle), consistently show that psychological safety is the single most important factor in team effectiveness. Not individual talent. Not technical skill. The team’s collective ability to take risks, admit mistakes, and challenge each other without fear.

One person can destroy psychological safety for an entire team. That’s not hyperbole, it’s what the research shows, and it matches everything I’ve seen over twenty-five years of working in and leading engineering teams. It only takes one person who ridicules questions, dismisses ideas with contempt, or reacts to mistakes with anger to make everyone else shut down. And once people shut down, you’ve lost something that’s incredibly hard to rebuild.

I’ve watched this play out more than once. The pattern is remarkably consistent. The brilliant jerk’s direct output stays high, but everything around them degrades. Code reviews become rubber stamps because nobody wants the confrontation. Design discussions become monologues. Knowledge stays siloed because the jerk doesn’t share and nobody dares ask. New hires either adapt to the toxic dynamic or leave within six months. The team’s bus factor quietly drops to one.

The thing that really drove this home for me was watching what happens after a brilliant jerk leaves. I’ve seen teams that were struggling, missing deadlines, low morale, high turnover, transform within weeks of the difficult person departing. Not months. Weeks. People start talking in meetings. Ideas flow. Problems get raised early instead of being hidden. The team’s collective output goes up even though you’ve lost your “best” individual contributor.

That’s when you realise the brilliant jerk wasn’t carrying the team. They were suppressing it.

The Alpha Geek Anti-Pattern

Fournier’s Alpha Geek concept deserves specific attention because it’s so common in engineering. The Alpha Geek is the person who has to have the final say on every technical decision. They might not be overtly aggressive, sometimes they’re even well-liked personally, but they’ve created a dynamic where their technical opinion is effectively unchallengeable.

This is insidious because it looks like strong technical leadership from the outside. The Alpha Geek makes fast decisions. They have strong opinions. They know the codebase inside out. But what they’ve actually done is create a team that can’t function without them and can’t grow beyond them. Junior engineers don’t develop judgement because they never get to exercise it. Senior engineers leave because they want autonomy. The team’s technical direction is limited to what one person can envision.

When I started paying attention to this pattern, I noticed it’s often enabled by well-meaning leadership. We promote the strongest technical person into a lead role, we praise their decisiveness, and we don’t notice that “decisive” has quietly become “dictatorial.” By the time we see the damage, half the team has mentally checked out.

Acting Too Late

Mike Fisher makes a point in 97 Things Every Engineering Manager Should Know that stuck with me: when it comes to letting someone go, the common fears rarely materialise. We imagine catastrophe, the system will break, the team will panic, we’ll never find someone as good. In practice, systems are more resilient than we think, teams are more capable than we give them credit for, and the relief of removing a toxic presence outweighs the short-term disruption almost every time.

The pattern I’ve seen, both in my own decisions and in talking to other leaders, is that we almost always act too late. We give too many chances. We have too many “one more conversation” moments. We tell ourselves that the behaviour is improving when really we’ve just had a quiet week. And all the while, the team is paying the price for our indecision.

I’m not suggesting that the first step is always termination. There’s a process, clear feedback, specific expectations, genuine support for behaviour change. Some people genuinely don’t realise the impact they’re having, and a direct conversation can be transformative. But you have to be honest with yourself about whether you’re running a genuine improvement process or just delaying an inevitable decision because it’s uncomfortable.

Fournier’s advice on this is straightforward: openly refuse to tolerate bad behaviour. Not quietly. Not through hints. Not through hoping it’ll sort itself out. Make it explicit that technical brilliance does not buy exemption from treating colleagues with respect.

The Decision Framework

After going through this enough times, I’ve landed on a fairly simple framework for thinking about it:

First, separate the behaviour from the output. Acknowledge that the person is technically strong. That’s not in question. What’s in question is whether their net impact on the team is positive or negative.

Second, make the invisible visible. Talk to the team, not just about the difficult person, but about how they feel about the team dynamic generally. Look at your attrition data. Look at who’s stopped contributing in meetings. Look at who’s stopped submitting code for review. The damage is there if you look for it.

Third, be direct and specific with the person. Not “some people find you difficult” but “in yesterday’s design review, you told Sarah her idea was stupid. That’s not acceptable.” Give them a genuine chance to change, with clear expectations and a defined timeline.

Fourth, if the behaviour doesn’t change, act. Don’t wait for the perfect moment. Don’t wait until after the next release. Every week you delay is another week your team is suffering.

What I’ve Learned

The hardest part of this isn’t knowing what to do. Most leaders I talk to know exactly what they should do about their brilliant jerk. The hard part is doing it. It means accepting short-term pain for long-term health. It means potentially losing someone whose technical output you genuinely value. It means having deeply uncomfortable conversations.

But here’s what I’ve come to believe after watching this play out repeatedly: keeping a brilliant jerk is not a neutral decision. It’s an active choice to prioritise one person’s output over everyone else’s wellbeing and growth. It sends a message to your entire team about what you value and what you’ll tolerate. And that message is heard loud and clear, even if it’s never spoken aloud.

The teams I’ve seen do their best work have been teams where people felt safe to be wrong, safe to ask questions, and safe to challenge each other respectfully. No individual contributor, no matter how brilliant, is worth sacrificing that. The maths simply doesn’t work, one person’s output will never compensate for the suppressed potential of everyone around them.

Every leader I know who’s finally addressed their brilliant jerk problem says the same thing afterwards: “I should have done it sooner.” I’ve said it myself. The goal is to keep shortening that gap between knowing and doing, until eventually you catch it early enough that the damage is minimal.

That’s not being ruthless. That’s being responsible.