Skip to content
All Posts
Engineering Culture

Managing Distributed Teams Across Time Zones

6 December 20242 min read

I manage teams across Indian and US time zones. On a good day, we have a four-hour overlap window. On a bad day — when someone in the US takes a morning meeting and someone in India leaves early — we have two hours.

Every coordination pattern I use is designed around this constraint.

The Overlap Window Is Sacred

Nothing optional goes into the overlap window. No status updates that could be async. No presentations that could be recorded. The overlap hours are exclusively for decisions that require real-time conversation — design reviews, incident triage, sprint planning, and problem-solving sessions.

Everything else happens asynchronously. Status updates go in Slack threads. Documents get commented on in Confluence. Code reviews happen in GitHub with written feedback.

Async-First Documentation

The biggest failure mode in distributed teams is knowledge that lives only in someone's head. If the offshore team cannot unblock themselves because they need to ask a question and the onshore team is asleep, you have a documentation failure.

I enforce a rule: any decision made in a meeting gets documented within one hour. Any blocking question gets posted in the team channel, not sent as a direct message. Direct messages are where information goes to die.

Handoff Rituals

At the end of each team's day, they post a brief update in a dedicated Slack channel. Three things: what they accomplished, what is blocked, and what the other team should pick up. It takes two minutes to write and saves hours of context-switching the next morning.

The Human Element

Distributed teams need to see each other as people, not just names on a screen. I schedule a monthly informal call — no agenda, no status updates, just conversation. It sounds trivial, but the teams that do this collaborate noticeably better than the ones that only interact through tickets and pull requests.

Time zone differences are a constraint, not an excuse. The teams that accept the constraint and design around it outperform the ones that pretend it does not exist.


Back to all posts