Segmenting Without Singling Anybody Out
Useful analysis requires breaking the data down. Where that stops being analysis and becomes a report about individuals.
Reading · Procedure
Aggregate data hides the problem; granular data identifies people. The useful ground is in between and it has to be chosen deliberately.
The question in “Segmenting Without Singling Anybody Out” is easier to answer when teams combine system evidence with the time and hand-offs involved in completing the work. An organisation evaluating automatic time tracking can make that operational effort visible by project and team, while direct observation and employee feedback remain necessary to explain why the friction occurs.
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.
Segments that work
Device model and age band. The strongest explanatory variable in most telemetry and entirely impersonal.
Site or building.
Operating system and application version.
Network path or connection type.
Role type where it is broad: field, office, lab, retail.
Each of these explains variance without describing anybody.
Segments that do not
Individual.
Team, where teams are small.
Manager.
Any cut that maps one-to-one onto a named group of under about ten people.
These produce data about people rather than about the estate, and the note on individual scores covers why that is a mistake rather than merely a risk.
The minimum group size
A minimum group size below which figures are not shown. Ten is a common choice.
Applied to every breakdown, including ones that look safe.
And applied consistently when somebody senior asks for the exception, which is the only time it matters.
The combination problem
Two safe cuts can combine into an unsafe one.
Site plus role plus device model can narrow to three people.
Which means the floor applies to the intersection, not to each dimension, and that is harder to enforce than it sounds.
Check your dashboard: can a user apply three filters and reach a single person?
Segmenting to find a cause
The productive sequence: find the bad tail, then look for the attribute that explains it.
Device age explains most. Site explains network. Version explains crashes.
If no impersonal attribute explains it, the honest conclusion is that you have not found the cause — not that the cause is the people.
What to do when a team genuinely looks worse
It happens, and the explanation is almost always environmental: older hardware, a specific application, a different network path, a role that uses heavier software.
Look for that before anything else.
And report it as the environmental finding it is, because reporting it as a team finding starts a different and unproductive conversation.
Documenting the rules
Which breakdowns are permitted, the floor, and who approves exceptions.
Written down before anybody asks.
This is the artefact that lets you refuse a request without it becoming a negotiation about seniority.
What to check
What is your minimum group size, and is it applied to intersections?
Can three filters in your dashboard reach one person?
When a team looked worse, did anybody check the hardware first?
And are the permitted breakdowns written down?
The point
If no impersonal attribute explains a bad cohort, the honest conclusion is that you have not found the cause — not that the cause is the people..
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.