Hours Logged Tells You Nothing About a Remote Team, and Asking for Them Makes It Worse

A timesheet is a self-report of a number that cannot be checked, submitted by someone who knows what number you expect. Every distributed team can produce forty hours a week indefinitely, whatever happened. That is not a claim about dishonesty. It is a claim about what the instrument can physically detect, which is nothing.

The screenshot tools and keystroke counters that get proposed as the fix are worse, because they measure something real and irrelevant. Typing is not the work. The most valuable half hour an engineer has this week will look, to an activity monitor, like an idle screen, because they were reading code or thinking about a data model. The tool will faithfully record that as a productivity gap.

The measurement destroys the thing it measures

Hours logged has a property that makes it uniquely bad among weak metrics: it is trivially gameable, and everyone involved knows it is being gamed, which makes the gaming feel obligatory rather than dishonest.

Once a team learns that hours are the reported number, several things follow mechanically. Tasks get estimated to fill available time, because coming in dramatically under raises questions. Work that produces no logged hours, such as helping a colleague, gets quietly deprioritised. Nobody reports a slow week, so you lose the early warning that something is stuck. The metric does not just fail to inform you. It removes the signal that was previously reaching you through ordinary conversation.

The same logic applies to the metrics that get proposed as more sophisticated substitutes. Story points completed, tickets closed, and commit counts are all inputs the team controls directly. Point inflation is not a moral failure, it is the predictable response to points being watched. Any number a team can increase without doing more useful work will eventually be increased that way, and the more attention you pay to it, the faster that happens.

What is worth watching instead

The measures that resist gaming share one property: producing them requires actually shipping something a user can use. You cannot fake a deployment.

Metric	Gameable?	What it tells you
Hours logged	Completely	Nothing
Commits or lines changed	Completely	Nothing, and rewards worse code
Story points completed	Yes, through estimate inflation	Only relative velocity within one stable team
Tickets closed	Yes, through ticket splitting	Little on its own
Deployment frequency	Hard	Whether the delivery pipeline works
Lead time from merge to production	Hard	Where the delays are, and they are usually not in coding
Change failure rate	Hard	Whether speed is being bought with instability
Time to restore after a failure	Hard	Operational maturity
Decision latency: question asked to answered	Hard	Whether your own organisation is the bottleneck

The last row is the one that most often surprises people, and it is the one that most often indicts the client rather than the team. Log the timestamp when an engineer asks a blocking question and the timestamp when they get an answer. On many distributed engagements the median sits above a working day, which means a feature needing four clarifications loses four days to waiting regardless of anyone's speed. No timesheet will ever show you that, because the waiting engineer is logging hours the whole time.

The reasoning behind these choices, and how to introduce them without triggering a defensive reaction from the team, is covered in the guide on what to measure when a development team's output is not directly observable. The short version is that outcome metrics work because they are properties of the system rather than reports from individuals.

Trust is a substitute for measurement, and it is cheaper

The reason organisations reach for timesheets is rarely a genuine belief that hours predict value. It is that they lack any other visibility and a timesheet arrives on a schedule. The instinct is reasonable. The instrument is wrong.

What replaces it is a working environment where you can see the output directly. Four things do most of the work.

1. Deploy continuously to something you can look at. A staging environment updated on every merge replaces every status report, because you can open it. If you cannot see the software running until the end of a sprint, you will ask for a proxy, and every available proxy is bad.
2. Make the work visible where it happens. Pull requests, issue threads and decision records, all readable by your side without anyone assembling a summary. Prepared reports are filtered by definition.
3. Write down what a good outcome looks like before the work starts. Most disputes about productivity are actually disputes about scope that were never resolved.
4. Talk to the engineers, not only the lead. A five minute conversation with the person doing the work tells you more than a month of timesheets, and it is the check that a distributed arrangement most often lacks.

None of these is a metric. All of them are visibility, which is what was actually wanted.

When the number really is the deliverable

There is one case where hours are the right unit, and it is worth separating cleanly. If you are buying capacity by the hour, from individuals embedded in your own teams and directed by your own managers, then hours are the commercial unit and tracking them is contract administration rather than performance measurement. The mistake is to treat that administrative number as a management signal.

If you are buying a team that owns outcomes, hours are not the unit at all, and asking for them signals that you have not decided which model you are in. The distinction between buying a team that owns delivery and buying individual capacity by the hour determines which question you are entitled to ask, and mixing the two produces the worst of both: a team held to outcomes it does not control, reporting hours nobody reads.

Getting this right is an onboarding decision, not a rescue operation. The measurement agreement should be settled in the first fortnight alongside environment access and escalation paths, which is why the sequence for onboarding a dedicated development team puts it early. A team that has been reporting hours for six months cannot easily be moved to outcome metrics, because the switch reads as an accusation. When we set up a dedicated development team, the reporting model is agreed before the first sprint for that reason.

What to do next

Take whatever report you currently receive and ask one question of each number on it: could the team increase this without a user being better off? Every number where the answer is yes should be deleted or demoted to internal use.

Then instrument two things this month. Lead time from merge to production, which you can get from your deployment pipeline without asking anyone. And decision latency, which needs nothing more than a shared log of blocking questions with two timestamps. Give both a month before drawing conclusions.

If the second number is bad, resist the urge to raise it with the team first. Look at who was on the other end of the unanswered questions. It is usually your side.