Every conversation about external engineering capacity starts with the wrong question: how many engineers do we need? The number is the easy part. The question that determines whether the engagement works is structural: when this project is late, whose problem is it? Staff augmentation and a dedicated squad give opposite answers to that question, and most disappointed buyers chose the model whose answer they did not actually want.
Headcount is the easy question. The hard question is where accountability for delivery should sit, and the two models answer it in opposite ways.
What staff augmentation actually is
Team augmentation embeds individual engineers directly into your existing team. They work inside your sprints, your tools, your code review process, and your culture. You direct the work; a good partner stays accountable for the person:
- Direction: your engineering managers set priorities and own the roadmap. The embedded engineers are, operationally, yours.
- Delivery ownership: stays with you. Augmentation adds capacity to a delivery machine you already run.
- Partner accountability: covers the engineer, not the outcome. Weekly performance reviews, code-quality checks, and a replacement guarantee keep the person reliable; your process keeps the project on track.
- Best-case fit: strong in-house engineering management with more roadmap than hands, and deep product context that would be expensive to transfer out.
The hidden cost of augmentation is management bandwidth. Every embedded engineer consumes code review, coordination, and context-sharing time from the leads you already have. That cost is worth paying when those leads have surplus capacity. When they do not, each added engineer makes the constraint worse while appearing on paper to relieve it. This is the single most common miscalculation we see in augmentation engagements, and it is invisible in the rate card.
What a dedicated squad actually is
A dedicated squad is a different contract with reality. The partner staffs and runs a complete cross-functional team around a scope, typically a delivery lead, engineers, QA, and DevOps, and owns the outcome, not just the people:
- Direction: you set the destination and the acceptance criteria. The squad's delivery lead runs the day-to-day and answers for progress.
- Delivery ownership: sits with the partner, with one named accountable owner from kickoff through support. Milestones, quality, and velocity are their problem to manage and yours to inspect.
- Composition: cross-functional by design, so the squad does not borrow your QA capacity or your DevOps attention to function.
- Best-case fit: a well-scoped outcome (a platform, a module, a modernisation) where you want progress without adding management load, or where no in-house team exists yet.
We delivered a Singapore university's student management platform this way: a squad of five under a single accountable owner, from requirements through commissioning, hosting, and multi-year support. The university's staff set requirements and inspected milestones. They did not run standups.
When augmentation is the right call
- You have delivery management to spare: your sprint machine works, your tech leads have review bandwidth, and the constraint is purely hands on keyboards.
- The work is entangled with your core product: context transfer would cost more than management overhead, so bringing people to the context beats moving the context out.
- Capacity needs are spiky: you need two backend engineers for three quarters, not a standing team, and you want to scale down as cleanly as you scaled up.
- You are testing the water: starting with one or two embedded engineers is the lowest-commitment way to evaluate an offshore partner's quality bar before trusting it with an outcome.
When a dedicated squad is the right call
- The outcome is scopeable: you can write down what done means. Squads thrive on defined outcomes; they drift on open-ended wander.
- Your managers are the bottleneck: adding five augmented engineers to an overloaded engineering manager makes the bottleneck worse. A squad brings its own management.
- The work is separable: a new platform, a distinct module, a system modernisation with clean seams to the estate. Separability is what lets accountability transfer honestly.
- You need the whole function: QA, DevOps, and a delivery lead included, rather than assembled from your own stretched teams.
The hybrid path most companies actually take
In practice the models are a sequence, not a fork. The pattern we see most: start with one or two augmented engineers on a contained slice of the roadmap. Use the first quarter to judge the partner's real quality bar, the responsiveness of its governance, and the honesty of its reporting. Then, when a scopeable outcome appears, convert trust into a dedicated squad, keeping the original engineers as its context-rich core. Co-delivery sits in the middle: your architects and the partner's squad sharing one plan, which suits organisations that want outcome transfer without losing architectural control. The mistake is not choosing the wrong model. It is signing a twelve-month commitment to either model before you have delivery data on the partner.
How to decide
- Write down who owns the outcome today. If the answer is a specific manager with capacity, augment. If the answer is nobody, or someone already drowning, buy a squad.
- Score the work for separability. Clean seams favour a squad; deep entanglement with your core product favours embedded engineers.
- Check your management surplus honestly. Every augmented engineer consumes review and coordination bandwidth. Count it before you spend it.
- Demand the same governance in either model: weekly performance reviews, independent code-quality checks, a replacement guarantee, and one named accountable owner on the partner side.
- Start smaller than you think, with a defined scale-up trigger. One to two engineers or a minimum viable squad, expanding on delivery evidence rather than projections.
Both models work. Both fail. The difference is almost never the engineers and almost always whether the accountability structure matched the buyer's actual capacity to manage. Decide by who owns the outcome, and the headcount question answers itself.
