Tech has had a name for its most talented, most difficult employee since the late 2000s: the brilliant jerk. What actual workplace data shows is that the reason this person survives isn’t mystery or myth. It’s proximity, and hybrid and remote structures make the mechanism stronger, not weaker.
Key Takeaways
- GCheck’s The Consequence Gap Report found that adoption of a difficult coworker’s behavior by others tracks closely with proximity: 7% among workers with occasional contact, 14% with regular contact, and 26% among those on the same team daily.
- “Brilliant jerk” has described a high-output, low-cooperation employee since Netflix’s Culture Deck popularized the term in the late 2000s. Tech didn’t invent the pattern; it gave it a name.
- Per BLS’s Occupational Requirements Survey, telework is routinely allowed for 62.8% of computer and mathematical occupations, well above most other job categories, which means the proximity dynamic in tech plays out across more distance than in most industries.
- The people who witness a brilliant jerk’s behavior most often, close teammates, are usually the ones with the least influence over whether anything happens about it.
- Fixing this isn’t about tracking remote workers more closely. It’s about building visibility into review structure that proximity alone no longer provides.
What “Brilliant Jerk” Actually Describes
An Established Term, Not a New Problem
“Brilliant jerk” is business shorthand for a high-output employee whose interpersonal conduct is difficult enough that coworkers routinely raise it, and whose results are strong enough that leadership routinely doesn’t act on it. The term dates to the late 2000s, when Netflix’s internal culture materials popularized it as a specific type of person a company should not tolerate regardless of output. It has since become common vocabulary in tech management circles specifically, likely because tech’s engineering-heavy structure makes individual technical output unusually visible and unusually easy to credit to one person.
The term has held up for nearly two decades because it names something specific enough to be useful. It isn’t a synonym for “difficult personality” or “tough manager.” It describes a narrower pattern: someone whose contribution shows up cleanly on a scoreboard, a shipped feature, a resolved incident, a system only they fully understand, while the cost of working with them shows up nowhere anyone is required to look.
Why the Pattern Predates Tech, Even If the Term Doesn’t
This doesn’t mean tech invented the underlying dynamic. Research on workplace accountability, covering industries broadly, found the same reward-and-protection pattern applies to anyone seen as valuable or hard to replace, not just engineers. What’s specific to tech is less the existence of the pattern and more the conditions that let it run further before anyone intervenes: a highly technical role where output can be measured precisely, a hiring market where a strong individual contributor is genuinely hard to replace, and, per this article’s central finding, a work structure that increasingly separates the people producing the output from the people deciding what to do about how they produce it.
A sales organization can usually tell a difficult top performer’s numbers are inflated by burning through leads or straining client relationships, because those effects eventually show up in a shared pipeline everyone can see. A brilliant jerk’s technical output rarely gets audited the same way. If the system works and the metrics look good, the actual cost of how it got built stays invisible unless someone specifically goes looking for it, which almost no one is incentivized to do.
Why Proximity Is the Real Mechanism
What the Data Shows
| Contact with the difficult coworker | Share who adopted the behavior |
| Occasional contact | 7% |
| Regular contact | 14% |
| Same team, daily contact | 26% |
GCheck’s Consequence Gap Report measured something more specific than whether a coworker’s behavior gets addressed. It measured whether other people start adopting that behavior themselves, and the pattern above is not subtle: adoption roughly doubles at each step up in contact frequency, and workers on the same team every day are more than three times as likely to pick up the behavior as workers with only occasional exposure. Proximity is not a minor variable here. It is close to the whole story.
What This Means for Who Actually Knows
That same proximity effect cuts the other way for visibility. The people who see a difficult coworker’s behavior constantly, close teammates, are the ones most likely to be shaped by it. They are also, in almost every org chart, the people with the least formal influence over whether the behavior gets addressed. The people with that influence, a skip-level manager, an HR partner, a director two levels up, are usually the ones with the least direct exposure to the behavior itself. Proximity determines who is affected. It does not determine who decides.
This is precisely why the same data shows adoption, not just awareness, concentrating at close range. It isn’t only that close teammates notice the behavior more. They’re the ones absorbing enough of it, often enough, that some of them start doing it too, which means the population best positioned to describe the problem accurately is also the population most at risk of no longer describing it as a problem at all.
Why the Damage Concentrates on the Closest Teammates
A brilliant jerk’s most consistent audience is whoever sits closest to their actual work, which in tech usually means the two or three people reviewing the same code, debugging the same system, or sitting in the same standups every day, a pod structure that hybrid and remote schedules tend to tighten rather than loosen. GCheck’s survey measured contact frequency directly, not remote-work status, so that connection is this article’s own reading of the data rather than something the survey asked about; the reading itself is simple, since whatever restructures how often people share physical space restructures the exact variable driving the numbers above. It’s a real fit for tech specifically: per BLS’s Occupational Requirements Survey, telework is routinely allowed for 62.8% of computer and mathematical occupations, well above most other job categories, so a small, tight, largely private pod is closer to the industry default than the exception. That’s a smaller, more concentrated exposure than a typical open-plan team, and it means the behavior gets witnessed constantly by very few people rather than occasionally by many. A skip-level manager sampling a fraction of that interaction sees a fraction of the pattern, and a fraction of a pattern often just looks like an intense personality rather than a documented problem.
This is a different shape of the accountability gap than the one that shows up with a protected manager. A toxic manager is protected because the people deciding whether to act have a personal or financial stake in not acting. A toxic high performer is protected partly for that same reason, their output is valuable, but also because the decision-makers frequently never see enough of the behavior to have a real basis for acting on it at all. The first is a willingness problem. The second is a visibility problem, and a visibility problem doesn’t get fixed by simply deciding to be braver about it.
That distinction has a practical consequence for how a complaint about a high performer tends to get received. A single report from one collaborator reads, to someone outside the pod, as an isolated conflict. It takes the same complaint from two or three people, echoing each other closely, before it starts to read as a pattern rather than a personality clash, and by the design of the proximity effect itself, two or three people is often the entire population who could plausibly make that report in the first place.
What Actually Helps
Rebuilding Visibility on Purpose
This isn’t solved by tracking remote or hybrid engineers more closely, and that isn’t what this article is recommending. Closer monitoring targets the wrong variable; the problem isn’t that leads can’t see what someone is doing, it’s that they rarely see how that person treats the people working closest to them. Three changes address that gap directly:
- Rotate who reviews code and who runs standups, even briefly, so the same two or three people aren’t the only ones with regular visibility into how a high performer treats collaborators. A lead who occasionally sits in on a pairing session sees more than one who only reviews pull request comments.
- Ask closest-collaborator questions in every peer review cycle, not just performance ones: who did you work with most closely this quarter, and would you want to work that closely with them again. A question aimed specifically at the people with the most contact surfaces what a skip-level manager’s limited sample never will.
- Treat a pattern reported by the same small group repeatedly as data, not noise. If the same two engineers keep raising a concern about the same teammate, the fact that it’s “only” two people is a proximity artifact, not evidence the concern is isolated. Given how sharply adoption and impact concentrate by contact frequency, a small, consistent signal from the closest observers deserves more weight than its headcount suggests, not less.
- Apply the same proximity logic when hiring a senior engineer externally, not just when managing one internally. A standard Professional Reference Checks process defaults to a candidate’s manager and one or two peers picked by the candidate. Given what this article’s data shows about who actually witnesses a pattern, the more useful reference is a former close collaborator, someone who paired with them daily or reviewed their code constantly, not necessarily someone the candidate would think to list.
Applying the Same Standard Tech Already Applies Elsewhere
Tech already accepts that a small, close group can carry an outsized signal. It’s the entire logic behind a tight code review culture: a change reviewed carefully by two engineers who actually understand it is worth more than one glanced at by ten who don’t. Applying that same respect for concentrated, high-quality signal to conduct concerns, rather than dismissing them because so few people raised them, closes most of the visibility gap this article describes without adding a single new tool or process to anyone’s day.
The reframe is simple enough to say in one sentence: a concern raised by exactly the people who would be expected to raise it, given how contact and adoption concentrate, is not weak evidence because of its headcount. It is, given what the data shows about who’s actually positioned to notice, close to the strongest evidence an organization is going to get.
Why This Is Also a Protective Compliance Question
More Than a Morale Problem
A protected toxic high performer in tech usually isn’t just a source of team friction. Senior engineers and technical leads routinely hold broad access to production systems, customer data, and proprietary code, access that reflects genuine trust in their competence, not their conduct. When the person holding that access is also someone the organization has shown it won’t hold accountable, the protection extends past interpersonal harm into a real question about what that trust actually rests on.
This isn’t a claim that difficult engineers are more likely to misuse access than anyone else; there’s no data in this article supporting that specific inference, and it would be an unfair one to make. The point is narrower and already implicit in how tech companies talk about their own access controls: privileged access is supposed to be reviewed and justified independent of how valuable someone’s output is, and a culture that already lets output override the conduct standard has, by definition, weakened exactly the kind of review that access is meant to require.
What This Doesn’t Change About the Fix
This isn’t an argument for new monitoring of senior engineers’ system activity, which would repeat the same wrong-variable mistake described earlier in this article. The actual recommendation is narrower: keeping access reviews and conduct standards on separate tracks, the same separation this article recommends for performance and conduct generally, so that a strong technical reputation never becomes an informal reason to skip a review that would otherwise be routine.
What This Means for Tech Leadership
The Standard, Restated
Everything in this article points to the same underlying requirement: a conduct standard that doesn’t bend based on how hard someone would be to replace, or how impressive their output looks from two levels up. That’s Fair Compliance in practice, applying a consistent standard to a coworker’s conduct regardless of their value to the organization, extended here to output and technical reputation specifically rather than rank alone. Pair it with Protective Compliance, the recognition that a high performer’s access, influence, and protected status are organizational risks worth managing on their own terms, and the two together describe what “fixing” this pattern actually requires: not new suspicion of the team’s best engineers, but a standard and a review structure that apply to them exactly as they apply to everyone else.
Neither pillar asks an organization to value technical excellence less. They ask it to stop treating technical excellence as a substitute for a conduct standard it would apply to anyone else, which is a different thing entirely, and one most engineering leaders would agree with immediately if the question were put to them directly rather than embedded in a specific, uncomfortable performance review.
Where to Start
A reorg or a new tool isn’t required to start. It starts with one question a team’s leads and HR partners can ask this quarter: if the same conduct concern came from your two most junior hires instead of your two most senior engineers, would it move through the same process, at the same speed, taken exactly as seriously. If the honest answer is no, the standard already isn’t consistent, whatever the policy document says, and that gap is worth closing before the next reorg quietly protects the same person all over again.
The proximity data that opened this article is, in the end, the whole argument in miniature: the people best positioned to know are rarely the people positioned to act, and closing that gap has nothing to do with how many people happen to be sitting in the same room.
Frequently Asked Questions
What does “brilliant jerk” mean in tech?
It describes a high-output employee, often a senior engineer or technical lead, whose interpersonal conduct is difficult enough that coworkers routinely raise concerns, but whose technical output is strong enough that those concerns rarely lead to any consequence. The term dates to Netflix’s Culture Deck in the late 2000s and has since become common in tech management vocabulary.
Does remote or hybrid work make toxic high performers harder to notice?
Indirectly, yes. Research on workplace accountability found that adoption of a difficult coworker’s behavior tracks closely with contact frequency, not job title or department. Hybrid and remote structures often concentrate daily contact into a small, tight-knit group while reducing how often anyone with decision-making authority is in the room, which widens the gap between who experiences the behavior and who could act on it.
Why does a toxic high performer get protected more than other toxic employees?
Partly for the same reason a toxic manager does, their output is valuable and hard to replace, but also for a distinct reason: the people deciding whether to act often only see a small sample of the behavior. A skip-level manager who joins a fraction of a team’s daily interactions has a fraction of the evidence the closest collaborators have.
Is the fix to monitor remote engineers more closely?
No. The problem isn’t a lack of activity data; it’s a lack of visibility into how someone treats the people working closest to them. Rotating who reviews code and runs standups, asking closest-collaborator questions in every review cycle, and treating a consistent signal from a small group as real data rather than noise addresses the actual gap without adding surveillance.
Is this the same finding as toxic managers getting protected more than toxic employees?
Related but distinct. The manager-specific pattern is about rank and sponsor relationships; a toxic high performer isn’t necessarily a manager at all. The mechanism here is proximity and visibility: a difficult teammate’s behavior gets witnessed constantly by whoever works closest to them and rarely by whoever has the authority to act on it.
ABOUT THE CREATOR
Charm Paz, CHRP
Recruiter & Editor
Charm Paz is an HR professional at GCheck, specializing in background screening, fair hiring, and regulatory compliance. She holds from the Professional Background Screening Association (PBSA) and helps organizations navigate employment regulations with clarity and confidence.
With a background in Industrial and Organizational Psychology, she translates policy into practice to build ethical, compliant, human-centered hiring systems that strengthen decision-making over time.
