Location is not the variable. Asynchrony is.

Insights

Most failures blamed on remote work are structural problems that distance exposed rather than caused. This is an account of what genuinely changes when a team stops sharing a room: the arithmetic of review latency, the illusion that group chat is a system of record, the two-tier information flow that hybrid produces by default, and the onboarding debt that interruptions used to subsidise. Deliberately free of survey figures, because the ones you see quoted rarely survive contact with your own team.

Two teams can both be "fully remote" and have almost nothing in common. One sits inside a two-hour band and can get everyone onto a call before lunch. The other spans ten hours, so a question asked in the afternoon is answered tomorrow. Managing those is not the same job, and advice that treats "remote" as a single category is wrong before it starts.

What distance actually changes is the price of three things: an unplanned question, a decision that needs more than one person, and the half-life of context inside someone's head. In an office all three are cheap, which is why co-located teams get away with leaving so much implicit.

So choose where you want to sit on the axis from mostly-synchronous to mostly-asynchronous, and commit to it. Teams that drift end up with the worst of both: the meeting load of a synchronous team and the latency of an asynchronous one.

The unit of remote cost is the round trip. Take a change that needs three review cycles before it lands. In one room you catch the reviewer's eye and all three happen in an afternoon. Between two people with no shared working hours, each cycle costs at least a calendar day, often two, because the reviewer replies in their morning and the author reads it in theirs. No amount of effort or commitment changes that arithmetic. You either reduce the number of round trips or you accept the wait.

Reducing round trips is a design problem. Agree the approach before the code exists, in a short written note with a named person who says yes to it, so that review stops being the place where architecture gets argued. Keep changes small enough to review in one pass. Assign a specific reviewer with a specific deadline rather than posting into a channel and hoping; a duty with no name attached belongs to nobody.

Spend your overlap hours on the work that genuinely needs them: contested decisions, ambiguous designs, anything with feelings in it, and pairing on the part of a task where the question rate is highest. A status round-robin is the worst available use of the only hours you share.

If two groups must negotiate constantly and share no hours at all, no process fixes it, because the problem is the boundary. Give each location a slice it can own end to end, operational consequences included, and the handoffs shrink because the dependency does.

Group chat behaves like organisational memory and is poor at being one. There is no canonical version of anything, search rewards whoever remembers the exact wording, and the reasoning behind a decision sits in a thread only the participants can reconstruct. The symptom is a question re-litigated every few months with nobody able to say why the current answer is the answer.

The fix is unglamorous: a small number of durable artefacts, each with an owner and a findable home. A design note per significant decision, including the options you rejected and why. Pull request descriptions that explain intent instead of restating the diff. A runbook per operational surface. State in the issue tracker rather than in conversation. The test is whether somebody who was not in the room can reconstruct the decision a year later.

Make it a rule that a decision is not a decision until it is written where a stranger would look for it. Recordings do not count. Nobody watches fifty minutes of video to find one sentence, and everyone knows it.

A hiring consequence follows. If writing is load-bearing, interview for it. A short written design exercise at least exercises the skill a distributed team depends on daily, which a whiteboard session does not.

The hardest configuration is not all-remote. It is most-of-the-team-in-the-office with a few people outside it. That arrangement produces two tiers of information: decisions get taken in the room and summarised outward afterwards, so the people outside are structurally a step behind. Proximity bias does the rest, because interesting work tends to go to whoever was standing nearby when it came up.

This is a mechanism, not a failure of intent. Information flows through the cheapest available channel. If the cheapest channel is a corridor, that is where it will flow, whatever your values page says.

There are two coherent answers. Be genuinely remote-first, which means co-located people also take meetings from their own laptops and put decisions into the shared written channel, so no room is privileged. Or be honestly office-centred and say so, so that remote staff can decide whether they accept the deal. The incoherent middle, where the policy claims parity and the practice does not deliver it, is where resentment grows and good people leave quietly.

In an office, new engineers absorb a great deal through proximity and interruption. Remove that and you find out how much of your system existed only as oral tradition.

Here is the test. Can a competent new hire get a working environment and land a small, real change without a synchronous session with the one person who knows the trick? If not, you do not have a remote onboarding problem. You have documentation debt that interruptions were quietly subsidising.

What helps is concrete: an executable setup path that fails loudly, rather than a wiki page of fourteen steps that rotted two releases ago; a first task chosen because it is small and touches a real code path; a named buddy whose explicit job is to be interrupted, so the new person is not guessing whose time they are allowed to take; and the architecture tour written once, as prose, by somebody who can write. Treat the reading as work, because it is.

Activity monitoring, hours logged, green dots, commit counts. Two problems. They measure the wrong thing, and they are trivially gameable, so what you get is the signal rather than the work. The second problem is the worse one: that tooling tells a competent adult you assume they are stealing from you, and the people most insulted by it are usually those you can least afford to lose.

Better questions need no surveillance. Is work moving into somebody else's hands, or accumulating in a nearly-done state? How long do items sit blocked, and who unblocks them? When something shipped, did it hold up? Is any one person the only route to a particular decision?

The most useful measure is blocked time, and it is the easiest one to leave untracked, because no tool produces it by default — it has to be recorded deliberately. Make it a first-class field on the work, ask about it in a way that makes admitting it safe, and act on what you hear. A team where saying "I have been stuck since Tuesday" feels like a confession will hide precisely the information you need.

The same blindness applies to people. In a room you notice when somebody has gone quiet or started grinding. At a distance, difficulty is silent right up to the resignation. One-to-ones actually held, rather than repeatedly bumped for delivery pressure, are the cheapest instrument available, and specific questions get further than opening with "how's it going".

Ambiguity is more expensive at a distance. In an office people infer norms by watching each other. Remotely they invent norms privately, then resent colleagues for breaking rules that were never stated. A handful of decisions are worth making explicitly, even where your answer is unfashionable.

None of these need to be generous in order to work. They need to be true, and stable enough that people can plan around them.

If you do only a few things, do these. Pick your point on the synchronous-to-asynchronous axis deliberately, and say out loud what it is. Write down the three questions people keep re-asking. Make review a named duty with a deadline, and shrink the changes that pass through it. Track blocked time, and treat a long block as your failure rather than the engineer's. Then hand your onboarding to the next new starter and watch, without helping, where they get stuck; that list is your real backlog. The uncomfortable part is that almost none of this is about remote work. It is ordinary engineering management done somewhere you cannot lean on proximity to cover the gaps. If a practice only worked because everyone was in the room, it was not working. It was being subsidised, and now you can see the bill.

Talk to us about this