The meeting that should have been a doc (and the doc that should have been a meeting)

"This meeting could have been an email" became a joke because it describes something everyone has experienced: sitting in a meeting that exists to transfer information in one direction, where the audience passively absorbs what one person is saying, and where no discussion, debate, or decision actually happens.

The joke persists because the problem persists. Meetings multiply with team size, the majority of them are informational rather than interactive, and nobody has a systematic framework for deciding which coordination activities need synchronous time and which don't.

Here's one.

The test

For each recurring meeting on your calendar, ask one question: is this meeting primarily about transferring information, or is it primarily about generating something new through interaction?

If the meeting is primarily transferring information in one direction (one person or team sharing status, context, decisions, or updates with others who are mostly listening), it should be a document. A self-writing wiki that captures status from GitHub and Slack, a decision record that documents the reasoning behind a choice, a project update that's written rather than presented. The information reaches a wider audience (everyone, not just attendees), persists longer (searchable, not forgotten), and costs less time (reading is faster than attending).

If the meeting is primarily generating something new through interaction (brainstorming, creative problem-solving, resolving conflict, making a decision that requires real-time debate, building relationships), it should stay a meeting. These activities require the back-and-forth, the nonverbal cues, the momentum of real-time exchange. A document can't replicate them.

Applying the framework

Standups → doc. The standard standup (what I did yesterday, what I'm doing today, any blockers) is information transfer. Each person shares status. Nobody discusses it in depth. The information is better served by a status doc that's visible to everyone and updated continuously from project activity.

Sprint review → doc. A presentation of what was shipped and why. The audience asks occasional clarifying questions but mostly listens. A change log generated from merged PRs provides the same information with less time investment.

Architecture discussion → meeting. Multiple people debating trade-offs, evaluating options, and reaching a decision that requires understanding each other's constraints and reasoning. This requires synchronous interaction. But the decision should be documented immediately after so it doesn't need a future meeting to reconstruct.

All-hands update → doc + optional Q&A. The update itself (company progress, strategy, announcements) is information transfer and can be written. The Q&A, if it addresses sensitive or complex topics, benefits from synchronous interaction. Split them: written update for the information, shorter live session for the questions that require discussion.

Onboarding walkthrough → doc + pairing. The factual content (system architecture, team conventions, tooling setup) is information transfer and should be documented. The relationship-building and judgment-based guidance benefit from synchronous time with a mentor. Separate the two so the mentor's time is spent on what only a human can provide.

Retrospective → meeting. Reflecting on what worked and what didn't requires honest, real-time discussion. The meeting should happen. The actions and insights from the retro should be captured in the docs so they're available for the next retro.

Cross-team sync → conditional. If the sync exists to share status across teams, it's a doc. If it exists to negotiate priorities, resolve dependencies, or plan collaborative work, it's a meeting. Many cross-team syncs are labelled as the second type but function as the first.

The doc that should have been a meeting

The framework works in both directions. Some things that are currently handled in documents or async channels would be better handled synchronously.

Conflict resolution. Disagreements that play out in Slack threads tend to escalate rather than resolve, because written communication lacks the nuance, tone, and real-time adaptation that help people find common ground. If a discussion has gone back and forth more than three or four times without resolution, move it to a synchronous conversation.

Sensitive feedback. Giving substantive feedback on someone's work or performance is better done face-to-face (or over video) because the recipient can ask questions, you can read their reaction, and the interaction can be adjusted in real time.

Complex decisions with high stakes. When the decision has significant consequences and the participants hold substantively different views, real-time discussion produces better outcomes than async comment threads, because the back-and-forth helps people understand each other's reasoning in a way that sequential written responses often don't.

Relationship building. You can't build trust through documents. Synchronous time, whether formal (one-on-ones, team events) or informal (coffee chats, social calls), is essential for the human dimension of work that no amount of documentation can replace.

Making it stick

The framework only produces lasting change if the documentation infrastructure supports it. Replacing a meeting with a doc only works if the doc is current, findable, and trusted. If the doc goes stale within weeks, people will reinstate the meeting because at least the meeting provides current information, even if it wastes time.

Self-writing documentation is the infrastructure that makes meeting-to-doc conversion sustainable, because the docs stay current without manual maintenance. The meeting doesn't come back because the document it replaced remains accurate and accessible.

Frequently asked questions

What if people don't read the docs? If the docs are current, searchable, and pushed to the right channels, adoption is typically high because reading is faster than attending. If adoption is low, check whether the docs are stale or hard to find, which are the two most common causes of non-adoption.

How do we handle the transition? Replace one meeting at a time rather than cancelling everything at once. Start with the most obviously informational meeting (usually the weekly status update), replace it with a document, and evaluate after two weeks. If the team has the same information with less time spent, replace the next one.

Won't we lose the social aspect of meetings? Separate the social function from the informational function. Schedule dedicated social time that serves the social purpose directly rather than using informational meetings as a proxy for it.

Related reading: How to reduce meetings, Why meetings multiply, The coordination tax, Work about work. Related pages: Self-writing docs, Decision log.