23 June 20267 min read
Once a company has decided to outsource, the next question is which shape to buy, and it is usually decided by whichever one the first provider they spoke to happened to sell. The two shapes are staff augmentation, where people join your team and you direct them, and managed delivery, where a provider takes a defined outcome and is responsible for producing it.
They are frequently described as differing in size or formality. They do not. The difference is one thing.
In staff augmentation you own the outcome and buy capacity. In managed delivery you buy the outcome and give up some control over how it is reached. Everything else follows from that.
What staff augmentation actually is
You get named people who work inside your process. They are in your stand-up, your board, your repository, your review process. You decide what they work on, day to day, and you are responsible for whether the right things get built. The provider is responsible for the people being good, being available, and being replaced when they are not.
It suits work where requirements move, where priorities are reset weekly, and where the value of a person grows as they accumulate context in your systems. It is also the right shape when you want to expand a capability rather than deliver a project: more front-end throughput, a second support shift, marketing execution that runs continuously.
It asks a lot of you. If your direction is thin, augmented people are expensive and idle, and the failure is invisible for a while because everybody looks busy. This is the model where overlap hours matter most, because the whole arrangement runs on questions being answered the same day.
What managed delivery actually is
You define an outcome and the provider organises the work to reach it. They run their own process, assign their own people, and carry the delivery risk. Your job moves from directing work to defining what you want and accepting what arrives.
It suits work that can be described up front and checked at the end: a mobile app mirroring a settled web product, a migration, an integration, a test suite, a defined remediation. It is also the right shape when you genuinely do not have management capacity, provided you can put that effort into the specification instead.
It asks something different of you. The scope, the acceptance criteria and the definition of done are now load-bearing, and a vague one produces something built exactly as written by people who were never told the writing was a guess. Managed delivery does not remove the work of thinking. It moves it earlier and concentrates it.
The mistake: buying one and managing it like the other
This is the most common way both models fail, and it is a buyer-side failure in both directions.
- Buying managed delivery and then directing daily. You reassign priorities in the stand-up, the provider loses control of the plan they are accountable for, and when the date slips nobody can say whose fault it was. You have paid a delivery premium and taken the risk back.
- Buying staff augmentation and then expecting ownership. You assume the team will decide what to build, spot the gaps and manage themselves. They will not, because that is not what you bought, and they are waiting for direction that is not coming.
- Switching models silently. An engagement that starts as a project and drifts into ongoing capacity, or the reverse, without anyone changing the contract, the reporting or who is accountable.
The prevention is dull and effective: say out loud, at the start, who is accountable for the outcome. If it is you, direct the work and stop expecting initiative on scope. If it is them, define the outcome properly and then leave the method alone.
What each one asks of you
- Staff augmentation needs: a named owner, a maintained backlog, a review habit, and roughly a day a week per workstream of real attention, dropping as context builds.
- Managed delivery needs: a scope that survives scrutiny, testable acceptance criteria, a person who can sign off, and a decision process fast enough that a blocked question does not sit for a week.
- Both need: access sorted before day one, someone who answers questions within a day, and a written definition of what good looks like at the end of the first month.
The honest way to choose is to look at which of those two lists you can actually supply. Attention but not certainty points to staff augmentation. Certainty but not attention points to managed delivery. Neither points at doing preparatory work before starting anything.
The risk and pricing shapes
Staff augmentation is normally billed for time, which means you carry the risk that the work takes longer, and you also keep the benefit if it goes faster. It ramps up and down on notice, and the cost is predictable per person even when the output is not.
Managed delivery carries a premium, sometimes as a fixed price and sometimes as time and materials with a delivery commitment attached. The premium is the price of the provider absorbing estimation risk, and it is fair. What it is not is a way of avoiding the consequences of an unclear scope, because a scope that moves converts the fixed price into a series of change requests and the premium then buys you nothing.
Most companies end up mixing them
The common mature arrangement is augmentation for the continuous work and managed delivery for bounded projects that sit alongside it: a steady augmented team on the product, plus a managed piece for the migration nobody has time for.
That works, with one condition: the two must be separately accountable. When the same people float between the augmented team and the managed project, the project absorbs the interruptions and its commitments quietly stop meaning anything. Different people, or at least explicitly ring-fenced time, and separate reporting for each.
Choosing, and changing your mind later
A practical default: if you can write down what done means and it will still be true in two months, managed delivery is available to you and worth the premium for the risk transfer. If you cannot, buy augmentation and steer, because steering is what you will be doing regardless and this way you are not paying for a commitment nobody can keep.
The models are also not permanent. Plenty of engagements begin as augmentation while the work is still being understood and move to managed delivery once the shape is clear and the provider knows the systems. That is a good sequence, and it is a better one than starting with a fixed outcome that had to be invented for the contract. If you make the switch, change the contract, the reporting and the accountability at the same time, because a model change that only happens in conversation is the drift described above with a friendlier name.