Capability centres are having a moment, and a lot of companies are being encouraged into one who do not have the scale, the management capacity or the roadmap to justify it. The model is genuinely excellent above a certain size and genuinely wasteful below it, and the people advising you rarely have an incentive to tell you which side you are on.
01The threshold is about management, not headcount
Below roughly eight to ten engineers, a capability centre gives you the overhead of a distinct organisation - hiring, retention, culture, local management - without the scale that makes any of it worthwhile. A managed team from a partner delivers the same capacity with far less of your attention.
The real threshold is not the headcount, it is whether you have someone senior who will own this. A centre without an engaged owner on your side becomes a group of people waiting for direction, and the resulting disappointment usually gets blamed on the location rather than the vacuum.
| Your situation | Better model | Why |
|---|---|---|
| Under 8 engineers needed | Managed team | Overhead exceeds benefit |
| 8-30, long roadmap, engaged owner | GCC | Retention and context compound |
| Over 30 | Own entity | Scale justifies direct control |
| Project with an end date | Managed team | No continuity to preserve |
| Nobody internally to own it | Managed team | A centre without an owner drifts |
02The costs that are not in the proposal
Entity setup, if you go direct, is months of legal and compliance work before the first engineer starts. Hosting under a partner's entity removes that, which is exactly why it is the sensible starting point - but it is worth understanding that the choice defers the cost rather than removing it.
Then there is the management cost. A capability centre needs a leader on your side who visits, who runs the relationship, and who is accountable for its output. That is a real allocation of senior time, and companies that will not fund it should not start a centre.
03Where GCCs genuinely outperform
The benefit is continuity. Engineers who stay two or three years know your systems, your customers and your history in a way that no rotating arrangement can match, and that knowledge is where the compounding value sits.
The second is control over hiring. You set the bar, you sit in the loop, you decide who joins. That is materially different from receiving whoever a vendor assigns, and it is the reason companies persist with the model even when the day rate is not obviously cheaper.
04Structure the exit before you sign
The uncomfortable question to ask every prospective partner is what happens if you want to take the team in-house. Some support it as a planned transition. Others rely on notice periods, non-solicit clauses and code they control to make leaving expensive.
That answer tells you more about the relationship than anything in the pitch. A partner whose commercial model depends on you being unable to leave has interests that diverge from yours the moment the centre becomes successful.
| Question | Good answer | Warning sign |
|---|---|---|
| Who owns the IP? | You, from the first commit | Assigned on final payment |
| Can we take the team in-house? | Yes, we help with it | Non-solicit, penalty clauses |
| Who makes the final hiring call? | You do | We assign from our bench |
| Average tenure on your accounts? | Two years or more | Deflection or no data |
| What is the overlap window? | A defined, protected block | Flexible, as needed |
05A reasonable way to decide
Start with a managed team of the size you think you need. Run it for two quarters. If the work is continuous, if you keep wanting the same people, and if a leader on your side has naturally taken ownership, convert it into a capability centre with those engineers as the founding group.
That sequencing costs you very little and answers the question with evidence instead of a projection. Companies that commit to a centre first, and then discover the roadmap was shorter or the management capacity thinner than expected, spend considerably more to learn the same thing.
Topics
Lena Voss
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.
Talk to an engineer