The Planning Meeting That Replaces Three Days of Unread Notion

The team is distributed across three time zones. The docs are in Notion. Decisions are supposed to be made asynchronously to respect everyone’s availability constraints.

The problem: the Q3 planning page has been in draft for three weeks. It has seventeen comments. No one has decided to launch capability A before capability B. The team is working on capability B because that’s what the developers chose while waiting for clarification that never came.

This isn’t a story about time zones or tools. It’s a story about confusing communication with decision-making.

Async Isn’t Suited for Everything

Asynchronous communication has valuable properties. It respects different rhythms. It allows time for reflection before responding. It creates a record. It works very well for transmitting information, sharing context, and gathering opinions.

It works poorly for making collective decisions on complex topics with multiple dependencies.

Here’s why: a complex decision often involves resolving several questions in rapid sequence. “Do we do A before B? That depends on whether C is already done. But if C is done, we can do A and B in parallel, unless the front-end team isn’t available. In that case, B first. But B depends on a design decision no one has made yet.”

This conversation, in async, produces comment threads that stretch over several days without resolution. Each response requires full re-contextualization. Intermediate decisions don’t get made because no one knows if the next reply will change the conditions.

The same conversation, synchronously, takes twenty minutes.

What a Good Planning Meeting Produces

A well-run planning meeting produces one thing: decisions.

Not meeting notes. Not lists of questions. Not “to be discussed with the team.” Decisions. Clear trade-offs on what’s in scope and what isn’t. Clear ownership of who does what. Dependencies identified and sequenced.

Once those decisions are made in the meeting, they can be documented asynchronously. Notion regains its value: it’s where you record what was decided, not where you try to decide.

The distinction is fundamental. Notion is excellent for documenting. It’s poor for deciding.

What Makes a Planning Meeting Work

Not all planning meetings are useful. Many are Scrum theater applied to planning: the form is respected, the substance is absent.

What makes a planning meeting effective:

A defined output objective set in advance. Not “we’ll discuss Q3.” “We leave this meeting with the Q3 capabilities list prioritized, dependencies identified, and an owner assigned for each capability.”

The difference between these two formulations is the difference between a meeting that ends with “thanks, we’ll talk again” and one that ends with “done, it’s settled - who’s writing up the decisions?”

Participants who have the authority to decide. A planning meeting with people who need to “check with their manager” or “confirm with the team” before committing produces no decisions. It produces a list of additional questions.

Each participant must have the authority to sign off on what falls within their scope. If that’s not the case, the right people aren’t in the room.

A pre-filtered backlog. Arriving at a planning meeting with an unprocessed backlog and trying to prioritize everything in real time is inefficient. The pre-filtering work - identifying candidates for the cycle, eliminating redundancies, grouping related items - must be done before the meeting, asynchronously.

The meeting handles ambiguous cases and trade-offs. Async handles preliminary triage.

A time limit that’s held. A planning meeting without a time limit drifts. Two hours to plan a quarter is achievable if the backlog is prepared. Four hours reveals a problem of preparation or authority.

The Geographic Distribution Question

The most common argument against synchronous meetings is geographic distribution. If the team spans Paris, Montreal, and Sydney, there’s no mutually acceptable window.

That’s true. But it calls for a different response than “we do everything async.” It calls for reflection on team structure.

A team where planning decisions require people across three time zones twelve hours apart likely has a more fundamental structural problem: too much coupling between sub-teams that should be more autonomous.

In truly distributed teams that function well, there are generally one of two solutions: either planning decisions are made at the local team level with a clear interface to other teams, or there’s an acceptable (even imperfect) synchronization window reserved for important decisions.

Saying “we do everything async” is often a way of avoiding the real problem.

The Async Documentation Paradox

Here’s a common paradox in tech teams: the more a team documents asynchronously, the less the documentation gets read.

When everything flows through Notion and Slack, everyone is overwhelmed with notifications and updates. The Q3 planning page is just one of the twenty pages that changed this week. It will be read partially, commented on without re-reading prior comments, or simply not read at all.

The planning meeting creates a point of synchronization. Everyone is in the same room (or the same call) at the same time. Information flows at once. Questions are asked and answered immediately. The document produced after the meeting isn’t a spec to decipher: it’s a record of decisions everyone heard.

That document gets read. Because there’s a shared context that makes people want to check what was decided.

Planning Without a Meeting: When It Actually Works

There are contexts where async planning genuinely works.

Very small teams with strong alignment. Two people who know each other well, share the same objectives, and have fluid communication can plan asynchronously because implicit decisions are already shared.

Low-impact decisions. Choosing the order of two equally prioritized tickets doesn’t require a meeting. Writing “I’ll start with X, does that work for you?” in Slack is sufficient.

Teams with a clear decision culture. When roles are defined and everyone can make decisions within their own scope without collective validation, async works because there are fewer collective decision points.

In these contexts, forcing a meeting would be counterproductive. The problem is when async is applied by default to situations that don’t meet these conditions.

What the Planning Meeting Reveals

One final effect of the synchronous planning meeting: it surfaces disagreements.

In async, disagreement can remain latent. Everyone continues on their own, convinced their reading of the plan is correct. The divergence only surfaces at the review meeting when it’s too late to change course easily.

Synchronously, disagreement surfaces immediately. That moment can be uncomfortable. It’s also productive: it’s the moment when two different visions of the same work meet, challenge each other, and arrive at a shared resolution.

The planning meeting is a detector for latent disagreements. That may be exactly why some teams avoid it.

Async is a powerful tool. So is the planning meeting. The mistake is treating async as an ideology rather than one option among many.

One hour of synchronization at the right moment produces more value than three weeks of Notion comments. The key is knowing when to use which.