A pattern I see at almost every remote engineering org that's struggling: leadership responds to "we feel disconnected" by adding more meetings. More all-hands. More skip-levels. More standups. More 1:1s. More syncs. The calendar fills up, the team gets exhausted, the disconnection worsens, and management blames remote work.
It isn't remote work. It's more synchronous communication in the wrong direction. The fix for a disconnected remote team is almost always more writing, not more meetings.
This is counterintuitive — meetings feel like communication — but it's correct. It's the central insight that distinguishes remote-native teams from those doing remote badly. Let me defend it.
Why writing scales and meetings don't.
A meeting includes only its attendees. A document includes everyone who reads it, now or later. Meetings have a per-attendee cost (their time). Documents have nearly zero marginal cost for additional readers. Meetings are real-time; non-attendees miss the content. Documents are async; people read them on their schedule.
Stack these advantages over a year of operating a remote team and the math is overwhelming. Teams that default to writing build a searchable knowledge base, include people across time zones, and free up calendars. Teams that default to meetings burn calendar time, fragment attention, and exclude those who couldn't attend.
Writing is harder than talking. The first time you ask an engineer to write a one-pager instead of "hopping on a quick call," they resist. The second time, less so. By the fifth time, they see how much faster they can move when the doc exists. The discipline grows over months, not days.
The specific communication shape that works.
Here's what I converged on at Mayven across 17 countries. Other teams will have variants, but the principles transfer.
Default-public written communication. Almost all team communication happens in public Slack channels, in docs everyone can read, in PRs visible to the team. DMs are for personal things — feedback, sensitive 1:1 conversations, scheduling. The norm: if you're discussing the work, do it in the open.
The argument against this is privacy, but the privacy at stake is mostly imaginary — engineers asking questions, sharing opinions, debugging together. The benefit of openness is enormous: new hires can read the history and understand decision-making; people in adjacent areas stay informed without being meeting-tagged; institutional knowledge accumulates instead of evaporating with each off-boarding.
Asynchronous status updates. Every team writes a short update — daily or weekly — on what's shipped, in flight, or blocked. These replace team-status meetings. They take five to fifteen minutes to write and less than five to read.
The format matters less than consistency. Some teams use a "yesterday/today/blockers" format. Some write a paragraph. Some use tools like Range, Status Hero, or Geekbot. Pick something and stick with it for six months before changing.
The huge underrated benefit: when management wants to know what the team is doing, they read the updates. They don't ask the team. They don't schedule a "check-in." They read. The interruption cost is zero.
Decision documents. When a meaningful technical or product decision needs to happen, someone writes it up first. Context, options, recommendation. Shared in the relevant channel. Stakeholders comment async.
If comments resolve the question, no meeting happens. If they surface real disagreement or open questions, a short, focused meeting follows — with the doc as the agenda.
This is the Amazon model and it works. The first meeting where you do this, people complain because they expected to "discuss" without preparation. By the third meeting, they prefer it, because the meeting takes 20 minutes instead of 60 and produces an actual decision.
Project docs that stay alive. Every meaningful project has a living document — usually in Notion, Linear, or Confluence — that captures what it is, why it's being built, who's responsible, what's been decided, what's in flight, and the rollout plan. It's the single source of truth.
The trap is creating these docs at project kickoff and never updating them. A stale project doc is worse than no doc because people act on outdated information. The discipline: update the project doc whenever a meaningful decision changes, at the end of each meeting, when something ships. Make it part of the workflow.
Aggressive Slack channel discipline. Channels named after their purpose (#eng-payments, #eng-platform, #design-reviews), pinned topics, archived when projects end. Threads for sub-conversations so the main channel doesn't fragment. Reactions as lightweight acks so people don't type "thanks" every time.
Slack is the synchronous-feeling tool in the async stack. Used well, it accelerates communication. Used poorly, it becomes a fire hose that drowns the team. The discipline matters.
Code review as communication. PR reviews are high-quality communication artifacts in a remote team. They're focused (about specific code), substantive (the work is in the PR), durable (the discussion lives forever). Investing in good PR review culture — thoughtful comments, real engagement, prompt turnaround — pays dividends beyond immediate code quality.
The norm: PRs get reviewed within hours, not days. Reviewers comment thoughtfully on substance, not nitpicks (autoformatters handle nitpicks). Authors are responsive to feedback. The PR review is the meeting, in writing, where the substantive engineering conversation happens.
Where meetings still matter.
Some conversations don't work async, and forcing them async produces worse outcomes than just having the meeting. The shape of those conversations:
Brainstorming and creative generation. When a team is genuinely exploring possibilities, real-time interaction generates more and better ideas than async iteration. Plan brainstorming sessions deliberately, with structure (a prompt, a time box, divergent then convergent phases), and capture the output in a doc afterward.
Difficult interpersonal conversations. Conflict resolution, feedback that's hard to deliver in writing, hard performance conversations — these work better in person. Don't try to do them in Slack.
High-stakes decisions where principals need to wrestle with tradeoffs together. The big architectural call, the major product pivot, the executive-level decision. Participants benefit from being in the room — physical or virtual — because the back-and-forth surfaces considerations that async wouldn't.
Onboarding pairs. New hires benefit from time with a peer or manager to ramp up. Less than a meeting and more than a doc — pair programming, screen-sharing walkthroughs, working sessions.
Off-sites. Periodic in-person time for the whole team. Cadence varies by company — quarterly, semi-annually, annually. The off-site isn't where the work happens. It's where the relationships get built that make the rest of the year's async communication work. Hugely worth the cost.
For all of these meetings, the discipline still applies: written agenda, written outcome, default time under an hour, prep work done in advance.
Specific anti-patterns to kill.
Recurring "status" meetings. Daily standups in a remote team almost always devolve into status reports. Replace with async written updates.
"Quick syncs" that aren't quick. A 30-minute meeting to discuss something that could have been a 2-minute Slack message. The meeting is calendared because it feels safer than asking the question in writing. Train the team to write the question first.
The "we should hop on a call" reflex. When someone asks a question in writing and someone else's first instinct is to say "let's hop on a call," push back. Ask whether the question genuinely needs voice, or whether the person is just uncomfortable typing the answer. Usually, the answer typed in five minutes is fine.
Skip-levels that become surveillance. A skip-level with a clear purpose (career development, signal from the ground) is valuable. A skip-level whose subtext is "I'm checking up on your manager" is corrosive. The team will sense the difference within a quarter.
Camera-on culture as a proxy for engagement. Cameras on every meeting is exhausting and not actually a signal of engagement. Let people choose. Audio-on is enough most of the time.
Communication and time zones.
If your team spans more than six hours of time zones, asynchronous becomes mandatory, not optional. Synchronous meetings will catch one or two time zones and exclude the rest. The team has to learn to operate where the expected response time is hours, not minutes, and most conversations resolve over a 24-hour cycle.
The benefit is profound: a question asked at end-of-day in San Francisco is answered overnight by the team in Eastern Europe, and the asker wakes up with the answer ready. The team is literally producing 24 hours per day, with overlap times used for the genuinely real-time things.
This requires discipline about not expecting fast responses. If managers ping engineers in their off-hours and expect a response, the model breaks down. The team starts feeling always-on. Good remote leaders are religious about respecting offline time.
The cultural piece.
Remote communication, done well, produces a different culture than in-office communication. Less hallway-chat, more deep work. Less ambient awareness, more deliberate documentation. Less spontaneous, more thoughtful.
This is not worse. It's different. Some people prefer the in-office model. Some prefer the remote-async model. Companies that try to have both at once — hybrid without commitment — usually get neither.
Pick a side. Build the muscles. Communicate accordingly. Teams that do this well become unstoppable. Teams that don't will keep adding meetings and wondering why nothing improves.