Averages Hide the People Having a Bad Time

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.

The measurement in “Averages Hide the People Having a Bad Time” should connect system evidence with the time required to complete real work, without turning one metric into a judgement about a person. Teams considering daily work tracking can compare workload and project time at an appropriate group level, but should interpret the pattern alongside surveys, walkthroughs and the people doing the task.

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

Why the tail is the point

Experience problems are concentrated, not 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.

What to report instead

Median rather than mean, which is less distorted by extremes.

And the worst tenth, always, beside it.

Those two numbers together describe the organisation. Either alone misleads in a predictable direction.

The distribution shape

Bimodal is common: two populations with different hardware or locations, averaging to a middle nobody experiences.

Where you see it, stop reporting one figure and report two cohorts, because they are different problems with different fixes.

Finding the affected cohort

Sort by the measure and look at the bottom decile.

Then ask what they have in common: device model, age, site, role, application set.

Usually one or two attributes explain most of it, and that attribute is the fix.

This takes an afternoon and is more productive than any amount of dashboard browsing.

The improvement illusion

Replacing the worst machines moves the average noticeably, which looks like broad improvement.

Reporting it that way overstates what changed for most people, who experienced nothing.

Say what happened: these four hundred people went from four minutes to ninety seconds, and nobody else changed.

Specific claims survive scrutiny; general ones invite it.

Per-person tails

A small group of people has a bad time on nearly every measure.

They are the ones raising repeated tickets and the ones who have given up raising them.

Finding and fixing that group is the highest-value action available to most programmes, and it is invisible in an organisational average.

The reporting rule

No experience measure should ever 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 to check

Does your reporting show a tail, or only an average?

Who is in your worst tenth, and what do they have in common?

Is any of your data bimodal?

And when you last reported an improvement, who actually experienced it?

The point

No experience measure should be published as a single average.

Median, worst tenth, and the size of the affected group.

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.