GCC 3.0: From Captive Centers to Nano GCCs
The global capability centre has been rebuilt twice in thirty years, and the label survived both rewrites intact. That continuity of naming hides how completely the underlying logic changed. A capability centre founded in 1998, one founded in 2012 and one founded today are not the same structure at different sizes. They were built to answer different questions.
The distinction matters because the operating assumptions of each generation are still circulating as general advice. Guidance about ramp plans, seniority pyramids, location strategy and governance that was correct for a two thousand person captive centre is actively harmful when applied to a twenty person team, and much of it is still repeated as though it were timeless.
This guide sets out what each generation was solving for, what broke, and what actually defines the third generation. The short version is that GCC 3.0 is not a smaller version of GCC 2.0. It is a different bet: that scope and ownership, rather than scale, are what produce value.
The three generations at a glance
- GCC 1.0 was an arbitrage bet: move defined work to a lower cost location and keep the decisions at home
- GCC 2.0 was a scale bet: build large centres, move up the value chain, and industrialise delivery
- GCC 3.0 is a scope bet: build small senior teams that own outcomes rather than absorb volume
- Each generation solved the previous one’s failure and inherited a new one
- The generations coexist today, which is why so much conflicting advice is in circulation
GCC 1.0: the arbitrage era
The first generation was an answer to a cost question. Work that was well defined, repeatable and documentable was moved to a location where the same work cost substantially less. Maintenance engineering, testing, transaction processing and support were the natural candidates, because they could be specified precisely enough to be executed at a distance by people with no context.
The design followed the logic. Decisions stayed onshore, work travelled in specified units, and the centre was measured on cost and on adherence to specification. Seniority was deliberately thin, because seniority was expensive and the model assumed judgement was not needed locally.
It worked for what it was, and the saving was real. What broke was the ceiling. A centre built to execute specifications cannot be asked to improve the thing it is executing, because it has never been allowed to understand why the thing exists. When companies tried to move higher value work into these centres, it mostly failed, and it failed for structural reasons rather than talent reasons.
GCC 2.0: the scale era
The second generation was an answer to that ceiling. If the problem was that the centre held no context, the solution was to make it large enough and permanent enough to accumulate some. Centres grew into the thousands, took on product engineering, data, analytics and eventually full ownership of platforms, and built genuine career structures that let good people stay.
This generation produced most of the capability centres people picture when they hear the term, and at its best it produced remarkable outcomes. Some of the most consequential engineering in large technology companies is now done in centres founded in this era.
What broke was the entry cost and the shape. GCC 2.0 economics only work above a threshold, because the fixed costs of entity, compliance, facilities, leadership and internal support have to be amortised across a large headcount. That produced a rule of thumb that a capability centre needs several hundred people to make sense, which in turn produced a second problem: centres hiring to reach a viable size rather than to do a defined job, and then searching for work to justify the headcount.
What actually changed to make a third generation possible
GCC 3.0 is not a philosophical reaction to GCC 2.0. It became possible because several of the fixed costs that forced the scale threshold fell sharply, more or less at once.
Company formation, payroll, statutory filing and compliance in India are now well trodden and can be stood up in weeks rather than quarters. This used to be a major share of the fixed cost that demanded scale.
Cloud, managed services and remote first tooling removed the data centre, the long lease and much of the internal IT function that a 2.0 centre had to carry.
The operating practices that make a small remote team effective are now industry standard rather than an experiment, which removed the argument that a team needed to be large enough to be self sufficient in one building.
A small company can now hire a principal engineer in Bengaluru directly and credibly. In the 2.0 era that access was mostly mediated by scale and brand.
Together these changes cut the fixed cost floor by enough that the arithmetic of a twenty person centre stopped being absurd. Once that happened, the constraint on capability centres shifted from what a company can afford to build to what it can usefully own.
What defines GCC 3.0
The third generation is defined by three commitments rather than by headcount. Small size is a consequence of these commitments, not the point of them.
| Dimension | GCC 1.0 | GCC 2.0 | GCC 3.0 |
|---|---|---|---|
| Primary bet | Labour arbitrage | Scale and permanence | Scope and ownership |
| Typical size | Hundreds to thousands | Thousands | Ten to two hundred |
| Work received | Specified units | Programmes and platforms | Outcomes and roadmap areas |
| Seniority profile | Thin, wide pyramid | Full pyramid with local leadership | Deliberately top heavy |
| Decision location | Onshore | Mixed, moving over time | Local from the outset |
| Time to operational | 12 to 24 months | 9 to 18 months | 3 to 4 months |
| Success measure | Cost per FTE | Cost, scale, capability transfer | Ownership, velocity, owned IP |
| Main failure mode | Ceiling on value | Headcount without mandate | Underinvestment in seniority |
The generations coexist. Advice built for the middle column is still the most commonly repeated, and it is the least applicable to a team of twenty.
Why the third generation inverts the seniority pyramid
The most counterintuitive feature of GCC 3.0 is that a smaller centre needs a higher proportion of senior people, not a lower one. Cost models built in the 2.0 era assume the opposite, which is why so many small capability centres are underpowered from the first hire.
The reason is structural. A large centre carries ambient context: there are architects in the building, precedent is visible, and a mid level engineer can absorb judgement from the environment. A twenty person centre has none of that, so judgement has to be present in the headcount itself. A small centre staffed to a 2.0 seniority ratio produces exactly what a 1.0 centre produced, which is a team that can execute specifications and cannot own anything.
Share of the centre at senior or lead level by generation
Planning guidance for structuring a centre rather than measured research. The pattern matters more than the exact figures: seniority requirement rises as centre size falls.
What the third generation inherits as its own failure mode
Every generation solved the previous failure and acquired a new one. GCC 3.0 is not exempt, and its characteristic failure is already visible.
Because a small centre is cheap to start, it is easy to start one without a real mandate. A twenty person team can be approved on a budget line that would never have survived the scrutiny a five hundred person programme attracted, which means the hard questions about scope, ownership and sponsorship sometimes never get asked. The result is a small team with a vague brief, which fails faster than a large team with a vague brief and is easier to quietly close.
The second inherited failure is applying 2.0 economics to a 3.0 structure. If a small centre is judged on cost per head, the rational response is to hire more junior people, which dismantles the only thing that made the small structure work.
- Starting a small centre without a named executive sponsor, because it was cheap enough not to need one
- Scoping the centre as capacity support rather than as owner of something specific
- Applying a cost per head target that pushes the seniority mix downward
- Expecting 2.0 ramp timelines and treating a fast ramp as a warning sign
- Measuring a 3.0 centre on throughput, which rewards volume over ownership
How to tell which generation you are actually building
The label a company uses is a poor guide. The reliable test is to look at where decisions are made, how work arrives, and what the centre is measured on. Those three answers place a centre in a generation regardless of what it is called or how recently it was founded.
Where do decisions get made?
If technical and product decisions of consequence are made onshore and communicated, the centre is operating as 1.0 whatever its founding date. Local decision authority is the defining feature of 3.0.
How does work arrive?
Specified tickets indicate 1.0. Programmes and platforms indicate 2.0. An outcome or roadmap area with the approach left open indicates 3.0.
What is on the first slide of the review?
Cost per FTE indicates 1.0 or an unreformed 2.0. Headcount and capability transfer indicate 2.0. Ownership, escalation rate and owned IP indicate 3.0.
What happens if the centre closes?
If the work simply moves back with some disruption, the centre holds no capability. If specific systems and knowledge would have to be rebuilt, it is a genuine third generation asset.
The generation is a design choice, not a founding date,Centres founded this year are routinely built on 1.0 assumptions, and centres founded fifteen years ago have successfully rebuilt themselves into 3.0. What determines the generation is where the decision boundary sits and what the centre is measured on.
Frequently asked questions
Is GCC 3.0 just a rebrand of the small offshore team?
No. A small offshore team that receives specified work and escalates decisions is a 1.0 structure at small scale, which is the most common thing mistaken for 3.0. The third generation is defined by local decision authority and ownership of outcomes, which a small execution team does not have.
Does GCC 3.0 replace large capability centres?
No, and it is not intended to. Large centres remain the right structure where the work genuinely requires scale, such as broad platform ownership across many product lines. The third generation opens the model to companies for whom scale was never achievable, and gives large companies a way to establish capability without committing to a multi year programme.
What size counts as a Nano GCC?
Commonly ten to two hundred people, but the number is a consequence rather than a definition. The defining characteristics are a top heavy seniority mix, local decision authority and ownership of a named outcome. A thirty person team without those is not a Nano GCC.
Why do third generation centres set up so much faster?
Because the fixed costs that forced long setup timelines have fallen. Entity formation, compliance, payroll and infrastructure are now routine and largely parallelisable, and there is no facility build or large scale hiring programme on the critical path. Three to four months to operational is realistic rather than optimistic.
Can an existing large GCC move to the third generation?
Yes, and several have. The transition is governance rather than headcount: move the decision boundary local, change what the centre is measured on, and give named teams ownership of outcomes rather than programmes. Shrinking a centre without changing those things produces a smaller 2.0 centre, not a 3.0 one.
Is the cost saving smaller with a Nano GCC?
Cost saving per head is usually similar. Total saving is smaller simply because the team is smaller, and the fixed costs are spread across fewer people, so the percentage advantage is slightly lower than at scale. The third generation argument is not primarily about cost, it is that a small senior team can own outcomes a larger junior team cannot.
What is the biggest risk in a third generation build?
Underinvesting in seniority. The structure only works if judgement is present locally, and the single most common failure is applying a cost per head target that pushes the seniority mix down until the centre can no longer decide anything.
How do the three generations coexist in one company?
Frequently and awkwardly. A company can run a legacy execution centre, a large scaled centre and a new small ownership centre simultaneously, each needing different governance and different metrics. Applying one operating model across all three is a common source of dysfunction.
Sources & further reading
- NASSCOM — https://nasscom.in/
- Deloitte — https://www.deloitte.com/
- McKinsey & Company — https://www.mckinsey.com/
- Everest Group — https://www.everestgrp.com/
Build for the generation you are actually in
Hexominds designs third generation capability centres: small, senior and scoped around ownership from the first hire rather than scaled into relevance.