Asynchronous work in practice: what works outside Silicon Valley

When it comes to asynchronous work, the conversation often stops at “fewer meetings.” As if the central point was the number of meetings on the calendar, and not the entire communication infrastructure that needs to change for the reduction to make sense. Teams that cut meetings without replacing what they were doing don't become asynchronous — they just become uninformed.

What asynchronous really means

Asynchronous work is a mode of operation in which communication does not require the sender and receiver to be available at the same time. The message is recorded, the context is accessible, and the response happens when the recipient can give quality attention — not when the notification arrives.

This model requires three things that most teams don't have: writing precise enough to obviate a debriefing, documentation that accumulates context over time, and decision-making processes that work without synchronous consensus. Without all three, asynchronous produces information gaps, stuck decisions and the feeling that no one knows what's going on.

Companies like GitLab document this obsessively. Its public handbook has thousands of pages describing how decisions are made, how projects communicate, how conflicts are resolved. It's not bureaucracy — it's infrastructure. It is the functional substitute for hallway conversations that in a face-to-face environment would carry this context invisibly.

What all-remote companies do differently

GitLab and Basecamp are often cited, but what they actually do is rarely described precisely. The list is more specific than it seems.

First, writing is treated as a core professional skill, not an administrative task. Hiring good writers is not a differentiator — it is a requirement. An engineer who cannot describe in writing what he implemented, why he made that decision and what the next steps are creates communication debt that is paid for with meetings.

Second, decisions have public and consultable records. When a decision is made, the context that led to it is documented in a place that anyone on the team can find months later. This eliminates an entire category of meeting: the meeting to explain what was decided earlier and why.

Third, work cycles have a clear beginning, middle and end, with status communication taking place in writing at the end of each period, not in a daily verbal update. The Daily Standup — that fifteen-minute meeting every morning — is, in asynchronous contexts, replaced by a three-paragraph written update that everyone reads when they have time.

Brazil's specific barriers

Transferring this model to Brazil without considering the cultural context is naive. Brazilian communication is what linguists call high-context: much of what is said depends on the previous relationship, the tone, the non-verbal. Trust is built through contact, not through documents. Ambiguity is tolerated in communication because the other person is expected to interpret it well.

This creates real friction with async, which requires the opposite: explicit writing, low ambiguity, self-contained context. An email that would work in an environment where the recipient already has the entire context in their head becomes a source of misunderstanding when the recipient is in a different time zone and read the message three hours later, with no memory of the conversation that preceded it.

There is also the dimension of relationships as a precondition of work. In Brazil, people collaborate better with those they know personally. This isn't cultural weakness — it's information about how to create the conditions for asynchronous to work. Brazilian teams that try to work asynchronously without having invested in relationship building report more conflict of interpretation, more feelings of exclusion and more distrust than those who made this investment first.

How to build infrastructure before cutting meetings

The sequence matters. Before reducing meetings, you need to have replacements working. This means creating a central place where projects are documented and updated. A decision recording system that anyone can consult. A written communication standard that defines what goes to which channel and with what expected response time.

Without this, reducing meetings creates a vacuum. And a communication vacuum is filled by rumor, assumption, and distrust — exactly the opposite of what asynchronous should produce.

One way to start that works in Brazilian contexts is the gradual transition by type of meeting. Status meetings become asynchronous documents first — this is the case with the least resistance because synchrony there clearly does not add value. Project alignment meetings come later, once the team has practiced writing context. Complex decisions stay synchronous for longer, until the group has enough confidence in the written process to forego the consensus meeting.

What cannot be asynchronous

There are cases where synchrony is genuinely necessary, and recognizing this avoids the dogmatism that sabotages many initiatives. Real interpersonal conflict is not resolved well in writing. Highly ambiguous decisions with many interdependent variables often require conversation. Moment of crisis, with the need for quick response and immediate coordination, calls for synchrony.

The problem isn't using meetings in these cases — it's using meetings in all cases. The mature model is not "zero meetings": it is "every meeting where synchrony is the best instrument available for that specific work". This distinction seems subtle, but operationalizing it completely changes the way the agenda is constructed and how collective time is allocated.