In March 2020, Microsoft sent more than 61,000 US employees home, all at once, with no ramp-up and no choice in the matter. A team of researchers — Yang, Holtz and colleagues — got access to the anonymized email, calendar, chat, call and workweek-hours logs for that whole population and compared the six months after against the same six months a year earlier. It's one of the largest natural experiments on remote work that exists, purely because of how abruptly and completely the switch happened.
The headline result isn't about total collaboration — it's about its shape. Time spent collaborating with people outside an employee's own business group fell by about 25%. Connections inside a person's own group actually got denser over the same window. The company didn't collaborate less. It collaborated in a smaller radius, and the bridges connecting distant parts of the org thinned out. approaches remote work from the operator's side, which complements the engineering view here. XenGrowth's growth operations team approaches remote work from the operator's side, which complements the engineering view here.
What makes this more than a story about isolation is what happened to the channel of communication, not just its reach. Synchronous modes — calls, video, in-person conversation — gave ground to asynchronous ones, email and chat, even while message volume overall went up. And meeting hours, which you'd expect to have absorbed some of that lost synchronous time, barely moved: down only about 5%. Distributed teams end up solving a version of this same design problem that writes about from the commercial side — deciding which conversations genuinely need a live channel and which ones a queue handles just as well.
It's worth being specific about what 'business group' means in this data, because the word can sound more organized than the reality it describes. Microsoft is organized into large divisions — think Windows, Azure, Office — each containing many teams that, before the pandemic, still bumped into each other constantly: shared floors, shared cafeterias, the same all-hands. The 25% drop in cross-group collaboration is a drop in exactly that kind of contact, the sort that was never on anyone's calendar because it didn't need to be, back when it was free.
What the data actually shows, and what it doesn't
Metric (6 months post-mandate vs. same period pre-pandemic) | Direction of change | Size |
|---|---|---|
Time collaborating outside own business group | Down | About 25% |
Density of connections within own business group | Up | Not separately quantified in the summary, but a clear rise |
Meeting hours (total) | Down | About 5% — a small change |
Share of communication that's synchronous (calls, video, in-person) | Down | Shifted toward async (email, chat) |
Rate of new collaborators added / old ones dropped | Down (slower on both) | Network became more static overall |
None of that is a controlled test of timezone overlap specifically. Nobody in this study chose their arrangement, there was no comparison between teams with two hours of overlap and teams with eight, and the whole population was inside one company navigating a single global disruption at the same time. Treat any blog post — this one included, if it tried — that gives you a precise number of overlap hours a team needs as making that number up. This dataset doesn't contain it, and as far as I can tell nobody's dataset does. works through the operations side of this in more operational detail. The XenGrowth resource library works through the operations side of this in more operational detail.
The finding worth taking seriously isn't a threshold. It's a mechanism: remove synchronous contact and the network doesn't spread out to compensate. It contracts toward whoever's already close.
So what actually needs a live room?
If raw overlap hours aren't the real variable, the useful question changes shape: which categories of engineering decision actually need synchrony, and which only feel like they do because synchrony is the default? A few genuinely need it. Most don't, and treating them as if they do is what burns a team's scarce overlap window on the wrong conversations.
Decision type | Needs synchrony? | Why |
|---|---|---|
Resolving a live incident with more than one on-call engineer | Yes | State changes faster than an async thread can track it, and the cost of a wrong guess compounds by the minute |
Breaking a genuine architectural disagreement that's stalled for a week | Yes, once | Text has already failed to resolve it — a bounded live conversation with a decision at the end beats another week of asynchronous back-and-forth |
Onboarding a new hire's first few weeks | Partially | Early psychological safety and quick answers matter enough to justify some scheduled overlap, even if it fades later |
Design review or RFC feedback | No | Written comments, given time to actually think, are frequently better than a live meeting's first reaction |
Status updates and progress reporting | No | This is exactly the kind of traffic the Microsoft data shows moving to async without any measured cost |
Routine code review | No | Already asynchronous by convention almost everywhere, and better for it — nobody wants a live meeting to review a diff |
Why the overlap window shrinks by default, not by design
The Microsoft study's most uncomfortable finding isn't the 25% drop itself — it's that the drop happened without anyone deciding it should. No policy said “stop talking to other groups.” The contraction was a side effect of removing incidental contact: the meeting before the meeting, the person you'd have run into at lunch, the hallway version of a question that never became a scheduled call because it didn't need to be one when proximity was free. Once proximity stopped being free, only the deliberately scheduled version of that contact survived, and deliberate scheduling has a much higher bar than a hallway glance.
That's the argument for treating a team's overlap window as something to design rather than something to maximize. An eight-hour overlap window used for eight hours of status meetings protects nothing that the Microsoft data suggests actually needs protecting. A ninety-minute window reserved specifically for live incident response, architecture disagreements that have already failed to resolve over text, and a standing slot for the newest person on the team to ask anything, does more for the failure mode this study documents than triple the hours spent on things that were always going to work over chat. A short, well-defended synchronous window is the kind of resource-automation teams get right when they decide which processes deserve and which ones still need a person paying attention live — the categorization skill is the same one this post is describing for meetings.
This is also why the fix isn't simply 'have more meetings' or 'mandate more overlap hours.' A mandate that increases overlap without changing what happens inside it just moves the same status updates and progress-checks into a wider window, which the Microsoft data suggests does nothing for the actual siloing problem — meeting hours in that study barely changed while cross-group contact still fell. The lever that matters is which specific conversations get pulled into the live window, not how wide the window is. On AI agents and marketing automation specifically, is worth reading. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
A team that's actually thought this through usually ends up with something narrower than people expect: two hours a day, sometimes less, explicitly reserved for the handful of categories that need it, with an explicit norm that anything else gets written down and answered when the other person's day starts. The narrowness is the point. A schedule that tries to cover 'reasonable working hours' across, say, a nine-hour gap between two continents ends up asking someone to be available at 6am or 11pm regardless of how it's framed, and that cost shows up eventually as burnout or attrition even if the meeting itself went fine.
Don't ask 'how many hours of overlap do we have' first. Ask which specific decisions in the last month actually needed a live room, and count those.
Protect a short window for the categories that genuinely need synchrony: live incidents, disagreements that have stalled over text, and new-hire onboarding — and defend it against being filled with status updates.
Treat everything else — design review, routine code review, progress reporting — as async by default, since the Microsoft data shows this shift happens with no measured cost to meeting-hour totals and no upside from resisting it.
Watch for silent contraction, not just complaints. The Microsoft finding is that collaboration narrowed without anyone announcing a policy — a distributed team should actively look for whether cross-team contact is thinning, because nobody will raise their hand about a hallway conversation that stopped happening.
If you're building a team from scratch across time zones, design the overlap window around the short list of things that need it, then let the calendar be as thin as the work allows — a thin, well-defended synchronous window beats a wide, badly-defended one.
A live conversational channel is genuinely good at exactly the things synchrony is for — resolving ambiguity in real time, reading tone, reaching a decision everyone leaves agreeing on. It's a mistake to treat that as a reason to keep it open all day; it's an equally real mistake to remove it entirely and hope chat picks up the slack, because the Microsoft data suggests it won't, not evenly. It'll pick up the slack for whoever's already nearby, and quietly drop the rest. There's a parallel worth naming in , where the same design question shows up: which interactions genuinely benefit from a real-time voice channel, and which ones a well-designed async text flow handles just as well, at a fraction of the coordination cost.
There's a failure mode worth naming on the other side too: teams that read a study like this one and conclude synchrony is basically obsolete, that async-everything is simply the more modern way to run engineering. That's an overcorrection the data doesn't support either — the Microsoft study found a real cost to losing synchronous contact, it just found that cost concentrated in cross-group bridging rather than in raw output. A team that removes its live channel entirely doesn't just save meeting time. It loses the mechanism the study identifies as the one actually damaged: the connective tissue between groups that isn't captured by any single team's velocity metrics but shows up eventually as duplicated work, missed dependencies and decisions made twice by people who didn't know about each other. If AI search, GEO and discovery is the part you are stuck on, is the better reference. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
A memo does not run a retrospective on itself, and neither does a policy change of this size — Microsoft's mandate happened because of a pandemic, not because anyone modeled the tradeoff in advance, and the research afterward is retrospective analysis of a decision nobody chose for these reasons. That's a reasonable basis for caution about the mechanism, and a poor basis for treating the exact percentages as a target to hit or avoid on purpose.
The honest limits of this evidence
This is one company, one event, and a population that had no say in the arrangement it was measured under. A team that chooses to be distributed, hires for it, and builds deliberate rituals around a protected overlap window is not the same population as 61,000 people sent home overnight by a memo. The Microsoft study is the best evidence that exists for what happens when synchrony disappears at scale and by force. It is not proof that a well-run, voluntarily distributed team gets the same result, and treating it as such would be the same mistake as treating a single company's promotion data as a universal law of careers. What it does establish, reliably, is the mechanism: remove synchronous contact and a network contracts rather than redistributing itself evenly. Any team's overlap-hour policy should be built to counteract that specific mechanism, not to hit an arbitrary number of hours.
Further reading from XenGrowth
Where this work meets go-to-market
Deciding which conversations deserve a live channel and which ones a queue can handle is a revenue-team problem as much as an engineering one. publishes operator guides on exactly that kind of channel design for distributed commercial teams.
Further reading from XenGrowth
Where this work meets go-to-market
covers the go-to-market side of remote work, which this piece deliberately leaves alone.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth, who work on the commercial side of this covers the go-to-market side of remote work, which this piece deliberately leaves alone.
Five questions on the largest dataset available for what happens to collaboration when synchronous overlap disappears at scale.
