Most meetings aren’t bad because people are lazy or inconsiderate. They’re bad because the person who called them didn’t think carefully about what they actually needed. A meeting and a document are both tools for moving information between people, but they have completely different cost profiles and completely different strengths. Using the wrong one isn’t just inefficient, it’s a form of disrespect toward everyone’s time, including your own.
Here’s a practical framework for telling them apart.
1. You Have Information to Deliver, Not a Decision to Make
If your goal is to get people up to speed on something, a document is almost always better. Reading is faster than listening. A good written summary lets people process at their own pace, refer back to specific sections, and ask questions asynchronously. A 30-minute status meeting where one person talks and nine people listen is a document that hasn’t been written yet.
The test: could you fully accomplish your goal by sending an email or a shared doc and asking people to read it? If yes, do that instead.
2. You’re the Only One Who Will Be Talking
A meeting requires participation to justify its existence. If you’re planning to walk through slides for 45 minutes and then ask “any questions?”, you’ve scheduled a presentation, not a meeting. Presentations can be recorded or written up. The Q&A can happen in a comment thread.
The live format is valuable when ideas need to collide in real time, when someone’s reaction to one thing changes what someone else says next, when the conversation genuinely needs to branch based on what’s in the room. If the output is predetermined before anyone joins the call, you don’t need a call.
3. The Decision Can’t Actually Be Made Today
This one is sneaky. Someone schedules a “decision meeting” but the actual decision depends on information that isn’t ready, approval from someone who won’t be in the room, or a technical spike that hasn’t happened yet. The meeting proceeds anyway, and it becomes a discussion meeting, which becomes a “let’s follow up” meeting, which spawns two more meetings.
Before scheduling any decision-focused meeting, ask yourself: do we actually have what we need to decide this today? If the answer is no, write down the open questions, assign owners, and set a date when you’ll have answers. That’s a document, not a meeting.
4. You’re Summarizing Something That Already Exists in Writing
This pattern is common in engineering orgs: someone writes a design doc, then schedules a meeting to “walk everyone through it.” The result is that people who read the doc sit through a verbal summary of what they just read, and people who didn’t read the doc get a verbal summary that they won’t be able to reference later.
The better approach is to require async reading before any synchronous discussion. If a document exists, it should do the informing. The meeting, if one is needed at all, should start with “okay, you’ve read it, what are your concerns?” Amazon’s famous practice of starting meetings with a silent reading period is a workaround for a world where people don’t read ahead. The cleaner fix is to enforce the reading and skip the summary portion entirely.
5. Attendance Is Mandatory but Participation Is Theoretical
If you look at your invite list and more than a third of the people are there “to stay informed” rather than to contribute, your meeting has passengers. Passengers belong in a document thread. They can read the outcome, ask follow-up questions, and not spend an hour in a room watching other people work.
The instinct to include people broadly comes from a good place, usually a fear of someone feeling left out or blindsided. But the solution to that fear is better written communication, not wider meeting invites. A well-written decision record that goes out after a focused meeting serves the “staying informed” audience far better than their silent presence in a call would.
6. The Topic Is Complex and Asynchronous Pushback Matters
Here’s where meetings are actually worth it: when the subject is genuinely complex, when reasonable people might disagree, and when you need to see how people react to each other’s arguments in order to reach a good outcome. The key phrase is “react to each other.” Not react to a document, but react to a person reacting to a thing someone else said.
Architectural decisions in software often have this character. You’re not just collecting opinions, you’re watching whether the person who’s most confident has actually thought through the edge cases, and whether the quieter person in the room has a concern that undermines the whole proposal. That dynamic is genuinely hard to replicate in a comment thread. This is the meeting worth having.
7. You Need Emotional Alignment, Not Just Logical Agreement
Some things require you to be in a room together (or at least on a live call) because the human element matters. Giving someone difficult feedback. Working through a conflict between two teams. Building trust with a new colleague or client. These aren’t information-transfer problems, they’re relationship problems, and documents are terrible at solving them.
The failure mode here is the opposite of the usual one: people try to handle difficult interpersonal situations over email because the async medium feels safer, and then the tone gets misread, the subtext gets amplified, and a solvable problem becomes an entrenched one. Some conversations need to be conversations. The skill is knowing which ones.
The underlying principle, if you want to compress this into something you can apply quickly: a meeting is the right tool when you need real-time, bidirectional, human-reactive communication and nothing else will do. Everything else is a document. The fact that a meeting is easier to schedule than a document is to write is not a good reason to hold a meeting. It’s actually an argument for getting better at writing.
