Remote work needs better systems

Location is not an operating system

There is a test you can run on any team. Take the building away. Remove the shared floor, the open-plan desks, the hallway conversations, the informal nods across a room. Then see what survives.

If coordination collapses, you do not have an operating system. You have a location dependency.

This distinction matters more than most organisations want to admit. Physical proximity creates an ambient form of alignment. People absorb context from being near each other. They pick up on urgency through tone of voice. They self-correct through micro-signals that no software currently replicates. That is genuinely useful. The problem is when teams mistake that ambient alignment for something designed: when they treat physical co-location as a management strategy rather than a convenient substitute for one.

The teams discovering this right now, in February 2020, are not discovering it because of a crisis. They are discovering it because distributed work has been growing steadily as a mainstream practice, and the tooling expectations have grown with it. Slack, Notion, Zoom, Linear: these are increasingly standard in organisations that would have described themselves as office-first two years ago. What has not kept pace is the operating logic that makes those tools useful rather than merely present.

---

What coordination actually requires

Coordination is not about communication frequency. It is about shared context, clear ownership, and a common understanding of what done looks like.

In a co-located team, much of this runs on social infrastructure. You know who is blocked because they look frustrated. You know a decision has been made because you were in the room when it happened. You know who owns what because you remember who agreed to it last Thursday. None of this is documented. None of it is recoverable if the person holding it leaves the building.

When a team moves to distributed work, even partially, even for two or three days a week, that social infrastructure does not travel. What transfers is whatever is written down, shared, and findable. Which means distributed work does not create the problem of weak operating systems. It reveals it.

This is what makes the question interesting right now. Remote work is not a special condition requiring special tools. It is normal work conducted without the ambient scaffolding that usually compensates for absent systems. The teams struggling with remote are, in the main, the teams that were already struggling. They just did not know it because the building was covering for them.

The teams that are not struggling have a different characteristic. They have made their operating logic explicit. They know what gets decided where, who has authority over what, how work moves from initiated to complete. That logic lives in their software and their practices, not in their floor plan.

---

Software that carries coordination weight

There is a category error that affects how most organisations evaluate work software. They evaluate it on feature coverage, does it have tasks, does it have messaging, does it have document storage, rather than on whether it actually carries coordination weight.

Coordination weight is the capacity of software to hold shared context, surface the right information at the right moment, reduce the overhead of alignment, and make the state of work legible without anyone having to ask.

Most tools in the market do not carry coordination weight. They carry communication volume. Channels fill. Threads accumulate. Notifications compete. The software becomes a place where things are said rather than a surface where work gets done. This distinction matters enormously for distributed teams, because when communication is your only coordination mechanism, you eventually have too much of it and still do not have enough alignment.

What software needs to do, genuinely needs to do and not just market as doing, is make the state of work visible without requiring a human intermediary to synthesise it. Where are we on this? Who is next? What has changed since yesterday? What is blocked and why? These should be answerable by looking at the system, not by sending a message.

There is a useful distinction between tools that record activity and tools that make activity legible. Most collaboration software is in the first category. It captures messages, edits, notifications, timestamps. But capturing and surfacing are different operations. A tool that captures everything and surfaces nothing has added noise without adding clarity. The shift to distributed work exposes how much of the organisation's clarity was coming from people rather than systems, and puts pressure on the question of whether that is sustainable.

---

The pattern we keep encountering

Building Orbit in this period, the recurring pattern is not a lack of features. It is a lack of operating surface.

Orbit is being built as a system for commercial execution: taking a team from first contact with a potential client through to a launched product. That is not a simple workflow. It involves multiple people, multiple phases, external dependencies, timing pressures, and information that changes as you move through it. Running that kind of workflow on a patchwork of disconnected tools does not merely create inconvenience. It creates genuine operational brittleness.

The useful question is not whether your tools have the right feature list. It is whether your tools, used together, constitute a coherent operating surface: a place where work has a shape, where people can see where they are, where momentum is maintained without constant managerial intervention.

Most teams do not have that. What they have instead is a collection of products that cover different domains without integrating into anything coherent. Their CRM does not speak to their project management. Their project management does not speak to their documentation. Their documentation does not speak to their communication. Everything connects through people doing manual work to keep multiple systems in sync, and the friction of that manual work is a direct drag on the speed and quality of execution.

TUXX runs into this constantly in client work. Not because clients are unsophisticated, most are running reasonable modern toolchains, but because reasonable modern toolchains are not the same as coherent operating systems. A stack can be technically capable and still extract enormous coordination overhead.

---

The overhead tax

Distributed work makes the coordination overhead visible in a way that co-located work does not. When you are all in a building, you pay the overhead tax but you do not see it as overhead. It looks like conversation, like meetings, like standing up at your desk and asking a question. Harmless. Normal. Part of the rhythm.

When you are distributed, the same overhead is explicit. You send messages and wait for replies. You schedule calls for things that could not be resolved asynchronously. You ask questions whose answers are probably somewhere in a channel you would need to scroll back through. The overhead is not new, it was always there, but now it has timestamps and a visible queue, and it is harder to ignore.

This is one of the more clarifying functions of distributed work. It forces accounting. The teams willing to do that accounting tend to come out of distributed arrangements having genuinely improved their operating logic, not just their tolerance for video calls. They have built systems that reduce the overhead tax rather than simply learning to pay it faster.

The teams that resist that accounting tend to double down on presence as a proxy for performance. More check-ins. More status updates. More standups. They are attempting to recreate the ambient monitoring of co-location through scheduled communication, which is an expensive substitute. It generates the appearance of coordination while the underlying problem, work without a legible structure, goes unaddressed.

---

What asynchronous work actually demands

There is a version of the remote work conversation that treats it primarily as a scheduling problem. Flexible hours, time zones, overlap windows. These are real considerations, but they are downstream of a more fundamental question: does your team's work have enough structure to function without synchronous narration?

Synchronous communication, calls, standups, real-time messaging, is often doing two jobs at once. It is coordinating and it is also compensating for ambiguity. People get on calls not only to decide things but to understand what they are deciding about. They do standups not only to surface blockers but to remind each other what work even exists.

When a team moves toward asynchronous-first operation, those two jobs have to be separated. Coordination can happen asynchronously with reasonable tooling. Compensating for ambiguity cannot, or at least not cheaply. If people are unclear on scope, ownership, or priority, the asynchronous equivalent of a clarifying call is a long thread full of misalignment. It takes longer, generates more noise, and usually requires a synchronous conversation anyway to resolve.

The implication is that asynchronous work is not easier than synchronous work. It is harder, and it rewards teams that have invested in clarity in advance. Scope written down precisely. Ownership assigned explicitly. Priorities visible to everyone without asking. These are not niceties for remote teams. They are load-bearing requirements.

---

Proximity as a crutch

There is a version of this argument that sounds like an attack on co-location. It is not intended to be one. Physical proximity has real, irreplaceable value: particularly in creative work, in early-stage product discovery, in any domain where you benefit from fast iterative feedback between people who are doing complementary things.

The argument is narrower. It is that proximity, when used as a substitute for operating logic, creates fragility. Teams that are good because of where they sit are not good in any portable sense. Their capability is a property of the building, not of the people or the practices. That is not a resilient foundation.

Building on better foundations means designing for legibility even when you could get away with informality. It means writing things down not because the regulation requires it but because clear documentation is how shared context survives context switches: people leaving, people joining, a weekend, a holiday, a distraction. It means treating your operating logic as an asset worth maintaining, not a background condition you happen to have lucked into.

This is unglamorous work. It does not make for good press releases. But it is the kind of work that compounds. A team with clear operating logic in February 2020 is a team that will adapt more readily to whatever the rest of the year requires of them.

That should probably count for something.