← all posts

In orbital mechanics, drift is the gradual deviation of a spacecraft from its intended trajectory. Left uncorrected, a small initial error compounds over time until the spacecraft is somewhere entirely different from where the mission plan expected it to be.

Distributed teams drift in the same way. The mechanisms are different. The outcome is recognisable.

How teams drift

It starts small. A decision gets made in a channel that not everyone monitors. A context note gets written in a document that not everyone has access to. An assumption gets encoded into a workflow that predates half the current team.

None of these are catastrophic individually. Collectively, over weeks and months, they produce a team that is nominally coordinating but practically operating from different versions of reality.

The calendar reflects none of this. It shows the same recurring meetings, the same block patterns, the same structure that was designed for a team that no longer exists in quite that form.

Correction burns

In orbital mechanics, drift is corrected with a burn — a precisely timed engine firing that brings the spacecraft back to its intended path.

For distributed teams, the equivalent is a structured realignment: a deliberate process of surfacing diverged assumptions, reconciling context, and resetting shared reference points. Not a meeting for the sake of a meeting. A specific intervention with a specific goal.

Continuum tracks the signals of drift — desynchronised schedules, expanding async gaps, coordination patterns that have quietly stopped working — and surfaces them before a correction burn becomes urgent.

On the literal case

We should be transparent: the drift compensation feature in Continuum was originally designed for a very specific customer situation that we are not currently at liberty to fully describe.

What we can say is that the principles of relativistic drift correction and organisational drift correction turned out to be more similar than we expected. Both involve maintaining a shared reference frame. Both require continuous monitoring rather than periodic intervention. Both get significantly harder to correct the longer they are left unaddressed.

We built the feature. It works for both use cases. We are cautiously proud of this.

What this means for your team

You are probably not experiencing relativistic drift. Your team is probably not operating at a meaningful fraction of the speed of light.

But you are almost certainly experiencing some form of accumulated temporal desynchronisation — decisions made in one context being implemented in another, schedules that reflect assumptions that have since changed, coordination overhead that has grown without anyone deciding to grow it.

Continuum’s job is to surface that drift early, when correction is cheap.

Not after the spacecraft is somewhere entirely unexpected.

// drift monitoring is active for all accounts, including the non-relativistic ones