Structuring a Distributed Team

Organisational structures designed for co-located teams tend to fail quietly at distance. The failures are predictable and mostly concern how much informal communication the structure assumes.

Structures assume communication they do not provide

Every org chart has an implicit assumption about how much unplanned coordination happens between the boxes. In an office that coordination is free — people overhear, ask across a desk, resolve something at the coffee machine.

Remove that and any structure requiring heavy informal coordination stops working. Not dramatically; things simply take longer and more falls through gaps.

The practical consequence: distributed teams need clearer boundaries than co-located ones, because ambiguity between teams no longer gets resolved incidentally.

Smaller spans, more explicitly

A manager with twelve direct reports in an office maintains awareness passively. The same manager remotely maintains it only through scheduled conversation, which does not scale the same way.

Six to eight is a more realistic ceiling for a remote manager who is genuinely managing rather than administering. Beyond that, one-to-ones become status updates and problems surface late.

Ownership must be unambiguous

In an office, unclear ownership resolves itself through conversation. At distance it resolves by nobody doing the thing.

For each area of work, one team owns it and one person within that team is accountable. Written down, in a place people can find. "The platform team and the product team both work on that" is a description of a future incident.

Reduce cross-team dependencies

Every dependency between distributed teams costs more than the same dependency co-located: more scheduling, more waiting, more misunderstanding.

This argues for organising around outcomes rather than functions where possible, so that most of what a team needs to ship sits inside the team. The classic functional structure — all designers here, all engineers there — is workable in an office and expensive at distance.

Time zone bands as a structural constraint

Teams that work closely together should sit within a workable overlap. Teams that interact weekly can be further apart.

This means time zone is a structural variable, not a hiring detail. Placing two tightly coupled teams eight hours apart is an organisational decision with predictable consequences, and it is usually made accidentally by hiring rather than deliberately by design.

Where the informal work went

Several things that happened incidentally in an office now need an owner:

Context distribution. Someone must ensure decisions reach the people affected. In an office this happened by proximity; remotely it happens because someone writes it down and posts it, or it does not happen.

Onboarding. New people absorbed norms by observation. Now someone must teach them explicitly.

Cross-team awareness. People no longer overhear what the next team is doing. Either you create a mechanism — written updates, a regular forum — or teams drift into duplicating and contradicting each other.

Escalation. Knowing who to ask was tacit knowledge. Now it needs to be documented.

None of these is difficult. All of them are invisible until they are missing, which is why they are usually noticed a year late.

The signals that structure is wrong

Decisions taking weeks that used to take days. Usually unclear ownership.

The same question asked repeatedly in different channels. Context is not reaching people.

Two teams surprised by each other's work. Boundary or awareness problem.

Everything routing through one person. They have become the coordination layer the structure omitted, and they will burn out.

Meetings growing. People adding themselves because they cannot otherwise find out what is happening.

Each of these is a structural symptom that gets treated as a behavioural one, which is why organisations respond with more meetings instead of clearer boundaries.