Last Tuesday at 9:47 PM, I was on a call with our engineering lead in Bangalore while eating dinner (cold, because I’d forgotten about it for 20 minutes). My wife walked past and said, "You know it’s almost 10, right?" I did. This was the third call of my second shift that day.
I’ve been running teams across India and the US for years at Spektra Systems. Engineering and support in Bangalore, sales and partnerships around Seattle. The time difference is 12.5 hours. Not 12, not 13. That half hour is a special kind of annoying because it breaks every mental shortcut you develop for converting times.
People write about remote work like it’s a solved problem. It’s not. Distributed teams across a near-opposite time zone is a different animal from "some of us work from home." Here’s what’s actually worked for us, and what hasn’t.
The 2-Hour Window That Runs Everything
Bangalore is 12.5 hours ahead of Pacific Time. When you map out the working hours, there’s barely any natural overlap. We carved out a window: roughly 8:30 to 10:30 AM Pacific, which is 9 to 11 PM IST. Two hours. That’s it.
Those two hours are sacred. No one-on-ones. No internal reviews. No "quick syncs" about stuff that could be a Slack message. The window is only for cross-team decisions that genuinely need real-time conversation.
We learned this the hard way. Early on, we packed that window with every meeting we could think of. Stand-ups, sprint planning, demos, retrospectives. By the end of it, the India team was exhausted (it’s 11 PM for them, remember) and nobody had actually made any decisions because we’d crammed too much in. Now we cap it at three recurring meetings per week. Everything else has to earn its spot.
Async Done Right (and How We Did It Wrong First)
When you only have two hours of overlap, async communication isn’t optional. But "go async" is easy to say and hard to do well. We did it badly for about a year.
The failure looked like this: someone in Seattle posts a question on Slack at 2 PM Pacific. The Bangalore team sees it at 9 AM their time (they were asleep). They respond at 9:30 AM IST, which is 9 PM Pacific the previous night. Seattle sees the response the next morning. One question, two days. Multiply that by twenty questions a day and you’re moving at half speed.
What fixed it was banning bare questions. No more "Hey, what’s the status of the API fix?" Instead: "The API fix for the billing module (JIRA-2847), I need to know if it’s going into this week’s release so I can update the customer. If it’s not ready, I’ll push the demo to next Tuesday. Can you confirm by your EOD?"
One round-trip instead of four. We made this a rule and it genuinely changed our velocity.
One more thing: decisions go in Google Docs, not Slack threads. If a decision lives in Slack, it’s gone. Nobody will find it in three months.
Handoffs and Documentation
When your Seattle team finishes at 5 PM Pacific, there’s a 3.5-hour gap before Bangalore wakes up. Work doesn’t stop during those gaps. Customer issues come in. Things break.
We built a "handoff doc" for each team, a running document where the outgoing team writes what happened, what’s blocked, and what’s on fire. The incoming team reads it first thing. Takes five minutes to write, saves an hour of "wait what happened while I was asleep?"
For critical coverage, we stagger one person on each side. An engineer in Bangalore starts late (noon IST) to overlap with Seattle’s morning. One person in Seattle starts at 6 AM Pacific to catch Bangalore’s evening. We rotate quarterly so nobody burns out.
Getting engineers to document things was the hardest culture change. What finally worked was tying it to our definition of done. A feature isn’t done until the doc is updated. A bug fix isn’t done until the runbook reflects the new behavior. I tracked it over a month: 23 incidents where someone needed info from the other time zone. In 17 cases, documentation answered the question. Before we enforced this? Almost every incident meant waiting.
Hiring for Distributed Work
Not everyone thrives in this setup. We hired a fantastic engineer once who lasted four months. Great technically, but she hated async communication. She wanted to brainstorm on a whiteboard, get immediate feedback. Totally reasonable. But in a 12.5-hour split, you can’t have that. She left for a Bangalore startup and I think she’s happier.
Now we screen for it. In interviews, we ask: "How would you handle getting stuck at 3 PM when the person who could help won’t be online for 8 hours?" People who say "I’d document what I’ve tried, outline where I’m stuck, and move to a different task" tend to do well. People who say "I’d Slack them and wait" tend to struggle.
I’d take a good engineer who writes clearly over a great engineer who can’t explain their work in text. Controversial take, but I’ve seen the second type create bottlenecks repeatedly.
Cultural Gaps Nobody Warns You About
I’m Indian, I’ve worked in both countries, and I still get caught off guard.
The biggest one: disagreement styles. In many Indian workplace cultures, directly disagreeing with a manager is uncomfortable. People will say "that should be possible" when they mean "that’s going to be really hard and might not work." In the US, someone’s more likely to just say "that won’t work."
I’ve had situations where I asked the Bangalore team if a deadline was realistic and got a "we’ll try our best." In my head, that meant yes. What it actually meant was "no, but we don’t want to disappoint you." We missed the deadline. My fault, not theirs. I should have asked differently.
We now have a shared vocabulary for commitments. "Committed" means it’s happening. "Stretch" means possible but risky. "Not feasible" means no. Simple, but it took us a while to get there.
What I Still Haven’t Figured Out
Team bonding across time zones is tough. Virtual social events feel forced when the Bangalore team is logging in at 10 PM for a "fun" activity. That’s not fun. Separate social activities in each location help, but it creates two cultures instead of one. I’m still working on this.
And some weeks, it’s just exhausting. Context-switching between two teams at different points in their day, different energy levels, different problems. The Bangalore team wrapping up and tired. Seattle just getting started with new ideas. Matching those rhythms is a daily act of translation.
But I wouldn’t change it. The setup gives Spektra access to incredible engineering talent in Bangalore and proximity to our biggest customers in the US. The follow-the-sun support coverage (which happened almost accidentally) is something our customers love. And the discipline that distributed work forces on you makes the whole company better organized than it would be if everyone sat in one office.
It’s hard. But hard doesn’t mean bad. If you’re running a similar setup, drop a comment or reach out. I don’t have all the answers, but I’ve got a decent collection of mistakes you can learn from.
Happy building, folks.
Amit
Assisted by AI during writing
