Staff augmentation is priced per person per month, and that number is the easy part of the comparison. The number that decides whether it was a good deal never appears on an invoice.
The cost that sits on your side
Every augmented engineer needs someone of yours to answer questions, review work, unblock decisions and provide context that exists nowhere written down. That someone is usually a senior engineer or a team lead — the most expensive and most constrained person in the building.
At one or two people this is unremarkable. At eight, your lead is running a small outsourcing programme in addition to their job, and the engineering they were hired for stopped happening some weeks ago.
This is the cost nobody prices, and it is the reason augmentation stops paying long before the rate becomes uncompetitive.
Onboarding, paid repeatedly
The second hidden cost is context transfer, and its multiplier is rotation.
A new engineer takes weeks to become genuinely productive on a non-trivial system — not because they lack skill, but because your domain, your data model and your undocumented conventions take time to absorb. That time comes from your senior people.
If the supplier can swap individuals without your agreement, you pay that cost again, and the domain knowledge you funded leaves with the person. This is why the right to approve replacements is commercially more significant than a rate negotiation, and why it is the clause worth arguing over.
Where the models cross over
| People | What usually happens | Better model |
|---|---|---|
| 1–2 | A lead answers questions occasionally. Fine. | Augmentation |
| 3–5 | Coordination becomes a recognisable part of someone's week. | Augmentation, watch carefully |
| 6–10 | A lead is effectively managing a team they did not hire. | Pod, with its own delivery lead |
| 10+ | Multiple leads coordinating; nobody owns the outcome. | ODC |
The threshold is not really a number. It is the point at which your leads spend more time coordinating than engineering — and that arrives earlier if they were already at capacity, which they usually were.
When augmentation is clearly right
- A specific, nameable skill gap. A data engineer for a migration. An SRE for a scaling problem. A mobile lead for two quarters.
- Your process works and you want capacity inside it, not a parallel one beside it.
- Short or uncertain duration, where a pod's structure would be overhead.
- You want direct control of prioritisation day to day.
What makes it work
Four things, none of them about the rate:
- Match to a brief, not a headcount. "A data engineer who has run a Tally-to-ERP migration" gets you someone who has done the work. "Two backend engineers" gets you whoever is available.
- Interview them. If you cannot meet the people, you are accepting availability rather than fit.
- Make handover a condition. Documentation and knowledge transfer as part of the engagement rather than a favour at the end, so a specialist leaving does not take the reasoning with them.
- Give each person a real owner on your side who is accountable for their productivity — not a rota of whoever is free.
The failure mode
Treating augmented engineers as interchangeable capacity. It guarantees the outcome people then complain about: no ownership, no continuity, knowledge that evaporates on rotation, and a growing suspicion that outsourcing does not work.
What did not work was the model, applied past the point where it fits. Above that point the honest answer is a pod or a centre — where the management load sits with the supplier, which is precisely what you are buying.