The first 90 days of a Global Capability Center in India get spent on the wrong scoreboard. Headcount. Office photos. Slack channels. A kickoff deck that says “India is live.”
None of that is a GCC yet.
I lead an India technology organization from Bangalore. Our GCC is completely remote. The first 90 days that worked were not the ones where we hired the most people. They were the ones where we hired a founding spine, made HQ rhythm boring and predictable, and shipped one shared win.
If you want the full stand-up sequence, read How to Set Up a GCC in India. For what breaks after the honeymoon, read Challenges of Setting Up a GCC in India. For how I lead India technology and AI/SaaS delivery day to day, see the India GCC case study.
What “good” looks like on day 90
I use one test: could this team keep shipping if HQ went quiet for two weeks?
If the answer is no, you still have a staffing ramp. You do not have a capability center.
By day 90 I want these to be true:
- India has a named lead with real authority, not a coordinator title
- A senior technical spine can set the bar without waiting on HQ for every design
- Priorities, escalation, and definition of done are written down
- Access, devices, repos, and security defaults are live
- HQ and India share a demo cadence and a small set of overlap hours
- One outcome both sides care about has actually shipped
Headcount is a trailing indicator. Ownership is the leading one.
What I refuse to optimize for in 90 days
Seat count. Ten juniors before two seniors who can coach is a retention problem, not a win. Remote makes that mistake louder.
Office theater. A lease does not create ownership. Our GCC is fully remote. The workplace model is a decision. It is not the strategy.
Ticket throughput. If the first 90 days are only “keep the HQ queue moving,” you have already started a body shop. Seniors will notice.
Utilization dashboards. Busy is not the same as useful. I would rather see one owned module than a green burn-down chart.
Days 1 to 15: write the contract before the offers
Most 90-day failures start before the first hire. HQ is still vague about what India will own, but recruiting is already live.
Before I push offers, I want five things in writing:
Mandate. One sentence: in 24 months, India will own ___. If nobody can finish that sentence, hiring will feel random.
Sponsor. A person at HQ with authority, not a Slack channel. Named counterpart in India. When something stalls, you need names, not “the leadership team.”
Workplace model. Remote, hybrid, or office. Say it out loud. For remote, agree overlap hours and the security baseline in week one.
Scoreboard. Capability and outcomes, not only cost per engineer. Cost still matters. Utilization as the only story will not keep seniors.
How we decide. Who owns architecture calls, how priorities change, what “done” means. Without this, India becomes the shock absorber for thrash.
Entity, payroll, contracts, and IP belong here too. Work them with legal and finance. Important, and not the strategy by itself. I’m not giving legal advice; get proper counsel.
Days 1 to 45: hire the founding spine
This is the actual 90-day work.
Hire the India lead first, or in parallel with the first senior engineers. Do not hire a large IC wave and “add leadership later.” Later never arrives cleanly.
Then hire a senior technical spine: people who can own a system, review design, talk to HQ without translating every sentence, and set the quality bar. Full-stack, cloud, and AI talent in Bangalore has options. They join for what they will own, not for a GCC label on a job post.
What I look for in those first interviews:
- Have they owned a module end to end, not only closed tickets
- Can they write a short design note that survives a time zone
- Do they push back when the brief is vague
- Will they coach, or only optimize their own output
What I skip early:
- A wide junior ramp with no mentors
- Keyword bingo that ignores ownership
- Product or design hires before India has a real roadmap slice to own
- Managers who only route work
Be honest in the offer conversation. If year one is “help stand this up,” say that. If HQ has not yet given India a mandate, do not sell autonomy you cannot defend. Strong people will leave when the work does not match the pitch. That is one of the challenges that actually break a GCC.
How many people by day 90? Fewer than most decks assume. A lead plus a handful of seniors who can ship is a real start. A twenty-person chart with no spine is noise.
Days 1 to 30: make security and tooling boring
In a fully remote GCC there is no office perimeter to hide behind. Week one is when access, devices, repo hygiene, and least-privilege defaults have to become normal.
What I get live early:
- Identity, access, and offboarding that actually works
- Device and data-handling norms people can follow from home
- Repos, CI/CD, docs, and one place for priorities
- No shared accounts “until we have time”
If security arrives at day 80 as an audit, it freezes delivery. Bake it into onboarding so compliance enables work instead of opposing it.
Days 15 to 60: install HQ rhythm, not more meetings
Silence gets misread. HQ reads quiet as risk. India reads quiet as “they already decided.” The first 90 days are when you either install a rhythm or install meeting theater.
What I do:
- Protect a small set of overlap hours. Do not pretend a 12.5 hour gap is a process.
- Write priorities. If it isn’t written, it isn’t real.
- Short design notes so context survives the time zone
- Demos over status-only calls
- Named people on both sides for escalation
Remote does not forgive a vague operating model. You cannot fix that with more Zoom.
The goal is not “India is always available.” The goal is that both sides can predict how work moves when someone is asleep.
Days 30 to 90: ship one shared win
Credibility compounds. Headcount does not.
Pick something HQ and India both care about. Small enough to finish. Visible enough that people stop asking “is India working?” Ship it. Demo it. Write down what you learned.
That first win is not a vanity launch. It is the proof that ownership, not only capacity, exists.
For a public example of AI delivery work from our side, see the AWS Machine Learning write-up on AI-generated trip reports. You do not need a flagship AI launch in 90 days. You need one outcome that makes the operating model believable.
Protect design and review time while you ship. If the first win is only “we burned down the HQ backlog,” you trained the org to treat India as a queue.
Remote-specific habits I install in 90 days
Because we are fully remote, I treat these as first-90-day defaults, not year-two polish.
Written over hallway. Decisions live in docs, not in a call nobody recorded.
Demos over presence. I do not score people on webcam time. I score owned outcomes.
Managers who can lead async. A manager who only assigns tickets will fail faster remote than in an office.
Visible underperformance. Without demos and module reviews, weak execution hides until a release slips. Review outcomes early, while the team is still small.
Security without an office. Home setups are the workplace. Hygiene is not optional.
Fully remote can work from day one. I run it. It demands sharper habits than colocation. If your HQ culture only works when everyone sits in one room, start hybrid, then move remote when the written rhythm is real. Do not use remote as a cost hack.
Day 90 scoreboard
I would rather show HQ this than a headcount slide:
- Mandate still true, or updated in writing
- India lead and senior spine in place and delivering
- Access, security, and delivery tooling live
- Overlap hours and demo cadence actually happening
- One shared win shipped
- At least one owned slice on the roadmap, even if it is small
- Hiring bar documented so the next wave does not dilute it
- A clear no-list: what we will not hire or take on until coaching bandwidth exists
If items 1, 2, and 5 are missing, do not scale. Fix the spine.
What I start only after day 90
- A junior-heavy hiring wave
- A second location or a vendor layer “to go faster”
- Broad product/design hiring before India owns roadmap slices
- Reorgs to look like a bigger GCC
- New workstreams that have no named owner in India
Scale is a year-one to year-two problem. The first 90 days are for making the center real.
What I’d tell someone starting Monday
- Write the 24-month mandate before the recruiting brief
- Name the HQ sponsor and the India lead
- Hire seniors first
- Make security and access week-one defaults
- Install written priorities, overlap, and demos
- Ship one shared win
- If remote, invest in async discipline. Office habits will not translate by accident.
- Ignore headcount theater. A small spine that owns work beats a large queue that does not.
FAQ
What should you do in the first 90 days of a GCC in India?
Hire the India lead and senior spine, get access and security live, write how you work with HQ, and ship one shared win. Do not maximize headcount.
Who should you hire first for an India GCC?
The India lead and a senior technical spine. Managers and juniors come after people exist who can set the bar and coach.
How many people should a GCC have after 90 days?
As few as can own and ship. A lead plus a handful of seniors is a real start. A large junior ramp before mentors exist is a retention risk, especially remote.
Can you start a GCC in India fully remote from day one?
Yes. Mine is completely remote. Remote is the workplace. Mandate, seniors, security, and HQ rhythm still have to be in place. Remote does not replace an operating model.
What is a founding spine in a GCC?
The first senior people who can own systems, review design, work with HQ, and set quality. Without them, you have capacity. You do not have a capability center.
Should you hire juniors in the first 90 days of a GCC?
Usually no, or only one or two next to mentors who have bandwidth. A junior-heavy first wave creates noise and leaves seniors stuck in onboarding.
What does a successful first 90 days look like?
Named ownership, a senior spine, boring security and tooling, a working HQ cadence, and one shipped outcome both sides care about.
How should HQ work with India in the first 90 days?
Named counterparts, protected overlap hours, written priorities, short design notes, and demos. More meetings without clarity make trust worse.
Is the first 90 days too early to give India owned work?
No. Start with a small owned slice. If India only executes HQ tickets from week one, ticket-factory culture is already forming.
When should you start scaling hiring after stand-up?
After the spine is delivering, onboarding includes product context, and managers can coach. If quality is already slipping, slow down.
Closing
The first 90 days of an India GCC are not a hiring race. They are a test of mandate, leadership, and whether India will own outcomes or only absorb tickets.
A fully remote GCC can start on day one. I live that model. Get the spine, the rhythm, and one shared win right, and year one has a chance. Get only the org chart right, and you will spend the next year fixing what actually breaks.
For the full stand-up sequence, read How to Set Up a GCC in India. If you want a free weekend conversation about Indian culture and scaling with it, see how I help or get in touch.