Why Your Highest-Performing GCC Can't Reproduce Itself

Why Your Highest-Performing GCC Can't Reproduce Itself

The hidden costs of scaling decisions across borders.

I've sat in rooms in Kraków and Manila where this exact conversation was happening: a second site, built from the first site's playbook, somehow landed different numbers than anyone expected. The story below happened in India. But I've watched a version of it play out everywhere a capability center is asked to replicate itself in a hurry. The playbook is documented, the dashboard is shared, and leadership assumes that if the process travels, performance comes with it. It usually doesn't. And the reason it doesn't is something you won't find on that dashboard.


How GCCs Went From Running Tasks to Owning Decisions

A decade ago, a capability center's job was narrow. Take a defined process and run it more cheaply and cleanly than headquarters could. You could write that down. Hand it over. Audit it.

That's not what most GCCs do anymore. They own outcomes now, including product calls, customer escalations, and P&L for whole functions. Which means the thing being scaled has quietly changed from a task to a decision. A task can be handed over completely. A decision can't. Whoever makes it also needs the standing to have it stick, and standing is the part nobody thinks to package.


Why the Playbook Worked Once and Broke the Second Time

I watched a team hit every milestone on its roadmap nine months ahead of the global template. Leadership flew in to see it. The case study slides were half-written before the results had even settled.

Here's what nobody said out loud during the celebration. That speed wasn't really about process. It came from a hundred small, unglamorous calls the team had made over months, which escalation to override, which customer request to say no to, which metric to protect even when it made the weekly numbers look worse. Nobody wrote any of that down. Why would they? None of it looked like a step. It was a track record building quietly, one unremarkable decision at a time. You only notice it's missing once you try to hand it to someone who hasn't made a single one of those calls yet.

So the organization did what organizations do with things that work: they ran the same playbook in a new geography and expected the same speed. What actually got exported was a set of steps, minus the years of small trust that had made those steps cheap to take. The new team got the document. They didn't get the benefit of the doubt. Every close call had to be argued for now, because nobody upstream had any reason to take their word for it yet.



That's the real story behind the org-chart mess that followed. Nobody could answer the simplest question: What is this, organizationally? A new business unit? Does it fold into the existing one because the customers overlap? For a while, someone parked it under the CFO as an infrastructure project. As if the open question were square footage and server racks and not a team nobody had gotten around to trusting yet. A year in, that unit was answering to more than half a dozen reporting lines. Each applied its own scrutiny, because none had the standing to simply defer. Nothing got established. Nothing has been given clear ownership, and you cannot own a decision you don't yet have the authority to make stick.

Process is the kind of knowledge you can write down. It moves at the speed of a document. What that team had built was not written-down knowledge. It moves at the speed of a relationship, which is to say it doesn't move at all. Every site has to build its own, from nothing.


What GCC Leaders Who Scale Well Do Differently

The GCC leaders I've seen handle this well, don't treat a second site as a copy of the first. They treat earning that same standing as a separate job. Most organizations leave it to chance. These ones don't.

A few things they get right. Someone is named accountable for the new unit before it opens, not after the first unresolved call forces the question. Not a committee. One person, whose job explicitly includes soaking up the ambiguity the org chart hasn't caught up to yet. Often there's someone from the first site, or from global leadership, who spends the early months quietly vouching for the new team's calls. Lending them credibility before they've had time to build their own. Think of a co-signer for someone with no credit history. Same idea. And the new site gets judged on a different clock. Not whether it hits the same milestones at the same pace, but whether it's accumulating the kind of decision history that will let it move that fast on its own eighteen months from now.

None of that shows up in a steering-committee deck. It's not a process improvement. It's a choice. It means spending deliberate effort building something most organizations just assume will appear on its own. The presumption that a team's judgment is worth trusting before it has had the time to prove it.

The centers that scale well aren't the ones with the tightest playbook. They're the ones who understood, before the second site even opened, that they weren't exporting a process at all. They were asking a new team to spend authority that nobody had given them the chance to earn.