Baselines and What Normal Looks Like

The first month of telemetry always looks alarming. Most of what it shows is ordinary variation that nobody has seen before.

The measurement in “Baselines and What Normal Looks Like” should connect system evidence with the time required to complete real work, without turning one metric into a judgement about a person. Teams considering the productivity guide 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 National Institute of Standards and Technology; the useful test is whether the evidence remains proportionate, accessible and understandable to the people whose work is being measured.

What a baseline is

The ordinary range for each measure, and how much it varies between devices, teams and days.

Not an average. A spread.

Until you have it, you cannot tell whether a figure is a problem or a Tuesday.

How long it takes

Six to eight weeks for weekly patterns.

A full year if anything in your organisation is seasonal, which for most is true: end of quarter, holiday periods, the January return.

Conclusions drawn earlier describe the period observed, and the period was chosen by when the agent was deployed.

The deployment artefact

Agents roll out in waves, usually starting with IT and willing departments.

Those cohorts have newer hardware and more technical users, so the early baseline is flattering.

As deployment widens, the score falls and nothing has got worse.

Record deployment phases on every chart, or the rollout itself will look like a decline.

Segmenting the baseline

One organisation-wide baseline hides everything.

Establish it per device model and age band, per site, and per role type.

A four-year-old laptop and a new one have different normals, and comparing a site to the global average tells you about the hardware refresh cycle rather than about the site.

What varies ordinarily

Day of week: Monday logins are slower everywhere, because everything authenticates at once.

Time of day.

Device age, which dominates most telemetry.

Location and network path.

Account these out before concluding anything about a team.

Marking changes

Every rollout, policy change, hardware refresh and office move goes on the chart with a date.

Without it, a step in the data gets attributed to the wrong cause, and somebody spends a week investigating a change you made.

When the baseline resets

A hardware refresh, an operating system migration, a major application change.

Mark it and start a new baseline rather than comparing across it.

Comparing across a known change without saying so is the commonest way this data misleads.

What to check

Do you know the ordinary range for your main measures, or only the current value?

Is your baseline segmented by device age?

Are deployment waves marked on your charts?

And has anything changed since the baseline that nobody recorded?

The point

Agents roll out in waves starting with IT and willing departments, whose hardware is newer.

The early baseline flatters, and the later decline is the rollout.

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.