Friction Is a Systems Signal
Every operation is already instrumented. The instrument is the effort people spend getting around it, and almost nobody reads the output.
Friction is output, not noise
When work is hard in a way it should not be, that difficulty is information. It has a location, a shape, and a cause, and it is being generated continuously by the system that produced it. It usually gets treated as weather. Something to be endured by good people, mentioned in a survey once a year, and otherwise absorbed.
The useful reframe is small. Friction is not a mood in the building. It is the operation reporting on itself, in the only language it has.
Treating it as an instrument rather than a temperament also changes who is credible. If friction is mood, then the person reporting it is a data point about themselves, and the standard organizational response is to manage the person. If friction is output, then the person reporting it is a sensor that happens to be positioned where the problem is, and the correct response is to go and look at what they are standing next to.
Complaints are unreliable. Improvisation is not.
The obvious way to find friction is to ask, and asking is the weakest instrument available.
People complain about what is annoying, which correlates poorly with what is expensive. A slow login screen generates more complaint per week than a broken handoff that costs the organization four days per request, because the login is irritating every morning and the handoff is somebody else's four days. Complaint volume measures salience.
There is a second distortion on top of that one. The most expensive friction is usually the friction people have already solved, and solved problems do not get raised. The person who built the workaround three years ago experiences that part of their job as fine now, because it is fine, at the cost of forty minutes a week that has become invisible to them. 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 is a better instrument than what people say. Nobody maintains a workaround for fun. A workaround is a cost somebody chose to pay repeatedly, which means it was cheaper than the alternative, which means the alternative was genuinely bad. That is a considered judgment about the system, made by the person best positioned to make it, and expressed in the most reliable form available: 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.
The artifacts are not hard to find once you are looking for artifacts rather than opinions. Shared spreadsheets with a version number in the filename. A group chat that exists to route work that 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, and each was 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 they are not interchangeable.
Waiting points at ownership. Work that sits is rarely blocked by difficulty. It is sitting because the next move belongs to nobody in particular, or belongs to someone who has not been told it has arrived.
Re-entry points at boundaries. When the same fact is typed twice, two systems that should be connected are not, and a person has become the connection.
Private records point at trust. A parallel spreadsheet means the official record is not good enough to act on, and someone has decided, correctly, that being right matters more than being compliant.
Asking points at visibility. Every question about where something is describes a state the system should have surfaced and did not.
Rework points at sequence. Work redone was usually work started before the information needed to do it correctly had arrived.
These distinctions matter because they route to different fixes. Ownership problems are not solved by better dashboards. Visibility problems are not solved by clearer process documents. Reading the friction as generic frustration collapses five different diagnoses into one, and the response ends up being training, which is what organizations do when they have not identified the failure.
The categories also predict what the fix costs, which is useful early. Visibility problems are usually the cheapest, because the state exists somewhere and needs surfacing. Boundary problems cost whatever an integration costs and are bounded. Ownership and sequence problems are the expensive ones, not technically but politically, 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 are in tells you whether you need an engineer or a sponsor, and getting that wrong is how good diagnoses die.
Ask people what is wrong and you learn what is annoying. Look at what they have quietly built and you learn what is expensive.
Some friction is load bearing
This is where the idea gets misused, so it is worth being precise. Not all friction is a defect.
A verification step that catches errors is producing something. A deliberate pause before an irreversible action is producing something. A regulatory check that has to happen is producing something, 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 separately. Checking produces assurance. Waiting for a person to notice produces nothing at all. Both feel like friction to the person experiencing them, which is exactly why the person experiencing them is not the right judge of which is which.
The harder cases are the ones where a control is real but badly placed. A check that genuinely needs to happen, happening three steps later than it could, is producing assurance and rework at the same time. The instinct in those cases is to argue about whether the control is necessary, which is the wrong argument. The control is necessary and its position is negotiable, and moving it is usually available where removing it is not.
Where it gets misattributed
Unread friction does not stay unattributed. It gets assigned, and it usually gets assigned to people.
The request arrives as a training problem, or an adoption problem, or a performance conversation about someone who is slow. Occasionally it arrives as a headcount request, which is the most expensive form of the same misreading. In each case the organization has correctly detected that something is wrong and then located it in the wrong layer.
A useful discipline is to treat every training request as a hypothesis rather than a conclusion. Sometimes people genuinely do not know how to use the thing. More often the thing requires knowledge it should not require, and the training is a subsidy the organization pays forever rather than a fix it pays for once.
The signature of the misread is that the same remedy keeps being applied. A process trained twice a year for four years is not a knowledge gap. It is a design that cannot be held in a working memory, and the training is the mechanism by which the organization keeps paying for that rather than noticing it.
Reading it without a project
None of this needs an initiative. It needs somebody to look at the operation with the assumption that the difficulty is meaningful.
Watch one piece of work move, and mark each point where a person is supplying something the system owed them. Look for what has been built beside the official tools. Notice which questions get asked repeatedly, because a repeated question is a missing feature with a person standing in for it.
You are not gathering complaints. You are reading an instrument that has been running the whole time, producing accurate output continuously, into a room where nobody was assigned to look at it.
If this describes an operation you are responsible for, the diagnostic is where that conversation starts.
How engagements begin
