What Co-Location Was Doing for You
Most governance advice assumes a shared physical space. Not explicitly — it rarely says "this only works in an office" — but implicitly, in the mechanisms it relies on. Real-time consensus in a meeting. The hallway conversation that corrects a misunderstanding before it compounds. The visible cue that tells someone an authority figure is paying attention. The social proximity that makes accountability feel real even when formal mechanisms are absent.
When teams distribute, these mechanisms do not degrade gracefully. They fail abruptly. The hallway conversation cannot happen asynchronously two time zones apart. The meeting designed for fifteen people in a room becomes a grid of faces that actively discourages the kind of dialogue that produces real decisions. The authority that was visible when the leader was physically present becomes invisible when the leader is a name in a status update.
Understanding what co-location was doing for your governance is the starting point for redesigning governance for distribution. The four assumptions that co-located governance typically makes explicit what has to change.
Decisions can be made synchronously. In a co-located environment, the default decision mode is the meeting: a real-time gathering of the relevant people, a discussion, a conclusion. This works because all participants can be present simultaneously at low coordination cost. In a distributed environment, "all participants simultaneously" carries a timezone tax that can be prohibitive. The meeting that spans three time zones means someone is starting work at 6 AM or finishing at 10 PM. The synchronous decision mode, applied universally to a distributed team, either concentrates decision-making in one timezone or imposes an unfair burden on participants in disadvantaged zones.
Informal coordination compensates for formal gaps. No governance system is complete. Every formal process has gaps where the informal organization compensates — people who know each other well enough to resolve ambiguities directly, relationships that allow quick clarifications without formal escalation, the ambient organizational knowledge that comes from being in the same physical space. In co-located environments, these informal compensation mechanisms develop naturally through proximity. In distributed environments, they do not develop at all, or develop so slowly that formal governance gaps become actual operational problems before the informal mechanisms catch up.
Authority is visible and legible. When the person with decision-making authority is physically present, their authority is visible in multiple ways — through physical presence, through the way others orient toward them, through the casual demonstrations of deference that happen constantly in shared space. These visibility mechanisms make it easy to know who has authority over what. In distributed environments, authority is what is documented. If it is not written down, it is effectively invisible — people make assumptions, those assumptions diverge, and decisions are either made by the wrong people or not made at all because no one is sure who should make them.
Accountability can be maintained through social proximity. In co-located environments, social proximity creates an informal accountability layer. People know when colleagues have been at the office, roughly when they are working, what projects they are on, whether they seem to be struggling. This ambient monitoring is not surveillance — it is the natural byproduct of sharing space. It allows problems to be noticed and addressed informally before they require formal intervention. Distributed teams lose this entirely. Accountability that was maintained partly through proximity must now be maintained entirely through formal mechanisms.
The Four Redesigns Required for Distributed Governance
Each co-location assumption has a corresponding governance redesign. These are not optional enhancements — they are the minimum required to maintain governance function at distribution.
Asynchronous decision protocols. The default decision mode must shift from synchronous (meet and decide) to asynchronous (propose, comment, decide within a window). This is not simply a matter of using different tools. It requires a different decision architecture: proposals are documented rather than presented verbally; the decision-making window is specified (48 hours, 72 hours, one week) so that participants know when input is due; the decision criteria are explicit in the proposal rather than established through discussion; and the decision-maker — the person with authority to close the decision — is named in advance.
Asynchronous decision-making surfaces a governance problem that synchronous decisions can obscure: unclear decision rights. In a synchronous meeting, unclear decision rights often resolve through social dynamics — the most senior person in the room, the most forceful personality, or the person who speaks last. None of these resolution mechanisms function asynchronously. Distributed governance requires that decision rights be explicit before the decision process begins.
Explicit coordination mechanisms. The informal coordination that co-location provides must be replaced with formal coordination structures — and the structures must be designed to be low enough friction that they are actually used. The most common failure in distributed coordination is designing mechanisms that are theoretically complete but practically burdensome. A coordination system that requires fifteen minutes of documentation per decision will not be used for small decisions, and the informal layer that was compensating for small-decision gaps will not exist.
Effective explicit coordination mechanisms share three properties: they are standardized (the same structure every time, so maintenance is low), they are asynchronous by default (requiring no scheduled meeting to update), and they are visible by default (new team members can see the current state without being briefed individually). Status documents, decision logs, and escalation paths that are maintained in shared, accessible locations and updated on a predictable cadence are the minimum infrastructure.
Documented authority structures. Every authority that was previously legible through presence must be made legible through documentation. This means: a clear map of who has authority to make which categories of decisions, what the escalation path is when a decision exceeds that authority, and what happens when the authority holder is unavailable. The authority map is not a permanent document — it should be reviewed when the organization changes, when roles change, and when distributed team members flag ambiguity.
The documented authority structure also resolves a problem unique to distributed teams: the timezone-advantaged decision. In a team spread across multiple timezones, the team members who overlap with leadership's working hours have disproportionate access to informal decision-making. The documented authority structure ensures that decisions requiring authority above a certain threshold cannot be made informally through timezone-convenient access — they must go through the documented process, which is equally accessible regardless of timezone.
Accountability systems that work without proximity. Replacing proximity-based informal accountability with formal mechanisms requires more than performance reviews and status updates. It requires designing accountability at the task and commitment level, not just at the outcome level. This means: explicit commitments with specific timelines (not "I will work on X" but "I will complete X by Thursday EOD"); a systematic way to track whether commitments have been met; and a clear escalation path when commitments are missed — one that is triggered by the structural system rather than by whether a manager noticed something was wrong.
The escalation path design is particularly important. In distributed teams, missed commitments often go unnoticed for longer than they would in co-located environments, because the ambient monitoring of shared space is absent. By the time the miss is noticed, it has often compounded. The accountability system must create visibility at the commitment level, before the outcome is affected.
A Worked Example: How One Decision Goes Wrong Across Time Zones
The redesigns are easier to justify when you watch a single decision fail without them. Take a team split between a leadership cluster in one timezone and an engineering cluster eight hours ahead, facing a decision: ship a feature with a known limitation, or hold for a fix.
In a co-located team this resolves in fifteen minutes. The engineer flags the limitation, the lead who owns the call weighs it, a decision is made, everyone in earshot knows the answer and the reasoning. None of those steps survive distribution intact. The engineer flags the limitation at the end of their day, in a channel. The lead reads it the next morning, eight hours later, by which point the engineer is asleep. Lacking the back-and-forth that would have clarified the limitation, the lead makes an assumption about its severity and replies. The engineer wakes to a decision built on a misread of the constraint, made by someone they could not question in real time, with no record of which alternative was weighed or why.
Decompose what actually broke and every failure maps to a missing redesign. There was no asynchronous decision protocol, so the proposal arrived as an offhand message rather than a documented question with explicit criteria and a named decision-maker. There was no documented authority structure, so it was unclear whether the lead even owned this call. There was no decision log, so the reasoning evaporated and the next person to hit the same limitation will rediscover it from scratch. And the timezone gap converted a fifteen-minute conversation into a thirty-six-hour exchange of assumptions — the timezone-advantaged-decision failure mode in its quietest form, where the disadvantage is not exclusion from the room but the inability to correct a misunderstanding before it sets.
Now run the same decision through the redesigns. The engineer files a documented decision request: the limitation, two options, the criteria that should decide between them, the named owner, and a 24-hour window. The owner — whose authority over this class of decision is on the authority map — responds against the stated criteria and logs the choice and rationale. The engineer wakes to a decision they can understand without having been present for it, and the next engineer who hits the limitation reads the log instead of reopening the question. The timezone gap is still eight hours wide. It simply no longer matters, because nothing in the process depended on the two clusters being awake at the same time.
The Governance Artifacts Distributed Teams Require
Governance artifacts are the documented structures — protocols, logs, maps, meeting formats — that make distributed governance visible and consistent. The artifacts described here are the minimum set for a distributed team with more than five members.
Decision log. A running record of significant decisions made asynchronously, including: the decision, the decision-maker, the date, the alternatives considered, and the rationale. The decision log serves two functions: it makes past decisions accessible to people who join later or who were not included in the original decision, and it creates a record that allows the team to identify decision patterns and evaluate whether the decision-making process is working well.
Async status protocol. A standardized format for team status updates that replaces the ambient status awareness of shared space. The protocol should be low-friction enough to be maintained daily or weekly and should surface: what each person is working on, what is blocked or at risk, and what decisions or input are needed from others. The protocol is most effective when it is structured — a defined format rather than a free-text update — because structured updates are faster to write and faster to parse.
Escalation paths independent of hallway conversations. The escalation paths that exist in co-located governance often rely on informal communication — a quick conversation with a manager, a mention in passing to the right person. Distributed escalation paths must be explicit and asynchronous: a documented process for raising concerns, requesting decisions, or flagging risks, with clear ownership at each level and a specified response timeline. The escalation path should not require a scheduled meeting to activate; it should be usable asynchronously by any team member at any time.
Meeting structures that respect timezone distribution. When synchronous meetings are necessary, they should be designed to respect the timezone distribution of the team. This means rotating meeting times so that the timezone burden is shared rather than consistently falling on the same group; recording meetings and providing written summaries for members who cannot attend; and using meeting time only for the content that genuinely requires synchronous interaction — decisions that need real-time dialogue, relationship-building, and escalation resolution — rather than status updates and information sharing that can be done asynchronously.
Failure Modes Specific to Distributed Governance
Beyond the general governance failure modes, distributed teams face failure modes that emerge specifically from the combination of distribution and governance.
Timezone-advantaged decision-making. The team members who overlap with leadership's working hours develop informal relationships and informal decision-making access that members in other timezones do not. This creates a de facto two-tier team: the timezone-advantaged members who participate in real decision-making, and the timezone-disadvantaged members who are informed of decisions but not involved in making them. This is governance capture at the timezone level.
The fix requires designing decision processes that do not depend on timezone overlap for access. Asynchronous decision protocols, documented decision rights, and explicit escalation paths that are accessible to all team members regardless of timezone are the structural solutions.
Documentation theater that substitutes for real governance. Distributed teams often produce documentation because documentation is the visible evidence that governance is happening. The status update is filed; the decision log has entries; the process was followed. But if the documentation does not actually drive decision-making, surface problems, or create accountability, it is governance theater — the form of governance without the substance.
The test for documentation theater is whether anyone uses the documentation to make decisions or catch problems. If the decision log is written after decisions are made rather than informing them, if the status updates are read by nobody with authority to act on them, if the escalation path exists but nobody uses it — the documentation is theater. The fix is to close the loop: after every significant decision, trace how the documentation contributed to it; after every problem, trace where the documentation should have surfaced it earlier.
The collapse of informal coordination without a replacement. The most common failure in distributed team governance is not a dramatic breakdown — it is a slow degradation of coordination as the informal mechanisms that co-location provided disappear and are not replaced. Problems are not escalated because there is no established path. Decisions are not made because the authority is unclear. Information is not shared because there is no regular mechanism for sharing it. The team continues to function, but increasingly in silos, with compounding coordination failures that accumulate until they become visible crises.
The prevention requires proactive investment in explicit coordination infrastructure before the informal coordination has fully collapsed. Teams that wait until they feel the degradation are already behind. The coordination infrastructure should be built at the point of distribution, not in response to the failures that follow it.
Where Distributed Governance Has Real Costs
The redesigns are necessary, but presenting them as pure gain would be dishonest. Distributed governance trades one set of costs for another, and the trade is not free.
The most immediate cost is speed at the small scale. A co-located team can resolve a minor decision in the time it takes to turn a chair around. The asynchronous protocol that protects the major decisions imposes overhead on the minor ones, and if applied indiscriminately it can make a distributed team slower than its co-located equivalent for exactly the routine coordination that used to be frictionless. The discipline is to scope the formality: documented protocols for decisions where a misread is expensive, lightweight async channels for decisions where it is not. A team that documents everything pays the documentation tax on work that never needed it.
The second cost is the maintenance burden of the artifacts themselves. A decision log, an authority map, and an escalation path are only useful if they are current, and currency requires ongoing effort that no single person owns by default. Distributed governance does not run itself once the structures exist; the structures decay without a named custodian, and a decayed authority map is worse than none, because people trust it and act on stale information. The honest accounting includes someone's recurring time to keep the artifacts alive.
The third cost is harder to price: documented authority and asynchronous protocols can reproduce the function of co-located governance, but not the relationship-building, the early read on someone struggling, the trust that accumulates from sharing space. Distributed teams that govern well still have to invest deliberately in the relational layer that co-location used to supply for free — a cost the governance artifacts do not capture but the team's health depends on.
What You Can Build This Week
You do not have to stand up the full apparatus to begin. The highest-return first artifact is almost always the decision log, because it is cheap to start and it immediately exposes whether your decisions have clear owners and clear reasoning. Open a single shared document. For the next two weeks, every significant decision gets one row: the decision, who made it, the date, the alternatives considered, and the rationale. Within those two weeks you will discover the gaps the log reveals — decisions with no identifiable owner, decisions whose rationale no one can reconstruct, decisions made twice because the first was never recorded. Each gap is a pointer to the next redesign you need.
The second move is to name, in writing, the owner for the three or four decision categories where ambiguity currently costs you the most. Not a full authority map — just the few categories where distributed team members are already uncertain who decides. Publish it where everyone can see it and revise it the first time someone flags that it is wrong. A short, accurate, contested-and-corrected authority list does more for a distributed team than a comprehensive one that no one trusts. Start where the ambiguity is biting, and let the structure grow from the failures it catches.
Governance at the Boundaries of Distribution
The governance challenge in distributed teams is most acute at the boundaries — the points where distributed teams interact with co-located leadership, where different geographic or timezone clusters must coordinate, and where new members are integrated into an organization whose informal culture they have no access to.
At these boundaries, the governance redesigns described above matter most. The asynchronous decision protocol must be able to reach across the boundary and produce decisions that are legible to all parties. The documented authority structure must be clear enough that boundary interactions do not produce authority ambiguity. The escalation path must function across the boundary without requiring real-time interaction.
Organizations that successfully govern distributed teams do not treat distribution as a concession to circumstance — a necessary evil managed by translating co-located governance into remote equivalents. They treat distribution as a different organizational form that requires a different governance architecture, designed from first principles for the conditions that distributed teams actually operate in.
That redesign is not optional. It is the work that makes distribution governable rather than merely possible.
Continue in this series
This piece is part of What Is Organizational Governance? A Systems Practitioner's Complete Guide, my systematic guide to organizational governance and operating systems. Related reading:
- Meeting Governance: When Meetings Are the Symptom
- The Meeting Audit: How to Recover Execution Bandwidth
- Operating Distributed Teams Across Philippine Time and Geography
- Decision Velocity in Distributed Operations Without Becoming the Bottleneck
Working through this in your own organization? I help technical leaders design it directly — advisory engagements.
