What Changed About Outsourcing, and What Did Not

Outsourcing discussions tend to be framed around rates, which has become the least interesting variable. Cost differentials have narrowed in most established markets, remote work removed the novelty of distributed teams, and the operational mechanics are well understood.

What has not changed is the thing that actually determines whether an engagement works, which is whether the people doing the work understand why the system is the way it is.

The arbitrage is smaller than the model assumes

Rate differences between markets persist but have compressed, particularly for senior engineers, whose salaries are increasingly set by global demand rather than local cost of living. A business case built on a large per-hour saving is frequently working from figures that were accurate several years ago.

The saving that remains is real but smaller, and it is usually offset by coordination overhead unless the engagement is structured carefully. Two teams in different timezones each waiting on the other's answers can lose more to latency than the rate difference recovers.

The engagements that still make clear economic sense are those buying access to scarce skills, or speed to start, rather than those buying cheaper hours for work an in-house team could do.

Distributed is normal; distributed and disconnected is not

The pandemic settled the question of whether distributed engineering works. It does, and organisations that were sceptical mostly are not any more.

What it did not settle is the difference between a distributed team and a separated one. A distributed team shares context: the same conversations, the same understanding of why decisions were made, the same access to the person who knows the awkward part of the system. A separated one receives specifications and returns deliverables.

The second arrangement is where outsourcing fails, and it fails in a specific way — the work is technically correct and practically unusable, because the constraint that made the obvious solution wrong was never transmitted. That is not a skills problem and no amount of process fixes it.

Context transfer is the entire game

The most reliable predictor of an engagement's success is how much unfiltered access the delivering team has to the people who understand the domain.

This is uncomfortable to arrange. It means engineers talking directly to operations staff rather than through a project manager. It means access to production incidents and support tickets rather than a summary. It means the first few weeks producing very little visible output, which looks like poor value if you are measuring throughput.

Organisations that protect their internal staff's time by routing everything through a single point of contact are optimising for the wrong thing. The bottleneck they create costs more than the time they save.

AI tooling has changed the ratio, not the requirement

Code generation tools have made producing code faster, which changes the composition of the work. Less time typing, proportionally more time deciding what should be built and reviewing whether what was produced is correct.

That shifts the value further toward judgement and away from throughput, which has an implication for outsourcing: buying hours of capacity is worth less than it was, and buying people who make good decisions is worth more. Engagements priced and measured on volume of output are increasingly measuring the part that has become cheap.

It also raises the stakes on review. Generated code that looks plausible and is subtly wrong is harder to catch than code someone wrote deliberately, and a delivery model where nobody with domain understanding reviews the output is now riskier than it used to be.

Data and residency constraints shape the options

Where work can be done is increasingly constrained by where data can go. Regulated industries, public sector work and anything involving personal data of certain populations carry residency and access requirements that rule out some arrangements entirely.

This is worth establishing before selecting a partner rather than after, because it can eliminate options that were otherwise attractive. It also argues for engagement models where work happens in your environment, on your infrastructure, with access that is granted and revoked by you.

What to ask a prospective partner

How long before someone is productive, and what happens during that period. A vendor claiming immediate productivity on an unfamiliar system is either not reading the code or telling you what you want to hear.

Whether the people who win the work are the people who do it. Continuity of named individuals matters more than the size of the organisation behind them.

What handover looks like if you stop. If the answer involves a transition project, knowledge has been accumulating in the wrong place throughout.

Fixed price rewards the wrong behaviour on unclear work

Fixed-price contracting is attractive because it moves risk to the supplier, and it does that by giving the supplier a financial interest in doing less. On genuinely specified work that is fine. On work where requirements will move, it makes every clarification a commercial negotiation.

The observable symptom is a relationship where both sides spend more time on scope than on the product. Neither party is acting badly; the structure is producing it.

Where cost certainty is genuinely required on unclear work, a paid discovery phase ending in a real estimate — with no obligation to continue with the same supplier — gets you a number that means something. A fixed price quoted before anyone has read the code is either padded or optimistic, and you will find out which.

Knowledge concentration is the risk to watch

The failure that hurts most is not a bad deliverable. It is discovering, two years in, that only the supplier understands a system central to your business.

It happens gradually and without anyone deciding it. Documentation is written for the supplier's team rather than yours. Decisions are recorded in their project tools. Your engineers stop reviewing because the supplier is faster on their own. Each step is locally reasonable and the accumulation is a dependency you did not choose.

The countermeasures are simple and need enforcing from the start: work in your repositories, decisions recorded in your repository, your engineers on the reviews even when it is slower. If any of those is dropped for efficiency, the efficiency is being borrowed against a future cost.

The structural question

Outsourcing works well for bounded specialist work, for capacity where the work is genuinely parallel, and for capability you do not intend to build in-house. It works poorly as a permanent substitute for engineering ownership of a system central to your business.

That distinction has not changed with technology, and it is the one worth settling before comparing rates.