You know that moment in a retro when everyone is on mute? Not because the connection is bad. Because no one wants to speak first when that one person is in the room.
Or the PR review that left a junior engineer so shaken they stopped pushing code for two weeks. Or the Slack message that landed wrong, again. And when you finally pulled your most senior developer aside to ask what was going on, they paused before saying: “I’m thinking about leaving.”
You probably know who I’m talking about.
Every tech leader has (or had in the past) at least one. Technically irreplaceable, or so it feels. Brilliant output on paper. And quietly, steadily, making everything around them worse.
That’s the brilliant jerk problem. And the reason most leaders don’t fix it isn’t because they don’t care. It’s because they don’t know what they’re actually dealing with.
It’s Not Just a Personality Problem
The first thing most leaders do is frame it as a personality issue. “They’re just difficult.” “That’s how senior engineers are.” “They deliver, so what can I do?”
None of that is leadership. That’s avoidance with a professional label on it.
The brilliant jerk is not just a personality problem. They are a mirror. They show you exactly what your promotion system values.
Think about it. How was this person promoted? Tickets closed. Systems shipped. Bugs fixed. Technical output. That’s the ladder most tech organizations built, and they climbed it perfectly. At no point did anyone measure how they made others feel. At no point did anyone check whether junior engineers grew under their influence or quietly withdrew. The relational bar was never set. So why are we surprised it was never cleared?
There is also a second layer that is harder to admit. The brilliant jerk often reflects something back at the leader themselves. A version of who they used to be. A type of intelligence they still, somewhere, prize. That ambivalence makes it even harder to act. And every day of inaction is a decision. Just not a conscious one.
The Real Cost of Keeping Them
Before we get into what to do, let’s be honest about what it costs to do nothing.
Research from Harvard Business Review shows that avoiding one toxic employee saves a company more than hiring a superstar delivers. A single toxic person on a team can cost an organization over $12,000 in turnover costs alone, not counting the invisible losses: the junior developer who stopped speaking up, the senior engineer who started updating their LinkedIn, the retro that’s been on mute for three months.
Google’s Project Aristotle research identified psychological safety as the single most critical factor in team effectiveness, more important than talent, resources, or even clear goals. One person who consistently erodes that safety is not a net positive, regardless of how impressive their output looks.
And the retention cost compounds. Losing one person costs between 30 and 200 percent of their annual salary. When your best people leave because of someone else, that bill lands on your budget and your credibility.
So the next time you think “they deliver too much for me to act,” ask yourself: at what cost to everyone else?
Diagnose Before You Decide: The Wheel of Conflict
Before you schedule that conversation, you need to diagnose what you’re actually dealing with. Because the intervention depends entirely on the root. And most leaders skip this step.
In the CQ Leadership Method, we use the Wheel of Conflict as a diagnostic tool. It gives you three different frames to look through:
- Conflict of data – they genuinely don’t know the impact of their behavior. No one has ever made it concrete. This is fixable with clear, specific feedback.
- Conflict of structure – the behavioral standard was never set. No one contracted what “being a good engineer on this team” actually means beyond technical delivery. This is fixable with explicit contracting.
- Conflict of values – they fundamentally don’t believe relational skills matter. They think collaboration is inefficiency and feedback is politics. This one is harder. And it requires a different decision framework.
Knowing which one you’re in changes everything. A data conflict solved with a values-level intervention will fail. A structural problem addressed with feedback alone will land as a personal attack.
Take five minutes before any difficult conversation and ask yourself honestly: which type of conflict is actually present? You can read more about how to structure that conversation in the article on leading tough 1:1s as a tech leader.
PCM Lens: What’s Driving the Behavior?
Not all brilliant jerks are the same. And the intervention that works depends on understanding what’s underneath the behavior, not just what’s visible on the surface.
Through the Process Communication Model (PCM) lens, the most common profile you’ll encounter in a senior tech role is a Thinker or Persister base. And here’s what that matters:
A Thinker in distress goes into perfectionist attack mode. They become hypercritical, dismiss other people’s thinking as flawed, and build walls around their work. It looks like arrogance. Often, it’s actually a frustrated need for competence recognition. The system never told them that being technically brilliant was only part of the job, and now they’re overinvesting in the only dimension that ever got them seen.
A Persister in distress becomes rigid and judgmental. They push their approach, dismiss alternatives as inferior, and frame everything as a values conflict. They can come across as contemptuous. Often they’re operating from a deeply frustrated need to be trusted and respected for their commitment. Same surface behavior, very different root.
The intervention is different for each. Telling a Thinker to “be more collaborative” without giving them a structured, logical framework for what that means will land nowhere. Telling a Persister to “watch their attitude” without acknowledging their contributions will make things worse, not better.
If you want to understand how PCM maps to communication and distress patterns more broadly, start here.
The Missing Conversation: Contracting
Here’s the thing that most leaders miss. They try to fix the brilliant jerk through feedback. Feedback fails, and then they conclude the person is unfixable. But feedback without contracting is almost always going to fail.
An implied contract is an invitation for someone to behave exactly as they want, because nothing was ever agreed.
Most teams have a very clear technical contract. Deliverables, deadlines, architecture decisions. What they almost never have is an explicit relational contract. What does it mean to be a good engineer on this team, beyond the code? What does influence look like here? What are the non-negotiable behaviors in how we treat each other?
When that contract doesn’t exist, you have no ground to stand on in the conversation. And the brilliant jerk knows it, even if they don’t articulate it that way.
The contracting conversation is not a performance review. It is not a warning. It is a specific, collaborative discussion about what the full job description actually requires. And it starts before anything else.
Come in with real examples. Come in curious. And be clear about what you need from them going forward. A script to start from:
“I want to talk about something that matters for this team’s success. I’ve observed [specific behavior]. I want to understand what’s driving it from your side – and I also want to be explicit about what I need from you in this role going forward.”
You can read more about contracting as a leadership tool in this article: Transactional Analyst’s Story: Contracting.
Three Possible Outcomes – Pick One
This is the part most leaders avoid, so I’m going to be direct about it.
After a clear, contracted conversation, there are exactly three places this can go:
- They change. The behavior shifts. The contract holds. The team recovers. This is the outcome you’re working toward.
- They stay and don’t change. This is not a default. This is a choice you are making, with full awareness of the ongoing cost to everyone else.
- They leave. Either because the new standards don’t suit them, or because you make that call. Both are legitimate outcomes, depending on what the data and the conversation tell you.
Leaders who don’t name these options to themselves stay stuck indefinitely. And while they wait, the rest of the team makes their own decision.
Keeping someone who is damaging the team is a choice. Defaulting to it is not leadership. That is avoidance.
This Week’s Challenge
If you have someone on your team who fits this pattern, this week’s challenge is not to fix it. It’s to diagnose it.
Use the Wheel of Conflict: is what you’re dealing with a data problem, a structural one, or a values conflict? And then ask yourself one more question: have I ever made the behavioral expectations of this team explicit, or have I just assumed everyone knows?
Because most brilliant jerks are not irredeemable. They are operating in a system that only ever told them half the job description.
The rest is on you to name.
What type of conflict are you actually looking at right now?
PS. Want more content like this every week? Sign up for the Leman Leadership Pulse, and make sure you’re listening to the latest episode of the Leman Tech Leadership Podcast.
