The first thing you notice is that nobody wants to sit next to him in the meeting. Not because he's unpleasant, exactly. It's more that he has this habit of asking the question everyone in the room has quietly agreed not to ask. The one about the assumption buried three slides back. The one that, if you pull it, unravels the entire plan.

I worked alongside a director like this at an enterprise technology company some years ago. Smart doesn't begin to cover it. He could trace a data flow through seven systems in his head and find the place where the logic broke — usually in the first ten minutes of a review that everyone else had spent two weeks preparing for. He was the person the CTO called at 2 a.m. when production was down. He was also the person that same CTO's staff spent the other twenty-three hours of the day managing around.

In the language that would eventually reach me through HR: he "created friction." That was the phrase. And they weren't wrong. He did create friction. The question nobody paused to ask was what kind.

The Mistake Hiding in Plain Sight

Organizations are not naturally good at distinguishing between different types of friction. Most treat all friction as equivalent — as organizational drag to be reduced, as a signal that something interpersonal has gone wrong. This makes sense on the surface. Meetings where people argue are exhausting. Teams where someone reliably challenges every decision are harder to manage than teams where consensus arrives quickly and everyone leaves feeling good.

But friction is not a monolithic thing. There is friction that has no information content — the kind that comes from ego, from turf wars, from someone who simply needs to win arguments. And there is friction that is pointing at something real. A gap in the logic. A risk that hasn't been accounted for. A dependency that everyone has tacitly agreed to ignore because naming it would complicate the timeline.

The social sciences have been trying to tell us this for fifty years. Irving Janis documented in 1972 what happens to high-stakes decisions when a group optimizes for harmony over accuracy — he called it groupthink, and the historical examples he used were not minor miscalculations. The research on cognitive diversity in leadership teams consistently shows that productive disagreement — the kind that feels uncomfortable in the room — correlates with better outcomes. None of this is controversial in theory. In practice, the person generating the discomfort is still the one who ends up on a performance improvement plan.

The director I mentioned never made it to his third year at that company. By the time he left, three of the five architectural decisions he'd challenged in his first eighteen months had failed in exactly the ways he'd described. The fourth was quietly reversed before it could. Nobody connected those dots at the exit interview.

Learning to Read the Signal

The distinction I've come to rely on — call it the friction framework — is simple to state and genuinely hard to apply in the moment: does the friction point at a real problem?

Social friction has no predictive value. It tells you about the relationship between people, not about the quality of a decision. Technical friction — the kind generated by leaders who process information differently, who have a low tolerance for ambiguity, who cannot let a faulty assumption pass without naming it — tends to have a high information yield. The challenge is that it arrives in a package that feels socially indistinguishable from the first kind. It sounds the same in the room. It produces the same elevated cortisol in the people sitting across from it.

The diagnostic question I've learned to ask is backward-looking: when this person has created friction before, was the process they challenged actually broken? Did the risk they flagged materialize? Did the decision they questioned fail? If the answer is consistently yes, you are not looking at a personality problem. You are looking at a signal-detection system that your organization has decided to experience as noise.

Leaders who process differently — who see patterns before they're obvious, who hold technical complexity in working memory at a level that makes abstractions feel dishonest, who experience the gap between stated process and actual process as acutely uncomfortable — surface dysfunction before it costs you. The friction they generate is often the first indication that a system has a load-bearing assumption that nobody has tested.

The harder part of this is what I think of as the Trust Paradox. The person your team calls during the crisis — the one who earns absolute authority in the war room, who everyone defers to when the stakes are real — is often the same person who accumulates the worst peer feedback during normal operations. The gap between those two evaluations tells you something important. It tells you that your organization is optimizing for peacetime comfort, and that you are only discovering the true value of certain people at the moments when you can least afford to have underinvested in them.

What the Organization Actually Controls

I want to be careful here, because this is where the argument usually gets misread.

The case I'm making is not that organizations should tolerate any behavior in the name of technical excellence. People who generate friction have the same obligation as anyone else to find ways of communicating that don't damage the people around them. That's not what I'm questioning.

What I'm questioning is the organizational design that makes this a solo problem for the individual to solve.

The NeuroBridge research published in 2026 found that 56% of managers reported lacking confidence in how to work with neurodiverse colleagues, and 70% had received no training on the subject whatsoever. That's a design failure, not a performance failure. When an organization builds a leadership operating system — decision rights, meeting formats, communication norms — around the preferences of one cognitive style, and then evaluates everyone else against those preferences, it isn't running a meritocracy. It's running a familiarity contest dressed up as one.

I've seen what actually works, and it's not complicated. Explicit decision authority — who decides, who advises, who gets informed — removes the ambiguity that turns every meeting into a negotiation over who gets to be right. Pre-read materials and async input channels for major decisions give leaders who need processing time the ability to contribute their best thinking rather than their fastest reaction. Structured agendas that separate information-sharing from decision-making from creative divergence reduce the cognitive load that makes some meetings feel like running six processes on one thread.

None of these are accommodations in the sense that word implies: special adjustments for someone who can't keep up. They are improvements to the operating system. Every person in the room benefits from knowing who owns a decision. Every person on the team benefits from getting materials before the meeting rather than encountering the problem cold. The neurodiverse leader makes the need visible — but the need was already there.

The five strategies I've found reliable across different organizations are: reframe contributions on outcomes rather than style; build clarity infrastructure (explicit ownership, documented escalation paths); match communication format to decision type; invest time in mutual understanding rather than expecting one-sided adjustment; and redesign meeting structures that were never working well for anyone to begin with.

The Question Before the People Decision

Before making any conclusion about whether a technical leader belongs on a team, I've learned to work through six questions. Not as a checklist in the bureaucratic sense — as a genuine pause before treating a signal as noise.

Has the friction this person generates been evaluated against outcomes, or only against comfort? When they've challenged a decision or flagged a risk, what happened? Have the people evaluating them received any preparation for doing so accurately? Is the discomfort about the quality of their thinking, or about the style of its delivery? Have we built the conditions that allow them to contribute at their level? And finally — could we describe precisely what problem we'd be solving by removing them, and are we confident we're naming the right problem?

The last question is the one that matters most. The answer I hear most often, when I push, is some version of "the team would work better without the friction." Which is true, in the same way that an immune system response is friction. You can suppress it. Things will feel calmer. The underlying problem doesn't go away; it just loses the mechanism that was surfacing it.

Back to the 2 a.m. Call

The director I described at the beginning of this is not a cautionary tale about one person at one company. He's a pattern I've encountered across twenty-five years of technical leadership — the brilliant-but-difficult composite, the crisis hero who doesn't survive peacetime, the person whose exit is followed six months later by the quiet admission that things have gotten harder to catch.

Removing a person for culture fit can be the right call. People genuinely can be the wrong fit for an organization, for reasons that have nothing to do with neurodiversity. But when the reason is that they surface problems in ways that make people uncomfortable, you want to be very sure you know what you're optimizing for.

The organization that fires the signal generator doesn't solve the problem. It solves the discomfort of having the problem named. The architectural failure — the broken process, the unexamined assumption, the single point of failure in your infrastructure — is still there. It's just quieter now. Until it isn't.

The teams I've seen do this well are not the ones with the most harmonious meetings. They're the ones that learned to read friction rather than simply reduce it. That distinction, it turns out, is worth quite a lot.

---

This is the first of three articles in the series. The second, "Navigating the Room," is written for neurodiverse leaders navigating senior leadership dynamics. The third, "When Structure Fails," addresses what happens when the structural preconditions for both break down.

References

• Janis, I.L. (1972). Victims of Groupthink: A Psychological Study of Foreign-Policy Decisions and Fiascoes. Houghton Mifflin.
• NeuroBridge. (2026). Neurodiversity in the Workplace: Manager Confidence and Training Report. NeuroBridge.