Most friction is not technical

What the term covers, and what gets sold

Digital employee experience describes how it feels to use the technology your job requires. The industry measures something adjacent to that, and the gap matters more than anything else in this subject.

The recommendations in “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 timesheet and task tracking 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 is sold is endpoint telemetry: boot time, memory pressure, application crashes, disk health, network latency. All of it useful, all of it about the machine. A laptop in perfect health, used to navigate a seven-step approval process, produces excellent telemetry and a miserable experience.

The substitution happens because device health is what an agent can see. Noticing it is the first thing to do when reading anything in this field, including the vendor material that dominates search results.

Four kinds of friction

Technical: the machine or the application is slow, broken or unavailable.

Process: the steps required exceed what the task needs. Approvals, forms, handoffs.

Informational: the person cannot find what they need, or does not know it exists.

Access: they do not have permission, and getting it takes days.

Telemetry sees the first. The other three produce most of the complaints and almost none of the dashboard — and each has a different owner, which is why programmes that stay inside IT fix roughly a quarter of the problem.

Start before you buy anything

The usual sequence is: see a demonstration, buy, deploy agents, produce a dashboard, look for something to do with it. Reversing it is cheaper and works better.

Read a hundred tickets — the free text, not the categories. Categories are chosen at ticket creation for routing, and agents pick whichever closes the ticket fastest, which is rational and destroys the data. An hour of reading descriptions produces a picture the category report does not contain.

Walk a common task with a stopwatch. Onboarding is the classic and the findings are reliably uncomfortable: new starters hit every provisioning gap in their first week and tell nobody, because they assume it is normal.

Time three approvals, end to end. The result is usually days; the working time involved is usually minutes. The gap is pure waiting, and fixing it needs no technology at all — a delegation limit, an auto-approve threshold, a named deputy.

Two days of work, no procurement, and it produces three or four candidate problems with rough sizes. That list is what determines whether you need a platform, and for which question.

Report the tail, not the average

An organisation with a median login of 55 seconds and a worst tenth at four minutes reports as healthy. The four-minute group is everybody complaining.

Experience problems are concentrated rather than spread: old hardware, one office with a poor network path, one application version, one team with a legacy configuration. The average absorbs them into a figure that looks acceptable, and the acceptable figure is what reaches the board.

No experience measure should be published as a single average. Median, worst tenth, and the size of the affected group — three numbers, one line, and it changes what the reader does with it.

What the agent sees, precisely

Worth being specific, because the boundary is where the common errors live.

It sees well: boot and login duration broken into phases, application launch times and crashes, memory and disk pressure with history, patch state, and which software is installed versus actually used. That last one is genuinely valuable and underused — a substantial share of installed software in most estates is opened by nobody.

It sees partially: whether a web application is slow, since what happens inside somebody else's cloud is inferred. Whether a meeting was poor — packet loss is visible, whether people could hear each other is not.

It does not see at all: waiting for a person, duplicate entry across systems, the twenty minutes spent finding a document, knowing who to ask, or whether the task was achieved.

That last one is the only outcome anybody actually cares about.

What to fix first

The measurement phase produces more findings than anybody will act on. Two questions order them: how much total time does this cost across everybody affected, and how much effort is the fix.

Rank by total time, not by severity. Four minutes a day for two thousand people is a far larger figure than an hour a week for five — and this ordering usually differs sharply from the complaint ordering, because the loudest complaints come from the most vocal rather than the most affected.

Several of the largest items need no budget at all. Audit group policy, which accumulates for years and is almost never reviewed. Check that every drive mapping still resolves — a mapping to a decommissioned server waits for a timeout at every login for everybody, and finding it takes half an hour. Remove startup applications nobody chose. Set a delegation threshold so routine approvals do not queue behind one person. Name a deputy for every approver, which costs nothing and removes the holiday bottleneck.

These get skipped because no procurement means no sponsor, and because each is individually small. A named owner with a list and a monthly slot is the whole remedy.

Measure before you change anything

A change was made, the dashboard looks better, and the improvement is announced. Whether the change caused it is a separate question that usually goes unasked.

Measure the specific thing for the specific population first, for long enough to know its ordinary range. Change one thing. Measure again the same way, and compare against the range rather than against the single prior value — a move within normal variation is not an effect.

Where you can, roll out to half the population first. The unchanged half is a control and it removes the seasonal and organisational effects that otherwise contaminate everything. This is cheap, rarely done, and it is the difference between a claim and a finding.

Then report it in a form that survives a question: "Median login for the 1,400 users on the old image fell from 3m10 to 1m25 over six weeks; no hardware changed in that group." That holds. "Experience improved 23%" does not.

Where it stops being about systems

An endpoint agent can report that a device is slow or that a person was idle for two hours. The technology is identical; the question is not.

Programmes cross that line gradually and by request rather than by design. A manager asks whether their team is using the new tool. HR asks during a performance process. Security asks what was running on a machine. Each request is individually reasonable and each one granted changes what the system is.

Per-person scores are the clearest case. They measure the person's device, its age, its configuration, the applications their role requires and the network they connect from — none of which they chose. A low score describes an allocation decision made by the organisation, and it will be read as describing the person. That is not a risk; it is what happens.

What holds the line is partly procedural and partly technical. Disabling individual views at the platform is a stronger position than controlling access to them, because a feature that exists will eventually be requested by somebody senior enough to get it.

It also protects the data. People who know activity figures affect them manage their activity figures, and the telemetry stops describing the estate.

What the agent sees, precisely

Worth listing, because the boundary is the thing most often blurred in this field.

It sees well: boot and login duration broken into phases, application launch times and crashes, memory and disk pressure with history, network latency to named destinations, patch and encryption state, and which applications are installed versus actually opened. That last one is genuinely valuable and underused.

It sees partially: whether a web application is slow, because what happens inside somebody else's cloud is inferred. Whether a meeting was poor — packet loss is visible, whether people could hear each other is not. Whether the device is in use, since input is not work.

It does not see at all: waiting for a person, process steps, duplicate entry across systems, the twenty minutes spent looking for a document, knowing who to ask, or whether the task was achieved — which is the only outcome anybody cares about.

Nobody has a trustworthy figure for how much lost time sits on each side of that line, and anybody quoting one is quoting a vendor. What is reliably reported by organisations that look at both is that process friction is substantial and routinely larger than expected.

The fixes that need no budget

These get skipped because no procurement means no sponsor, and because they are distributed across teams so nobody owns the set.

On the device: remove startup applications nobody chose. Audit group policy for rules that outlived their reason — in long-established estates this is routinely the dominant phase of a slow login. Check that every drive mapping still resolves, because one pointing at a decommissioned server waits for a timeout at every login for everybody. Uninstall software nobody has opened.

In the process: set a delegation threshold so routine approvals do not queue behind one person. Name a deputy for every approval role, which costs nothing and removes the holiday bottleneck. Remove form fields asking for information the organisation already holds.

In communication: tell people what changed. A visible fix generates goodwill out of proportion to its size and keeps survey responses coming.

Each needs a before figure. Without it the improvement is an assertion, and the next request for attention is harder to make.

Where programmes stall

Most make visible progress for about a year and then stop. The pattern is consistent enough to anticipate: the technical findings get fixed because they sit inside the programme's own authority, and the remaining ones belong to finance, HR, security or whoever owns the intranet.

Then the dashboard keeps running, reporting becomes a monthly recital of unchanged figures, and attention drifts.

There are three ways out and they are worth choosing between deliberately. Widen the mandate, taking the quantified process backlog to a sponsor above the functions involved — strongest immediately after the technical wins, with evidence in hand. Deepen technically, since the first pass rarely exhausts the estate. Or embed and close: hand the measures to owners who will keep them, and end the programme while the practice continues.

That last option is legitimate and under-considered. What should be avoided is the drift: licences renewed annually, dashboard unopened, agent on every machine collecting data for nobody.

What is deliberately absent here

No products or suppliers are named. The useful distinctions are between methods rather than between vendors, and every comparison available online is written by somebody selling one.

No productivity percentages. The figures in circulation come from vendor calculators multiplying four individually defensible assumptions into one that is not. Time saved is real; the rate at which it converts to output is unknown, and anybody claiming to know it is selling something.

And no claim that a platform is required. Several of the highest-return findings in this field cost nothing to discover and nothing to fix.