How to Measure an Outsourced Developer's Productivity

Any company working with an external development team for the first time eventually faces the same uncertainty. Let’s assume they can (to varying degrees) verify technical competence, alignment with requirements, deadlines, and code quality at any time; but how do they know if these people are truly doing good work, or just ticking off tasks?

This question comes up constantly in our conversations with clients looking for providers through our platform. It is becoming increasingly clear that a strong CV or an extensive portfolio is no longer enough; what particularly concerns clients is how to evaluate, month after month, whether the investment is worth continuing.

The issue is that most answers found online are designed for in-house teams, where you can see who is at their desk, who is active on Slack, and who is participating in stand-ups. With an external team, that visibility simply doesn't exist, which is precisely why the classic productivity metrics applied to in-house employees almost always fail when transferred to an outsourcing context.

The Metric That Replaces the Goal

It stands to reason that when you cannot see the day-to-day work, you look for a figure to stand in for it, whether that translates to billed hours, completed story points, tasks closed during a sprint, or anything else that can be quantified. While this may seem like a reasonable solution at first, let’s consider what actually happens to that figure once it becomes important to someone.

There is research highly relevant to this situation. Willie Choi, Gary Hecht, and William Tayler experimentally studied the phenomenon, which they termed "surrogation", and published their findings in The Accounting Review. The core idea is simple: over time, managers come to treat the metric as the strategy itself, rather than merely a signal reflecting it. They view it not as an indicator, but as the actual goal.

The interesting part follows. Researchers observed that the phenomenon intensifies precisely when the metric is tied to money or a direct reward. The more weight placed on that figure, the more completely it supplants the real objective. This creates an awkward dilemma, because a manager’s natural reaction when a figure fails to move is to raise the stakes attached to it, so exactly the kind of intervention that makes matters worse.

Now, apply this to an outsourced team. Do you pay by the hour? The hour becomes the goal. Do you track story points as the primary performance indicator? Story points become the goal. In most cases, no one is intentionally trying to deceive you. Yet the mechanism works exactly that way, regardless of intentions: the financial metric ends up gradually replacing the very value it was merely meant to describe.

This means the hard part isn't finding the perfect metric. It’s deciding, before the work begins, what truly matters; because if the only thing you track and pay for is the hour worked, don’t be surprised when that hour comes to matter more than what was actually built during it.

7 Dimensions of Outsourced Developer Productivity

Once a company accepts that no single number can carry the whole story, the next question becomes what to look at instead. The honest answer is a handful of separate signals, each catching something the others miss. None of them is perfect on its own, and that's exactly the point: put together, they're much harder to game than one metric ever was.

1. Delivery predictability, not raw speed. A developer who ships fast but unevenly, three weeks of nothing followed by a rushed sprint before a deadline, is harder to plan around than one who moves at a steady, slower pace. What actually matters for a client is whether the time between "we agreed on this" and "it's live" stays roughly consistent from one task to the next.

This is close to what the DORA research group (the DevOps Research and Assessment team, now part of Google Cloud) calls lead time for changes, one of the four metrics they identified after years of studying what separates high performing engineering teams from the rest, described in their guide to measuring DevOps performance. You don't need their full tooling to borrow the idea. Tracking how long a task sits between "started" and "delivered," and watching whether that window shrinks or grows over a few months, tells you more than counting how many tasks got closed.

Delivery Speed vs. Predictability in Outsourced Development

2. How much comes back. Every outsourced relationship produces a defect rate sooner or later, the share of delivered work that bounces back with bugs, edge cases missed, or things that technically work but weren't what was asked for. What matters isn't whether this number is zero (it never is), but whether it's shrinking as the developer learns the codebase and the domain, or staying flat, or getting worse. A team that keeps sending back the same category of mistake month after month is telling you something about attention, not just skill.

3. Rework caused by unclear requirements. People mix this up with the point above constantly, but it's not the same problem. A defect is something built wrong. Rework is something built right, to a spec that turned out to be incomplete or nobody quite understood, and none of that is on the developer's technical skill.

CIO's guide to writing unambiguous requirements gets at exactly why this happens: when a requirement can be read more than one way, people fill in the gap with whatever interpretation is easiest for them, not necessarily the one the client had in mind. Now stretch that across an outsourced relationship, where there's no hallway to walk down and just ask. A small ambiguity that would've been cleared up in thirty seconds in person turns into a whole feature getting rebuilt weeks later.

If you're measuring an outsourced developer and most of the wasted hours come from things being redone rather than fixed, the productivity problem might sit on your side of the table, in how tasks get written and handed off.

4. Communication that moves things forward, not just replies fast. A quick "got it, on it" isn't the same as a message that actually helps you make a decision. What's worth tracking is whether the developer's updates give you something to act on: a clear "this will take longer because X" instead of silence until the deadline slips, a specific question instead of a vague "any thoughts on this."

The Project Management Institute's research into why projects fail found that poor communication was named as a contributing factor in the majority of failed projects it surveyed, detailed in PMI's report on the role of communications. With an outsourced team, where you can't just walk over and ask, this weighs even more.

5. Willingness to flag a problem before it becomes one. This is the dimension companies notice only when it's missing. A developer who mentions, two days into a task, that the original approach won't scale the way you expected, is saving you a much larger conversation three weeks later. One who stays quiet and lets you find out when something breaks in front of a client is not being technically wrong, just quietly expensive. It's hard to put a number on this, but you can ask yourself a simple question after each project: did anything surprise you at the end that a mid-task heads-up could have prevented?

6. What happens to the knowledge when the task ends. An outsourced developer who solves problems but leaves nothing behind, no comments, no documentation, no explanation of why a workaround exists, is quietly making your team dependent on them personally rather than building something your team owns. This becomes painfully visible the moment that person is unavailable, whether on vacation, switched to another client, or gone.

Researchers studying the SPACE framework, a model for developer productivity published in ACM Queue by Nicole Forsgren and colleagues from GitHub and Microsoft Research, include collaboration and shared awareness as one of five dimensions precisely because individual output that isn't transferable to the rest of the team doesn't really count as team productivity, even if it looks productive in isolation.

7. Whether the work moved the business forward. This is the dimension that's easiest to lose sight of and the hardest to fake. Forsgren, one of the SPACE framework's authors, has made the point directly: performance is better evaluated as outcomes than as output.

A developer can close dozens of tickets in a sprint and still not move the metric the client actually cares about, whether that's fewer support complaints, a feature that increases sign ups, or a page that finally loads fast enough that people stop abandoning it. Tying at least one review conversation per quarter back to a real business result, not a task count, keeps everyone honest about what "productive" was supposed to mean in the first place.

Quick reference: the 7 dimensions at a glance

Why Common Metrics Can Mislead You

The pattern behind surrogation has a name that predates the accounting research quoted earlier. Charles Goodhart, a British economist, made an observation in 1975 about monetary policy that has since outgrown its original context by a wide margin: any regularity used as a target tends to break down once people start optimizing for it. The idea is usually summarized as a measure ceasing to be a good measure the moment it becomes a target, and it's described in more detail in this article. It explains, almost mechanically, what happens to every one of the metrics companies reach for first when trying to keep an outsourced developer accountable.

Billable hours are the most obvious case. Pay for time logged, and time logged is what you'll get more of, regardless of whether the hours produced anything worth having. This doesn't require dishonesty. A developer working under time pressure will naturally start logging research, meetings, and context switching as billable, because that's what the system rewards. Nobody sat down and decided to inflate the number. The incentive did that on its own.

Story points and sprint velocity fail in a quieter way. These were designed as internal planning tools, a rough way for a team to estimate its own capacity, not as an external performance score. The moment a client starts asking "how many points did you close this sprint," the team has a reason to estimate generously. A task that would have been a 3 becomes a 5. Velocity climbs, nothing about the actual output changes, and the number stops telling anyone anything useful about capacity, which was its only job in the first place.

Lines of code and commit counts might be the oldest example of this failure, and also the most absurd in hindsight. When Elon Musk's team at Twitter reportedly used lines of code written as a factor in 2022 layoff decisions, the backlash from the engineering community was immediate, and the episode is recapped here alongside the broader argument that followed. The same counting habit shows up in smaller, quieter forms too, developers making trivial commits just to keep their activity graph green, or padding a function with extra lines that add nothing. A deeper look at why line counts fail as a productivity signal points out that this isn't a new problem AI coding tools invented, it's one they've made harder to ignore, since a tool can now generate hundreds of lines in seconds without anyone having thought through whether they should exist.

Tasks or tickets closed run into a version of the same trap that's easy to miss because it looks so reasonable on a dashboard. Close more tickets, get a better score, and suddenly a developer has every reason to pick off the small, easy items first and let the genuinely hard, valuable one sit at the bottom of the backlog. The count goes up. The thing the client actually needed built is still waiting.

None of this means these numbers are worthless. Hours, points, commits, and ticket counts all carry real information, just not the kind that survives being turned into a target on their own. The moment any one of them becomes the sole basis for payment, review, or renewal, it starts drifting away from the reality it was supposed to describe, and everyone involved, client and developer alike, ends up optimizing for the wrong thing without quite meaning to.

A Simple Client-Side Framework

Everything so far points to a smaller, more practical setup than most companies expect.

• Choose three dimensions, not seven.

Trying to track all seven at once usually collapses within a quarter. Asked years later what actually holds up, the SPACE framework's own authors recommended drawing from at least three dimensions, including at least one that isn't a pure count, as described in this retrospective interview.

For most outsourced engagements, delivery predictability, rework rate, and communication quality cover the essentials.

• Pair every number with a conversation.

A defect rate tells you something changed, not why. When a chosen metric moves, ask about it in the next check-in instead of letting it sit in a spreadsheet.

• Bundle metrics so none can be gamed alone.

Reviewing two metrics together, say delivery speed and rework rate, makes it obvious when one improves at the other's expense, a practice noted in the same interview.

• Revisit the framework itself.

What matters in month one, usually communication and requirement clarity, isn't what matters by month twelve, usually knowledge continuity and outcome alignment. A framework set once and left untouched is measuring last year's problem.

Conclusion

None of this needs new software or a technical background, just a few things that matter for this relationship, checked regularly enough to catch patterns before they get expensive.

No single number tells you whether an outsourced developer is doing good work. Leaning on one just makes things worse, usually. The harder a metric gets tied to money or a renewal decision, the faster people start optimizing for the number itself, and that's rarely on purpose. It just happens.

What actually works is smaller than most companies expect. A short list of signals, checked often enough that patterns show up before they get expensive. No special tooling needed. Just the habit of asking what a number is really showing before you trust it.