Captive vs BOT vs Managed GCC: Which Operating Model Should You Choose?

An operating model is not a procurement preference. It fixes four things at once: who legally employs the people doing the work, who holds the intellectual property and process knowledge they create, who carries the execution risk during setup and ramp, and what it costs — in money, time and disruption — to change the arrangement later.

Those four consequences run in different directions. Direct employment gives the strongest control over roadmap, culture and retention, but it also puts entity formation, hiring, compliance and attrition management on the parent organization at the exact moment senior attention is scarcest. Contracting the same work to a partner removes that burden and starts delivery sooner, but the operational knowledge accumulates in the partner's organization rather than yours.

The choice is also not permanent in principle and quite permanent in practice. Moving between models is legally possible and routinely underestimated: it involves people who must consent to transfer, contracts that must be renegotiated from a weaker position, and tacit process knowledge that does not appear on any asset schedule. That is why the model should be chosen against the work you intend to move and the control that work genuinely requires — and why the terms of any future change belong in the first agreement, not the last.

Finally, the operating model is distinct from the commercial terms you agree with any provider. Rate cards, minimum volumes, gain-share and notice periods are negotiable within every model. Which entity employs the engineers and who owns the capability at the end is not — that is the operating-model decision.

Captive is the right answer when the work is core to the product or the regulated process, when the horizon is long enough for fixed overhead to amortize, when target scale justifies an entity, and when the parent organization can commit senior attention through the ramp. Under those conditions nothing else gives comparable control over roadmap, hiring bar, security posture and culture, and the marginal cost per role is usually the lowest of the four models once scale is reached.

It is the wrong answer more often than boards expect. The most common failure is not financial but managerial: the entity is registered, hiring begins, and the senior sponsor's time is consumed by the parent organization's own quarter. The center then runs for a year without a decision-maker who can resolve scope, quality or escalation questions, and it under-performs while carrying its full cost. A captive that no one has time to run is the most expensive of the four models, not the cheapest.

The second failure is scale mismatch. Entity formation, statutory compliance, HR infrastructure, facilities, security and leadership are largely fixed. Below a certain headcount those costs dominate, and the arbitrage that justified the program disappears into overhead. If the credible three-year headcount is small, the honest answer is usually that a captive is premature rather than that the model is wrong.

The third is treating captive as risk-free because it is owned. Attrition, wage inflation, leadership hiring and the productivity dip during transition apply to owned centers exactly as they do to contracted ones — the difference is that you absorb them directly rather than pricing them into a fee.

BOT creates genuine value when you want eventual ownership but cannot absorb the setup burden now: no India entity, no local leadership, and a delivery date that will not move. The partner contributes entity, premises, recruitment machinery and operating discipline immediately, and you retain a contractual route to owning the capability once it exists.

The value depends entirely on how the transfer is engineered. The terms that matter are specific: exactly what transfers (people, contracts, IP, tooling, documented processes), on what timetable, at what price or pricing formula, under whose employment terms, what consents are required, and what happens if either side delays. When those are settled in the original agreement, BOT behaves as intended. When they are left to good intentions, you negotiate them years later from the weaker position, because the partner holds the operational knowledge and the relationships.

Transfer risk outweighs speed in three situations. First, when the transfer price is a valuation exercise rather than a formula — the acquisition cost can exceed what a direct build would have cost. Second, when key people are not contractually within scope, so what transfers is an entity rather than a team. Third, when the operate phase runs entirely on the partner's management system: the center then develops the partner's ways of working, and legal transfer is followed by a second, undisclosed integration program.

A practical mitigation is to treat the operate phase as a supervised apprenticeship rather than an outsourced period. Place your own leadership inside the center early, adopt your engineering standards and tooling during operate rather than after transfer, and define transfer readiness in operational terms, not only legal ones.

A managed model is attractive when the work is definable and benchmarkable, when volumes vary, when speed matters more than ownership, and when the capability is genuinely not a source of competitive advantage. It removes entity, employment and infrastructure burden entirely, converts fixed cost to contracted cost, and can be operating within weeks rather than quarters. For scoped support, testing, back-office processing or surge capacity, it is frequently the correct end state and should be contracted as one.

It becomes strategically limiting when the scope quietly drifts from defined delivery toward the organization's core work. The mechanism is gradual: a capable partner team absorbs context, becomes the only group that understands a system, and the parent organization loses the ability to specify, evaluate or move the work. At that point the arrangement is no longer a service — it is a dependency, and dependencies are repriced by the party that holds them.

The second limitation is capability accumulation. Under a managed model, every year of delivery experience builds the partner's institutional knowledge, not yours. If your intent is eventual ownership, that is a compounding disadvantage, and it is the reason organizations that plan to convert later should either choose BOT now or write conversion rights into the managed contract from the start — rights over named people, tooling, source, data, documentation and transition support at defined notice.

Cost is rarely the deciding argument either way. Managed delivery is usually predictable per unit and rarely the cheapest at large scale; captive is usually cheapest at scale and rarely cheapest early. Both statements are conditional on your volumes, ramp and utilization, and should be modelled rather than assumed.

Hybrid is the most common outcome at scale, and the least well designed. It works when the boundary is drawn by criticality: a captive core owning product direction, architecture, proprietary data, security and client-facing work, with partnered capacity handling scoped, well-specified or variable-volume delivery around it.

It fails when the boundary is drawn by convenience — whatever was easiest to contract at the time. The result is two teams doing similar work under different employment, different tooling and different performance frameworks, with accountability that dissolves at the seam whenever quality or delivery is challenged.

Four design rules separate the two outcomes. One accountable owner for the entire capability, not one per mode. One performance framework and one definition of quality applied to both. Explicit decision rights stating which choices may only be made inside the captive core — architecture, security standards, hiring bar, data access. And a single technical and security standard that partner teams adopt, rather than parallel environments that must later be reconciled.

Sequencing also matters. Standing up partnered capacity first and the captive core later tends to leave the core permanently subordinate to a running delivery machine. Where both are intended, establish the core leadership and standards first, even at small scale, and let partnered capacity attach to them.

Changing models is legally routine and operationally expensive. Managed-to-captive conversion is the most common direction: people must be offered and must accept employment with a new entity, contracts and licences must be reassigned, tooling and environments must be rebuilt or transferred, and process knowledge that lives in individuals must be documented before they decide whether to move. Where the contract anticipated conversion, this is a transition project. Where it did not, it is a rebuild in which you may be recruiting against the incumbent partner.

BOT transfer is a change of model by design, and it still fails when the trigger, price and scope were left open. Captive-to-managed carveouts are usually the cleanest, because you control the asset being contracted — though employee consent, severance and morale during the announcement window are real constraints.

The practical protections are the same in every direction and cost very little to secure at the start: named-personnel provisions, defined transfer or conversion pricing, assignment rights over tooling and licences, source, data and documentation escrow where relevant, mandatory knowledge-transfer periods, and a maintained runbook that is a contractual deliverable rather than a courtesy.

Assume at least one model change over a ten-year horizon. Programs are rarely designed for that, which is why the cost of change is discovered at the worst possible moment — during a renegotiation, a leadership transition or a downturn.