Not All Friction Is a Problem

There is something deeply compelling about an operation with no friction.

A request that used to take three emails now resolves in seconds. A data point no longer has to be entered manually across several systems. A bureaucratic approval disappears. A decision can be made closer to where the work actually happens, without waiting for someone several levels up to find the time to review it.

It is hard to argue with that. And in many cases, there is no reason to.

Organizations accumulate an absurd amount of resistance that nobody deliberately designed: duplicated information, steps that outlived the reason they were created, waits caused by ambiguous responsibilities, controls that no longer control anything. Removing that friction does not require a sophisticated defense. It is work that should be done.

The problem comes shortly after, when the experience of removing waste supports a broader conclusion than it actually warrants: that any resistance is evidence of poor design.

That is when systems start looking deceptively simple. We count steps. Measure time. Locate approvals. Look for human intervention. Anything that interrupts the flow begins to seem suspicious.

And often, it is.

Just not always.

The speed of a flow is not, by itself, a sufficient measure of the quality of the system that contains it.

An operation can become faster while losing a separation of responsibilities, a boundary of authority, or a necessary opportunity for deliberation. Time improves. The system may not.

That is where the argument gets uncomfortable.

Two approvals that look the same

A financial transfer requires a second approval before it can be executed.

From the outside, the diagnosis seems obvious: two people are doing what one person could do. The second intervention adds delay. Remove it, and the transfer goes through sooner.

The same visible step can sit inside a very different architecture.

In one organization, the second person holds no distinct authority, receives no information the first person does not already have, and rarely changes the outcome. The step remains because the flow was designed that way years ago and nobody has had a sufficiently strong reason to question it.

The wait, however, is never abstract. Someone pays for it.

The team trying to move the money waits. An urgent transaction generates another message, a phone call, a reminder. If the approver is away, work piles up. Dozens of small interruptions can concentrate around one person who, in systemic terms, no longer contributes anything that explains the cost.

The organization is paying for resistance whose function it can no longer clearly explain.

In another organization, the screen may look exactly the same. One person initiates the transfer; another approves it.

Here, however, the two actions represent different authorities. The person preparing the transaction can initiate it but cannot unilaterally commit capital. The second intervention separates initiation from authorization and establishes a real boundary of authority.

It still costs time. The requester still waits. There is no reason to romanticize that delay simply because the control can be described in elegant language.

The difference is that this organization can explain what risk it is accepting the delay to contain.

Even that does not settle the design. The threshold may be too low. Human review may still be required for transactions whose risk could be handled through better-defined permissions. The control may be valid while the way it is exercised remains clumsy.

A restriction can serve a real function and still be badly designed.

The presence of an approval, then, tells us very little by itself about whether we are looking at residual bureaucracy or deliberate architecture.

The surface is misleading.

Resistance can also do work

Some decisions need space between intention and execution.

Waiting is not a virtue. But certain actions deserve another opportunity to be examined before they become facts. When an action is difficult to reverse, a pause can serve a design function rather than merely adding delay.

In other cases, resistance makes a boundary of authority visible. A system may need to distinguish between who can prepare an action, who can authorize it, and who can execute it. Concentrating those powers can certainly be faster, while producing an architecture nobody would want to discover only after something goes wrong.

How difficult it is to go back matters too.

In The Weight of a Signature, the cost of reversal emerged as an important property of the point at which a decision begins to be treated as binding. The same issue appears here from another direction: when undoing an action is expensive, it becomes much harder to treat every form of prior resistance as waste.

That does not turn reversibility into a formula.

Some decisions are easy to reverse and still require limits because of privacy, authority, or accumulated risk. Other consequential decisions can proceed with very little human intervention because the system already contains precise permissions, explicit boundaries, and reliable mechanisms for detecting and correcting deviations.

The goal is not to accumulate controls. It is to understand why a particular action encounters resistance before execution, and what would change if that resistance disappeared.

That distinction seems small until an organization starts removing friction at scale.

Having a function is not enough

This is where the argument can become too comfortable.

Find a function for every control, and it becomes tempting to assume that time has somehow legitimized it—as though habit were evidence.

But organizations are full of things that perform exactly the function they were designed to perform and still deserve to disappear.

A restriction may preserve authority. That does not prove the authority belongs where it currently sits.

A control can reduce risk for one level of leadership while creating dozens of small interruptions across the operation. It can give reassurance to the people who hold control while distributing the cost among those with the least ability to challenge it.

That cost matters.

The person who creates the resistance and the person who bears its cost are rarely the same person.

Understanding what function a control serves is therefore only the beginning. We also need to know under what authority it is imposed, who absorbs its burden, and whether that burden remains proportional to what the control is meant to protect.

Even an organization’s inability to explain a restriction does not automatically authorize its removal.

Sometimes the restriction is a relic. Other times it points to tacit knowledge that was never documented, a valid responsibility that was poorly represented, or a precaution whose logic survived more successfully than its explanation.

A lack of clarity is a reason to review. It is not yet a verdict.

But keeping the restriction requires an argument too.

A rule does not become necessary because it has existed for ten years. An approval does not acquire legitimacy because it once responded to a real risk. Human review does not deserve automatic permanence simply because the previous system depended on it.

If the same function can be preserved through more precise permissions, better information, or an architecture that imposes less burden on the people doing the work, the restriction should change.

Friction has to justify its place.

Not only when someone first designs the process, but for as long as it continues to impose a cost on the system.

That obligation works in both directions. Removing resistance means understanding what disappears with it. Keeping it means remaining able to explain what it protects and why the price it imposes is still worth paying.

When friction becomes easier to remove

Automation makes this discussion more consequential for a simple reason: it is increasingly cheap to remove visible forms of resistance from an operation.

A wait can become a rule. A manual check can become an automated validation. An approval can disappear because permissions, conditions, and limits now allow the decision to be resolved another way.

That is progress when the new design preserves what actually needed to be preserved.

The problem begins when we measure first what automation makes easiest to measure.

A time metric can register delay, but it cannot tell us why the delay exists.

The number of interventions can tell us how many people touched an operation, but not whether those interventions represent unnecessary duplication or an intentional separation of responsibilities.

Fewer clicks may improve the experience while revealing nothing about the distribution of authority underneath it.

When the unit of analysis is too local, an accidental wait and a necessary moment of deliberation can look like exactly the same problem.

The result can be strangely convincing: a technically flawless intervention removes precisely what the project was meant to remove, produces better metrics, and leaves behind a system that is less capable of governing certain decisions.

The answer is not to preserve manual work.

A better architecture can produce more control with less friction. It can replace an approval queue with better-defined permissions. It can turn a late-stage review into a condition the system checks before the action is allowed to occur. It can make a decision that once required constant supervision safe enough to resolve locally.

In those cases, reducing friction does not remove the function. It redesigns how the function is performed.

That difference changes what optimization means.

Ease is not always the goal

Most accidental friction deserves very little nostalgia.

If a data point can stop being entered twice, it should. If a decision clearly belongs to a team, it should not have to travel up a hierarchy in search of a ceremonial approval. If a control no longer contains any identifiable risk, age alone does not entitle it to protection.

But the absence of resistance should not become a moral property of a good system either.

A mature organization needs to know which actions can be resolved without asking, where each actor’s authority ends, and at what points a decision should encounter enough resistance for its consequences to be understood before it is executed.

None of those choices are permanent.

Risk changes. Technology changes. Responsibilities move. A restriction that once protected something important can remain installed long after the need has disappeared. Deliberate friction cannot become a permanent fixture either.

Design therefore includes revisiting the things we have deliberately made difficult—not because difficulty should always become ease, but because the reason for that difficulty must remain good enough to justify it.

Designing a system is not about making everything easy. It is about deciding, with enough precision, what should be easy to do and what should not happen without a good enough reason.