In the last piece, we explored the journey of digital work. We said that most of digital work happens not in the moments when everything works, and not in the moments when everything breaks, but in the long stretch in between — the place where the technology mostly holds, yet the work still doesn't quite flow. It is in this space that much of digital friction lives.
But friction does not always reach us in the same way. Sometimes, it is the technology that gets in the way of our work — something slows down, stops, fails or simply does not behave the way it should. At other times, the technology may be working perfectly well, yet the friction comes from us — from what we know, what we understand, what we notice, the habits we have formed, or how we choose to work with what is available to us.
The first is performance friction: the technology gets in the way of the work. The second is perception friction: the technology may be capable, but our understanding or behaviour keeps us from fully reaching what it makes possible. They are two very different forms of friction, but from where we sit as employees, both can leave us with the same feeling: work was harder than it needed to be.
Performance Friction: When Technology Gets in the Way
Performance friction is perhaps the easier of the two to feel. Something in the technology gets between us and what we are trying to accomplish.
A device is slow to wake, slow to keep up with a mind that has already moved on. An application doesn't respond, or responds late, or responds and then quietly loses what we just did. A connection wavers in the middle of the one call that mattered. A file won't sync, a login won't hold, a screen freezes at exactly the wrong second. Nothing about our intention was wrong — we knew what we wanted, we knew how to do it — and the technology simply failed to meet us there.
This is friction as fault: something in the digital environment is not behaving as it should, and the gap it opens is the gap between a working tool and a broken one. You would expect this, at least, to be the friction IT can see. Mostly, it cannot. Far more of it than we admit is absorbed in silence — the employee waits, retries, finds a workaround, and moves on, and nothing is ever recorded. IT comes to know of performance friction only in the fraction of cases where it hardens into something reportable: a user incident finally raised, an infrastructure error alert tripped. And even that is a lagging, partial signal — the visible tip of something far larger that never surfaces at all. Digital friction does not announce itself. It waits to be caught, and most of it never is.
How Did Digital Friction Become an Application Problem?
Wherever digital friction is discussed today, one part of the digital workplace tends to dominate the conversation: the application. Friction is commonly described through difficult interfaces, confusing workflows, unused features, poor adoption or software that is simply difficult to use. All of these are genuine forms of digital friction. But are they the whole of it? Does digital friction really begin and end with software?
The connection is understandable. As SaaS transformed the enterprise application landscape, organisations suddenly had more software, more frequent change and far more functionality reaching employees than before. Deploying applications became easier; getting people to understand, adopt and use them effectively became a challenge of its own. Digital Adoption Platforms emerged around precisely that problem, and digital friction naturally became an important part of the category's language — because the friction between employees and the applications they were expected to use was real. Over time, that application and adoption view became one of the most visible ways digital friction itself was described. That is a valid view from the application and adoption perspective. But from where we sit as employees, is the application really the only place where we experience digital friction? Is software really the boundary of the problem?
[Article card → Digital Friction — The Three Market Positionings]
What We See Is Not Always What Failed
There is another reason the application so easily becomes the centre of the friction conversation. The application really is the last mile — the final stretch where everything beneath it is delivered, and the only part of the whole stack the employee actually interacts with. So when anything anywhere in the chain falters, that is where it surfaces, and that is where the blame lands. When the screen freezes, we do not say "the network flickered" or "the cloud was slow to answer." We say the app is broken, because the app is what we see. It is the storm we feel, even when the weather formed layers away. Picture the digital workplace as a war room, every layer playing its part — device, OS, network, cloud — but the application stands at the front, takes the first hit, and gets named when anything goes wrong.
prabhu kaliaperumal
The Whole Stack, Not Just the Last Mile
But proximity is not cause. The technology an employee depends on is not one app; it is a complete ecosystem — the device, the application, the operating system, the network, the cloud — and friction can begin anywhere along it. Where friction is felt is almost never a reliable guide to where it began. And still — widen that picture as far as it will stretch, and we will have mapped only one of the two forms in which digital friction reaches us. The other is not on this map at all — because on its side, the technology itself may be working exactly as it should.
Perception Friction: When Technology Works, but It Doesn't Work for Us
The other form of friction is different. The technology may be working perfectly well — fast, stable, exactly as designed — and yet the work still doesn't flow as easily as it could. This time, the friction is not necessarily in the performance of the technology. It is somewhere in the relationship between us, the technology and the work we are trying to do.
We may not know that a feature exists. We may know it exists but not know how to use it. A process may have changed while we continue following the old one. There may be a faster way to complete something we do every day, but we keep taking the route we already know. An AI capability may now do in seconds what we still spend twenty minutes doing manually. Or perhaps we know perfectly well what a technology can do, but we do not trust it enough to use it. A policy, process or way of working around the technology may make the easier path difficult anyway. The technology can be doing its job while something around it — or within us — still gets in the way of ours.
This is perception friction. The gap is no longer simply between what the technology should do and what it actually does. It is between what the technology makes possible and our ability or willingness to turn that possibility into the way we actually work.
The Friction IT May Never See
And there is something else that makes this form of friction particularly difficult to see. It rarely becomes an IT incident.
When a device slows down enough, an application crashes often enough, or a connection becomes unusable, there is at least a chance that someone eventually raises a ticket or a technical alert exposes the problem. Perception friction has no such natural path into IT.
If we don't know a capability exists, there is nothing to report. If we keep following an inefficient process because it is the only one we know, we don't necessarily see a problem. If we avoid a tool because we don't trust it, struggle with a policy, or quietly stay with an old way of working, none of those behaviours naturally becomes a Service Desk ticket.
The work carries the friction. The employee carries the effort. But IT may never know either exists.
That makes perception friction particularly easy to live with — and particularly difficult for organisations to see.
How Does the Gap Form?
It is tempting to look at all of this and call it a training problem. Someone doesn't know something, so someone should have taught them. But the gap is rarely that simple.
Sometimes the perception was never built. A capability was introduced but never really explained. A process changed, but the change never properly reached the people expected to work differently. A new tool was deployed, access was provisioned, perhaps an announcement was sent — but somewhere between deployment and everyday work, the understanding, confidence or trust needed to make use of it never arrived. The technology made it into the workplace. What it could mean for the employee's work did not.
Sometimes the perception never formed. The information may have been available. The communication may have arrived. The training may even have existed. But we skimmed past it, stayed with the method we already knew, ignored another new feature, or simply had too much competing for our attention. Sometimes habit is easier than discovery. Sometimes what we already know feels good enough. Sometimes we understand the new way but don't quite trust it enough to change the old one. The capability was there, but it never became part of how we understood or approached our work.
And often, it is somewhere between the two. The organisation believes it communicated. We believe nobody told us. The feature exists. The documentation exists. The training exists. The process says one thing while everyday behaviour says another. Yet the capability never becomes part of the work.
That is why perception friction is not simply about knowledge, training or adoption. It is the distance that can quietly open between capability and the person — between what technology makes possible and what we understand, trust, embrace and eventually put to work.
When Technology Moves Faster Than We Do
And that distance becomes particularly important now, because technology itself is beginning to move much faster than our perception of it.
AI makes that gap difficult to ignore. A capability we did not have six months ago may exist today. Something that once required specialist knowledge may now be available to anyone. A task we have performed the same way for years may suddenly have a completely different path. Technology can become more capable almost overnight. Our awareness, understanding, trust, behaviour and habits do not necessarily change at the same speed.
Which creates a strange possibility: the technology can keep getting better while the work does not get proportionately easier.
Not because the technology failed. Because what became possible and what we are able to turn into everyday work have drifted apart.
That too is digital friction.
Two Forms. One Experience.
Performance friction and perception friction are very different underneath.
With performance friction, we know what we want to do and how to do it, but something in the technology gets in the way.
With perception friction, the technology may be working exactly as intended, but something between its capability and us — awareness, understanding, habit, behaviour, trust, process, policy or the environment around our work — prevents that capability from translating cleanly into the work we are trying to do.
One asks us to look at how the technology is performing. The other asks us to look at how technology and people actually meet in the flow of work.
They therefore cannot be addressed in the same way. Fixing a slow device will not help someone discover a capability they do not know exists. Improving an application will not necessarily change a process that makes it difficult to use. Training someone will not help if the underlying technology continues to fail. And making an AI capability available does not mean people will automatically understand it, trust it or change the way they work because of it.
But from where we sit as employees, these distinctions are rarely what we experience. We simply try to work.
And whether the technology gets in our way, or something prevents us from getting the best out of the technology, the feeling can be remarkably similar:
Work became harder than it needed to be. That is digital friction.
Performance and perception do not tell us where that friction was originally born. There are many possible sources behind both, and that is another part of the story. They tell us something different.
They tell us how digital friction reaches the person trying to work.
Performance friction breaks the surface || The first form is the one everyone recognises. The technology fails — an app crashes, a login stalls, a file won't sync — and friction scatters outward from the edge of productive work.
Perception friction is the quieter half || The second form is harder to see. The technology works, but the employee's grasp of it falls short — a feature they never knew existed, a task done the long way round. Two forms now ring the core: one loud, one silent.
Only a sliver becomes a ticket || Draw the full boundary and the truth stands out. Of all this friction — performance and perception together — only a small cluster is ever logged as a ticket. The rest is absorbed, worked around, and never seen by IT.