Friction Is a Systems Signal
Every operation is already instrumented, and the instrument is the effort people spend getting around it. Almost nobody reads what it's saying.
Friction is output, not noise
When work is hard in a way it shouldn't be, the difficulty is information, with a location, a shape and a cause, and the system behind it keeps generating it all day. Most places treat it like weather, something good people endure, mention in a survey once a year and otherwise absorb.
The useful reframe is a small one. Friction is the operation reporting on itself, in the only language it has.
Reading it as an instrument also changes who's credible. If friction is a mood, the person reporting it is a data point about themselves, and the usual organizational response is to manage the person. If friction is output, the same person is a sensor that happens to be standing where the problem is, and the right response is to go and look at what they're standing next to.
Complaints are unreliable. Improvisation is not.
The obvious way to find friction is to ask, and asking turns out to be the weakest instrument there is.
People complain about what's annoying, which lines up poorly with what's expensive. A slow login screen draws more complaints in a week than a broken handoff that costs the organization four days per request, because the login irritates everyone every morning and the handoff is somebody else's four days. What complaint volume measures is salience.
There's a second distortion on top of that one. The most expensive friction is usually friction people have already solved, and solved problems don't get raised. The person who built the workaround three years ago experiences that part of the job as fine now, because it is fine, at the cost of forty minutes a week they've stopped seeing. So surveys systematically miss exactly the places where the compensation is most established, which is to say the places where the underlying design failed longest ago.
What people build tells you more than what they say. Nobody maintains a workaround for fun. A workaround is a cost somebody chose to pay over and over, which means it was cheaper than the alternative, which means the alternative was genuinely bad. Each one amounts to a considered judgment about the system, made by the person best placed to make it and expressed in the most reliable form there is, behavior over time. When I want to know where an operation is failing, I stop asking and start looking at what people have quietly built beside it.
Once you go looking for the things people have made, they're easy to find: shared spreadsheets with a version number in the filename, a group chat that exists to route work a system was supposed to route, a saved search everybody uses because the default view is wrong, a document titled something like "actual process". Each of these is a piece of infrastructure the organization is running without knowing it, built by somebody who had a problem and no budget.
Different friction, different failure
The kind of friction tells you which part of the system gave out, and each kind points somewhere different.
Waiting points at ownership. When work sits, the next move usually belongs to nobody in particular, or to someone who hasn't been told it's arrived, and difficulty rarely has much to do with it.
Watch for the same fact being typed twice. Re-entry points at boundaries: two systems that should be connected aren't, and a person has become the connection.
Private records point at trust. Someone keeping a parallel spreadsheet has decided the official record isn't good enough to act on, and decided, correctly, that being right matters more than being compliant.
Every question about where something is describes a state the system should have surfaced and didn't, so asking points at visibility.
Rework points at sequence. Work that gets redone was usually started before the information needed to do it correctly had arrived.
The distinctions matter because each one routes to a different fix. A better dashboard won't touch an ownership problem, and a clearer process document won't do much for visibility. Reading all of it as generic frustration collapses five different diagnoses into one, and the response ends up being training, which is what organizations reach for when they haven't identified the failure.
The categories also predict what the fix will cost, which is handy early on. Visibility problems tend to be the cheapest, because the state already exists somewhere and needs surfacing, while a boundary problem costs whatever an integration costs and stays bounded. Ownership and sequence are the expensive ones, and the expense is political, because they require someone senior to give something up: a decision right, a review position, a place in the order of things. Knowing which category you're in tells you whether you need an engineer or a sponsor, and getting that wrong is how good diagnoses die.
Ask people what's wrong and you learn what's annoying. Look at what they've quietly built and you learn what's expensive.
Some friction is load bearing
Here's where the idea gets misused, so it's worth being precise. Not all friction is a defect.
A verification step that catches errors is producing something, and so is a deliberate pause before an irreversible action, or a regulatory check that has to happen whatever it costs. Removing friction as a general goal is how organizations delete their own controls and find out later what those controls were for.
The test is whether the effort produces a result the organization would pay for if it were priced on its own. Checking produces assurance, and waiting for a person to notice produces nothing at all, yet both feel like friction to whoever is going through them, which is exactly why that person isn't the right judge of which is which.
The harder cases are the ones where a control is real and sitting in the wrong place. A check that genuinely needs to happen, happening three steps later than it could, produces assurance and rework at the same time. The instinct is to argue about whether the control is necessary, and that argument goes nowhere, because the control is necessary and its position is up for negotiation. Moving it is usually on the table in places where removing it never was.
Where it gets misattributed
Unread friction doesn't stay unattributed for long, it gets assigned somewhere, and usually to people.
The request arrives as a training problem, or an adoption problem, or a performance conversation about someone who's slow. Now and then it shows up as a headcount request, the most expensive form of the same misreading. Each time, the organization has correctly sensed that something's wrong and then placed it in the wrong layer.
A useful discipline is to treat every training request as a hypothesis. Sometimes people genuinely don't know how to use the thing. More often the thing asks for knowledge it shouldn't need, and the training becomes a subsidy the organization pays forever for a problem it could have fixed once.
You can recognize the misread because the same remedy keeps getting applied. A process that's been trained twice a year for four years is a design that can't be held in working memory, and the training is how the organization keeps paying for that without ever noticing it.
Reading it without a project
None of this needs an initiative, just somebody willing to look at the operation on the assumption that the difficulty means something.
Watch one piece of work move and mark each point where a person is supplying something the system owed them. Along the way you'll notice what's been built beside the official tools, and which questions get asked over and over, and each repeated question is a missing feature with a person standing in for it.
What you're reading, when you do this, is an instrument that's been running the whole time and producing accurate output, into a room nobody was ever assigned to watch.
If this describes an operation you’re responsible for, the diagnostic is where that conversation starts.
How engagements begin
