Good operations in a remote-first company is mostly invisible. You notice it by its absence. You’re not frantically Slacking someone in a different timezone asking if they’ve updated the shared document. You’re not in your fourth meeting of the day that could have been a five-minute async update. New starters aren’t spending their first month asking “where do I find the X” because everything is documented and findable. Information moves through the company without friction. Decisions get made without everyone needing to be online at the same time. Work happens.
Bad remote operations is very visible. It’s aggressive and exhausting. It looks like Slack messages that require an instant response because nobody knows where else to find the information. It’s Slack as institutional knowledge — someone asks a question, someone else answers it in a channel, and three months later someone else asks the exact same question again because searching for the answer feels like a herculean task. It’s meetings scheduled at times that work for the headquarters timezone and absolutely don’t work for anyone else. It’s new people who start on a Monday and spend a week trying to figure out how things actually work because there’s no documentation, only oral history passed down by long-standing employees. It’s decisions that get made in hallway conversations or quick calls between people in the same office, and the rest of the company finds out later, if at all.
The difference between these two scenarios isn’t luck. It’s operational infrastructure.
The first building block is async-first communication. This means defaulting to writing things down and giving people time to read and respond, rather than defaulting to synchronous communication — calls, meetings, real-time back-and-forths. It doesn’t mean never meeting or calling. It means meetings are the exception, not the default, and they’re scheduled because they add real value, not because it’s faster than writing an email.
Async-first communication requires discipline. It’s actually slower to sit down and write a clear email than to ping someone in Slack and wait for them to respond. But it scales. When you’ve got people across multiple timezones, async communication is the only way distributed teams actually function without everyone either working nights or missing important decisions.
The second building block is documentation as a cultural habit. Not a project. Not a “we need to document things” initiative that happens once and then stops. A cultural expectation that if you know how to do something, you write it down for the next person. If you make a decision, you document why. If you’ve discovered something useful, you share it. This sounds simple and it’s genuinely difficult because it requires you to pay a small cost — the time it takes to document — to prevent a larger cost later when someone else has to figure it out from scratch.
The companies that get this right usually have a cultural touchpoint around it. They celebrate good documentation. They reference “did you check the wiki” when someone asks a question. New people are trained to document as they learn, so documentation is always being refreshed by people who remember what it’s like not to know. There’s usually a person who cares about keeping the documentation system clean and navigable — not the person who knows everything, but the person who cares about accessibility.
The third building block is tooling decisions that match your actual team size and structure. You don’t need the same infrastructure at ten people that you need at fifty. You don’t need the same tools for a co-located team that you need for a distributed team. Bad companies pick tools because they’re trendy or because they’ve heard about them. Good companies pick tools because they solve a specific problem their team actually has. And they’re willing to throw them out and pick something else if the problem changes.
This means being thoughtful about where information lives. If you’ve got your documentation in five different places — the wiki, a Google Drive folder, a notion workspace, some internal blog, and someone’s personal notes — you’ve created a system where information is impossible to find. It doesn’t have to be fancy. It just has to be consistent. Slack is for conversations. Email is for async communication that needs to be kept. The documentation system is for things that need to be remembered. The project management tool is for tracking work. The CRM is for customer data. Everyone understands this. New people learn it on their first day.
Then there’s the invisible part. The operational work that holds distributed teams together without anyone noticing it’s happening.
Someone needs to care about onboarding new people. Not in a ceremonial way — not the welcome email and the laptop and the team lunch. In a real way. Someone needs to make sure they can access the systems they need. Someone needs to make sure they know who to ask for what. Someone needs to make sure the documentation is written in a way that actually helps them. Someone needs to check in with them during their first month and ask if things are making sense. Most of the time, this is not a dedicated role. It’s just someone who treats it like it matters.
Someone needs to care about meeting culture. To notice when you’re scheduling too many meetings. To push back on “let’s sync up” as the default response to every question. To make sure that when you do have meetings, they’re scheduled at a time that doesn’t require someone to join at midnight. This is a cultural thing, but it requires someone to actually enforce it — to cancel meetings that don’t need to happen, to encourage async alternatives, to model the behaviour.
Someone needs to care about communication norms. To notice when Slack is becoming the default for important information. To regularly share links to the documentation system. To ask “is this decision documented?” To gently push back on hallway conversations being allowed to stand. This sounds petty, but it’s not. It’s the difference between a company where information is available to everyone and a company where information is only available if you’re in the right social circle.
Someone needs to care about decision-making processes. To document how decisions get made, who gets to make them, and who needs to be consulted. To push back on decisions being made in closed meetings and then announced. To make sure that the people who will be affected by a decision have a chance to input on it. This is usually a leadership responsibility, but it requires an operational mindset to actually implement.
The reason remote operations falls apart is usually because people assume it will just happen naturally. They assume that if you hire good people and give them the tools, the culture will sort itself out. But culture is actually built through operational decisions. It’s built through the communication norms you enforce, the documentation you require, the meeting culture you model, the transparency you enforce around decision-making.
Good remote operations looks boring. It looks like things just working. It looks like someone asking a question and finding the answer in the documentation. It looks like meetings that actually need to happen, scheduled at times that work for everyone. It looks like new people who get up to speed faster because they can actually find the information they need. It looks like decisions being made and communicated clearly so everyone understands what’s happening and why.
This doesn’t happen by accident. It happens because someone cares enough to build it, and then it has to be maintained. The maintenance is the harder part. When your company is small, you can get away with relying on oral history and people knowing each other and hallway conversations. When you scale, those systems collapse. You have to actually build infrastructure.
The companies that get this right usually started with someone who came from a remote-first company and understood what matters. Or they failed at it spectacularly once and learned. Either way, they know that remote operations isn’t something you figure out once. It’s something you have to keep paying attention to, keep iterating on, keep reinforcing.
Because the moment you stop paying attention, you’re back to Slack as your documentation system and meetings as your default communication mode, and the invisible operational work that was holding everything together slowly falls apart.