Global Capability Centers Scale Further When Leaders Hire for Value Over Headcount

Most companies decide how big a new team should be before they know what it's for. They pick a number, 500 people or 700, and hire toward it while the work stays undefined. A team built around a headcount target can be fully staffed and still fall short of what it was meant to do. Its size should follow from the value it's there to produce.

Priji Thomas has spent more than two decades building global capability centers, the hubs companies open to expand engineering capacity beyond their headquarters. Most recently, as vice president and site leader at Flexera, he grew the company's India center from an acquisition into an organization of more than 800 people. Before that, at Ness Technologies, he led delivery teams of more than 1,000 across 15-plus of these centers. "Is the goal reaching 500, or is the goal reaching the business value that you want to unlock?" he says. Reaching that value depends on the first people hired. They set what the group can do, who leads it, how it runs, and how far it can grow.

Thomas doesn't reach for the candidate whose résumé matches the job description line for line. A person who already holds every skill on the list has nothing new to figure out and gets bored fast. "If I hire someone who has everything, what is that person going to learn?" he asks. The skills keep changing regardless, so Thomas hires for problem-solving and a drive to keep learning. He then gives each new person a path for the year ahead so the role keeps opening up.

Founding roles

Those first hires settle into three distinct roles. One is the technical leader who goes deep on architecture and becomes the person others bring problems to. Schooling carries an engineer only so far, and a strong architect gives the team someone to reason with when what they learned doesn't match what they run into on the job. "You need someone to bounce your ideas off," he says. That leader also mentors the engineers who arrive later.

A second role owns how the group works day to day. Governance for 10 or 100 people looks nothing like governance for 1,000, so the team needs someone who can set up process that survives each jump in size. Thomas hires for the person who standardizes early and keeps the system coherent.

The third role is managing people, and it still calls for technical skill. When someone on the team asks a question, a manager who keeps passing it along stops being useful. Thomas points to a rule he associates with Microsoft, where a person is promoted to manager only once they can do the work their team does. That way they can answer questions directly. A manager leading an AI team, then, has to understand the technology well enough to guide the people building it. The routine parts of the job, approving timesheets and signing off on leave, are "things which are going to go away," he adds.

Build complementary teams

Thomas builds the group like a jigsaw, fitting it together one piece at a time. "Each person in the team will not have all the skills, but the team as a unit, they would complement each other," he says. The one who does know everything becomes a bottleneck, because the team ends up routing everything through a single person.

Thomas also wants a spread of experience and temperament. "You can't have all A-players in a team. You need to have a bunch of leaders and a bunch of followers," he notes. What motivates each person differs too, whether it's pay, a title, the work itself, or the difference they get to make. Reading that in conversation is the part Thomas treats as a craft, one that sharpens over years of hiring.

Design for ownership

When a company opens a capability center, it usually sits next to an existing team in the US or Europe, and the easy move is to copy how that team is organized. Thomas designs the structure around what he wants the new group to be responsible for. A team that owns its work decides how to do it and answers for the results. He also sets the working process early, how the group tracks progress and stays accountable, so everyone knows what's expected. "When you have more than three or four people doing something together, it's very difficult to converge," he says.

That process holds up over time, and Thomas changes little about it. The main adjustment is sharing specialists, such as a database engineer, across teams as the group gets bigger. "A database engineer might not be necessary for every team. You might make do with maybe one database engineer for two or three teams," he notes. A consistent way of working and open communication are what keep the team moving together.

Rethink team size

AI is changing how much a team can get done, so the right number of people for a job won't stay fixed. A company that locks in a headcount at the start is committing to a guess. For Thomas, the question is whether 100 strong early hires can build an organization that delivers what 1,000 would.

He calls what makes that possible the X factor. It comes down to the leadership and skill concentrated in those first hires, enough for them to set up and run new teams themselves. The result might be a group of only 700 or 800 people that still does the work of 1,000.

Thomas is skeptical when a company announces a new hub by headcount alone. "Where is this 500 number coming from?" he asks. The figure rarely traces back to what the group is meant to achieve.