How do you run a virtual meeting that is actually worth the time?

What actually makes a virtual meeting worth the time?

A virtual meeting is worth the time when it changes a decision, unblocks something specific, or shortens a back and forth that would otherwise take days in writing. That is roughly it. Everything else, the status round robin, the demo nobody asked for, the recurring sync that exists because it has always existed, can usually be replaced with a short written update and a place to comment.

The test we like is simple. Before you put a call on the calendar, write down the one question the meeting needs to answer. If you cannot phrase it as a question, you do not have a meeting, you have an announcement. Send the announcement. If you can phrase it as a question, ask yourself whether the people you want to invite could answer it faster by reading a short doc and replying in a thread. Usually the answer is yes. The meetings that survive that test, things like working through a tradeoff with two or three people who hold different opinions, or aligning on the shape of a project before anyone writes specs, tend to be the ones that earn their hour.

The clearest pattern we see in teams that use Breeze well is that their meeting calendars get thinner over time, not because they communicate less but because the project board and the comment threads on tasks already carry the status. The leads who run good virtual meetings treat the call as the place to make a call, and the project board as the place to track everything else. The same approach is laid out in detail in running a project without daily status meetings, which pairs naturally with this one.

When should this be a meeting and when should it be a message?

Most things that get scheduled as a call would land better as a written update with a comment thread underneath. The table below is the rough rule of thumb we use when someone is about to send an invite.

Why do most virtual meetings still feel like a waste?

Most virtual meetings fail for the same handful of reasons, and almost none of them are about the tool. Zoom, Meet, Teams, Around, it does not really matter. The friction is structural. There is no clear decision being made, too many people are in the room out of politeness, nobody owns the agenda, and the outcome lives only in the heads of the people who happened to attend.

Invite bloat is the biggest one. Microsoft's Work Trend Index has been showing for years that the majority of meeting time on knowledge workers' calendars goes to people who are not active contributors to the discussion. The instinct to add anyone who might want to know quietly turns a six person working session into a twelve person performance. The two people who actually need to decide spend the call performing for the other ten, and the ten sit through it because saying no to an invite still feels rude. The meeting goes longer, the discussion gets shallower, and the people who needed to argue something out end up scheduling a smaller call afterwards to actually decide.

The second failure mode is the meeting that has no written artifact. No agenda before, no notes during, no outcome after. GitLab's async meeting playbook is blunt about this: if it was not written down, it did not happen. A week later, the same conversation happens again because nobody can remember what was decided or, more often, whether anything was decided at all. This is where async tools earn their keep. If the discussion lives in writing, in a project board, in a task comment thread, in a doc that anyone can reread, the meeting becomes optional rather than load bearing.

The third is the recurring meeting that nobody is allowed to cancel. Standing weekly syncs accumulate like browser tabs. Each one had a reason once. None of them have been audited since. The honest fix is to delete them all and re-add only the ones the team actively misses after two weeks. Almost no one re-adds the status meeting. Harvard Business Review's piece on meeting madness is still the cleanest summary of why this audit usually pays for itself.

What changes when the default becomes async?

When teams shift the default from meet to write, two things happen quickly. The calendar opens up, which is the obvious one, and the quality of the remaining meetings goes up, which is the one people do not expect. The meetings that survive are the ones with a real reason, and those tend to be sharper because the people in them know why they are there.

The before state, in most teams we have seen, looks like this. Three to five recurring calls a week per person. A weekly all hands that is mostly one way. A standup that is performative. Project updates given verbally and then forgotten by Thursday. Decisions made in the call but never written down. Anyone who missed the meeting is now blocked or guessing.

The after state, once async updates take the load off the calendar, looks different. Project status lives on a board where each task has an owner, a state, and a thread. Updates are written, short, and skimmable. Decisions are posted as comments on the task or project they relate to, so the next person who picks up the work can see how the team got there. The meetings that remain are smaller, shorter, and almost always tied to a specific decision rather than a generic catch up. A team using Breeze in this mode mostly checks the project board in the morning and only opens video for the things that genuinely benefit from talking. If your team is still leaning on weekly recitals, the case for killing status meetings spells out exactly what to replace them with.

When is a virtual meeting actually the right call?

There are real cases where a virtual meeting is the right tool. The trick is recognising them and not stretching the category to cover everything else. Roughly, the meetings that earn their slot fall into three buckets.

Decisions with real disagreement

When two or three people hold different views and the back and forth in writing has stalled or is going in circles, a short call is faster and kinder than another round of long messages. Keep it small, keep it bounded, and write down the decision afterwards so the rest of the team does not have to ask what happened.

Trust building and hard conversations

1:1s with new teammates, feedback that is at all sensitive, performance conversations, anything involving conflict. None of these belong in writing first. A call, ideally with video, is the right format and async cannot replace it. This is also true for the conversations that build the relationships that make async work in the first place. If the team only ever interacts through written updates, the trust thins out and the writing eventually stops working too.

Genuinely open ended creative work

Some early stage thinking, especially the kind where the shape of the problem is still moving, is hard to do well in writing. A small group on a call with a shared whiteboard or doc, time boxed to an hour or less, is often the best format. The clue that you are in this bucket is that you cannot yet phrase the question precisely. If you can, write it down and run it async first.

When it is mostly a mismatch

Status updates, FYIs, anything that is one to many, anything where the same information has to be repeated to people who joined late, anything that ends with someone saying we should have just put this in a doc. These are the meetings to kill first. Replace them with a short written update on the project board, let people comment in their own time, and reclaim the hour.

How should you actually run the ones that survive?

For the meetings that pass the test, a small set of habits makes most of the difference. None of these are new and none of them are tool specific. They just get skipped under time pressure, which is exactly when they matter most.

Write the agenda as a question

The top line of the meeting doc should be the decision the group is there to make, phrased as a question. Under it, list the two or three things people need to read or think about before the call. If you cannot write the question, cancel the meeting. If you can, send the doc at least a few hours before so people show up having read it. The first ten minutes of silent reading at the top of the call is also fine and often faster than chasing people for prep.

Invite only the people who change the outcome

If someone does not need to speak and does not need to decide, they do not need to be on the call. They need the written outcome afterwards. Default to fewer people, not more. It is much easier to add a person to a follow up call than to claw back the hour you took from ten people who did not need to be there.

Set a hard end time and mean it

A 30 minute meeting that ends in 30 minutes is more respected than a 60 minute meeting that runs to 75. Pick the shorter slot, get to the question fast, and end early if you reach it. Parkinson's law applies to virtual meetings more than physical ones, because nobody has a next room to get to.

Post the outcome where the work lives

Within an hour of the call, post a short note in the place the work actually happens. For most teams that means a comment on the project or task in the project board, not an email and not a buried chat message. The note should say what was decided, who owns the next step, and by when. If you cannot write that, the meeting did not really finish. The companion piece on taking meeting notes covers a few formats that hold up well for async readers.

Quick questions to ask before sending the invite

Can I phrase the goal of this meeting as a single question?

If yes, you probably have a meeting. If no, you have an announcement and should send it as a written update instead.

Would the right people be able to answer this faster in a thread?

If yes, post the question with a deadline for replies and only escalate to a call if the thread stalls or splits into clearly different views.

What will I post afterwards, and where?

If you cannot picture the follow up note already, the meeting probably does not have a clear enough outcome to be worth scheduling.

Kill the recurring status meeting first

If you only change one thing this quarter, delete the recurring status meeting and replace it with written updates on the project board. The team will get the same information in less time, the people who joined late will not need a recap, and the meetings that remain will be the ones that actually need to happen.

A practical next step is to audit your own calendar for the next two weeks, mark each recurring call as decision, trust building, creative, or status, and cancel everything in the last bucket. Pair this audit with a tighter time management routine so the recovered hours actually become focused output, not more shallow chat. Run a written update in its place. Most teams find that nothing breaks, the week opens up, and the few meetings they kept feel sharper because they earned their slot.