Managing Change in Distributed Teams: Catch the Drift Before It Ships
Composite scenario, built from common patterns; not a real organisation. A software company with engineering hubs in the US, Poland and India decided to move from long-lived feature branches to trunk-based development behind feature flags. The VP of engineering announced it at a US-morning all-hands, which fell in the Polish afternoon and the Indian evening, and posted a decision document afterwards.
Three weeks later the release manager noticed that the three hubs were running three different policies. The India hub had heard, through a manager's summary the next morning, that "branches are banned", and had stopped using release hotfix branches too, which the decision never intended. The Polish hub had understood the change as "optional until Q3", because that was the phrase someone repeated in their channel. The US teams were halfway through the change, as intended.
Nobody had resisted. There was no pushback to manage and no silence to decode. Each site had acted in good faith on the version of the decision that reached it.
That is the failure mode this piece is about. Advice on distributed change usually stops at "go async-first and document everything", and that advice is right. For the general practice, see Remote Work That Actually Works. For the routing process behind any change, see Change Management for Engineering Teams. Here the subject is narrower: why a single, well-documented decision still splits into regional versions, and how to measure and stop that drift.
Why one decision becomes three
Two mechanisms do most of the damage, and both are documented.
Information arrives by relay, at different times. In a co-located team, most people hear a change from the same source at the same moment. In a distributed one, each site's first hearing is often secondhand: a manager's summary, a recording watched at double speed, a thread that started after the meeting. Each relay compresses the decision, and compression drops qualifiers. "Long-lived feature branches go away; release branches stay" becomes "branches are banned".
Questions take longer to get answered, and fewer of them cross boundaries. Herbsleb and Mockus's 2003 study of a globally distributed software organisation found that distributed work items took about two and a half times as long to complete as comparable same-site items, and involved more people. They traced the delay to communication: people at other sites often didn't know who had the information they needed. Two decades later, Yang and colleagues' study of more than 61,000 Microsoft employees (published 2022) found that firm-wide remote work made collaboration networks more siloed, with fewer connections across groups. A question raised in Pune about a decision made in Seattle has further to travel, and is more likely to be answered locally by someone guessing.
Put the two together and drift follows. The decision arrives compressed, the clarifying question doesn't reach the decision-maker in time, and a local answer fills the gap. That local answer becomes the site's policy.
The test you can run: pick your last significant change. For each site, write down who they first heard it from, and how many hours after the decision. If any site's first source wasn't the decision document itself, assume that site is running a relay's version until you've checked.
The restatement test: measuring drift directly
Drift is invisible from headquarters. Dashboards show the change as communicated, so the only way to see it is to ask.
Seventy-two hours after an announcement, ask two or three people at each site to answer three questions in a sentence each, without looking anything up:
What is changing?
From when?
What will you do differently?
Score each answer against the decision document: matches, partly matches (a qualifier is missing), or contradicts it. At the company above, the test produced this:
Site | What is changing | From when | What I'll do differently |
US | Matches | Matches | Matches |
Poland | Partly matches ("optional for now") | Contradicts ("Q3") | Contradicts ("nothing yet") |
India | Contradicts ("all branches banned") | Matches | Contradicts ("hotfix on trunk") |
The India row was the dangerous one. Hotfixing on trunk during a release freeze meant shipping unrelated, unreleased work with an emergency fix. It was caught in week three, before a hotfix was needed. Running the restatement test on day three would have caught it before any team changed its workflow.
The test is cheap: nine people, three sentences each, ten minutes of scoring. It also respects people. It audits the communication, not the individual: a site that can't restate the change correctly was sent the wrong version.
The test you can run: run the three questions on your current change this week, with two people per site. Any "contradicts" answer is a correction to send today, from the decision-maker, in writing, to that site.
The decision document as the only source, with a changelog
GitLab, which runs as an all-remote company, describes its practice as "handbook-first": write the change into the handbook, then announce it with a link, so the announcement points at the source instead of becoming one. The detail that matters for drift is what happens after the announcement. Clarifications made in threads, calls and one-to-ones are new relays unless they go back into the document.
The artifact that stops this is a dated changelog at the top of the decision document:
Changelog4 Mar: Clarified: release branches and hotfix branches are not affected. Only feature branches older than 2 days are in scope. 2 Mar: Added: cutover date in each hub's local time. 1 Mar: Decision published.
Each site can then see what has changed since they last read it, and a manager relaying the decision can link to it instead of summarising. The company added that changelog after the restatement test, and the first entry was the hotfix clarification. It went out with a direct note to the India hub's leads.
The test you can run: open your last decision document and count the clarifications made since publication that appear in the document versus only in chat. Every one that lives only in chat is a relay waiting to drift.
Local answerers with written boundaries
Herbsleb and Mockus's finding about not knowing whom to ask points to a structural fix: for each site or time-zone band, name one person who can answer questions about the change during their working day. Give them the decision-maker's reasoning and written boundaries for what they can answer.
A boundary note for the trunk-based change looked like this:
You can answer | You must escalate |
Which branches are in scope (feature branches older than 2 days) | Any request to keep a long-lived branch |
How to put unfinished work behind a flag | Changes to the release or hotfix process |
The cutover date in local time | Anything the decision document doesn't cover |
Without boundaries, the local answerer becomes another source of drift. With them, most questions are answered within the site's own day, and the rest reach the decision-maker as escalations rather than guesses.
The test you can run: for questions posted about the change, measure the median time to a first correct answer by the asker's region. If one region's median is a working day longer than the others, it needs a local answerer.
Culture changes how a decision is heard
Erin Meyer's The Culture Map (2014) describes how countries differ in how decisions are made, from consensual to top-down, and in how openly people disagree. Both affect drift. In a consensual culture, a decision announced as final without visible consultation can read as provisional, which is close to the Polish "optional for now". In a culture where open disagreement with a senior leader is unusual, a confusing decision is more likely to be interpreted locally than questioned upwards.
Treat these as prompts for the first-hearing map, not as stereotypes to apply to individuals. The question for each site is practical: will people here read this as final, and will they ask if it's unclear? The local answerer usually knows.
If the risk is silence rather than misunderstanding, that is a different problem. See Managing Resistance to Change in Software Teams.
Trade-offs
Approach | Gains | Costs | Best suited for | Warning signs |
Single all-hands plus recording | Fast; one moment | Relays fill the gaps; worst timing for some sites | Small, low-stakes changes | "We heard it from our manager" |
Document first, then announce | One source; can be reread | Slower to launch; needs discipline after launch | Any change that alters workflow | Clarifications living only in chat |
Repeated live sessions per time zone | Questions answered live everywhere | Decision-maker's time; sessions drift from each other | Contentious or high-impact changes | Different answers in different sessions |
Local answerers with boundaries | Fast answers inside each site's day | Coordination; boundaries need maintenance | Multi-site organisations, long rollouts | Answerers deciding beyond their brief |
Restatement test | Measures drift directly | Ten minutes per site; needs follow-through | Every change that alters what people do | Skipped because "everyone was in the meeting" |
Exceptions
A change that alters nothing people do, such as a renamed tool or a new office address, doesn't need any of this; an announcement and a document will do. At the other end, a change with legal or safety consequences, such as a production access policy or an incident-severity definition, may need explicit acknowledgement from every affected person, not a sample. The restatement test samples; compliance needs a census.
A method for your next distributed change
Write the decision document first, with what changes, from when (in each site's local time), what doesn't change, and a changelog section.
Draw the first-hearing map. For each site, decide who gives the first hearing and make it the document itself, linked from a short note sent within that site's working day.
Name local answerers and give each the boundary table.
Run the restatement test at 72 hours with two or three people per site.
Correct in writing. Put each correction in the changelog and send it directly to the affected site.
Repeat the test before the cutover date.
You're done when every site's restatement matches the document, and every clarification since launch is in its changelog.
What to do next
Take the change you're rolling out now and run the restatement test on two people per site this week. It takes less time than the meeting where you announced it.
Final takeaway
Distributed teams rarely reject a change outright. More often each site ends up following a different relay of it. Make the document the only source, give each site someone who can answer within its working day, and check what each site actually heard before the cutover.
When the change is a migration with a long tail, pair this with Communication Plans for Major System Migrations.
Sources
Herbsleb, J. D. and Mockus, A. (2003). "An Empirical Study of Speed and Communication in Globally Distributed Software Development." IEEE Transactions on Software Engineering, 29(6), 481–494.
Yang, L., Holtz, D., Jaffe, S., Suri, S. and others (2022). "The effects of remote work on collaboration among information workers." Nature Human Behaviour, 6, 43–54 (published online September 2021). doi.org/10.1038/s41562-021-01196-4
GitLab. "The importance of a handbook-first approach to communication." GitLab Handbook. handbook.gitlab.com
Meyer, E. (2014). The Culture Map: Breaking Through the Invisible Boundaries of Global Business. PublicAffairs.
