Staff Augmentation Metrics: What to Measure and When to Worry

Why augmentation needs its own metrics

Delivery metrics such as the DORA set (deployment frequency, lead time, change failure rate, time to restore) tell you how well a team ships. They're the right tool for a self-organizing vendor team, and we cover them in how to manage a dedicated development team. With staff augmentation they're necessary but not enough, for three reasons.

First, augmented engineers are mixed into your team, so team-level numbers can't tell you whether the extra people are paying off. Second, a large part of the value is the vendor's promise: fast candidates, fast replacements, people who stay. That promise needs its own measures. Third, you're paying a monthly rate per person, so the question "what do we get per dollar?" is fair and answerable.

So we split the metrics into four layers. Each answers a different question, and each has a different owner on the vendor's side.

The twelve metrics, with thresholds

These are the thresholds we use as defaults when a client asks us to agree on measurable terms. They assume mid or senior engineers and a reasonably healthy codebase. Adjust them after the first quarter, once you have your own baseline. A metric without a threshold is just a chart; a threshold tells everyone when to talk.

A few notes on the less obvious lines. Time to productivity is the only judgment call in the list; define "routine ticket" with your team once, then let the buddy or tech lead mark the date. PR cycle time mixes the engineer's work and your review speed, which is deliberate: if it goes red because your reviewers are slow, that's a finding about your side. For reference on the QA line, our own internal number is 5% of tickets returned from QA to developers, so 10% as the green line is a generous default.

Attrition deserves a closer look than most clients give it. Every unplanned departure costs you a new ramp of one to three months, which is why a vendor that keeps people is worth a higher rate. Ask for attrition across the vendor's whole company as well as on your account; the company-wide figure predicts your future.

Cost per delivered unit, worked through

This is the metric finance will ask for, and the one most teams skip because "delivered unit" sounds hard to define. It doesn't need to be perfect. It needs to be consistent.

Pick the unit your team already counts: story points if your estimates are stable, completed tickets of a normal size class if not. Then divide the monthly cost of the augmented engineers by the units they delivered. An example:

Never compare cost per point across teams. Points aren't a currency, and comparing them encourages inflation. Compare each team with its own past. For the rate side of the equation, see IT staff augmentation cost.

Built by Gilzor

Results we’ve shipped

70+products launched

98%delivered on time

85%clients come back

Real estateModernizing a Multi-Service Real Estate Marketplace→FinTechAndroid application for FinTech industry→Pharmacy · DACHRedesigning and modernizing an Online Pharmacy mobile app→

Talk to the people who build it. Tell us about your project and get a free estimate of scope, timeline and cost.

See how we’d approach yours →

Score your engagement

Enter your current numbers. The tool applies the thresholds above, marks each metric green, amber or red and tells you which layer needs attention first. Leave a field at its default if you don't track it yet.

How to collect the data without micromanaging

Every metric above comes from a system you already pay for. That's the point: nobody fills in a form, and nobody watches anyone's screen.

• Git hosting (GitHub, GitLab, Bitbucket): first merged PR, cycle time, review rounds. Most platforms export this; a small script or an engineering analytics tool does the rest.
• Your tracker (Jira, Linear, Azure Boards): throughput, QA returns via status transitions, and the date someone first closed a ticket alone if you tag it.
• Vendor reports and your inbox: request and start dates for candidates and replacements. A shared spreadsheet with four columns is enough.
• Finance: invoices and timesheets for cost per unit and billing accuracy.

Be careful with tools that capture screenshots, count keystrokes or score "activity". They measure presence, not output, and good engineers leave clients who use them. Many CEE vendors' engineers are employed under EU privacy law, and their employer may not be allowed to run that kind of monitoring for you anyway. If hours need verifying for billing, a timesheet tied to tickets does the job.

A word on AI coding tools: they inflate commit and line counts, which is one more reason to ignore both. Flow and quality measures still work. We look at how AI changes the picture in AI in staff augmentation.

A dashboard that fits on one page

The monthly vendor review needs one page, not a BI project. The layout we recommend:

1. Top row: four tiles, one per layer, each colored by its worst metric. Anyone can read the state of the engagement in five seconds.
2. Middle: the twelve metrics with this month, last month and a three-month sparkline. Trends matter more than single values; one amber month after a holiday is noise.
3. Bottom: the people table: each engineer, start date, ramp status, any open feedback item, planned leave. This is where attrition risk gets discussed.
4. Footer: actions agreed last month and their status.

Keep it in whatever your team already uses: a spreadsheet, a Notion page, a Looker or Grafana board. The format matters far less than the habit of reading it together every month.

Review cadence and who owns what

When a metric turns red

A red metric is a question, not an answer. Here's where each one usually points, from what we see in practice:

If the same layer stays red for two months after a clear conversation, that's a vendor problem rather than a people problem, and it may be time to rethink the vendor or the model. Our guide to vetting augmented developers covers how to raise the bar at the front of the funnel so fewer metrics go red later.

Put the vendor metrics in the contract

The vendor service layer only works if the numbers are written down. Sales decks promise "candidates in 48 hours" and "replacement at no cost"; contracts often say nothing measurable. Before signing, ask for the following in the agreement or a service schedule:

• Candidate profiles within a set number of business days of a written request.
• A trial period per engineer (two to four weeks is common) with no penalty for release.
• A replacement target in business days, and whether the replacement's ramp-up is billed.
• A monthly report with hours, changes in the team and known risks.
• Notice periods in both directions and what happens to work in progress.

Treat these as service targets with a review clause, not as penalties. Penalty-heavy SLAs push vendors to send the first available person rather than the right one. The software outsourcing contract guide covers the legal side, and our staff augmentation RFP guide shows how to ask for these numbers before you shortlist.

FAQ

Where Gilzor fits

We like being measured, because the numbers usually help us. Before an engagement starts we agree the metrics and thresholds with you, and the monthly report covers hours, team changes, ramp status and risks. Internally we track the same quality signals we recommend here; 98% of our work is delivered on time and 85% of our customers come back. If you're comparing vendors, our team extension page explains how we start, and our projects show what the teams have shipped.