Managing Globally Distributed Teams
Final Prep · People Management — how to run a team split across timezones so it moves as one, with async-first communication, local ownership, and no HQ-versus-satellite hierarchy.
This question tests whether you can lead a team you can’t gather in one room. Distributed teams fail in predictable ways: decisions made in a hallway that half the team never sees, a satellite site that gets the leftover work and no real ownership, meetings scheduled for HQ’s convenience at 11pm for everyone else, and knowledge trapped in people’s heads instead of documents. The interviewer wants the mechanisms that prevent all of that: async-first communication with written decisions of record, timezone-fair meeting practices, genuine local ownership of whole areas, a documentation and trust culture, follow-the-sun on-call, and a deliberate refusal to let an HQ/satellite hierarchy form. Answer in CARL shape.
What this question is really testing
Whether you default to async and written as the operating system of the team, and whether you understand the political trap of distributed work: the HQ/satellite hierarchy, where the site the manager sits in gets the interesting work, the real decisions, and the promotions, while remote sites get commodity tasks and quietly disengage. The senior signal is treating documentation as the substrate for trust (you trust output, not hours-at-desk seen), giving remote sites ownership of whole areas rather than slices, and actively distributing the inconvenience — of meeting times and of on-call — fairly.
How to answer- Default to async, write decisions down. Every meaningful decision lands in a written record — a doc, a task, a decision log — so no one is disadvantaged by which timezone they were awake in.
- Make meetings timezone-fair. Rotate the painful slots so the same site isn’t always taking the late call, keep synchronous time for what genuinely needs it, and always post notes and decisions afterward.
- Give each site ownership of whole areas. A remote site should own a system end-to-end — roadmap, design, on-call — not execute tasks handed down from HQ. Ownership is what creates engagement and growth.
- Build on documentation and trust. Measure output, not presence. Strong docs let people work independently across timezones and remove the temptation to equate visibility with value.
- Use follow-the-sun and refuse the hierarchy. Hand off on-call across regions so no one covers the night alone, and actively watch for and dismantle any HQ/satellite dynamic in how work, decisions, and credit are distributed.
- Async-first, written-decision instinct as the default, not the fallback.
- Timezone fairness treated as an equity issue you actively manage.
- Real ownership of whole areas at every site — no commodity-work satellites.
- Trust built on output and documentation, not on hours seen online.
- Explicit awareness of, and countermeasures for, the HQ/satellite trap.
A worked example (CARL)
Context. My Ads Events Infra team was split across two sites with roughly an eight-hour offset — the larger group where I sat, and a smaller group in another region. The pattern when I took over was the classic satellite failure: the remote site was doing execution work on tickets scoped by the main site, the real design decisions happened in synchronous conversations the remote engineers were asleep for, and their standups were scheduled at the tail of their day for our convenience. Predictably, the remote engineers were disengaged, their growth had stalled, and we’d lost one strong person who felt like a contractor rather than an owner. Meanwhile the whole team was slower than it should have been, because so much depended on a few hours of overlap.
Actions. I reset the operating model. First, I moved the team to async-first and made written decisions non-negotiable: any decision of consequence had to be captured in a doc or task with the reasoning, not settled verbally in an overlap-hours call. I started a lightweight decision log so the remote site woke up to what was decided and why, not just an outcome they had to reverse-engineer. Second, and most important, I gave the remote site ownership of a whole area — I moved the aggregation-freshness subsystem to them entirely, roadmap through on-call, and stopped scoping their work from my site. They now owned an end-to-end piece of the pipeline that mattered, with a named tech lead there who set its direction. Third, I fixed meeting fairness: I rotated the painful slot so my site took the awkward-hours meeting half the time, cut the number of standing synchronous meetings hard (replacing most with written updates), and made a rule that any decision reached in a meeting was re-posted in writing so the absent site could weigh in before it was final. Fourth, I built the trust substrate: we invested in real documentation — design docs, runbooks, architecture overviews — so people could act without waiting for a timezone overlap, and I was explicit with my own site that we evaluated output, not who was visibly online. Fifth, on-call: I set up a follow-the-sun rotation so each region covered its own daytime and handed off cleanly, which ended the misery of the remote site taking pages in the middle of their night. Throughout, I watched the second-order signals of hierarchy — who got the interesting projects, who got credited in reviews, who got promoted — and deliberately corrected toward the remote site where it had been starved.
Results. Over about two quarters the dynamic changed. The remote site’s ownership of the aggregation subsystem stuck — they shipped a freshness improvement that my site hadn’t had bandwidth for, and their tech lead started representing that area directly in cross-team reviews. Velocity across the whole team improved because far less work was bottlenecked on overlap hours. On-call satisfaction went up on both sides after follow-the-sun. And the retention signal reversed: the remote engineers’ engagement scores in the team survey rose, and we promoted one of them the following cycle — the first promotion that site had seen in a while, which mattered symbolically as much as individually.
Learnings. The thing that actually fixed it wasn’t better tooling or more meetings — it was giving the remote site real ownership of a whole area. Everything else (async decisions, fair meetings, follow-the-sun) was necessary support, but ownership was the root cause of both the disengagement and the fix. The lesson I carry: a distributed team fails not because of distance but because of hierarchy, and the antidote is distributing ownership, decisions, and credit as deliberately as you distribute work.
Common follow-ups
How do you keep decisions from being made without the whole team?
How to answer- Write every decision down. A decision log or doc with the reasoning means no one is excluded by being asleep when it was discussed.
- Give an async window before finalizing. Post a proposed decision and leave time for the other timezone to weigh in before it’s locked.
- Ban the hallway decision. If it was decided verbally, it isn’t decided until it’s written — make that an explicit team norm.
- Rotate who drives. Let the remote site own and document decisions too, so decision-making isn’t centered on one location.
How do you avoid the HQ/satellite hierarchy?
How to answer- Give whole areas, not tasks. A site that owns a system end-to-end has real stakes; a site that executes tickets is a satellite by design.
- Watch the second-order signals. Track who gets the interesting projects, the visible credit, and the promotions — hierarchy shows up there first.
- Distribute leadership. Grow tech leads and decision-makers at every site so influence isn’t concentrated where the manager sits.
- Share the inconvenience. Rotate meeting pain and on-call fairly — who absorbs the cost is a strong signal of who’s considered central.
How do you build trust and cohesion without co-location?
How to answer- Trust output, not presence. Evaluate what people deliver, not when they’re green online — presence-based trust is impossible and unfair across timezones.
- Invest in documentation. Good docs are the substrate that lets people work independently and still stay aligned.
- Create human connection deliberately. Occasional overlap, periodic in-person gatherings, and non-work channels build the relationships that async work runs on.
- Be present for the remote site. Regular 1:1s and genuine attention to the site you’re not in prevents the out-of-sight-out-of-mind drift.
How do you run on-call across timezones?
How to answer- Follow-the-sun. Each region covers its own daytime and hands off, so no one routinely takes pages in the middle of the night.
- Make handoffs clean. A written handoff of open issues and current state at each transition keeps continuity across regions.
- Local ownership enables it. A site can only run on-call for a system if it genuinely owns that system — which is another reason to distribute ownership.
- Keep runbooks current and shared. Cross-region on-call depends on documentation good enough that any region can respond.
- Eng-satisfaction / team-health surveys — pull the per-site engagement and inclusion signal before and after, split by location.
- Perf / calibration records — pull evidence of promotions and scope growth at the remote site to show the hierarchy was dismantled.
- GSD — pull the ownership map showing whole areas owned per site, and velocity/throughput trends.
- Decision log & the internal wiki — pull the written decisions and docs that made async work function.
- On-call / SEV records — pull the follow-the-sun rotation and the on-call load balance across regions.