These three models get compared on rate, which is the least interesting difference between them. The distinction that determines whether an engagement works is who owns the outcome — and that has consequences for how you manage it, what you can hold someone to, and what happens when things slip.
Staff augmentation: you own the outcome
Individuals join your team and take direction from your managers. They attend your standups, work your backlog and follow your engineering practices. The supplier provides people; you provide everything else.
This works when:
- You have a functioning delivery process that additional people can plug into
- The gap is specific skills or capacity, not delivery management
- Requirements change often enough that a fixed scope would be renegotiated constantly
- You want direct control over priorities day to day
It fails when the underlying delivery process is the actual problem. Adding four engineers to a team that cannot get work to production does not produce more output; it produces more work in progress and a larger group of people waiting.
Managed team: the supplier owns delivery
A complete team with its own lead, reporting against outcomes rather than timesheets. The supplier owns delivery management, quality and reporting; you own priorities and acceptance.
This works when:
- You want a workstream owned end to end without staffing it internally
- Your own delivery management capacity is the constraint
- The work is separable enough to be owned by a distinct team
- You would rather review outcomes fortnightly than manage individuals daily
It fails when the work is not genuinely separable. A managed team that needs to coordinate constantly with your internal team on shared code has all the coordination cost of augmentation and none of the control.
Project outsourcing: the supplier owns the whole thing
A defined deliverable, a fixed scope, an agreed price. The supplier decides how to build it and carries the risk of getting the estimate wrong.
This works when:
- Scope can genuinely be defined up front and is unlikely to move
- Acceptance criteria can be written objectively
- You have a hard budget ceiling that matters more than flexibility
- You do not need the resulting capability in-house afterwards
It fails, predictably, when scope moves. Fixed-price contracts create an adversarial dynamic around change, because every variation is a commercial negotiation. If you expect to learn things during the build that change what you want, this is the wrong model and no amount of goodwill will fix it.
| Staff augmentation | Managed team | Outsourcing | |
|---|---|---|---|
| Outcome owner | You | Shared | Supplier |
| Day-to-day direction | Your managers | Supplier lead | Supplier |
| Handles changing scope | Very well | Well | Poorly |
| Needs your delivery capacity | Yes | Some | Minimal |
| Capability stays in-house | Yes | Partly | No |
| Commercial shape | Rate per person | Monthly team rate | Fixed price |
The mistake that causes most friction
The common failure is buying augmentation and expecting outcome ownership. A client contracts individual engineers, then holds the supplier accountable for a delivery date — despite owning the backlog, the priorities, the architecture decisions and the release process.
The engineers cannot be accountable for an outcome they do not control. Either contract a managed team and hand over delivery ownership, or keep augmentation and accept that delivery accountability sits with you. The unhappy middle is where most soured engagements live.
Mixing models
Most mature arrangements use more than one. A managed team owning a separable workstream, augmentation topping up the core team, and occasionally a fixed-price piece for something genuinely well-defined like a migration.
That is fine, provided each piece of work is unambiguously in one model. The failures come from work that drifts between models without anyone acknowledging it — where accountability quietly becomes unclear, and stays that way until something goes wrong.