Measuring output when you cannot count hours
Output measurement is the answer to remote management and it is genuinely difficult, which is why so many teams fall back on activity.
'Measure output, not hours' is the standard advice and it is correct. It is also given as though it were easy, and it is not — which is precisely why teams revert to counting availability. For broader context on privacy and workplace data, ICO employment guidance is a useful reference.
Why it is hard
Much valuable work has no countable unit. Reviewing someone else's design, unblocking a colleague, noticing a problem before it happens, writing documentation that prevents twenty questions — all real, none of it produces a number.
Counting what is countable therefore rewards the visible and penalises the connective work that holds a distributed team together, usually done by the same few people. For a practical software-side reference on project-level time records, online timesheets adds useful detail.
A team measured on tickets closed will close more tickets and write less documentation. The metric will improve while the team gets worse.
Agree expectations at the right grain
Weekly output measurement produces churn and rewards small visible tasks. Annual measurement is too coarse to correct anything.
A monthly or quarterly rhythm, with agreed goals stated as outcomes rather than activities, is where most teams land. What matters is that the person could tell you, without asking, whether they are on track.
Use several signals, none of them alone
- Agreed outcomes delivered, discussed rather than scored.
- Quality feedback from the people who depend on this person's work — often the most informative signal available and rarely collected systematically.
- Whether commitments hold: does what was said would happen, happen.
- Contribution to the team's capability: documentation, review, mentoring.
Any one of these gamed alone produces bad behaviour. Together, they are hard to game and much closer to what actually matters.
Time data answers a different question
Knowing where a team's hours go is genuinely useful — for planning, capacity, pricing and finding out that a supposedly minor client consumes a third of the week. That is a planning question and it is legitimate.
It is worth keeping firmly separate from performance. Recording time against projects, either in a spreadsheet or with a tracker built for it (Monitask and similar tools report hours by project and by person over a period), tells you what the work costs. Used at team level for planning, the data stays honest; attached to individual assessment, it becomes fiction within a month, because people report what is safe rather than what happened.
Ask the people around them
In distributed work the best information about someone's contribution comes from the colleagues who depend on them, and it is rarely gathered.
A light structured question to two or three collaborators — what does this person do that helps you most, what would you like more of — takes minutes and consistently surfaces the connective work that no metric captures.