Why Most Friction Is Not Technical

Organisations that measure both technical and process friction consistently find the second is larger. That finding has implications for where a programme should sit and who should run it.

The recommendations in “Why Most Friction Is Not Technical” need visible ownership, review time and a way to show whether the change reduced effort for the affected group. An organisation can use this workflow overview to coordinate that implementation work and compare workloads, without treating hours or activity as a complete measure of digital employee experience.

For an independent benchmark, compare this approach with Nielsen Norman Group; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

What turns up

Approvals waiting on a person who is in meetings.

Forms requesting information the organisation already holds.

Tasks requiring three systems because nobody integrated them.

Policies written for a risk that no longer exists.

Onboarding that takes two weeks to produce a working account.

None of this is a technology failure, and all of it is experienced as one.

Why it gets blamed on IT

The person encounters it through a screen.

The ticket goes to the service desk.

And the service desk can only fix the technical layer, so the ticket is closed with the friction intact.

Which produces the familiar pattern: high ticket volume, high closure rate, unchanged experience.

Why it persists

Nobody owns the end-to-end task. Each step has an owner and the sequence has none.

Each step is individually defensible. The approval exists for a reason, the form field was requested by somebody, the policy was written after an incident.

And the cost is distributed: four minutes each, across two thousand people, is invisible to everyone except in aggregate.

What this means for a programme

A DEX programme confined to IT will find and fix technical friction and plateau.

To go further it needs access to process owners, which is a political question rather than a technical one.

Which is why the strongest programmes report somewhere other than infrastructure — operations, transformation, or the chief operating officer.

The approval case

Worth naming because it is almost universal.

Measure the elapsed time from request to decision for your three most common approvals.

The result is usually days, the working time involved is usually minutes, and the gap is pure waiting.

Fixing it needs no technology: a delegation limit, an auto-approve threshold, a named deputy.

Making the case internally

Do not argue it abstractly.

Take one task, walk it, time it, count the steps and the waits, and present that.

One concrete walkthrough persuades where a dashboard does not, because it is specific and everybody recognises it.

What to check

What proportion of your tickets are resolved without the underlying friction changing?

Who owns an end-to-end task in your organisation — anybody?

How long do your three most common approvals take, elapsed?

And where does your DEX programme report?

The point

Organisations that measure both consistently find process friction is larger than technical, and it gets blamed on IT because people encounter it through a screen..

Underlying all of this

Everything in this collection reduces to four habits: find the friction cheaply before buying anything, fix what needs no budget first, report the worst tenth rather than the average, and keep the data about systems rather than about people. None requires a better platform, and a programme doing all four changes more than one twice its size.

The recurring pattern

The recurring pattern across every section here is the same: the measurable is mistaken for the important. Device health stands in for experience, ticket categories for causes, a composite score for a finding. Each substitution is convenient, each produces confident decisions on thin ground, and each is corrected by going and looking at the thing itself.