Buyers routinely put the same brief to a consultancy, a staff augmentation firm and a managed delivery partner, then compare the three quotes on price. The quotes are not comparable, because the three models transfer completely different amounts of risk and require completely different amounts of client capacity. Picking the wrong one is the most common reason an engagement disappoints without anyone doing anything obviously wrong.
01Diagnose which problem you have
A decision problem means you do not know what to do - which architecture, whether to rebuild, which platform. You need judgement and analysis, delivered over weeks, ending in a recommendation you can act on. Buying engineers to solve this gets you people building while the decision is still open.
A capacity problem means you know exactly what to build and lack hands. You have technical leadership, standards and a backlog. Buying consulting here produces a document restating what your own team already knows. An accountability problem means you need an outcome owned end to end, with someone else carrying delivery risk - and that is a third thing again.
| Model | Solves | You must supply | Risk sits with |
|---|---|---|---|
| Consulting | Decision problems | Access, context, a decision-maker | You |
| Staff augmentation | Capacity problems | Technical leadership, backlog, standards | You |
| Managed delivery | Accountability problems | Clear outcomes and acceptance criteria | Partner |
| GCC / dedicated team | Sustained capacity at scale | Long-term roadmap, retention investment | Shared |
02Staff augmentation fails when leadership is what is missing
Augmentation assumes you supply direction. Where a team is already short on technical leadership, adding contractors makes the gap worse - more people producing more code with no consistent view of where it should go, and a review burden landing on whoever is left.
The signal is honest self-assessment: if there is nobody who can say definitively how something should be built and hold that line, augmentation will not help. That is an accountability problem, and it needs a partner who brings leadership as part of the arrangement.
03Managed delivery only works with defined outcomes
Transferring delivery risk requires something specific to transfer it against. Where outcomes are genuinely definable - build this integration, migrate this system, hit this availability target - managed delivery works and the partner earns their margin by absorbing variance.
Where requirements are genuinely emergent, the model fights the work. Every discovery becomes a change request, the partner protects their margin by resisting scope, and both sides spend more time on the contract than the product. Discovery work belongs in consulting or augmentation; managed delivery starts once the shape is known.
04Blended engagements, sequenced deliberately
The arrangement that usually works is sequential rather than simultaneous. Start with a short consulting engagement to settle the decision and produce a costed plan. Move to managed delivery for the parts that are now well defined. Use augmentation for sustained capacity alongside your own team once direction is set.
What to avoid is buying all three at once from different suppliers with overlapping remits, which produces a coordination problem larger than any of the problems being solved.
- Consulting first when the decision is genuinely open - keep it short and time-boxed
- Managed delivery once outcomes are definable and acceptance criteria exist
- Augmentation when you have leadership and need throughput
- Never buy managed delivery for work whose requirements are still emerging
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.