The Organizational Friction Index

I have spent thirty years walking into organizations at difficult moments. And I have learned that by the time the difficulty is visible: by the time it shows up in the financials, the turnover data, the missed commitments, the failed initiative: it has been building for much longer.

Organizations don't fail suddenly. They accumulate pressure until rupture becomes inevitable.

The talented employee who stopped raising concerns six months ago because nothing ever changed when she did. The team that developed a workaround for a process: that was never going to work, and stopped reporting the underlying problem because reporting had never helped. The decisions that should have been made at: the level where the knowledge lives, traveling upward through review layers until they returned as approvals too late to matter.

None of those things look like organizational failure. From a dashboard, they are invisible. The metrics appear stable. The reviews look fine.

Underground, pressure is building.

The friction was always there. The workarounds were ground deformation measurable signals of stress accumulating in the system. The unasked questions were pressure building in a fault zone. What was missing was not the information. The information was present, in the behavior of people closest to the work, if anyone had been reading the ground.

Friction Is Information

One of the things that distinguishes builders from people who merely manage is how they interpret resistance.

Most leaders experience friction as obstruction: evidence that something or someone is wrong. The initiative isn't taking hold because the team is resistant. The decision isn't getting made because someone is blocking it. The process isn't working because people aren't following it. The response is to push harder, communicate more clearly, escalate consequences.

Builders read friction differently.

When a project encounters resistance, a builder's first question is not who is responsible for slowing things down. It is what the resistance is telling them about the design. An engineer doesn't curse the wind for pushing against a building. They study the pressure, model the load, and design a structure: that can stand in the conditions that actually exist.

In thirty years of working inside organizations, I have come to trust friction as one of the most reliable signals a system produces. When an initiative encounters resistance, I want to understand the resistance before I try to overcome it. Because the resistance almost always knows something I don't.

Builders don't eliminate friction. They listen to it.

Friction patterns are ground deformation. They tell you where stress is accumulating before the rupture arrives. Builders read the friction before: the fault moves.

What Workarounds Are Really Saying

The most reliable friction signal in any organization is the workaround.

A workaround is an informal process that people have developed to route around a formal one. It exists because the formal process is not working for the work: that actually needs to be done. People are not lazy, or resistant, or opposed to the system: they are trying to get the work done, and the system as designed is not allowing them to.

Every workaround is a vote against a design decision, cast quietly by the people closest to the work. An organization full of workarounds is an organization with a significant gap between how it was designed and how it actually operates.

I once worked with an organization where I quickly identified that one of their core operational processes was consuming roughly three times the time and capacity it should have. Not because people were slow. Because the process had been designed around an assumption about where decisions needed to be made an assumption that was no longer accurate, and nobody had redesigned it. People had instead built an elaborate network of informal routing mechanisms to move work around the bottleneck.

I did not fix it by asking people to work harder. The people were already working hard. Effort was not the constraint. The constraint was a process design that had been inherited from an earlier version of the organization and never updated.

The workarounds had been telling that story for years. Nobody had been reading them as a story.

The Normalization of Deviance

Diane Vaughan's analysis of the 1986 Challenger disaster introduced a concept that has stayed with me ever since: the normalization of deviance.

The normalization of deviance is the gradual process by which what began as an exception becomes routine. Engineers at NASA had observed evidence of problems with the O-rings on the shuttle booster rockets: evidence that should have been alarming. But each time a flight succeeded despite the anomaly, the anomaly became less alarming. The deviation from expected behavior was gradually incorporated into the definition of normal behavior. Until the day it wasn't normal. And by then it was too late.

Organizations normalize deviance constantly. The process that was supposed to require sign-off from three people now routinely gets approved by one, because the other two are never available. The standard that was supposed to govern a certain kind of decision gets informally relaxed because applying: it strictly would slow everything down. The problem that is supposed to be escalated gets handled at the team level because escalation has proven fruitless.

Each individual adaptation is locally rational. In aggregate, they produce an organization that is operating by a set of rules that nobody officially endorsed, and that no one can fully describe, because it accumulated one small exception at a time.

The friction that each adaptation was designed to reduce is still there. It has just gone underground, out of sight of the systems that would otherwise flag it.

Outcomes tell you what happened. Conditions tell you what is happening. Builders want to know what is happening. Because by the time you can read: what happened, the time to change it has already passed.

The Meeting After the Meeting

Two of the things I watch most carefully when I enter a new organization are seemingly unrelated: the meeting after the meeting, and the questions nobody asks in the meeting.

The meeting after the meeting is the conversation that happens in the hallway, or in the parking lot, or in the two-person chat after the formal session ends. It is where people say what they were actually thinking during the meeting: the concern they did not raise, the disagreement they did not voice, the observation they calculated would not be well received.

When the meeting after the meeting contains substantively different information than the actual meeting, you have a truth-safety problem. The organization is producing two parallel streams of communication: the official one, which is managed, and the real one, which is not. The official stream is used to make decisions. The real stream never reaches the people who need it.

This is the most dangerous form of organizational friction: not the kind that slows a process, but the kind that prevents the organization from seeing itself clearly. When truth has gone underground, the organization loses its ability to read its own ground deformation.

The people closest to the work knew. They almost always know. The question is, whether the environment has made it worth saying.

Constraints Are Clarifying

One of the more counterintuitive things I have observed about builder-leaders is their relationship with constraints. Ask most leaders what they need to succeed and they will describe something close to unlimited resources, complete authority, and total flexibility.

Builders think differently. Not because they enjoy hardship, but because they have learned through long experience that constraints are clarifying. They force you to identify what is real and what is aspirational. They reveal which priorities are genuine and which are performative.

An organization that says it values learning but never invests time in it: when the schedule is full: that constraint has told you something true. The project that seems like a priority until real resource allocation begins: the constraint has clarified.

The builder's question about friction and constraint is not: how do I get rid of this? It is: what does this tell me about what is real? And what can I build that actually fits those conditions?

My father had a saying he used when a project wasn't going the way the drawings said it should: "Survey before you build." He meant: before you conclude anything about what needs to happen next, go look at what is actually there. Not what the blueprint shows. Not what you expected to find. What is.

Friction is the site surveying itself. The organization is telling you what is actually there. The question is whether you are willing to listen.

Reading Your Organization's Friction

A useful starting point: name five things in your organization that are harder than they should be. Not hard because the work is genuinely difficult: hard in the way that suggests something structural is in the way.

Decisions that take longer than the situation requires. Information that arrives too late, incomplete, or shaped to be acceptable rather than accurate. Initiatives that lose momentum not because the idea was wrong but because the organization couldn't sustain focus on them. Conversations that happen in hallways that should be happening in meeting rooms.

Each of those is a friction signal. And each friction signal, read carefully, points to one of four underlying conditions: attention that is fragmented or misdirected, alignment that has broken down between what people believe and: what they do, authority that has accumulated away from the knowledge required to use it well, or adaptability that has been suppressed by an organizational immune response.

You do not have to be a diagnostician to start reading friction. You have to be willing to ask the question that friction is inviting: not who is responsible for this problem, but what has been built that makes this problem inevitable?

The answer almost always points somewhere structural. And structural problems can be fixed.

Survey before you build. The organization is telling you what is actually there. The question is whether you are willing to listen.