What Actually Breaks in Distributed Engineering Teams

A colleague opens a pull request at 18:00 in one time zone. The reviewer who understands that subsystem best is eight hours behind and will not see it for another fourteen hours. The comment, when it comes, contains a question. The author is now asleep. Three sentences of feedback have cost two calendar days. That arithmetic governs distributed engineering teams and no tooling repeals it.

I have run engineering work where the people doing it were not in the same room, not in the same country and not awake at the same time. What follows is the pattern rather than any particular setup, which is more useful anyway, because the failure modes repeat with unnerving consistency across organisations that have nothing else in common.

What breaks is almost never the thing people prepare for. Teams buy video conferencing and worry about culture. What actually destroys throughput is round trips.

Distributed engineering teams take two and a half times as long

This has been measured. Herbsleb and Mockus, writing in IEEE Transactions on Software Engineering in 2003, matched source-control records against survey data at a large software organisation with sites in Germany, the UK and India. Work items involving more than one site took roughly two and a half times as long in calendar time as comparable items done entirely at one site.

The mechanism they identified matters more than the multiplier. Distance itself was not the cause. Distributed items simply pulled in more people, and the number of people involved was strongly related to how long the item took. Every additional person is another wait state, another context to rebuild, another chance for the thread to go quiet overnight.

The study is old and its tooling is ancient. The mechanism has not aged at all, because the mechanism is about coordination cost rather than about software. A more recent look found the same shape: researchers tracking 61,182 Microsoft employees through the 2020 shift to firm-wide remote work saw collaboration networks become more siloed, with the share of time spent on cross-group connections falling by about a quarter.

For most changes, a slightly less expert reviewer who is awake beats the best reviewer who is asleep.

Handover as a designed artifact

Most teams hand over with a status message. Yesterday I did X, today I will do Y, blocked on Z. That is a report to a manager wearing the costume of a handover.

A handover artifact is a different object. It is written for one named person who will take the next action without you, and it is designed backwards from that action. It carries the state of the work as decisions rather than percentages. It names the next step and its owner. It lists the options already rejected, with reasons, because an option rejected silently gets proposed again on Thursday. It states open uncertainties as uncertainties instead of burying them in confident prose. And it includes the concrete residue needed to resume: branch names, environment state, the exact command that reproduces the failure.

One test settles whether you have written one. Could the receiver take the next step without sending you a question? If not, it was a status message and you have just bought another round trip.

Write for the reader with the least context. On a distributed team you do not get to choose who reads it.

Written decisions beat meetings that cannot include everyone

A meeting that cannot include everyone it affects is not a decision forum. It is a private conversation with public consequences. On a team spanning enough hours, that describes almost every meeting.

The replacement is a written decision record: the context, the options considered, the option chosen, the reasoning and the person accountable. Stored next to the code, in version control, where it survives everyone who was in the original conversation.

The documentation value is real but secondary. The primary value is that writing forces the decision to become specific enough to write. Half the disagreements in a design meeting dissolve the moment somebody has to commit the sentence to a file, because two people were using one word for two things. The other half sharpen into a disagreement worth having.

The cost is honest and not small. A decision record takes forty minutes that a ten minute call would have covered. You pay it to avoid relitigating the question in six months, when nobody remembers the reasoning and the decision gets reversed for a reason already considered and rejected. Usually worth it. Not always.

The follow-the-sun fallacy

The pitch is seductive. Hand the work off at end of day, wake up to progress, get twenty-four hour development out of an eight hour day.

Carmel, Espinosa and Dubinsky studied that workflow properly and concluded that handoff efficiency governs the outcome. Duration falls only when lower within-site coordination and improved individual productivity outweigh the extra cross-site coordination the handoffs create. That is a demanding condition and most teams do not meet it.

Software work is not a baton. Most of the value of a working session lives in state held inside one head: the half-formed hypothesis about why the test is flaky, the three things already tried, the sense that the bug is in the serialisation layer without yet being able to say why. Handing off means reconstructing that state in someone else, and reconstruction usually costs more than the receiver's first two hours.

Follow-the-sun works for genuinely partitionable, well-specified work. Triage queues. On-call. Build breakages. A defined test run. It fails for design and for debugging, which is where the interesting time goes.

The version that does work is not follow-the-sun at all. It is ownership that does not move. Each zone owns whole components end to end, with real authority to decide inside them. Nothing hands off because nothing crosses. You give up the fantasy of continuous progress on one task and you get the elimination of the handoff.

Review latency and the synchronous minimum

Google's engineers published their numbers. In a study of their code review practice, median latency for the whole review process came in under four hours, with initial feedback on small changes arriving in under an hour. That is the high-overlap baseline.

Now put the reviewer in a zone with two hours of working overlap. Ordinary case, feedback lands the next working day. Two rounds of comments and the change merges on day three, having consumed perhaps ninety minutes of actual human attention.

The instinct is to chase overlap hours. The better move is to cut rounds.

Smaller changes, because a change understood in one sitting can be approved in one round. Reviewers assigned partly by wake time rather than purely by expertise: for most changes, a slightly less expert reviewer who is awake beats the best reviewer who is asleep. A pull request body carrying the context that would otherwise arrive as a question, which is the handover discipline at smaller scale. And a standing rule that a reviewer who asks a question must also state their best guess at the answer, so the author can confirm rather than explain. That converts a round trip into half of one.

Four things have to stay synchronous. Disagreement that survives both people writing their positions down. Anything with emotional weight, which means performance feedback, conflict and bad news. The opening hours of a genuinely ambiguous design problem. And incidents.

Everything else must not be. Status reporting, first and permanently. Information broadcast. Any decision a written record could carry. And nothing recurring should land at 23:00 for one zone, because a meeting like that is a tax with compound interest and the people paying it leave. Retention belongs inside the productivity equation, not beside it. The randomised hybrid-work trial published in Nature in 2024 put 1,612 employees on a partly remote schedule and found resignations fell by a third with no measurable effect on performance grades, promotions or code written.

Technical precision degrades in a second language

I work across English, Mandarin and French, and read Chinese technical sources directly rather than in translation. The thing nobody warns you about is that fluency is rarely the constraint. Precision under time pressure is.

In your first language you have margin. You can put a hedge in exactly the right place. I think the cache is stale, but I have not confirmed it, is a sentence with the uncertainty positioned precisely where it belongs. Under load in a second language, the hedge is the first casualty. What comes out is the cache is stale. Confident, unverified and now in the record as fact.

Live conversation adds a second effect. Non-native speakers compose a beat behind. By the time the objection is assembled the group has moved on, and raising it now means rewinding everybody, so it does not get raised. That is not confidence. It is latency, and it produces a systematic bias in which decisions reflect the views of whoever is fastest in the meeting's language.

This has been studied. Interviews with 27 Chinese developers in commercial and open source global teams, published in Computer Supported Cooperative Work in 2024, found insufficient language capital blocked access to the social and symbolic capital careers are built from, reproducing a durable disadvantage rather than a temporary one.

Writing restores the margin. A written thread gives a non-native speaker the seconds needed to be exact, and exactness is the entire job. A second argument for deciding in text that has nothing to do with time zones.

One more failure worth naming: terminology drift. A concept acquires a different name in each working language and two people argue for an hour before discovering they agree. The fix is a glossary carrying the term in every working language, plus a hard rule that code, identifiers, comments and commit messages live in one language. Discussion can be multilingual. The artifact cannot.

Co-located teams are genuinely faster for ambiguous work

The strongest argument against everything above is that it is a set of workarounds for a handicap you chose.

Teasley and colleagues studied software teams moved into shared project rooms and found them roughly twice as productive as comparable teams in conventional offices. Olson and Olson, reviewing a decade of work on collocated and remote collaboration, catalogued what proximity actually supplies: rapid repair when a misunderstanding occurs, multiple channels for a complex message, shared local context, gaze and gesture to establish what is being referred to, plus the fluid movement between subgroups that overhearing makes possible.

Every item on that list is what you need in the first days of an ambiguous problem, before anyone can state the problem cleanly. That phase is not information transfer. It is the construction of shared understanding, and shared understanding is built fastest through fast, cheap, low-stakes correction. Distributed teams cannot do fast cheap correction. Every correction costs a round trip.

Pretending otherwise is exactly why some distributed teams stay slow. They run the ambiguous phase over asynchronous threads, reach a design nobody has actually agreed to and then spend a quarter discovering the disagreement in code.

The honest response is to concentrate the ambiguity and pay for it in synchronous time. Put the people in one room for the week that sets direction, then distribute the execution. If a room is impossible, compress it into a few long overlapping sessions with a designated writer, and treat that as an inferior substitute rather than an equivalent one.

The compensation is reach, not speed

Everything takes longer. That is the price and it does not go away. Any leader who tells their organisation otherwise is arranging a failure they will later blame on the team.

What you buy is composition. The engineer who is among the best anywhere at your particular embedded problem and is never leaving their city. The person who reads primary sources in a language your competitors read only in summary. Markets covered by people who live in them rather than modelled from outside. A team that survives one country's bad year.

So the trade is legible. You give up iteration speed on ambiguous problems and you buy a team you could not otherwise assemble. If what you are building does not require that assembly, do not distribute it. Hire in one city and go faster. Distribution is not a virtue.

The failures I have watched were never caused by the time zones. They were caused by someone promising the speed of a co-located team while collecting the reach of a distributed one and then being measured against the promise. Nobody wants to write that trade down, because writing it down means committing in advance to being slower. Which is, of course, precisely the kind of decision that ought to be written down.

Sources

Herbsleb & Mockus, An Empirical Study of Speed and Communication in Globally Distributed Software Development, IEEE TSE 2003: https://dl.acm.org/doi/10.1109/TSE.2003.1205177

Carmel, Espinosa & Dubinsky, Follow the Sun Workflow in Global Software Development, Journal of Management Information Systems 2010: https://dl.acm.org/doi/abs/10.2753/MIS0742-1222270102

Sadowski, Soderberg et al., Modern Code Review: A Case Study at Google, ICSE-SEIP 2018: https://sback.it/publications/icse2018seip.pdf

Yang et al., The effects of remote work on collaboration among information workers, Nature Human Behaviour 2022: https://www.nature.com/articles/s41562-021-01196-4

Bloom et al., Hybrid working from home improves retention without damaging performance, Nature 2024: https://www.nature.com/articles/s41586-024-07500-2

Wang, Yue, Wang & Zhang, Uncovering Non-native Speakers' Experiences in Global Software Development Teams, CSCW 2024: https://arxiv.org/abs/2501.06437

Teasley, Covi, Krishnan & Olson, Rapid Software Development through Team Collocation, IEEE TSE 2002: https://dl.acm.org/doi/10.1109/TSE.2002.1019481

Olson & Olson, Distance Matters, Human-Computer Interaction 2000: https://ics.uci.edu/~corps/phaseii/OlsonOlson-DistanceMatters-HCIJ.pdf