I've managed distributed engineering teams across India, the US, the UK, and Australia for over a decade. Fifty-plus remote projects, teams from 3 to 35 engineers, time zone gaps as wide as 13 hours. Here's what I've learned about making it work — not the theory, but the practices that survived contact with reality.

The fundamental insight: async is the default, sync is the exception

Most teams try to replicate co-located rituals over Zoom. Daily standups at a time that's painful for at least one time zone. Sprint reviews where half the team is barely awake. Retrospectives that run long because the connection keeps dropping.

The teams that work best flip the model: everything is async by default, and synchronous time is reserved for the 20% of communication that genuinely requires real-time interaction.

What needs real-time: architectural decisions with trade-offs, conflict resolution, sprint planning (the negotiation part), and onboarding new team members. Everything else — status updates, code reviews, design feedback, bug reports — works better async because it gives people time to think before responding.

The three practices that actually matter

1. Written standups, daily

Every engineer posts three things in Slack before their day starts: what they shipped yesterday, what they're working on today, and what's blocking them. No calls. The update stays in a channel where anyone can read it in their own time zone.

This works better than synchronous standups for distributed teams because: the Bangalore engineer isn't mumbling through a 7 AM call, the US engineer isn't staying late for a 6 PM sync, and — crucially — the written record means blockers get addressed by whoever sees them first, regardless of time zone.

The key is discipline: it has to happen every day, and managers have to actually read and act on blockers within 4 hours. If blockers sit for a day, the team stops trusting the system.

2. Overlap windows, not overlap hours

With a 10+ hour time zone gap, you can't have a full overlapping workday. Don't try. Instead, identify a 2-3 hour overlap window and protect it fiercely: no deep work, no solo coding — this is the window for all synchronous communication.

For India-US teams, I typically use 9:00-11:30 AM IST / 8:30-11:00 PM PT (or the morning US equivalent depending on coast). That window handles sprint planning, architectural discussions, and any real-time problem-solving. Everything outside that window is async.

The mistake I see: teams schedule meetings randomly throughout the day, forcing engineers on both sides to fragment their schedules. Concentrate all sync in one window and let engineers have uninterrupted blocks the rest of the day.

3. Documentation as a first-class deliverable

In a co-located team, you can tap someone on the shoulder and ask "why did we build it this way?" In a distributed team, if the answer isn't written down, it doesn't exist — because the person who knows is asleep.

Every PR needs a description that a reviewer in another time zone can understand without context. Every architectural decision gets a one-page ADR (Architecture Decision Record): what we decided, why, what alternatives we considered. Every sprint has written goals and acceptance criteria, not just Jira ticket titles.

This feels like overhead until you realize it eliminates the "I'll just ask them tomorrow" delays that silently add 24-48 hours to every handoff.

What to skip

Skip: synchronous daily standups. Written async standups work better for distributed teams. I've tested both across dozens of projects. The async version consistently surfaces blockers faster because there's no "I'll mention it at standup" delay.

Skip: mandatory cameras-on for every call. Camera fatigue is real, and forcing it breeds resentment. Cameras on for sprint planning and retros (where reading the room matters). Cameras optional for everything else.

Skip: trying to create "virtual water cooler" moments. Forced fun over Zoom is painful for everyone. What actually builds distributed team culture is: public recognition of good work in Slack, pair programming sessions (voluntary, focused on learning), and meeting in person once or twice a year if budget allows.

The tooling that matters

After years of experimenting: Slack for async communication (channels, not DMs — searchable context matters). Linear or Jira for work tracking (I prefer Linear for speed, Jira for enterprises that need the audit trail). Loom for async video updates when text isn't enough. Notion or Confluence for documentation. GitHub with required PR reviews and CI checks as quality gates.

The tool matters less than the discipline. I've seen teams succeed with basic tools and fail with expensive ones. The difference is always process consistency, not software.

Measuring what matters

The metrics I track for distributed team health:

Notice what's not on the list: hours logged, lines of code, or "time in meetings." Those metrics optimize for presence, not outcomes. Distributed teams succeed when you measure output and remove friction, not when you surveillance attendance.