The call came on a Tuesday. A leader I'd worked alongside at a mid-market company was being let go — "not a fit," they said, "too rigid, too escalatory, not reading the room." I knew this person. I'd watched them spend the better part of two years quietly raising the same risk through every available channel: one-on-ones with their manager, written notes in project retrospectives, a carefully worded memo to the executive team. Specific. Evidence-based. Consistent. The risk materialized about a month after they left. Then again a few weeks after that. By the time the sixth incident hit, the company had quietly promoted someone else to address the exact problem this leader had been naming since their first quarter.

Nobody called back.

I've seen variations of this story across a quarter century of organizations — technology firms, retailers with hundreds of locations, professional services shops, mid-market operators of every kind. The details differ. The shape doesn't. A sharp, precise leader surfaces a structural problem. The organization lacks the mechanism to receive it. The leader escalates, because the private channels produced nothing. The organization reads escalation as dysfunction. The leader leaves. The problem stays.

What I want to name, here at the end of this three-part series on friction and navigation, is the precondition that both prior pieces quietly assumed: that somewhere in the organization, someone with authority has decided to build the infrastructure that makes friction productive. That assumption, in my experience, is wrong often enough to warrant its own article.

The Network Layer Doesn't Know About the Application

There's an engineering concept I return to whenever I'm trying to explain this to executives. In a networked system, the application layer — your software, your interfaces, your user experience — can be beautifully designed and still fail completely if the network layer beneath it is broken. The packet loss isn't happening in your code. It's happening in the infrastructure your code depends on. And no amount of optimization at the application layer fixes a broken network layer. You can refactor forever. The packets still drop.

Organizational structure is the network layer. Individual capability — how well a leader communicates, adapts, reads the room, manages up — is the application. When I watch organizations struggle with leaders they describe as "difficult" or "not a fit," I am very often watching application-layer diagnosis on a network-layer problem.

The leaders who get characterized this way are not, in my observation, the ones who can't think. They are frequently the ones who think most precisely — who identify the gap between what is said in the meeting and what is actually decided, who notice that the retrospective produces the same action items quarter after quarter without resolution, who raise the risk early and specifically enough that it could theoretically be addressed. The precision is not the problem. The precision is the sensor. And what I've learned, more times than I'd prefer, is that when the sensor trips before anyone else's, organizations tend to check the sensor rather than the system.

The leaders I've watched navigate this pattern most clearly are what I'd describe as systematically precise — the ones who hold two or three levels of implication in mind simultaneously, who notice a process gap the way some people notice a wrong note. They are overrepresented among the leaders I've watched organizations characterize as "difficult" and underrepresented among the ones who get credit for the problems they identified. That pattern is not random. It's structural.

What Structural Abdication Looks Like from the Inside

I was brought in to assess a leadership team at a regional organization — not as a therapist, as an operator — and I spent two weeks in their weekly executive meeting before I understood what I was watching. Two hours, every Tuesday. Dense agenda. Competent people, genuinely. And at the end of each meeting, nothing changed. Not because the problems were hard. Because no one owned the call.

The senior leader at the table had a governing style I've come to recognize: consensus as cover. Every contentious item got reflected back to the group. "What does everyone think?" Which sounds like collaboration and functions like abdication. Because when a senior leader defers every hard call to group dynamics, what they're actually doing is replacing a decision structure with a social one — and social structures select for whoever is most fluent at working the room, not whoever has the most accurate read on the situation.

This matters enormously for the leaders we're discussing, because analytical precision and social fluency are different capabilities that organizations routinely conflate. A leader who can see three steps further than the room but can't perform the warmth ritual that makes that vision legible will lose to a leader who performs confidence without depth, every time, in an environment without structural decision-making. Every time.

The meeting that nobody changes is not a neutral artifact. It is a leadership failure wearing a meeting's clothes. And formal mechanisms for disagreement — structured pre-mortems, written objection processes, asynchronous input before synchronous convergence — are not bureaucratic overhead. They are the infrastructure that makes accurate information more valuable than social positioning. Organizations that refuse to build those mechanisms are not choosing collaboration. They are choosing comfort. And they are encoding a selection process that will reliably surface the wrong leaders over time.

Onboarding by Emotional Tone

The most specific version of this failure I've encountered happened fast. A leader was let go ten days into a new role. The feedback was that they weren't "radiating kindness." Not that they'd made a bad decision. Not that they'd damaged a relationship. Not that they'd failed to deliver anything measurable. Ten days in, and the onboarding feedback was an emotional performance standard with no behavioral definition attached to it.

This is not an isolated story. I've seen it in different language across several organizations: "culture fit," "energy," "presence," "how they show up." What these phrases share is the absence of any structural definition. Culture fit to what, exactly? Presence measured how? What decisions get made by whom, through what process, and with what latitude? When onboarding is defined entirely by emotional experience — how you make people feel in the hallway, whether your energy matches the energy of the room — what you are running is an undocumented test for social mimicry. Leaders who naturally perform the expected emotional register pass. Leaders who don't, regardless of their capability, fail. And the leaders who fail this test are often the ones who would have asked the structural questions nobody wanted answered.

The accommodation myth runs underneath all of this, and it's the part I want to be direct about. When a capable leader struggles under organizational pressure, the intervention almost always targets the leader: coaching, communication workshops, resilience training. Rarely does anyone ask what is generating the pressure. But if you have a sensor in a system that trips before any other sensor trips — the pattern I've observed repeatedly in leaders with a certain kind of systematic precision — the right diagnostic question is not "why is this sensor so sensitive?" The right question is "what is the load on the system that no other sensor is capturing?"

Coaching the sensor to be more resilient does not reduce the load. It just means the load builds longer before you hear about it.

Six Questions Before You Decide It's a People Problem

I want to give you something concrete, because the pattern I've described is abstract enough to feel deniable. Before you characterize a leader as "not a fit," before you decide the problem is the person rather than the infrastructure, answer these six questions honestly.

One: Do you have a formal mechanism for dissent — not an open-door policy, but a structured process that doesn't require the dissenter to win a social negotiation to be heard?

Two: When a hard call is made, can you name specifically who made it and what authority they exercised? Or was it "the group"?

Three: When a leader raised a risk before it materialized, what happened? Was the content of their concern evaluated separately from the manner of their escalation?

Four: How is "culture fit" defined in your onboarding? Can you write it down in behavioral terms? If not, you don't have a culture definition. You have a social vibe test.

Five: Is the role this leader was placed in actually suited to systems thinkers, or is it primarily a relationship-management seat? If the latter, whose decision was that placement?

Six: Is the pressure this leader is operating under being assessed — not whether they're "handling it well," but whether the pressure itself is appropriate to the role and the moment?

If you can't answer these questions, you don't know whether the problem is the leader or your infrastructure. You're guessing. And in my experience, the guess almost always lands on the leader.

The Engineer You Just Fired

I started with that Tuesday call, and I want to end there. After the sixth incident at that organization — after the problem this person had named for nearly two years had finally become too visible to ignore — I heard that someone on the executive team said they just needed leaders who could "work within the system."

I've thought about that phrase more than I probably should. Working within the system is a reasonable expectation when the system is functional. It becomes something else when the system is broken and "working within it" means not naming what's broken. At that point, what you're selecting for is compliance, and you're selecting against accuracy.

The leaders organizations lose to this pattern are not the easy ones to replace. They are, disproportionately, the ones who saw further, who raised things early, who held analytical precision as a professional standard. When they leave — or are asked to leave — the problems they pointed at don't leave with them. They stay. Quieter, because the person most likely to surface them is gone. More expensive, because structural problems compound. Waiting, because someone else will eventually identify them and go through the same sequence: the private conversation, the right channel, the exhausted playbook, the escalation, the characterization.

Friction frameworks are real. Navigation playbooks are useful. I've written about both in this series and I believe in them. But they attach to infrastructure. They assume a floor. And when the infrastructure isn't there — when the organization has chosen comfort over structure, abdication over decision ownership, emotional performance over behavioral clarity — no amount of individual adaptation closes the gap.

You didn't have a people problem. You had an engineering problem. And you just fired the engineer.

---

This is the third article in the series. The first, "The Friction Framework," addresses organizations and managers working alongside neurodiverse technical leaders. The second, "Navigating the Room," is written for neurodiverse technical leaders navigating senior leadership environments.