Distributed Teams: What Breaks First Isn't the Connection — It's the Shared Definition of Done
We ran three sites: the main office, a second office opened in another city to cut costs, and contractors in China. On top of that, there was project work with clients who had their own teams. The connection itself worked fine — that part rarely causes problems anyway.
What broke was something else. One person considered a task done; another expected something from it that simply wasn't there, and both were certain they had agreed. The gap surfaced a day or two later than it would have in a single room, and that extra day or two was the real cost of being distributed.
A distributed team doesn't lose communication — it loses the shared readiness criterion: what counts as done, who the result goes to, and when. In one room, a gap surfaces within minutes through incidental signals; across sites, it takes days. The fix isn't more meetings — it's a written definition of done and an explicit handoff point tied to the system, not to a conversation.
What Breaks First in a Distributed Team
It helps to separate three things people usually lump into a single word: "communication." They break in a different order, and each is fixed differently.
The connection channel. Rarely breaks, and gets fixed with tools. It's the only piece people usually talk about when discussing distributed work.
The readiness criterion. Breaks first, and almost always invisibly. In one room, it's held up by incidental signals: you see a colleague get up and walk over to the tester, you catch a fragment of conversation, you notice someone's frustrated expression. Across sites, none of those signals exist, and there usually isn't a written criterion either.
The handoff moment. Breaks second. In one room, a handoff happens physically: someone walks over, says it, gets confirmation. In a distributed team it turns into a message that can go unread, and both sides assume the ball is in the other's court.
| What breaks | How it shows up | What fixes it |
|---|---|---|
| The connection channel | "Couldn't reach them," "the call dropped" | Tools |
| The readiness criterion | "I thought that was already done" | A written definition of done |
| The handoff moment | "I did post it in the chat" | An event in the system, not a message |
| The feedback loop | "Nobody told me that wasn't allowed" | Regular review of specific cases |
The first row is solved by a purchase; the other three are solved by process decisions. That's exactly why distributed-work improvement projects that boil down to picking a tool don't deliver results.
What Cross-Site Coordination Actually Costs
The size of the delay has been measured in a study that combined system logs with participant surveys.
A task requiring cross-site coordination took 2,5 times longer than equivalent work within a single site: 12,7 days versus 5 in one division, and 18 versus 7 in another.
This is late-1990s data, from before modern communication tools existed, and it's an observational study, not an experiment; two divisions of a single company. I'll name the limitation directly: the 2,5× multiplier can't be carried over into today's practice as a benchmark. What holds up is the mechanism itself — cross-site coordination adds delay, and it adds it not in the connection channel, which has improved radically since then, but in agreeing on what counts as done.
What the Remote Work Experiment Shows
In a randomized experiment, working from home produced a 13% productivity gain: about 9% from more minutes worked per shift (fewer breaks and sick days) and about 4% from more calls handled per minute.
One company, one profession, and volunteer participants — meaning the sample skews toward people the format already suits. A separate finding from the same study: employees working from home were promoted more slowly. That's an important caveat: the experiment measured productivity on tightly scoped tasks where the readiness criterion is set externally and needs no negotiation.
When a large company's call center shifted to remote work, quality dropped most for employees without experience, and the promotion rate for remote employees fell. Roughly a third of the performance gap is explained by the remoteness effect itself, not by differences in who was doing the work.
The study period is tied to a forced transition, which introduces possible bias, and again, it's a single company and a single industry. But together with the previous study, it paints a consistent picture: distributed work isn't better or worse — it affects different groups differently. An experienced employee with a clear readiness criterion comes out ahead; a newcomer without one comes out worse.
What We Started Doing
The first fix looks like bureaucracy right up until the first disagreement. A readiness criterion is three or four bullet points per task type, not a document: what's done, what's been checked, where the result lives, who it's been handed to.
The second fix removes an entire class of disputes: "but I posted it." A chat message isn't a handoff — it can go unread, get read and forgotten, or get read by the wrong person. An event in the system records the fact, the time, and the recipient — I wrote separately about the difference between an event and a message.
The third fix is the most organizationally expensive and the most effective. As long as a process has two owners on two sites, they'll keep two different versions of it in good faith.
Four Steps for a Team Working Across Multiple Sites
Write the readiness criterion
Three or four bullet points per task type. Test: two people, asked independently, give the same answer to whether the task is done.
Turn the handoff into an event
Not a message — a state change in the system, with a recipient and a timestamp.
Name one process owner
One person, across all sites. Two owners means two versions of the process within a quarter.
Treat gaps as a defect in the criterion
Every "I thought that was already done" is a reason to add a bullet point, not to discuss someone's attentiveness.
If two people at different sites give different answers to "is this task done," the problem isn't the connection and it isn't the people — there simply is no readiness criterion.
Questions People Ask Most Often
What breaks first in a distributed team?
The shared understanding of readiness. In one room, it's held up by incidental signals — you see and hear what stage a colleague's work is at. At a distance, those signals don't exist, and there usually isn't a written criterion either, so the gap surfaces days later. The connection channel, which people talk about the most, actually breaks the least and is fixed with tools.
How many meetings does a distributed team need?
Fewer than usually get scheduled, if there's a written readiness criterion — and more, if there isn't. Meetings compensate for the missing criterion in an expensive way: by using everyone's synchronous time. A practical sign of excess: the meeting is spent discussing whether a task is done, not what to do next.
Does a distributed team perform worse?
It depends on the group. A randomized experiment showed a 13% productivity gain on tightly scoped tasks where the readiness criterion is set externally. Another study in a similar setting found that employees without experience were hit hardest, and that promotion odds fell for remote workers. In other words, the format amplifies the gap between people who have clear criteria and people who don't.
How should work be handed off between sites?
Through a state change in the system with an explicit recipient, not through a message in a chat app. A message can go unread, get read by the wrong person, or get read and forgotten — while both sides remain convinced the handoff happened. An event in the system records the fact, the time, and the recipient, and shows how long the work sat waiting to be picked up.
The three-site setup (a main office, a second office opened in another city to cut costs, and contractors in China) and the practice of managing cross-functional teams across multiple locations come from Alego.Digital's work and the author's projects in China in 2017–2019. This is internal information from the author's companies; it hasn't been verified by an independent party and is presented as an illustration of the mechanics. No quantitative measurement of cross-site delay was ever carried out, so this article contains no internal numeric metrics on that question; every figure comes from external sources with the methods stated.
- Herbsleb J. D., Mockus A. An Empirical Study of Speed and Communication in Globally Distributed Software Development. IEEE TSE, 29(6), 2003. uni-saarland.de
- Bloom N., Liang J., Roberts J., Ying Z. J. Does Working from Home Work? Evidence from a Chinese Experiment. QJE, 130(1), 2015. nber.org
- Emanuel N., Harrington E. Working Remotely? Selection, Treatment, and the Market for Remote Work. FRBNY Staff Report 1061, 2023. newyorkfed.org