I remember the spreadsheet. It was long.
Two women had been asked to test a module developed by a researcher in the organization. They took the task seriously and documented their findings thoroughly. Then came the meetings. Finding after finding was discussed, dismissed, and often rejected as not being a bug at all. This did not happen once, after a particularly bad day or an unfortunate misunderstanding. It became the pattern.
I no longer remember what happened to each item on that spreadsheet. Some may have been confirmed as bugs. Some may not. The technical truth disappeared from my memory years ago, which is inconvenient for a tidy story but rather important for an honest one.
What I do remember is the effect of the process. The women were soft-spoken and genuinely trying to help. Yet they repeatedly came away feeling that their work had been thrown out and their competence questioned. Some meetings ended in tears.
One of the women was in my team. The researcher was not.
That gave the situation some extra spice. I was responsible for supporting my colleague, but I had no authority over the person whose behavior was affecting her. I escalated the problem and was instructed to coach my people. This was not the only action taken, but it was the part expected from me.
And I did take it seriously. I wanted to help. At the same time, something felt wrong about solving the situation by making the people on the receiving end better at enduring it.
When the value is real
It would be easy to flatten the researcher into the villain of the story. But he had a rare and useful capability: finding creative technical solutions. The organization had good reasons to want to keep him.
The face of this person changes from one organization to another. It may be the senior engineer who understands the architecture better than anyone else. The celebrated “10x developer” who can finish work nobody else can. The person who built a key system and still carries most of its history in their head. In this case, it was the researcher expected to keep producing ideas others could not.
The job title could be almost anything. What these situations share is a capability the organization believes it cannot easily replace. Leaders can point to the ideas, difficult problems solved, domain knowledge, or delivery that depended on them. Gradually, protecting that capability becomes entangled with protecting the person from ordinary expectations about how colleagues should work together.
The cost appears elsewhere: in the meeting people dread all morning, the question somebody decides not to ask, the extra preparation before raising a routine concern, or the manager helping a capable colleague recover from another conversation that should have been about software.
A system that needs protective workarounds around one valuable person is already paying for that person’s brilliance.
The question is not whether the person is talented. They may be exceptionally talented. The question is whether the organization is looking at the whole bill.
Look for the protective architecture
The workarounds did not arrive as a system. We added them one by one: move this discussion into writing, prepare more carefully for the next meeting. Eventually, the workaround became the process.
In our case, one workaround was to move more communication into writing. It reduced the emotional edge enough that people stopped coming out of meetings crying. The price was a much heavier technical process. Every finding and response had to be documented in detail, and there was less room to explore the problem together or ask a quick follow-up question. We had made the situation more bearable. We still had not found a healthy and effective way to collaborate.
When trying to understand the real impact of a highly valued but difficult person, look beyond their own work. Look at what everyone else has learned to do around them:
Do people choose communication channels based on how that person might react?
Does raising a concern require more preparation than investigating the concern itself?
Do colleagues soften, postpone, or withhold feedback because the discussion feels too expensive?
Are managers privately helping people prepare for ordinary interactions?
Does the team seem lighter when the person is away?
None of these observations prove that every complaint about the person is correct. They show that the system is spending energy managing their presence. That cost should also count when the organization evaluates the person’s contribution.
Separate the questions before choosing a side
The label “brilliant jerk” is satisfying because it sounds like a diagnosis. In practice, it can hide several different problems inside one memorable phrase.
First, there is the technical question. Were the findings valid? Was the expert protecting an important standard, or presenting a preference as an engineering necessity? An abrasive expert can still be correct, and the rest of the team may have skill gaps. Leaders need evidence, acceptance criteria, or an independent reviewer rather than seniority and confidence.
Then there is the behavioral question. What happens when the person’s judgment is challenged? Do they explain their reasoning and consider that they may have missed something, or does the discussion shift toward the competence of the people raising concerns? One disputed bug proves little. A repeated pattern tells us much more about how the team can work.
There is also an organizational question. What has the person been rewarded for? If their success has always been measured through individual ideas and heroic problem-solving, mentoring and collaboration may feel like distractions. If leaders repeatedly make exceptions because the expertise is rare, the organization teaches the person that ordinary expectations do not quite apply to them.
Gender can add another layer. I cannot claim that it caused the behavior in this story, and I do not know the researcher’s motives. I do know that having their technical judgment discounted was not a new experience for these women. It was not new for me either. In my experience in technology, calm and collaborative communication is still easily mistaken for weak technical authority. This means a dismissive response sometimes lands on a bruise that has been pressed many times before.
That was the knot. The technical concerns still needed a fair hearing. His behavior made that hearing harder, and the impact did not fall evenly. Meanwhile, the organization kept counting the visible output and treating the rest as somebody else’s people problem.
Support people without making them the solution
Helping someone navigate such dynamics is part of leadership. We can prepare for a difficult conversation, establish boundaries, document repeated behavior, or choose a communication channel that reduces immediate harm. I do not regret helping the women find ways to make the situation more manageable.
But support becomes organizational avoidance when it is treated as the solution.
I could help my colleague carry less of the emotional load, but I could not coach her into no longer being affected when her work and expertise were repeatedly dismissed. Calling that success would mean teaching one person to absorb more damage without showing it.
The division of responsibility matters here. I was responsible for supporting my colleague and bringing a documented pattern to people with authority. I was not in a position to manage the researcher’s behavior. That responsibility sat with his manager. If the two management lines could not resolve the situation, it needed to move to the first leader with authority over both — not end with everyone being informed and nobody taking action.
I remember how absurd that felt: I was expected to reduce the damage, while the behavior creating it sat in somebody else’s reporting line.
From there, the next steps belong to different people:
Behavioral feedback belongs to the person’s manager. “You are difficult” gives the person little to work with and plenty to reject. Their manager can describe the recurring pattern instead: findings were dismissed before being properly examined, discussions shifted toward the competence of the people raising them, and colleagues became reluctant to participate. That manager is also responsible for setting expectations and following up.
The technical process belongs to the leader accountable for the quality and delivery of the work. Their title will vary. They need to establish clearer acceptance criteria, agree on how findings will be decided, and bring in a neutral reviewer when necessary. This gives strong technical concerns a path forward without requiring one person to dominate the room.
Senior leadership defines productivity and high performance; each manager applies that definition. Whatever makes the contribution rare, other people still need to work with it. Collaboration is part of delivery and should affect how the person is evaluated and promoted.
The job titles may vary. What matters is that the first leader with authority over the whole situation assigns these responsibilities explicitly. Otherwise, the manager supporting the affected people can end up caring for the human consequences and repairing the wider system without having the authority to do either.
The final test is whether the protective workarounds can eventually come down. Can people raise a concern directly again? Can disagreement happen without somebody’s competence becoming the subject? Can the expert’s knowledge become more accessible rather than more guarded? Does any improvement survive the next period of pressure?
If the answer remains no, the organization has not solved the problem. It has made the symptoms manageable and accepted the cost as permanent.
The full bill
I have watched highly valued people leave teams for different reasons. The organizations survived. They had to replace expertise and redistribute the work. This was not always easy, but “irreplaceable” eventually turned out to mean difficult and inconvenient to replace.
For the people who had struggled to work around them, the first response was often relief. A weight had lifted before the replacement plan was even complete.
This does not mean firing every abrasive expert or choosing harmony over standards. Rare expertise deserves effort. Difficult feedback is part of serious work, and technical disagreement should not be softened until it becomes meaningless. But none of that requires humiliation, habitual dismissal, or an operating model built around one person’s reactions.
Leaders need to measure what a brilliant person creates. They also need to measure the questions that go unasked, the feedback that arrives late, the hours spent preparing for ordinary conversations, and the capable people who gradually become smaller around them.
Protecting rare talent can be a rational choice. Teaching the rest of the organization to keep paying for it usually is not.
Food for Thought
Who in your organization requires everyone else to work around them, and what are those workarounds costing?
When a technical disagreement becomes personal, how do you distinguish a real quality concern from a repeated pattern of dismissal?
If the difficult person sits outside your reporting line, who has both the authority and the responsibility to act?
What does your organization reward more clearly: exceptional individual output or the ability to make others more effective?
Whose expertise is easiest to dismiss in your organization, and what does that teach the rest of the team?