When a company needs more engineering capacity than it can hire in time, it usually looks at three models: staff augmentation, a dedicated team, or managed delivery. Vendors use the names loosely, and the same contract can describe very different day-to-day arrangements. The labels matter less than two questions: who directs the work, and who is accountable for the outcome.
Answer those two, and the rest follows: what you need to provide, what the partner needs to provide, and how the arrangement is likely to go wrong.
Who directs the work, who owns the outcome
Put the three models on a line.
- Staff augmentation. You direct the work and you own the outcome. The partner supplies engineers.
- Dedicated team. You set the direction and priorities, and own the product outcome. The team organises its own day-to-day work and owns the quality of its delivery.
- Managed delivery. You agree the outcome and the constraints. The partner plans, directs and delivers the work and is accountable for the result.
Moving along the line, you give up day-to-day control and take on less management load. Neither end is better. The right point depends on how much engineering leadership you have and how clearly you can define what you want.
Staff augmentation
With staff augmentation, individual engineers join your existing team. They attend your stand-ups, work in your tracker, follow your coding standards and report to your engineering manager or tech lead. From the inside, they look like colleagues with a different employer.
It works well when:
- You already have a functioning team, process and technical leadership.
- The gap is capacity or a specific skill, not direction.
- The work is ongoing and mixed rather than a separate project with clear edges.
What it needs from you: a lead who can assign work, review code and answer questions quickly; onboarding documentation or a person who does onboarding; and access to everything your own engineers use. Augmented engineers inherit your process, so they inherit its gaps too.
Dedicated team
A dedicated team is a complete unit (engineers, and usually a team lead, QA and sometimes a designer or business analyst) that works on your product full time. You set the priorities and accept the results. The team runs its own delivery: planning, estimation, code review, testing and releases.
It works well when:
- You have a product or a clear area of one to hand over, such as a new module, a mobile app or a platform migration.
- You can supply a product owner who sets priorities and is available to the team, but you do not want to manage engineers individually.
- The work will run for many months and benefits from a stable team that builds up knowledge.
What it needs from you: a product owner with authority, a clear area of ownership, and agreed ways of reporting. The team should show working software regularly, and you should see its backlog, its velocity and its problems without having to ask.
Managed delivery
In managed delivery, you and the partner agree an outcome, such as a first release with a defined scope, a migration finished, or a process running faster by an agreed measure, along with the constraints: budget range, timeline, standards. The partner then decides how to get there: team shape, sequencing, technical approach. You judge the results, not the tasks.
It works well when:
- You have no in-house engineering leadership, or it is fully occupied elsewhere.
- The goal can be described and measured.
- You want one party accountable for delivering it.
What it needs from you: a clear definition of the outcome and how it will be measured, fast decisions when the partner needs them, and willingness to hear that part of the plan should change. Managed delivery fails when the outcome is vague, because then nobody can say whether it was delivered.