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 is more writing, not more meetings.
Meetings feel like communication, but they're not the solution. This insight distinguishes remote-native teams from those failing at remote. Let me defend it.
GitLab's all-remote handbook articulates the operating model I'll describe — they documented what most distributed companies learn through experience.
Why writing scales and meetings don't.
A meeting includes only attendees. A document includes everyone who reads it, now or later. Meetings have a per-attendee cost (time). Documents have near-zero marginal cost for additional readers. Meetings are real-time; miss it, lose it. Documents are async; read on your schedule.
Over a year, 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 time, fragment attention, and exclude absentees.
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, they see how much faster they can move with a doc. 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. Most team communication happens in public Slack channels, docs everyone can read, PRs visible to the team. DMs are for personal matters — feedback, sensitive 1:1s, scheduling. The norm: if it's about the work, do it openly.
Privacy concerns are mostly imaginary — engineers asking questions, sharing opinions, debugging together. Openness benefits are enormous: new hires can read history and understand decisions; 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, less than five to read.
Format matters less than consistency. Some teams use "yesterday / today / blockers." Some write a paragraph. Some use tools like Range, Status Hero, Geekbot. Pick one and stick with it for six months before changing.
The underrated benefit: when management wants to know what the team is doing, they read updates. They don't ask the team. They don't schedule a "check-in." They read. Zero interruption cost.
Decision documents. For meaningful technical or product decisions, 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 six-page-memo model and it works. The first meeting, people complain because they expected to "discuss" without preparation. By the third, 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 — capturing 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: creating these docs at kickoff and never updating them. A stale project doc is worse than none, because people act on outdated info. The discipline: update the project doc whenever a meaningful decision changes, after 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 to prevent fragmentation. 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. Discipline matters.
Code review as communication. PR reviews are high-quality communication artifacts in a remote team. They're focused (specific code), substantive (work is in the PR), durable (discussion lives forever). Investing in good PR review culture — thoughtful comments, real engagement, prompt turnaround — pays dividends beyond immediate code quality.
The norm: PRs reviewed within hours, not days. Reviewers comment on substance, not nitpicks (autoformatters handle nitpicks). Authors respond to feedback. The PR review is the meeting, in writing, where 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. Those conversations:
Brainstorming and creative generation. 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 output in a doc afterward.
Difficult interpersonal conversations. Conflict resolution, feedback that's hard to deliver in writing, tough 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. Big architectural calls, major product pivots, executive-level decisions. Participants benefit from being in the room — physical or virtual — because back-and-forth surfaces considerations 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 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 for 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 another's first instinct is "let's hop on a call," push back. Ask if the question genuinely needs voice or if typing the answer is uncomfortable. Usually, the typed answer 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 with subtext "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 a true 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 is mandatory. Synchronous meetings catch one or two time zones and exclude the rest. The team must operate with expected response time in hours, not minutes, resolving most conversations over a 24-hour cycle.
The benefit: 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 for genuinely real-time things.
This requires discipline about not expecting fast responses. If managers ping engineers off-hours expecting a response, the model breaks down. The team feels 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 isn't worse. It's different. Some prefer the in-office model. Some prefer remote-async. Companies trying both — 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.