Why a GBS Capability Model Depends on Skill Depth, Not Headcount

---

Most GBS organisations respond to rising demand by hiring. That’s operationally logical, but it's thinking too small. 

In the previous article, we examined how structural clarity and phased build-up discipline determine whether a GBS remains stable as complexity grows. Governance maturity, tested decision rights, and clear authority lines prevent escalation and operational drift. 

But structure only holds the organisation together. It doesn't determine what the organisation can actually deliver. That question belongs to capability.  

"Most organisations don't have a capability problem. They have a capability clarity problem. Nobody defined what good looks like at each level, so nobody noticed when it wasn't there." 

Before any hiring decision, there’s a more fundamental question most leadership teams skip.

What is this GBS actually supposed to be?
A processing engine built for transaction volume? 
A transformation partner that improves the business operates? 
A capability hub that provides expertise the wider enterprise can’t replicate elsewhere?

These aren’t stages on a maturity curve. They are different organisations with different skill requirements, different role architectures, and different definitions of performance. 

The answer to that question should drive every hiring decision. Most of the time, it doesn’t. 

What we see repeatedly across GLCs and enterprise GBS centres, drawn from advisory engagements, is capability concentrated in a handful of people. Exceptions go to them. Judgment calls go to them. It’s a risk most leadership teams don’t see coming, because without a live competency matrix, there’s no mechanism to see it. The concentration only becomes visible when those individuals leave and the organisation discovers the depth was never there to begin with. 

A competency matrix, used seriously, forces the harder conversation. Not what skills exist today, but whether the organisation is actually architected to do what leadership says it should do. If the organisation intends to operate as a capability hub, the role architecture must reflect that intent. The competency matrix is where that alignment either becomes visible or gets exposed as absent.

It also solves something most GBS organisations never formally address: who owns what. When capability expectations are defined across roles, accountability becomes structural rather than assumed. Decision stop flowing to the same few people not because of better management, but because the organisation was designed so they don't have to. That's what operational control actually looks like when it's built correctly.

Most organisations have a version of this document sitting somewhere. What they don't have is one that reflects current business intent. That’s the gap between capability architecture and a file nobody opens. 

Most GBS organisations, mapped honestly, sit in the top left quadrant. High headcount, shallow skill depth. The matrix shows what the org chart was designed to hide.  

"A competency matrix isn't an HR document. It's a mirror. Most leadership teams don't look at it closely enough to see what it's actually showing them." 

Hiring without capability logic adds headcount to an architecture that was never properly defined. The fragility doesn't show up immediately. It shows up when the wrong two people resign in the same quarter. 

Headcount is visible. It shows up in org charts, budget approvals, and board decks. Capability architecture doesn't. Which is exactly why it gets deprioritised. Leaders approve headcount partly because it signals action. Without capability logic underneath it, that's not a design decision. It's a response dressed up as one. 

Most GBS leaders approve the next hiring round before answering the more important question: what is this organisation actually designed to be good at? Headcount scales. GBS capability model has to be built. The organisations that get this right treat that distinction as a design decision, not an HR one. 

"The organisations that compound over time aren't the ones that hired the most. They're the ones that knew what they were building and designed every role around that answer."