Think Build Implement Repeat
Business Automation

Knowing Whether Work Is Progressing, Without Watching People

Last updated:

Activity metrics make things worse

Lines of code, tickets closed, hours logged, keystrokes. All measurable, all gameable, and all measuring effort rather than value.

Worse, they change behaviour in predictable ways: more small tickets, less refactoring, less helping colleagues, and quiet resentment. The measurement damages the thing it measures.

Measure flow instead

  • Cycle time — how long from starting a piece of work to it being live
  • Work in progress — how many things are open at once, which is usually too many
  • Blocked time — how long things wait, and on what
  • Deployment frequency — how often value reaches customers
  • Failure rate — how often a change causes a problem
Blocked time is the most useful and least measured. In most teams, work spends far longer waiting than being worked on, and the waiting is usually a management problem rather than a capacity one.

Look at the system, not the individual

Flow metrics describe the system. If cycle time is long, the cause is usually queueing, unclear requirements, or too much work in progress — not individuals working slowly.

Using team metrics to assess individuals is how a diagnostic tool becomes a surveillance one, at which point the numbers stop being honest.

Ask the team

The people doing the work know where the friction is. A regular, blameless conversation about what slowed things down this fortnight surfaces more than any dashboard.

Then fix what they name. A team asked repeatedly and never acted upon stops answering honestly.

What monitoring software costs you

Screenshot monitoring and activity tracking damage trust substantially and measure presence rather than contribution. The strongest performers are usually the first to leave when it is introduced.

If the underlying concern is that you cannot see progress, the answer is regular demonstrations of working software, not surveillance.

For outsourced work

The same principle applies: judge on delivered functionality demonstrated regularly, not on hours reported. Time sheets tell you what was spent, not what was achieved.

Frequently asked questions

How do we know if someone is underperforming?

Through the work: what is delivered, its quality, and how they collaborate. A manager close enough to the work knows within weeks, without any metric.

Is velocity a useful measure?

As a capacity planning input for a stable team, sometimes. As a target or a comparison between teams, no — it inflates immediately and stops meaning anything.

What about billable utilisation?

Necessary in a service business as a commercial measure, and it is not a productivity measure. High utilisation with poor delivery is worse than moderate utilisation with good delivery.

Should we track time at all?

For client billing and for understanding where effort goes, yes, at a coarse level. Fine-grained tracking costs more in accuracy and morale than it returns.

Keep reading

Wondering whether your team is delivering?

Regular demonstrations of working software answer that better than any metric. Happy to talk through what to look at.

Book a free 30-minute call Get a project estimate WhatsApp us

Related services

What we build for problems like this one

Business AutomationCustom Software Development