Managers Asking for Team Data

A manager asks for their team's experience figures. The request is well-intentioned and granting it is how a programme becomes a monitoring system.

The measurement in “Managers Asking for Team Data” should connect system evidence with the time required to complete real work, without turning one metric into a judgement about a person. Teams considering online timesheet software 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 they ask

Usually genuinely: somebody on their team is struggling and they want to help.

Sometimes to check adoption of a new tool.

Occasionally for performance purposes, which is the one to worry about and is rarely stated.

Treating all three as the last one is unfair and unproductive.

Why granting it is a problem

Team-level data for a small team is individual data.

A manager who can see device scores will, reasonably, ask why one is low — and the answer involves a person.

And once one manager has it, refusing the next is a negotiation about seniority rather than a policy.

What to offer instead

Ask what they are trying to find out. Nearly always the answer maps to something you can provide safely.

"Is somebody struggling?" — offer to run the operational check and send an engineer, without a report.

"Is the new tool being adopted?" — give the department-level figure with a minimum group size.

"Is my team's equipment adequate?" — give the device age and specification profile, which is an asset question and entirely safe.

The refusal that works

Not "policy forbids it", which invites escalation.

"That data describes equipment rather than people, and at team size it identifies individuals. Here is what I can give you, and here is how I can help with the actual problem."

Specific, helpful, and it holds, because it addresses the need rather than the request.

Writing it down first

A one-page statement of what is available at what level, agreed before the first request.

Shared with managers proactively, so the answer is a published position rather than an individual decision.

This is the single artefact that prevents the drift, and it takes an hour to write.

When it is refused and escalated

Have the named owner take it, and have the written position to point at.

And have an alternative ready, because an escalation answered with only a refusal gets overturned.

Telling the manager what you did

If you sent an engineer, say so.

A manager who asked for data, got help instead, and saw the problem fixed will not ask for data again.

That outcome is what makes the policy sustainable, rather than the policy itself.

What to check

Has a manager asked, and what happened?

Is there a written statement of what is available at what level?

Do managers know it exists?

And when somebody asks, does anybody ask them what they are trying to find out?

The point

Ask what the manager is trying to find out.

Nearly always it maps to something you can provide safely, or to help you can send without a report.

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.