How do you measure a remote team's output without counting hours?
Do not compare velocity between teams, and do not report it upward. Story points are a planning aid a team calibrates for itself, and the moment they become a performance measure they inflate, quietly and reasonably, because everyone involved would rather deliver eleven points than eight. The measures worth having describe flow and outcomes rather than effort, and there are fewer of them than any dashboard suggests.
Why do the usual metrics fail?
Because each of them measures something a team can increase without producing anything more valuable. Hours logged measure presence. Commit counts measure how often someone types a command. Lines of code measure verbosity and punish the deletion that is often the best work of the week. Story points measure a team's own estimate of its own work, which is why comparing them across teams is meaningless.
This is not cynicism about teams, it is a property of measurement. Any number attached to consequences becomes a target, and targets get met by the cheapest available route. If the cheapest route to a better number is better work, the metric is good; if a cheaper route exists, that route gets taken by ordinary people acting reasonably.
The test to apply to any proposed metric is simple: could a competent, honest team improve this number without the business being better off? If yes, it is a diagnostic at best and should never carry consequences.
What should you measure instead?
Flow and stability, which resist gaming because improving them requires actually improving how work moves. Four measures cover most of what you need: how long a change takes from starting work to running in production, how often you release, how often a release causes a problem, and how long it takes to recover when one does.
These work because they are measured on the system rather than on people, and because the shortcuts that would improve one degrade another. A team can release more often by skipping testing, and the failure rate immediately tells you. A team can reduce failures to zero by never releasing, and the cycle time tells you. The set is self-checking in a way that single metrics are not.
Add one non-technical measure: how much of what shipped was still in use three months later. That is the only number in this list that measures whether the work mattered, and it is uncomfortable enough that most organisations avoid it.
| Measure | What it tells you | How it gets gamed | What catches the gaming |
|---|---|---|---|
| Cycle time, start to production | Whether work flows or queues | Splitting work into trivial pieces | Look at the size of what shipped |
| Release frequency | Batch size and pipeline health | Releasing untested changes | Change failure rate |
| Change failure rate | Quality of what reaches production | Releasing less often | Release frequency and cycle time |
| Time to restore service | Operational maturity | Reclassifying incidents as non-incidents | Customer-reported issue counts |
| Feature still used at three months | Whether the work mattered | Hard to game, easy to avoid measuring | Nothing, which is why it is worth having |
| Story points per sprint | Very little across teams | Estimating more generously | Nothing, do not use it for assessment |
How do you judge quality without reading the code?
Look at what happens after delivery rather than at the code itself. The proportion of work that is rework, meaning changes made to fix something recently shipped, is the most honest quality signal available to a non-technical buyer, and it needs no engineering judgement to read.
Two other signals are almost as good. How often the team's estimates hold, not as a performance measure but as an indication of whether they understand the system they are working in. And how often something breaks in an area nobody touched recently, which points at fragility rather than at carelessness.
If you want a technical read and have no engineer, ask the supplier's lead to walk you through a recent pull request and explain the review comments. You will learn more from watching how they discuss their own work than from any static analysis report, and the absence of substantive review comments is itself the finding.
What about individual performance?
Do not measure it, and be sceptical of any supplier who offers to. Individual output metrics in software are the most reliably destructive measurement practice in the field, because most valuable engineering work is collaborative and the individual attribution is arbitrary. The engineer who spent Tuesday helping two colleagues finish their work looks unproductive in every individual metric that exists.
Managing individuals is the supplier's job and it is one of the things you are paying for. Your relationship is with the team and its lead, and reaching around them to assess individuals undermines the person who is accountable for the whole.
The exception is a specific, observable concern raised as a concern rather than as a number: someone is unresponsive, someone's work needs unusual amounts of rework, someone appears to be on three projects. Those are legitimate to raise with the lead, and a good lead will already know.
How often should you look at any of this?
Monthly for trends, never weekly for judgement. Software delivery is noisy at short intervals, and a fortnight with a difficult migration in it will look terrible by every measure while being the most valuable fortnight of the quarter. Reacting to weekly variation produces a team that manages the metric rather than the work.
What is worth watching weekly is the demo, because it is the only source of information that cannot be summarised into something misleading. Working software either does what was asked or does not, and that judgement takes ten minutes and no dashboard.
The right cadence for metrics is a monthly conversation with the lead in which you look at the trend together and they explain what happened. If the explanation for every dip is convincing and the trend never improves, that is the finding.
What single question tells you most?
Ask the team what is slowing them down, and see whether the same answer appears twice. A team that says the same thing three months running is telling you about a real constraint that nobody has been empowered to fix, and it is usually something cheap: a slow test suite, a flaky staging environment, an approval that takes four days, an unanswerable question about priorities.
This works because the team already knows where the waste is, and no metric will find it faster than asking. It also tests something the numbers cannot: whether they feel able to answer honestly. A team that says nothing is slowing them down is either extraordinarily well run or not telling you.
Run it as a standing item in the monthly review, write down the answers, and fix one of them each month. The visible act of fixing what they raised does more for output than any measurement programme, because it converts the team from being measured to being helped.
Common questions
- How do you measure developer productivity on a remote team?
- Measure the system rather than the people. Four flow measures cover most of it: how long a change takes from starting work to running in production, how often you release, how often a release causes a problem, and how long recovery takes. They resist gaming because the shortcuts that improve one degrade another. Add one outcome measure, such as how much of what shipped is still in use three months later.
- Is velocity a good measure of a development team?
- Only as a planning aid inside a single team. Story points are that team's own estimate of its own work, so comparing them between teams is meaningless, and using them for assessment causes gradual, reasonable estimate inflation. Velocity should never be reported upward as a performance figure or written into a contract, because meeting the target does not require producing anything more valuable.
- Should I track hours for a dedicated development team?
- Hours measure presence, not value, and tracking them shifts attention toward looking busy. There is a narrow legitimate use where billing is genuinely hourly, but for a fixed monthly team arrangement it produces administrative work and no information. What you actually want to know is whether work is flowing and whether what ships holds up, and neither is visible in a timesheet.
- How can a non-technical client judge code quality?
- Watch what happens after delivery. The proportion of work that is rework on recently shipped features is the most honest signal available without engineering judgement. How often something breaks in an area nobody touched recently indicates fragility. If a technical read is needed, ask the team lead to walk through a recent pull request and its review comments; the absence of substantive review comments is itself informative.
- Should I measure individual developers on an outsourced team?
- No. Most valuable engineering work is collaborative, so individual attribution is arbitrary, and the engineer who spent a day unblocking two colleagues looks unproductive by every individual measure. Managing individuals is the supplier's responsibility and part of what the arrangement buys. Specific observable concerns, such as unresponsiveness or unusual rework, should be raised with the team lead as concerns rather than as metrics.
- How often should delivery metrics be reviewed?
- Monthly for trends, and never weekly for judgement, because short-interval delivery data is noisy and a fortnight containing a difficult migration will look poor while being valuable. Review the demo weekly instead, since working software cannot be summarised into something misleading. In the monthly review, ask the team what is slowing them down and fix one of those things before the next one.
