The Build-in-Build, Operate & Transfer:

Location selection is treated by most organizations as an analytical exercise producing a defensible recommendation. Data is gathered on talent availability, salary benchmarks, real estate costs, and regulatory environment. A shortlist of two or three cities is produced. A site visit is conducted. A decision is made. The process feels thorough because it is data-rich. It is often inadequate because it is not asking the right questions. 

The standard analysis measures what is visible and quantifiable today. It rarely models what the talent market will look like in three years, when the center is approaching transfer, or in five years, when the client operates it independently. The cities that appear most attractive on a current snapshot are frequently the cities where GCC concentration is highest, talent attrition is most competitive, the employer brand of an unestablished center is weakest relative to established names competing for the same professionals, and salary inflation is most aggressive. The Everest Group identifies location selection as among the top three sources of Build phase execution friction, with the most common failure mode being a Tier 1 city choice made on aggregate talent data, while the specific function required is heavily competed there and an equivalent pool exists at significantly lower attrition risk elsewhere. 

A significant and growing proportion of BOT engagements involve dual-hub or multi-hub configurations, where different functions are located in different cities within the same country to optimize for role-specific talent availability. The Plugscale case study from the storage engineering sector is illustrative: a dual-hub configuration with primary software engineering in Bengaluru and QA and support operations in Chennai was selected after a city-by-city analysis of storage engineering talent availability, because the specific combination of distributed systems, firmware, and cloud engineering talent required was distributed across both cities rather than concentrated in one. 

The dual-hub model creates genuine complexity during Build, Operate, and Transfer, each of which must be managed separately across two locations. It is, however, frequently the right answer when the role architecture includes functions with materially different talent market profiles. Organizations that resist dual-hub configurations on grounds of governance simplicity and then struggle to hire the right talent in a single city are paying a higher long-term cost than the governance overhead they avoided. 

The principle that guides sound location selection is this: the right location is not the most obvious location, but the location where the specific talent the center needs can be found at depth, hired at sustainable cost, and retained at acceptable attrition rates over a three-to-five year horizon. This requires analysis that goes beyond city-level aggregate data to role-level talent mapping, ideally conducted with recruitment partners who have active pipelines in the candidate locations. 

Of all the decisions made during the Build phase, entity structuring receives the least client attention and carries the most underappreciated long-term consequence. Most organizations approach entity structuring as a legal logistics question: which structure allows us to begin operations most quickly? The BOT partner, experienced in local entity formation, recommends a structure and the client accepts it. The conversation that rarely happens is the one that should happen first: which structure produces the cleanest and least costly Transfer, and which structures create Transfer complications that will take months and significant legal cost to resolve? 

In India, the most common structures used in BOT engagements and their Transfer implications are materially different. A wholly owned Private Limited Company registered in the client’s name, or in a holding structure that will transfer to the client, creates the cleanest Transfer path: shares are transferred, or the entity is restructured, under a well-established legal framework. The entity, its contracts, its employees, and its compliance history all transfer together. Using the BOT partner’s existing entity as employer of record is faster to establish and avoids the regulatory timeline of new entity registration, but it creates a Transfer that requires creating a new client entity, novating all employment contracts, and separating years of compliance history, all of which takes time and introduces transitional risk. 

Intellectual property ownership in a BOT context is determined not by what the contract says at Transfer but by what the contract says at Build. IP created during the Operate phase, including code, proprietary processes, data models, and documentation, belongs to whoever the contract designates as its owner at the moment of creation. Well-drafted contracts vest IP ownership continuously and immediately in the client, regardless of which legal entity employs the developers at the time. Poorly drafted contracts, or contracts that address IP ownership only in the Transfer provisions, create the possibility of ownership ambiguity over IP created during the Operate phase. 

The practical consequence of Build phase IP ownership ambiguity can be significant. A technology company that spent three years developing a proprietary recommendation engine during its GCC’s Operate phase discovered at Transfer that the BOT partner’s contract language vested code ownership in the employing entity rather than the client, requiring a multi-month legal resolution process and a material revision of the Transfer timeline. The resolution was eventually straightforward but could have been avoided entirely with contract language drafted correctly during Build. 

IP ownership provisions written during Build should address four things clearly: that all IP created by employees of the BOT center vests immediately and continuously in the client; that this applies regardless of whether the IP is created using client tools, partner tools, or open-source infrastructure; that the partner has no residual license to use client IP post-Transfer; and that the partner is required to maintain an IP registry documenting all significant IP created during the Operate phase, updated at agreed intervals. Organizations that negotiate these provisions during Transfer are at a significant disadvantage; the leverage to obtain strong IP protection sits in the Build phase negotiation, before the engagement has begun and the client’s dependency on the partner is lowest. 

Everest Group research on GCC execution identifies the founding leader hire as consistently among the top factors determining whether a GCC reaches its potential. The founding leader, typically the first senior hire designated to run the GCC on behalf of the client, occupies a role that is structurally unlike any other in the organization. They must simultaneously navigate the local talent market, represent the client’s culture to a team that has never interacted with the client organization, manage the relationship with the BOT partner, translate the client’s strategic direction into local operational reality, and establish the center’s institutional identity before the center has any institutional history. 

This is a rare profile. The Everest Group’s operational research notes that enterprises consistently underestimate how long it takes to find the right founding leader, because they apply the same search criteria and timeline expectations they would use for a senior hire in their home market. In the GCC context, the search must identify someone who possesses operational credibility in the local talent market, genuine understanding of the client’s industry and technical domain, cultural empathy with both the local team and the parent organization, and the entrepreneurial disposition required to build an organization from scratch in parallel with delivering live commitments. The combination is rare, and the search typically takes two to three times longer than the client’s initial timeline assumes. 

Organizations sometimes make the mistake of thinking the founding leader’s primary job is to manage the team. During the Build phase, managing the team is the smallest part of the role. The founding leader’s primary job is to exist in the local market with enough credibility and visibility that talented professionals become aware of the center and consider it a serious career option. In markets like Bengaluru and Hyderabad, where engineering talent has dozens of GCC options, a center led by a founding leader with a strong local market reputation attracts inbound interest from candidates who would otherwise never apply. A center led by a less visible leader depends entirely on active sourcing, which is slower and more expensive. 

The founding leader is also the primary interpreter of the client’s culture to the local team. This interpretation happens continuously, in the smallest decisions: how feedback is given, how disagreement is handled, how ambiguity in the client’s direction is resolved, how success is celebrated, and how failure is processed. Organizations that invest significant effort in articulating their culture to their founding GCC leader before the Build phase begins, including structured immersion time with parent organization teams, consistently report better cultural alignment in the transferred center than those that assume culture will emerge naturally from working relationships. 

One more function of the founding leader that receives insufficient attention during Build: they set the bar for the center’s subsequent hiring quality. A founding leader with high standards, clear technical credibility, and a reputation in the local market for building strong teams will attract candidates who want to work for such a leader. A founding leader who is perceived locally as a project manager rather than a domain expert will attract candidates who are comfortable in execution-focused environments. Both teams will perform adequately in the early Operate phase. They will produce very different results by the time Transfer occurs. 

Role architecture is the set of decisions governing who is hired during the Build phase: which functions, at what seniority levels, with what specialization profile, and in what sequence. Most organizations approach these decisions primarily through a cost lens: what roles can be hired in this market at what salary, and how does that compare to the cost of the same roles in our home market? This is a legitimate analysis, but it is incomplete, because it does not ask the more important question: what does the center need to look like at Transfer, and does the Build phase talent strategy create a credible path to that state? 

The capability ceiling problem arises when Build phase hiring is calibrated to minimum viable delivery rather than to the capability profile required at Transfer. A center built primarily with junior-to-mid-level execution talent, rationalized as appropriate for the current scope of work, creates an Operate phase that must simultaneously deliver on live commitments and upgrade its talent base toward the more senior, more strategic profile required for Transfer. Executing this upgrade without disrupting delivery is harder than it sounds. It requires managing out people who were hired appropriately for Build but are not appropriate for Transfer, recruiting into a center whose talent market reputation is calibrated to its founding cohort, and maintaining delivery continuity through the disruption of senior talent turnover. 

The organizations that avoid this problem share a common discipline during Build: they design their role architecture backward from Transfer rather than forward from immediate delivery need. They ask what the center needs to be doing, and who it needs to employ, in the final quarter of the Operate phase, and they build a hiring plan that creates a credible talent trajectory toward that state. This does not mean hiring expensive senior talent before the work exists to engage them productively. It means ensuring that the earliest hires have the personal growth trajectory to be the senior team in three years, and that the hiring bar is set accordingly from the first day of Build. 

The hiring bar established during Build is difficult to raise during Operate without significant disruption. This is one of the most consistent findings across practitioner accounts of BOT engagements. The mechanism is straightforward: candidates evaluate a role partly by the quality of the team they will be joining. If a center’s early hires are perceived in the local talent market as competent but not exceptional, subsequent candidates of exceptional calibre have less motivation to join a team they perceive as below their professional peer group. The hiring bar thus creates its own gravitational field. 

Plugscale’s GCC practice documentation articulates this as the founding cohort effect: the first thirty to fifty employees of a GCC establish its market identity as an employer, and that identity persists for years because the local talent market has long institutional memory. Centres that set a high bar from Day 1 of Build, investing additional time and recruitment effort to attract professionals who are slightly above the minimum required capability level, tend to find that subsequent hiring gets easier as the centre’s reputation accumulates. Centres that optimize for speed of hire in the Build phase tend to find subsequent hiring harder as their reputation consolidates around their early hires. 

A US-headquartered enterprise storage company with no prior India presence engaged a BOT partner to establish a Global Capability Center targeting a talent profile, distributed systems engineers, firmware specialists, and cloud infrastructure professionals, that is genuinely scarce in any single Indian city. The engagement, documented in the Plugscale case study, is instructive because the Build phase began with an honest acknowledgment of the location question rather than a presumptive answer. 

The partner’s location analysis mapped role-by-role talent availability across Bengaluru, Hyderabad, Pune, and Chennai, finding that the specific combination of storage engineering disciplines required was most efficiently sourced across two cities rather than concentrated in one. The resulting dual-hub model, with primary engineering in Bengaluru and QA and support operations in Chennai, added Build phase governance complexity but produced a talent acquisition outcome, thirty or more engineers onboarded within ninety days without quality compromise, that a single-city approach would have struggled to match. The hiring bar discipline established during Build was explicit: role scorecards mapped to real-world storage engineering competencies were developed in collaboration with the client’s senior engineers before a single offer was extended. 

The founding leader hire was given the same diligence as any partner selection decision. The BOT partner presented three candidates; the client’s engineering leadership participated in final evaluations. The selected candidate had deep local market credibility in the storage engineering ecosystem, which materially accelerated the center’s employer brand establishment in a competitive talent market. By the time the Operate phase began, the center had a visible identity in the local engineering community rather than the anonymity that characterizes most new GCC builds in their first months. 

A European financial services firm entering the Philippine market through a BOT engagement made what its legal counsel later described as a recoverable but costly Build phase decision: it chose the partner’s existing Philippine entity as the employer of record for the first eighteen months of operations, prioritizing speed of setup over Transfer path clarity. The initial operations launched in approximately six weeks, a genuine speed advantage over the ten to twelve week timeline for new entity registration. 

The cost of this decision became apparent at month fourteen, when the client began planning the Transfer. The Philippine entity owned by the BOT partner held employment contracts for forty-seven professionals, vendor agreements with local IT infrastructure providers, office lease agreements, and a two-year compliance history with the Bureau of Internal Revenue and the Social Security System. Transferring these relationships to a new client-owned Philippine entity required twelve months of parallel operations, significant legal costs across two jurisdictions, and a period of employment contract uncertainty that elevated attrition risk among the center’s most senior staff. Three senior professionals resigned during the transition period, citing uncertainty about their employment terms in the new entity structure. 

The total cost of the entity restructuring, measured in legal fees, additional operational time, and the cost of replacing the professionals who resigned, substantially exceeded the cost of registering the client’s own entity during the Build phase. The engagement is referenced in practitioner circles as an illustration of a principle that belongs in every BOT orientation: the six-week setup advantage of using a partner’s existing entity is typically consumed within the first quarter of Transfer preparation. 

A US software company establishing its first European engineering center in Warsaw through a BOT engagement made a Build phase decision that its engineering leadership later credited as the single most important factor in the center’s success: it set a hiring bar deliberately above what the immediate delivery scope required, and it held that bar even when the Build phase timeline came under pressure. 

The founding leader, a Warsaw-based engineering executive with fifteen years of experience in the Polish technology sector and a visible profile in the local engineering community, had a clear mandate: the center should be known from its first month as a place where exceptional engineers would want to work. This mandate translated into a Build phase hiring process that was slower than the partner’s typical timeline because the client’s founding leader personally conducted final technical evaluations for the first twenty hires and returned four candidates to the partner for replacement despite their technical adequacy, on grounds of insufficient intellectual ambition. The center launched three weeks behind its original Build schedule. 

Within twelve months of the Operate phase, the Warsaw center had developed an employer brand strong enough to generate meaningful inbound interest from senior engineers at established local technology employers. The attrition rate in the first three years of operations was well below the Warsaw technology sector average. By the Transfer phase, the center’s talent base was materially more senior and capable than the client’s original scope had required, enabling scope expansion without additional hiring. The three-week Build delay proved to be the cheapest investment the engagement made. 

The BOT model’s value proposition rests on the Transfer: the client inheriting a mature, capable, transfer-ready organization at the end of the engagement. That inheritance is earned backward, beginning in the Build phase, where the decisions that determine whether it is possible are made. Organizations that understand this design their Build phase accordingly. Those that do not discover the dependency during Transfer, when the cost of correcting it is at its highest.