How to measure employee productivity fairly

Most productivity scores measure activity and then quietly present it as output. Keyboard and mouse events are easy to count, so they get counted, and a number appears next to somebody’s name. The number is real. What it means is much less obvious.

What activity data can and cannot tell you

Activity signals are genuinely useful for a narrow set of questions:

• Was this person working during the hours billed to a client?
• Is this team’s workload distributed anywhere near evenly?
• Has utilisation shifted materially since last quarter?
• Which projects consumed more time than they were scoped for?

They are close to useless for others:

• Is this person good at their job?
• Was this the right work to be doing?
• Did the thinking that happened away from the keyboard have value?

The distinction matters because a score used outside its competence produces bad management decisions with a veneer of objectivity.

A three-layer model

Layer 1 — Presence

Hours worked, attendance, shift adherence. Objective, easy to verify, and the right basis for payroll and client billing. It says nothing about quality and should not be asked to.

Layer 2 — Application of time

Where the hours went: which projects, which categories of tool, how much was fragmented across context switches. This is where app and URL data earns its place, provided it is classified per role.

Layer 3 — Output

What was actually produced. Tickets closed, deals moved, cases resolved, features shipped, articles published. This layer never comes from a monitoring tool — it comes from the systems where the work lives.

A productivity conversation that only uses layers one and two is a conversation about attendance. The judgement always lives in layer three.

Make every score drillable

If a manager cannot answer "where did this number come from?", the number should not be in a review. Any score you publish needs a path from the headline figure down to the individual sessions that produced it. This is partly fairness and partly practicality: roughly one score in ten turns out to have an innocent explanation, like a laptop left running overnight or a mislabelled project.

Compare people to themselves

Ranking a team against each other rewards whoever has the most keyboard-heavy role, not whoever contributes most. Trend lines per person are far more informative. A drop from someone’s own established baseline is a signal worth a conversation — usually about blockers, tooling or workload, and occasionally about something happening outside work.

Handle the edge cases deliberately

• Meetings: calendar-aware scoring, or heavy-meeting roles will always look idle
• Deep work: long low-input periods in a document are not the same as an empty desk
• Field and client work: expect and exclude time spent away from a machine
• Part-time and flexible schedules: score against the contracted pattern, not a nine-to-five default
• Accessibility: assistive technology produces different input patterns and must not be penalised

Four failure modes

Optimising the metric

Once people know activity is scored, activity rises and output does not. Mouse jigglers exist for a reason. If your metric can be gamed with a twelve-dollar USB device, it was never measuring what you claimed.

Scoring the wrong unit

Individual scores in genuinely collaborative work misattribute constantly. Team-level scoring is often more honest, and less corrosive.

Precision theatre

Reporting productivity to one decimal place implies an accuracy the underlying data does not support. Bands — strong, expected, needs a look — communicate the real confidence better.

Using it as evidence after the fact

Pulling six months of activity data to justify a decision already taken is the fastest way to destroy trust in the whole system. If the data was not being reviewed at the time, it should not be introduced afterwards.

What good looks like

A fair productivity measure is transparent about what it counts, adjusted for role, compared against a person’s own history, always paired with real output, and reviewed regularly enough that nothing in it is a surprise. If your current approach fails any of those, that is the place to start.