How to measure offshore team performance (without surveillance software)

When your engineers sit in the next room, a hundred small signals reassure you that work is happening, most of them worthless as evidence but comforting all the same. Distance removes the comfort. What should replace it is measurement, and the good news is that the measurement which works for an offshore team is the same measurement that works for any engineering team. The bad news is that a whole industry of monitoring software would like to sell you something worse.

This guide sets out what to measure, what to refuse to measure, the small set of signals that genuinely are different for distributed teams, and a cadence for reviewing all of it. It is written for founders, CEOs, COOs and heads of engineering at UK and UAE companies running, or considering, offshore engineering, design or AI teams.

The surveillance trap

Type this article’s question into a search engine and much of what comes back is monitoring software: screenshot capture, keystroke counting, webcam attendance, activity scores. These tools are marketed directly at the anxiety every buyer feels at the start of an offshore engagement, and they answer the wrong question. They tell you whether a person appears busy. You are not paying for the appearance of busyness. You are paying for working software.

Activity monitoring fails on its own terms in three ways.

First, it measures presence, not value. An engineer can generate excellent activity scores while producing code your team spends the next quarter unwinding. The most valuable hours in engineering often look like nothing at all from the outside: reading the codebase, thinking through a design, writing up a decision.

Second, it punishes exactly the behaviour you want. Deep work reads as idleness to a keystroke counter. An engineer who stops to ask a clarifying question before building the wrong thing looks less productive, that day, than one who confidently builds the wrong thing.

Third, it tells your best people what you think of them. Strong engineers have options, and engineers with options do not stay under surveillance. Over time, monitoring selects for the people who will tolerate it, which is the opposite of the selection you want. If a partner proposes screenshot tooling as the answer to your measurement question, that tells you about the calibre of person they expect to place.

None of this means measuring nothing. It means measuring output and flow instead of activity, which is harder to fake and more useful to manage with.

One team, one standard

The structural point comes first, because it decides everything downstream. Under staff augmentation, offshore engineers work inside your sprints, your repositories and your review process, directed by your own leads. Measure them with the same instruments you point at everyone else. The moment you stand up a separate dashboard for the offshore people, you have created a two-tier team, and both tiers can tell.

This has a useful corollary: if you cannot currently measure your in-house team’s delivery, the offshore engagement is the prompt to fix that for everyone. The disciplines that make distributed work measurable, tickets that carry context, reviewed pull requests, decisions written down, are the same disciplines covered in how to manage an offshore team, and they improve the local team too.

The three layers worth measuring

Layer 1: delivery flow, measured at team level

The most widely used starting point is the four measures popularised by the DORA research programme (dora.dev): how often you ship, how long a change takes to reach production, what proportion of changes cause failures, and how quickly you recover when they do. You do not need tooling sophistication to begin; a spreadsheet updated weekly is enough to see the trend, and the trend is what matters.

Two disciplines keep these numbers honest. Measure the team, not individuals: flow metrics describe a system, and using them as individual sticks corrupts them within a sprint. And never set a metric as a target in isolation; teams reliably hit the number by sacrificing the thing the number was supposed to represent.

Layer 2: quality

Flow without quality is just speed. Watch the proportion of work that comes back: defects that escape to production, rework on recently shipped features, pull requests that need repeated rounds of revision. Review turnaround deserves attention in both directions, how long the team waits for your reviews as well as how quickly they respond to feedback, because a slow review loop is the most common hidden tax on distributed delivery and it is usually the buyer’s side that pays it in.

Layer 3: individual contribution, judged rather than counted

Individual performance in engineering is a judgment made by a competent technical lead, informed by evidence: the quality of pull requests, the usefulness of code review comments, the questions asked before building, the reliability of estimates against delivery. It is not a number produced by counting commits or lines of code, and research into developer productivity, including the SPACE framework from Forsgren, Storey and colleagues (ACM Queue), has repeatedly made the case that no single activity metric captures it. Your tech lead already evaluates in-house engineers this way. The same judgment, applied in the same reviews, is the standard for augmented team members.

The four signals that genuinely are different

Applying one standard does not mean pretending distance changes nothing. Four signals earn a specific place on an offshore scorecard.

Ramp milestones. Agree them before day one: environment access working on the first day, a first merged pull request inside the first fortnight, a first meaningful feature shipped inside the first six weeks, calibrated to your stack’s complexity. A ramp that misses milestones is the earliest reliable warning you get, and it is far cheaper to act on than a missed quarter. Setting these up well is part of onboarding, and the groundwork is covered in how to build an offshore team.

Overlap usage. With a UK and Pakistan working day, several hours of live overlap exist; the question is what they are spent on. Healthy teams spend shared hours on the collaboration-heavy work, reviews, design discussions, unblocking, and push solo work to the quiet hours. If overlap time is being consumed by status meetings, you are spending your scarcest resource on your least valuable ritual.

Blocked time. Track how long the team spends waiting: for access, for answers, for decisions, for reviews. This is the metric most likely to embarrass the buyer rather than the team, which is exactly why it belongs on the scorecard. Distance amplifies waiting, because a blocked engineer cannot lean over a desk to resolve it. If blocked time is high, the fix is almost always on your side of the engagement.

Written trail. Sample it monthly: could a competent newcomer reconstruct this month’s decisions from tickets, pull requests and written records alone? Distributed teams run on the written trail, and its decay predicts delivery problems a quarter before the delivery numbers show them.

A simple scorecard

When the numbers say something is wrong

Measurement only matters if it leads somewhere, so decide in advance what happens at each threshold.

Read team-level and individual signals differently. If the whole team’s flow degrades at once, the cause is almost never four people simultaneously deciding to underperform; look at process, priorities, review latency or blocked time first. If one individual’s ramp misses milestones or the lead’s judgment stays negative after a fair run of feedback, that is a placement question, and it should be acted on quickly rather than managed around for a quarter.

This is also where your engagement terms come in. Measurement without recourse is just documentation of disappointment. A partner should stand behind its screening with replacement terms; ours include replacing an underperforming placement within 7 days at no extra fee, so a placement question becomes a one-week fix rather than a renegotiation. The full engagement structure is set out in how it works.

Finally, keep the frame honest in the other direction too. A quarter of green numbers is evidence, and it should settle the internal debate. The point of measurement is not permanent suspicion; it is to replace anxiety with information, in both directions, until the offshore team is simply the team.