The capability you bought a vendor for is the one you should have hired

Most GCCs start life leaning on partners. It’s the right call early. A vendor gets a capability running while the centre is still proving it can run anything, and a statement of work is faster to sign than a headcount plan is to approve. The problem is that the arrangement that was correct at month 6 is rarely revisited at month 30. The vendor stays because removing them is a decision, and keeping them is a default.

The inertia is structural. Extending a contract sits inside an existing budget line and needs one signature. Building an in-house team needs a business case, a set of approved reqs, a hiring runway and a manager who does not exist yet. So the centre keeps paying for the work rather than owning it, and the meter runs on something the accounts never quite name.

This is happening inside a base that is maturing fast. India’s GCC base crossed roughly 2,117 centres employing about 2.36 million people in FY26, per Zinnov and Nasscom, and the mandate is shifting from cost-arbitrage delivery toward owned capability, more than a third of the Fortune Global 500 now run India GCCs, on ANSR’s count. Yet Zinnov, Nasscom and Tiger Analytics find 51% of centres still stuck at the earliest AI-maturity stage, all activity, little ownership. Maturation is exactly the phase where the old vendor relationships stop fitting, because the centre has grown past the reason it hired them.

The first trigger is quiet and it is the most dangerous one. Over enough quarters, a good vendor stops being a pair of hands and becomes the memory of the system. They know why a workaround exists, which edge case broke production last year, which upstream team to call when a pipeline stalls. None of that is written down, because writing it down was never in the scope of work.

At that point the relationship has inverted. You are renting the institutional knowledge of your own operation from a company that can raise the rate, reallocate its best people, or lose the account to a competitor, and take the memory with it. The dependency is not visible on any dashboard until the day the vendor’s lead engineer rolls off and nobody on your side can explain the thing that just failed.

The signal to watch is escalation flow. When your own people route real questions to the vendor rather than the other way round, the knowledge has already moved outside the building. That is the moment to start pulling it back, and it usually arrives well before the contract math says anything is wrong.

The second trigger is about what the work has turned into. A capability that was peripheral when you outsourced it can drift to the centre of the mandate without anyone re-classifying it. The data pipeline that fed one report now feeds the product. The QA function that checked releases now shapes what gets built. The work did not change hands, but its weight changed. The migration is visible across the ecosystem, EY finds India’s life-sciences GCCs now run around 70% of finance, 62% of supply-chain and 67% of IT work for their parents, capability that was once peripheral now sitting at the core.

Core work is the work a competitor cannot easily copy and a customer actually feels. Once a capability crosses that line, keeping it at arm’s length inside a vendor contract becomes a strategic exposure. You are letting an outside party set the pace on something your business now depends on, and their incentives are their utilisation, not your roadmap.

David Byrne makes a version of this point about music in How Music Works: the room shapes the song, and a piece written for a stadium is built differently from one written for a small club. Capability grows the same way. A function developed inside a vendor’s environment takes the shape of the vendor’s constraints and incentives; bring it into your own building and it grows toward your priorities instead. Once the work is core, the shape it grows into is the part you can no longer afford to have set by someone else.

The tell here is prioritisation friction. When the vendor’s backlog and your business priorities start diverging, when the thing you most need done next quarter is not the thing they are staffed to do, the work has outgrown the arrangement. Core capability wants an owner whose only priority is your outcome, and a vendor, by design, is not that owner.

The third trigger is the one that shows up in calendars before it shows up in budgets. Early on, a vendor saves you coordination: they run themselves and you check the output. As the work gets more entangled with your systems, the cost flips. Your own people spend their weeks writing briefs, clarifying context, reviewing handoffs and re-explaining decisions the vendor was not in the room for. That time is a real cost, and it does not appear on the invoice.

There’s a threshold where the fully-loaded coordination tax, the internal hours spent managing the relationship plus the latency of every decision that has to cross the boundary, exceeds what it would cost to run the capability with your own team. Past that point the vendor is more expensive than in-house even when the rate card looks cheaper, because the expensive part was never the rate card.

The failure mode is to give notice first and hire second. Centres do it because it looks disciplined, end the spend, then backfill, and it’s how transitions go wrong. You lose the vendor’s knowledge on the vendor’s timeline, and the person meant to absorb it is still 3 months from a signed offer. The gap is where continuity breaks.

The right sequence puts one hire ahead of the exit. Bring in the in-house owner while the vendor is still fully engaged, and give that person a defined window to do one job: absorb what the vendor knows, document the system that was never documented, and decide what a standing team actually needs to look like. The owner is the first head of the new function and the instrument of the transition itself, the one who converts rented knowledge into owned knowledge before the meter stops.

Who that owner is matters more than the title on the req. You are hiring for two things at once: the technical depth to run the capability, and the judgment to reverse-engineer a system from a vendor who has every reason to hold context close. That person is senior, they are specific, and they are hard to find on a job board, because the skill is as much about extraction and decision-making as it is about the domain. This is the hire to run a targeted search for.

Once the owner is in, the transition follows their read, not a generic playbook. They will tell you whether the capability needs a team of 4 or a team of 10, which parts of the vendor’s work were genuinely hard and which were just unowned, and how long the vendor should stay in a reduced role while the bench builds behind them. Cutting the contract becomes the last step, taken when the owner says the knowledge is inside the building, rather than the first step, taken when the budget cycle asks for a saving.

The centres that get this right treat insourcing as a hiring problem before it’s a procurement one. The real question is whether the capability has become something you can no longer afford to have owned by anyone but you, and if it has, the first move is a search for the person who will own it, run early enough that the vendor is still there to teach them.