On Friction

Years ago, I was working on a redesign initiative with Emirates. One of the biggest complaints we heard from both customers and employees sounded straightforward.

Passengers were getting to the airport with plenty of time before their flight, reaching the check-in counter, and still missing their plane.

Everyone assumed the problem was check-in.

Long lines. Slow agents. An inefficient process.

That's where the frustration showed up, so that's where everyone was looking.

As we started mapping the entire journey, something interesting happened.

The check-in process itself wasn't the issue.

When a flight reached a certain point before departure, it was automatically marked as closed in the system. If a passenger arrived after that point, even if there was still enough time to board, the check-in agent couldn't simply check them in.

They had to call a centralized operations team and ask for permission to reopen the flight.

Sometimes those calls were answered quickly.

Sometimes there were dozens of agents across the airport waiting to do the exact same thing.

The passenger stood at the counter watching the agent type, wait, make phone calls, and apologize.

From the passenger's perspective, check-in was failing.

From the agent's perspective, they couldn't do their job.

But the real bottleneck wasn't at the counter.

It lived in an operational process most passengers would never see.

That project permanently changed how I think about friction.

Most organizations treat friction as the thing to eliminate.

A customer complains.

An employee invents a workaround.

A project stalls.

A process takes longer than it should.

The instinct is to fix whatever appears broken.

But I've found that friction is often more valuable as information than as the problem itself.

In healthcare, symptoms tell us something is wrong.

A fever isn't the disease.

Chest pain isn't the diagnosis.

The symptom matters because it points us toward the cause.

Organizations work the same way.

A repeated customer complaint.

An employee who constantly bypasses a process.

A spreadsheet someone built because "the system doesn't do what we need."

An inbox full of the same questions.

These are symptoms.

They reveal the distance between how a system was designed to work and how it actually works.

That's why I pay attention whenever people struggle.

Not because the struggle is always the problem.

Because it's often pointing somewhere else.

The place where friction shows up is rarely the place where the real problem lives.