A GCC charter sounds simple. Write the mission, add the headcount, define the functions, name the leader, get HQ to approve it, then start hiring.
The problem is that most charters describe an organisation that only exists in PowerPoint. They sound strategic but go quiet the moment the first 20 employees join and real questions arrive. Who can hire? Who approves architecture? Who owns the roadmap? Who controls the budget? What happens when India and HQ disagree? What does India actually own, and what happens when the original scope shifts? A useful charter has to survive those questions. SquadXP's GCC content frames the India center around a clear mandate, leadership, capability, and eventual ownership rather than an offshore hiring program, and this guide shows how to write a charter that can genuinely run an organisation.
What a GCC charter is
A charter defines the purpose, scope, ownership, governance, responsibilities, and success measures of a Global Capability Center. Think of it as the GCC's operating contract with the parent. A good one answers why the GCC exists, what it owns, what it doesn't own, who leads it, who decides, what capabilities it will build, how it works with HQ, how success is measured, and how it will evolve. It should be detailed enough to remove ambiguity but flexible enough to survive changing conditions.
The ten sections every charter needs
One, the executive mandate. A single paragraph answering why the GCC exists. Weak: "the India GCC will support global technology teams." Strong: "the India GCC will build and own global platform engineering, starting with cloud infrastructure and developer productivity and expanding into AI-enabled engineering over three years." The second creates direction.
Two, strategic objectives. Three to five, not twenty. If everything is a priority, nothing is. Three, scope, an explicit in-scope list (backend, platform, cloud, DevOps, data, security engineering) and an out-of-scope list (global sales, corporate finance, brand, customer success), which prevents scope creep.
Four, ownership, its own section, specifying for each capability whether India owns, consults, executes, or governs, and the same for HQ. The exact split varies; the point is that it's explicit, drawing the execution-versus-ownership distinction from what a GCC actually owns. Five, decision rights, a matrix stating who decides local hiring, GCC structure, global product roadmap, technical architecture, major capital spend, senior leadership, and vendor selection, which eliminates recurring escalation.
Six, the leadership mandate. Don't write "GCC Head will manage India." Define what the leader owns, hiring, budget, culture, workforce planning, operations, stakeholder management, capability development, local execution, the builder role described in why your first hire is a site leader. Seven, the organisation roadmap, showing the org at year one, two, and three with how capabilities evolve, not just a headcount chart. Eight, governance, the meeting and decision rhythm (weekly delivery, monthly operating, quarterly strategy, semi-annual workforce, annual charter refresh), covered fully in the India-to-HQ governance model.
Nine, KPIs, a balanced scorecard across talent, engineering, business, and capability. Ten, an evolution mechanism, an explicit statement that the document will change, with a quarterly or annual review, because a charter that can't evolve becomes a constraint.
What not to put in it, and the one-page test
Don't turn the charter into a recruitment plan, a technology architecture document, a 50-page legal agreement, a job description, or a detailed project plan. It defines direction and accountability; supporting documents hold implementation detail. And apply the one-page test: if you can't summarise the mission, ownership, capabilities, leadership, decision rights, three-year roadmap, KPIs, and governance on one page, the organisation isn't aligned yet. If executives disagree with the one-page version, another 30 pages won't fix it.
The charter's real value is in disagreement
A strong charter answers hard questions in advance. What if HQ wants to hire five engineers directly? The ownership section decides. What if India wants to change architecture? The decision-rights matrix answers. What if the GCC needs another ₹2 crore, or wants to launch a new capability? Budget governance and the strategic review process answer. The charter's value isn't what it says when everyone agrees, it's what happens when they don't.
It also helps to keep documents separate: the business case answers whether to build the GCC, the charter answers what you're building and how it operates, the operating plan answers how you'll execute, and the workforce plan answers who you need and when. And it should address ownership explicitly, which product, platform, domain, KPI, customer, or business outcome, because if the charter can't name any of those, the GCC is still an execution organisation. Review it at least annually, and on triggers too: headcount doubling, a new country joining, product ownership changing, a new function moving to India, leadership changes, a new city, or major security shifts.
Conclusion
A GCC charter isn't a board presentation. It's an operating document for the people who have to make the GCC work. The strongest version tells everyone why the team exists, what it owns, what it doesn't, who decides, how it works with HQ, how success is measured, and how the organisation is expected to evolve. Write it before the GCC gets large enough to develop conflicting assumptions, because once 100 people have joined, fixing unclear ownership is far harder than defining it before the first hire.