Think Build Implement Repeat
London, UK +44 7367 067226
WhatsApp FOLLOW f in X
  1. Home
  2. Blog
  3. Measuring Augmented Developer Performance Fairly
Software Strategy

Measuring Augmented Developer Performance Fairly

Ticket counts and commit volume measure the wrong thing. What to look at instead, and how to account for the ramp-up period honestly.

Updated 2 min readBy SpiderHunts Technologies

Free estimateNo obligation

Get a free estimate

Tell us what you need. A senior engineer reads every enquiry.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →

Quick answer — TL;DR

Judge on rework rate, review feedback trend and whether they are becoming independent. Volume metrics reward the wrong behaviour and punish people working on the hardest parts of the system.

The short answer

Three things tell you most: how often work needs redoing after review, whether the same feedback keeps recurring, and whether they are asking fewer questions about the same areas over time. All three improve with competence and none of them can be gamed easily.

Commits, lines and tickets closed measure activity rather than progress, and they punish whoever is working on the genuinely difficult parts.

What to look at

SignalWhat it tells youWatch for
Rework after reviewWhether the work lands correctlyShould fall over the first month
Repeat feedbackWhether they absorb conventionsSame point twice is fine, five times is not
Question patternWhether they are becoming independentFewer basics, better questions
Blast radius of changesWhether they understand the systemShould widen as confidence grows
Defects found laterQuality that review missedSlow signal, worth tracking

Account for ramp-up honestly

Somebody in their second week is slower than somebody in their third month, and that is expected rather than a problem. Comparing a new person against your longest-serving developer tells you only that one of them knows the codebase.

Compare against the same person two weeks ago. The direction matters more than the level, particularly early.

What not to measure

  • Commit count, which rewards splitting work artificially
  • Lines of code, which rewards verbosity
  • Tickets closed, which rewards picking easy tickets
  • Hours logged, which measures presence
  • Velocity points, which drift the moment they become a target

Each of these changes behaviour the moment people know it is watched, and the change is rarely the one you wanted.

Raise concerns properly

  1. Be specific: which work, what was wrong, what you expected.
  2. Raise it early, in week three rather than month four.
  3. Put it in writing to the supplier as well as saying it.
  4. Give a clear indication of what improvement looks like.
  5. Set a point to review it, and actually review it.

Suppliers can act on that. They can do nothing useful with a general sense that things are not going well, delivered late.

The measure that matters most

Would you want this person on the next piece of work? It is subjective, it is not a metric, and it captures more than any dashboard.

If the answer is yes, the numbers rarely matter. If it is no, work out which of the specific signals above is behind it, because that is what the supplier can act on.

FAQ

Frequently asked questions

The questions readers ask us after this guide.

Still have a question?

Ask us directly — a senior engineer will get back to you.

Ask about your project

How long before we judge?

Give it a month before drawing conclusions, and look at direction rather than level. Judging in week one measures your onboarding, not the developer.

Should we share metrics with the supplier?

Share the specific concerns and what good looks like. Sharing a dashboard of volume metrics tends to produce volume.

Is it fair to compare against our own team?

Only for people at a similar stage of familiarity with the codebase. Comparing a new joiner against a five-year veteran is not a comparison.

What if they are good but slow?

Work out whether it is caution, unfamiliarity or the work being harder than it looks. All three have different fixes, and only one is a performance issue.

Keep reading

More on Software Strategy

Software Strategy

Machine Learning Myths That Waste Budgets

Eight beliefs about machine learning that quietly inflate project costs, what is actually true instead, and how to spot each one in a proposal.

Start here

Thinking about adding developers to your team?

Tell us what you are building, what your team looks like now and where the gap is. We will come back with an honest view on whether augmentation fits, how many people it would take and what it costs. If hiring directly would serve you better, we will say so.

  1. You tell us what you needTwo minutes on the form, or a message on WhatsApp.
  2. A senior engineer reviews itAnd comes back with questions, a realistic range and an honest view on fit.
  3. Free 30-minute scoping callWe talk through scope, options and a realistic estimate — with no obligation.
Free estimateNo obligation

Talk to someone who builds this

Send a short brief and we will come back with an honest view and a realistic range.

Takes under a minute. We never share your details.

  • Free consultation
  • No commitment
  • NDA on request

Prefer to talk? Book a free 30-minute call →