Micro GCC vs Nano GCC: Which Model Fits Your Company
The distinction between a Nano GCC and a Micro GCC sounds like marketing vocabulary, and in some hands it is. But there is a real operational threshold underneath the labels, and companies that cross it without noticing tend to discover the same set of problems: coordination overhead nobody planned for, a leadership gap nobody owns, and a governance model designed for one team being stretched across four.
The difference is not primarily headcount. It is whether the center runs one mandate or several, because that single fact changes what leadership, governance and measurement the center requires.
This article sets out where the threshold actually sits, what changes when you cross it, and how to tell which model your requirement calls for today. If you are earlier in the decision, start with What Is a Nano GCC.
Key takeaways
- A Nano GCC is one mandate, typically 10 to 40 people, with a single accountable owner.
- A Micro GCC is several related mandates, typically 40 to 150 people, requiring a leadership layer.
- The threshold is mandate count, not headcount. Three mandates at 35 people behaves like a Micro GCC.
- Crossing the threshold without adding leadership is the most common failure in this transition.
- Most companies should start Nano and grow into Micro on demonstrated value rather than committing upfront.
Where the threshold actually sits
If you ask how many people separate the two models you will get an unsatisfying answer, because headcount is a symptom rather than a cause.
A Nano GCC is defined by having one mandate and one accountable owner. Everyone works toward the same outcome, the tech lead can hold the whole picture, and your side needs one person to direct it. Coordination cost stays low because there is only one thing to coordinate around.
A Micro GCC has several related mandates running in parallel: perhaps a product engineering pod, an agentic AI team and a platform group. Each needs its own technical direction, they have dependencies on one another, and somebody has to arbitrate priority between them. That arbitration role is the thing that did not exist before, and it does not appear by itself.
The practical test. Can one person on your side hold the full context of what the center is doing and set priority across all of it, without it becoming their entire job? If yes, you are running a Nano GCC. If not, you are running a Micro GCC whether or not you have named it one.
| Dimension | Nano GCC | Micro GCC |
|---|---|---|
| Mandates | One, named | Several, related |
| Typical size | 10 to 40 at launch | 40 to 150 |
| Leadership | One tech lead | Tech leads plus a center lead |
| Your side | One owner, part time | One owner, close to full time |
| Priority arbitration | Not required | Required and formalised |
| Governance | Sprint cadence plus quarterly review | Adds cross-team planning and dependency management |
| Time to operational | 3 to 4 months | 4 to 6 months for first mandates, staged after |
| Measured on | Outcomes of one mandate | Portfolio outcomes plus cross-team throughput |
| Best suited to | A specific capability owned properly | A durable multi-capability presence |
Both remain far smaller and faster than a traditional captive center. See the three-model comparison for that wider context.
What actually changes when you cross over
Four things change, and all four cost something if they are not planned for.
A leadership layer becomes mandatory
With one mandate the tech lead is sufficient. With three, someone must own the center as a whole: hiring standards across teams, shared architecture decisions, and priority when two mandates want the same engineer. Skipping this role does not remove the work, it distributes it badly.
Dependencies become real
Separate mandates start depending on each other, usually through shared platform or data. Managing those dependencies is a discipline in itself and the most common source of unexplained slowdown in a growing center.
Measurement moves to portfolio level
Reporting on three mandates individually hides the question leadership actually asks: is the center as a whole worth what it costs? Portfolio-level outcome reporting has to replace per-team status.
Governance formalises
A single pod runs fine on sprint cadence and a quarterly review. Several mandates need cross-team planning, an explicit priority mechanism and a named escalation path.
The path most companies take
A pattern worth naming, because it is both the most common and generally the most defensible.
Start with a Nano GCC around one mandate you can state in a sentence. Prove it: reliable delivery, then ownership of a defined area, then measurable outcomes against the Value Generation Framework. Expand only once that first mandate runs without constant attention from your side.
This sequencing has a real financial advantage. It defers the largest commitment until after the capability has demonstrated value, rather than requiring the commitment as a precondition of finding out whether it works. It is also a far easier case to take to a board than asking for a hundred-person center on a projection.
One mandate, Nano GCC
A single pod of 10 to 40 owning one named capability, one tech lead, one accountable owner on your side. Governance is a sprint cadence plus a quarterly outcome review.
Prove and deepen
The mandate reaches full velocity and takes outright ownership of its area. Measurement shifts from ramp milestones to value measures, and you learn what the operating model actually costs you in attention.
Add a second mandate
The first genuine test. Add one adjacent mandate rather than two, and appoint the center lead at this point rather than after it becomes obviously necessary.
Micro GCC
Three or more mandates under a center lead, portfolio-level reporting and formal dependency management. Headcount typically 40 to 150 depending on the mandates involved.
Illustrative share of effort spent coordinating rather than building
Illustrative of the pattern rather than measured data. The point is that the middle state, several mandates without a leadership layer, is worse than either endpoint.
The expensive middle state
The worst position is neither Nano nor Micro. It is running two or three mandates on Nano governance because the transition was never explicitly decided.
This happens gradually and almost always without a decision. A successful pod gets asked to take on something adjacent, then something else. Nobody adds a leadership layer because each addition individually seems small. Six months later the tech lead is arbitrating priority across three workstreams while trying to write code, your accountable owner is in meetings all week, and velocity has quietly dropped across all three mandates without any single one obviously failing.
The fix is cheap if applied early and expensive if applied late. When you add a second mandate, appoint the center lead at the same time.
Sources & further reading
- NASSCOM — India industry body publishing GCC headcount, growth and maturity research
- Deloitte Global Shared Services and Outsourcing Survey — Benchmarks on capability center maturity and governance models
- McKinsey on Global Capability Centers — Analysis of GCC operating models and value creation
Frequently asked questions
What is the difference between a Nano GCC and a Micro GCC?
A Nano GCC runs one named mandate, typically 10 to 40 people, under a single tech lead. A Micro GCC runs several related mandates, typically 40 to 150 people, and requires a center lead to arbitrate priority and manage dependencies between them.
Is the difference just headcount?
No, and treating it as headcount is what causes problems. The threshold is mandate count. Three mandates at 35 people behaves like a Micro GCC and needs Micro GCC governance regardless of the number.
Should we start as a Micro GCC?
Rarely. Starting Nano and expanding on demonstrated value defers the largest commitment until the capability has proven itself, and it is a considerably easier case to take to a board.
When exactly should we appoint a center lead?
When you add the second mandate, not after coordination problems appear. Appointing late is the most common and most expensive mistake in this transition.
Can a Nano GCC become a Micro GCC without rehiring?
Yes. The team continues; what changes is the leadership layer, the governance model and the measurement framework. This is one of the practical advantages of starting small.
How long does the transition take?
Adding a mandate to an established center typically takes two to three months, considerably faster than the original launch because entity, compliance, facilities and hiring pipelines already exist.
Does cost per head change between models?
Per-head cost is broadly similar. What changes is leadership overhead, which is a real line item that should be modelled explicitly rather than absorbed. See the True-Up Cost Methodology.
What if we only ever need one mandate?
Then a Nano GCC is the correct permanent answer, not a stepping stone. Many centers stay at one mandate indefinitely and perform extremely well.
Conclusion
The useful question is not which model is better but how many things you are asking the center to own. One mandate is a Nano GCC and should be governed as one. Several related mandates is a Micro GCC and needs a leadership layer, dependency management and portfolio-level reporting.
The models are stages rather than alternatives, and the transition between them is a decision to make deliberately rather than a threshold to drift across. Companies that name the transition and staff for it tend to find the second and third mandates easier than the first. Companies that do not tend to find all three getting slower at once.
If you are choosing today, start with the mandate you can state in one sentence, and let the model follow from that. If you want help scoping it, talk to our team or take the readiness assessment.
Four signals you have already crossed over
Rather than a general rule, these are the observable conditions that indicate the transition has happened whether or not it was decided.
Your accountable owner is always in meetings
When the person directing the center spends most of their week arbitrating rather than deciding, the arbitration work has outgrown a part-time role and needs an owner on the center side.
Teams are waiting on each other
If one mandate regularly blocks on another for platform, data or review capacity, you have dependencies that need managing explicitly rather than resolving ad hoc each time.
The tech lead is no longer writing code
A tech lead absorbed entirely into coordination is a center lead without the title, authority or support. Naming the role formally is cheaper than leaving it implicit.
Nobody can answer “is the center working?”
When per-team status reports exist but no portfolio view does, leadership cannot evaluate the center as a whole, which is precisely the question that gets asked at budget time.
What to do if you recognise these
Appoint a center lead first, before restructuring anything else. That role owns hiring standards across mandates, arbitrates priority, and produces the portfolio view that leadership needs.
Then formalise the dependency picture: which mandates depend on which, and who resolves conflicts. Most centers discover the dependencies are fewer and more predictable than they felt when nobody was tracking them.
Finally, move reporting to portfolio level. Individual mandate reporting continues internally, but what leaves the center should answer the question leadership actually asks.
- Appoint the center lead before restructuring anything else
- Map dependencies explicitly rather than resolving them case by case
- Move external reporting to portfolio level, keep team reporting internal
- Agree a written priority mechanism so arbitration is not personality-driven
- Re-baseline value measures at the portfolio level, not just per mandate
Not sure which stage you are at?
Tell us the mandate you need owned. We will come back with a team shape, a realistic timeline and an all in cost model you can take to your board.