Two models, two different bets
A Nano GCC is not a small traditional GCC. The two are built on different assumptions about where value comes from, and that shows up in almost every operating decision.
One bets on scale, the other on scope
A traditional GCC assumes value comes from absorbing volume efficiently. A Nano GCC assumes it comes from a small group owning something outright.
The traditional capability centre was built on a sound premise: if you are going to carry the fixed cost of an entity, a compliance function and a facilities operation, you should spread it across enough people to make it worthwhile, and then move progressively more work into it. Scale was both the justification and the mechanism.
A Nano GCC starts from a different premise. If a small number of senior people can own a system end to end and decide about it locally, the value comes from that ownership rather than from the volume of work processed. Size then follows from what needs owning, rather than from a threshold that has to be cleared.
Neither is a better model in general. They are answers to different questions, and most of the disappointment in this field comes from building one while measuring it as though it were the other.
How the two models compare
These are the dimensions that actually differ. Everything else about running a capability centre is broadly the same.
| Dimension | Nano GCC | Traditional GCC |
|---|---|---|
| Core bet | Scope and ownership | Scale and permanence |
| Typical size | 10 to 200 | Several hundred to thousands |
| Seniority mix | Deliberately top heavy | Full pyramid, cost optimised |
| Work received | Outcomes and roadmap areas | Programmes and specified work |
| Decision location | Local from the outset | Mixed, moving over time |
| Time to operational | 3 to 4 months | 9 to 18 months |
| Fixed cost per head | Higher, base not amortised | Lower, spread across scale |
| Cost per delivered outcome | Usually lower | Depends heavily on ownership |
| Governance | Light, outcome based | Formal, programme based |
| Main failure mode | Underinvesting in seniority | Headcount without a mandate |
| Ease of reversing | Moderate and bounded | Difficult and expensive |
| Success measure | Ownership, escalation, owned IP | Cost, scale, capability transfer |
The seniority row is the one that causes most damage in practice, because applying a traditional pyramid to a team of twenty produces a group that can implement well and decide nothing.
Three differences that are not about size
If you only take three things from this comparison, take these. Each is a design decision rather than a consequence of headcount.
Seniority runs the other way
A smaller centre needs a higher proportion of senior people, not lower. A large centre carries ambient context; a team of twenty has none, so judgement must be in the headcount. Cost models built for scale get this exactly backwards.
Decision authority is local from day one
A traditional centre typically earns decision rights over years. A Nano GCC is staffed so that it has them from the start, which is what removes the transition where most centres stall.
Size follows scope
A traditional centre grows toward a viable threshold and then looks for work. A Nano GCC is sized to what needs owning, which means it can be right at twelve people and does not need to justify itself by growing.
Which model fits which situation
Work backwards from what the centre is for, not from how much capacity you think you need.
Choose a Nano GCC when
You need capability you cannot hire locally, you have specific systems that should be owned, the work is permanent, and you want the centre operational within a quarter.
Choose a traditional GCC when
The work genuinely requires scale, such as broad platform ownership across many product lines or high volume operations, and you can commit to a multi year build.
Run both when
You already operate a large centre and need capability that does not fit its operating model. A small senior team scoped separately is often better than extending the existing one.
Choose neither when
The work is a bounded project with a real end date, or the underlying constraint is prioritisation rather than capacity. An offshore team will scale the existing problem.
How the economics actually compare
Per head the traditional model wins. Per outcome it frequently does not, and the difference is the fixed base against the seniority premium.
Illustrative comparison of cost composition rather than measured research. The last two rows are the ones that never appear on an invoice and frequently decide which model is actually cheaper.
The row worth dwelling on is onshore supervision. A centre that escalates constantly consumes expensive senior time at headquarters, and that cost is invisible in every comparison built on rate cards. It is also the cost a Nano GCC is specifically designed to reduce, by putting judgement where the work is.
The same work, ordered very differently
Four tracks open at once
Entity, compliance, infrastructure and the senior search all begin immediately. Nothing waits on anything else, which is what compresses the timeline.
Sequential foundation
Entity, then facility, then infrastructure, then a hiring programme. Each handoff adds a wait, and the waits are most of the elapsed time.
Senior core, then first output
Pod lead first, senior engineers next, first production changes by roughly week ten to sixteen.
Volume hiring and onboarding
A large intake against a defined operating model, with delivery ramping over the following quarters.
Ownership transfers
A named system changes hands on a named date with the approval gate removed.
Ownership is earned
Decision rights typically transfer gradually over years rather than on a date, which is where many centres stall.
What each model risks, and what it costs to be wrong
The models differ as much in how expensive a mistake is as in what they deliver when they work.
Nano GCC: the seniority risk
If cost pressure thins the seniority mix, the team loses the ability to decide and the model collapses into an expensive small execution centre. This is the characteristic failure and it is entirely self inflicted.
Nano GCC: bounded downside
Small team, reasonable notice periods, no facility, no capital expenditure. Being wrong costs a defined amount and can be unwound within a quarter or two.
Traditional GCC: the mandate risk
Hiring to reach a viable size and then looking for work to justify the headcount. The centre ends up solving its own existence rather than a business problem.
Traditional GCC: unbounded downside
Facility commitments, large headcount and multi year obligations mean being wrong is expensive and slow to reverse, which is why the decision attracts more scrutiny up front.
The asymmetry is worth naming. A traditional GCC decision is scrutinised heavily because it is hard to reverse. A Nano GCC decision is sometimes approved casually because it is cheap, which means the hard questions about scope, ownership and sponsorship occasionally never get asked at all. Cheap to start is not the same as low risk.
Frequently asked questions
Is a Nano GCC just a small traditional GCC?
No, and treating it as one is the most common mistake. The models differ in seniority mix, decision authority, how work arrives and what success is measured on. Shrinking a traditional centre without changing those produces a small traditional centre, which is the worst of both.
Which is cheaper?
Per head, the traditional model, because fixed costs are amortised and the seniority mix is lighter. Per delivered outcome, usually the Nano GCC, because a senior team resolves its own ambiguity and consumes far less onshore supervision. Compare on the second.
Can a Nano GCC grow into a traditional GCC?
It can grow, and whether it should become traditional in character is a separate decision. Many stay small deliberately and add a second team with its own ownership rather than expanding one team past the point where it can still own things clearly.
Which is faster to set up?
A Nano GCC, by a wide margin: three to four months against nine to eighteen. The difference is mostly that there is no facility build or large scale hiring programme on the critical path, and the remaining work runs in parallel.
Is a traditional GCC obsolete?
No. Where the work genuinely requires scale, it remains the right structure and nothing about the Nano model changes that. What has changed is that scale is no longer a precondition for having a capability centre at all.
Which has lower risk?
A Nano GCC is materially easier to reverse: smaller commitment, no facility, no capital expenditure. A traditional centre is harder to unwind, which is why those decisions attract scrutiny that small ones sometimes escape, occasionally to their cost.
Can we convert an existing traditional GCC?
Yes, and several have. The transition is governance rather than headcount: move the decision boundary local, raise the seniority mix, change what is measured. Expect about four quarters, and expect the visible metrics to worsen for the first two.
Which model suits an innovation mandate?
A Nano GCC fits it better. Small, senior and high autonomy is close to the ideal shape for exploratory work, and it avoids the pressure to fill a large headcount with delivery work in order to look busy.
Related reading
Work out which model your situation actually calls for
Tell us what needs owning and what you have tried to hire. We will tell you which model fits, including when the answer is neither.