A Team Twelve Hours Apart

A question asked at four in the afternoon at one site arrives at four in the morning at the other. It is read at nine, answered by ten, and lands back in the first inbox at ten at night, where it sits until the following morning. One question, one day. If the answer raises a second question, that is a second day, and by the time the work is actually understood well enough to start, a week has gone by in which nobody was slow, nobody was unavailable, and nobody did anything wrong.

This gets discussed as a communication problem, so the proposed fixes are communication fixes: a better chat tool, a shared document, a stand-up with cameras on, an agreement to write more clearly. Some help at the margin. None changes the number of times in one day that a question can be asked and answered, and that number is the constraint. Two people in the same city who dislike each other have a communication problem. Two people twelve hours apart have a scheduling constraint that goodwill does not remove.

So the question worth asking is not how the team communicates better. It is how the work is arranged so that finishing a piece of it requires very few round trips. Everything useful I know about running teams across a large gap is a version of that single sentence, and almost everything expensive I have watched happen is the result of an arrangement that made the number of round trips large without anyone noticing that it had.

James Herbsleb and Audris Mockus published a study of two globally distributed departments in IEEE Transactions on Software Engineering in June 2003. They took change-management data and survey responses from two departments of one telephony company, each split across several countries, and compared work items handled at one site with work items that involved more than one. Same-site items averaged about five days. Distributed items took 12.7. In the second department the pair was about seven days against 18: the same ratio, roughly two and a half times as long.

The number people repeat is the two and a half. The finding I care about is the one underneath it. The delay was not explained by distributed changes being larger or touching more modules; they were not. What distributed work items had was more people involved, and the number of people involved was what predicted the calendar time. The distance did not slow the work down directly. It slowed the work down by requiring more heads per unit of work, and each head across a gap is another round trip waiting to happen.

Two limits, stated in the same breath as the citation. The study measured sites, not hours: a four-hour gap and a twelve-hour gap both count as distributed in that data, and the paper does not separate them, so it under-describes exactly the case I am writing about. And the authors say themselves that results may differ for organizations that divide work across sites differently or under different business arrangements, which is a real caveat about a two-department study inside one company in one industry.

This is what follow-the-sun really is. The pitch is continuous progress: one site hands off at the end of its day and the work carries on while they sleep. The reality is a handoff every twelve hours, and a handoff costs the same whether or not anything was learned since the last one. Somebody writes down where they got to, somebody else reads it, forms a model, discovers what was left out, and asks. Two handoffs a day is two full context transfers a day, and the transfer is the expensive part.

There is work it genuinely suits. Serial, well-specified work with a clear definition of done and no judgment in the middle. A long test suite that someone needs to watch. A migration script running against a large table. An operational queue where each item is independent and the procedure is written down. In those cases the handoff carries almost nothing, because the state lives in the system rather than in a person's head, and continuous coverage is exactly what you get.

And there is work it destroys. Anything where the next step depends on judgment about the last one. Design, debugging, and the entire category of tasks whose shape changes once you start. Handing a half-diagnosed bug across a gap is handing over the artifacts of the investigation without the reasoning that produced them, and the receiving engineer will re-derive most of it, correctly, and slowly. Two people can take twice as long as one on the same defect, which looks like incompetence and is arithmetic.

There are two ways to split work between two locations and they are not close in quality. You can split by system, so one site owns a service end to end, from design through implementation and review to the pager. Or you can split by activity: one site designs and another implements, or one writes code and another reviews it. The second is the arrangement that gets proposed, because it maps onto job titles and looks like specialization. It is also the arrangement that guarantees a round trip inside every unit of work.

Splitting by system does the opposite. It puts the round trips inside a site, where they cost ninety seconds, and leaves across the gap only the traffic that genuinely has to cross it: interfaces, contracts, and the occasional argument about them. This is Conway's observation from 1968 turned around and used deliberately. If the system's structure is going to end up mirroring the organization's communication structure anyway, then choose a partition of the system you would be happy to have mirrored, and give each side of it to one place.

Herbsleb and Grinter, writing about a split organization in 1999, found something worth remembering here: the coordinating mechanisms an organization leans on across sites, plans and processes and interface specifications, all worked until something unforeseen happened, at which point they needed exactly the informal, unplanned conversation that was almost entirely absent across the gap. So the interface you define between two sites is not just an engineering artifact. It is the thing standing in for a conversation that is not going to happen.

Do not spend them on status. The overlap window is the only time synchronous bandwidth exists at all, and most teams fill it with a meeting where people say what they did. That information is not urgent, it survives being written down, and it is read faster than it is spoken. What genuinely needs to be synchronous is disagreement, design under uncertainty, and unblocking somebody who is stuck. Those are the three things that go badly in writing, and they are the three things that get squeezed out by the update.

The hour is a tax, and it lands on somebody. If the call is always at nine in the morning for one site, it is always at ten at night for the other, and that is a standing cost paid by the same people every week, in their evenings, indefinitely. Rotating it is a small change with a disproportionate effect, partly because it shares the cost and mostly because it demonstrates that the cost was noticed. A site that always takes the late call learns something about its position that no statement of values will contradict.

Some of it is genuinely lost. The unplanned conversation is the part you cannot recover. Perry and colleagues, in a study cited by Herbsleb and Mockus, found developers spending around seventy-five minutes a day in unplanned interpersonal interaction, and Allen's work at MIT found that engineers thirty meters apart already communicated about as often as engineers many miles apart. If a corridor kills it, a gap of half a day is not going to be repaired by a chat channel. Plan for its absence rather than for its replacement.

Wherever the leadership of an organization sits, the people near it hear things earlier and more completely. They catch the reasoning behind a decision, not just the decision. They know which initiative is genuinely funded and which one is being talked about. They are in the room when a priority quietly changes, and they adjust the same afternoon. None of this is favoritism and most of it is not even deliberate. It is a byproduct of proximity, and it accumulates.

The far site gets the output of all that, filtered, late, and stripped of the reasoning. So its engineers decide with worse inputs, and decisions made with worse inputs look worse. Then somebody says the work from that site is not at the same level, and a conclusion gets drawn about the people, when one group had context and the other had a summary. I have watched that misdiagnosis happen and been slow to spot it, because the symptom really does look like a capability gap.

The fix is unglamorous and mostly consists of moving information deliberately rather than hoping it flows. Write down why, not just what. Put the far site's people in the rooms where things are argued, not the rooms where things are announced. And when a decision is made in a corridor, and some of them will be, repeat it in a written channel that same day, in enough detail that somebody reading it twelve hours later knows the reasoning and not just the outcome.

The people you need do not all live in one place. This is the honest reason most of the time and it is a good one. The engineer who has done the specific hard thing you need done lives where they live, and the choice is not between one site and two, it is between two sites and not hiring them. A well-partitioned team spread across a gap will comfortably beat a badly organized team sitting together, and I have seen both often enough to be confident about the direction.

Distance is a cost, not a discount. The one thing I would not concede is the accounting. Work across a gap takes longer, the research says about two and a half times longer for the items that cross it, and a plan that budgets for the same throughput as a co-located team is wrong before it starts. Distributing a team can be the right decision and it is never the cheap one, and pretending otherwise means the difference gets charged to the engineers as a performance problem.

I should narrow this. A four-hour gap is a different animal from a twelve-hour one, and much of what I have said softens as the overlap grows: with half a day in common you have a slower team that mostly works. It is at the full inversion, where the overlap is an hour or none, that the arrangement of the work stops being one factor among several and becomes the only one. And the studies I leaned on measured sites rather than hours, so I am extending them further than their authors did.

What stays with me is how little of this is about the gap itself. The gap is fixed and no organization has ever improved it. What is not fixed is how many times a piece of work has to cross it, and that is decided months earlier by somebody drawing a line on a diagram of who owns what. Get the line right and twelve hours are an inconvenience. Get it wrong and you have two teams sharing a repository, with somebody taking the call at ten at night to hold them together.