Working across distributed teams: lessons that transfer

Most of the work I have done across my career has happened across time zones.

The people I coordinated with were rarely in the same room, often not in the same country, and occasionally not in the same week. A question asked in Juba in the morning might be answered by someone in Geneva that evening, reviewed by a colleague in New York the following morning, and acted on in Nairobi by the end of the cycle. The rhythm of the work was shaped not by any one schedule but by the handoffs between them.

Crypto-adjacent work is structured almost identically — just with different labels. Remote researchers. Distributed engineering teams. Protocol DAOs with contributors in a dozen jurisdictions. Operations support spread across continents. The surface looks different from humanitarian coordination. The underlying problem is the same.

A few things I learned doing that work, and which still matter now.

Written clarity is not a preference. It is infrastructure.

In a co-located team, a lot of coordination happens through casual conversation. You overhear context. You pick up a tone. You know who is stressed and who is not. You can ask a quick question without filing anything.

In a distributed team, none of that exists by default. If it is not written down, it did not happen — and often, it did not really exist in the first place. The team’s shared understanding of what is going on lives entirely inside the documents, messages, and notes produced by people writing on their own.

This means the quality of the writing determines the quality of the coordination. A badly written update is not just an aesthetic problem. It is a coordination failure with consequences that show up three weeks later when everyone discovers they had different assumptions.

The discipline that transferred most cleanly from humanitarian work into distributed environments is the habit of writing so that a reader in another time zone, with different context and no ability to ask a quick question, can still understand what you mean and what is being asked of them.

Decisions should be legible.

The fastest way to lose trust in a distributed team is to make decisions invisibly.

Co-located teams can absorb a certain amount of informal decision-making because the reasoning is usually available in fragments — a hallway conversation, a meeting someone attended, a slack thread that was still live when the choice was made. Distributed teams cannot absorb the same pattern. If a decision appears without a record of how it was reached, the team below it spends the next several days reconstructing the reasoning — usually badly, usually with some resentment.

A useful habit, in both humanitarian coordination and distributed crypto work: when a decision is made, write the decision and the reasoning in the same note. Not every decision. But any decision that changes direction, consumes resources, or binds other people’s work.

This sounds bureaucratic. It is actually the opposite. Legible decisions remove the need for endless follow-up conversations and let the team focus on execution.

Shared context is built on purpose, not assumed.

The failure mode of distributed work is the assumption that “we are all on the same page.” You almost never are. Different people are holding different pieces of the picture, and unless someone has deliberately stitched those pieces together in writing, the team is operating on the illusion of alignment rather than the fact of it.

A lot of distributed coordination work is, honestly, just this: building and maintaining the shared document that keeps everyone looking at the same picture. It is unglamorous. It is also the difference between teams that execute and teams that constantly rediscover the same confusion.

In crypto, this shows up especially in research and operations roles. The people who hold a team’s context together — who can write a one-page summary that leaves no ambiguity about what is being worked on, why, and what is next — are more valuable than they look from the outside.

Silence is information.

In distributed work, you cannot take silence at face value. If someone has not responded, it could mean they agree. It could also mean they disagree and have not said so. It could mean they missed the message entirely. It could mean they are blocked on something they have not yet admitted to being blocked on.

Assuming the most generous interpretation is usually correct interpersonally and usually wrong operationally. The discipline is to treat silence as a prompt to follow up, not as confirmation. In a good distributed team, this becomes a shared norm rather than a personal burden — the team as a whole treats ambiguity as something to be named quickly rather than absorbed quietly.

Operational discipline scales relationships.

The lesson that runs under all of the others is this: in a distributed environment, the quality of your operational discipline is the quality of your relationships over time.

People you write clearly for, make legible decisions with, build shared context around, and follow up with honestly — those people become your durable collaborators. They keep working with you across projects, across organisations, across years. The trust compounds because the work produced in each cycle is clean enough to be built on.

This is the real continuity between humanitarian coordination and crypto-adjacent work. The specific tools change. The specific subject matter changes. The discipline of working well with people you rarely see, in writing that respects their time and reality, is the same in both.

It is a skill worth taking seriously.

It transfers further than most people realise.