US Founder's Guide to India #4: Culture, Communication and the Midnight Call Problem
Episode 4 of a weekly series for US founders building a Global Capability Centre in India. One practical insight per week. No fluff.
It usually starts around Month 4
Everything looks fine on the weekly call.
Your India team is onboarded. Work is flowing. Status updates are positive. You're feeling good about the decision.
Then something doesn't ship. Or ships wrong. Or you find out three weeks later that there was a blocker the team knew about in Week 1 but never mentioned.
You schedule a call. At 8pm your time — which is 6:30am in Bengaluru.
Everyone apologises. Everyone explains. You hang up more confused than angry, because the problem wasn't capability. It wasn't effort. It was that nobody told you there was a problem until it was too late to fix it cleanly.
This is the midnight call problem. I've seen it happen with almost every US founder who builds a team in India without understanding one fundamental thing about how Indian professional culture works.
"Yes" is not an agreement. It's an acknowledgement.
When your India team says yes on a call, they are almost always telling you they heard you. Not that it's done. Not that it's possible. Not that they agree with the approach.
This isn't deception. It isn't a competence issue. It's a deeply ingrained cultural norm rooted in hierarchy.
In most Indian professional environments, pushing back on a senior — and as a US founder you are the most senior person in the room by default — carries real social risk. The safer path is to absorb the request, attempt it, and hope it works out. If it doesn't, the instinct is to keep trying rather than escalate early.
The result is that problems compound in silence. A small blocker in Week 1 becomes a missed deadline in Week 4. By the time you find out, the cost of fixing it has multiplied.
I've watched this dynamic play out at companies with genuinely talented India teams — teams that were perfectly capable of delivering, but were operating in a communication environment where flagging a problem felt riskier than hiding it.
More calls won't fix this
The instinctive response most US founders have is to add more touchpoints. Daily standups. End-of-day written updates. More Slack messages. More visibility.
This treats the symptom, not the root cause.
More calls just create more opportunities to say yes. They don't change the underlying dynamic — which is that your India team doesn't yet feel safe enough to tell you something isn't going to work.
Psychological safety isn't created by a policy or a process. It's built interaction by interaction, over time, based on how you respond when someone does raise a problem early.
The first time someone flags a blocker in Week 1 instead of Week 4 — how you respond in that moment sets the norm for everything that follows. If your response is frustration, the team learns that early escalation leads to a bad outcome. If your response is genuine appreciation, the team learns that it's safe to speak up.
That sounds obvious. Most founders agree with it in theory. Far fewer practice it consistently, especially under delivery pressure.
Three things that actually work
1. Reward the flag, not just the fix.** Make it visible when someone raises a problem early. Call it out in your all-hands. Thank them publicly. When the team sees that early escalation is celebrated rather than punished, the norm shifts over time.
2. Move status out of people's discretion and into systems.When updates live in a project tracker, a shared dashboard, or a structured weekly template, blockers surface automatically. The team member doesn't have to choose to tell you — the system surfaces it. This removes the interpersonal risk entirely.
3 Ask the question directly. At the end of every weekly call, ask: "Is there anything that might not land on time that we haven't talked about yet?" It sounds simple. It gives people explicit permission to raise concerns without it feeling like a personal admission of failure.
None of these are silver bullets. But used consistently over 60 to 90 days, they genuinely shift the communication culture of a team.
This is exactly what your Site Leader is for
This is why Episode 3 of this series was about the Site Leader hire — and why I said it's the most important decision you'll make in India.
A great Site Leader is not a project manager. Their most important function is to be the bridge between how your organisation expects to communicate and how your India team naturally communicates.
They translate your instructions into context the India team can act on. They surface the things the team tells them but won't put in writing. They tell you — diplomatically but directly — when you're managing the team in a way that's landing badly.
That last one requires real trust on both sides. Build it early. It will save you from more midnight calls than any process change ever will.
One thing to do this week
If your India team is already running, ask your Site Leader this question:
"Is there anything the team is worried about that hasn't come up on our calls?"
The answer — and the ease or hesitation with which they answer — will tell you more about the health of your communication culture than any status report.
Next week — Episode 5
What does Year 1 actually cost? Most US founders budget wrong — in both directions. I'll share the real numbers and where the surprises tend to show up.
Follow to get each episode as it publishes. If you found this useful, share it with a US founder who is thinking about India — this conversation happens too late more often than not.