When a remote team actually needs a meeting

The seventy minutes I spent refusing to call

A deploy went out late one afternoon and image uploads stopped working. Not everywhere, just for some users, which is the worst kind. Three of us picked it up in the incident thread: me, a backend developer and the person who looked after the servers. For the next seventy minutes we typed.

I posted a stack trace. The backend developer posted a theory about a changed config key. The ops person said the queue looked healthy and restarted a worker, at the exact moment I was reading that worker's logs, so my evidence vanished mid-scroll. Somebody asked "which users?" and three of us answered with three different partial lists. Every message was sensible. Together they were noise, because none of us had the same picture of the problem and the thread had no way of building one.

When we finally got on a call, one person shared a screen, we agreed on what we were looking at, and the cause (a storage permission that the deploy had reset for one bucket) took about ten minutes to find. I had resisted calling because I like to think of myself as someone who works async. That was the mistake. I had turned a preference into a rule, and the rule did not fit the situation.

So this is the other side of the argument for fewer meetings. Writing should be the default on a remote team. But a default is something you leave on purpose, and you need to know when.

I had turned a preference into a rule, and the rule did not fit the situation.

Why writing is the default at all

A meeting costs everyone the same hour at the same time. Writing costs each person some reading, spread across their own day, at a time that suits them. A meeting wins only when everyone's attention at once saves more than it burns.

That trade is easy to forget because meetings feel productive while they happen. People are talking, nodding, deciding. Async feels slow until you count it properly: six people each reading a one-page brief for five minutes is half an hour of attention, against three hours for the same six people sitting through a call where one person shares a screen.

The incident above flipped that maths. Three people were already giving the problem their full attention at the same time. We were paying the cost of a meeting and getting the results of a slow email chain.

Five questions, asked in order

I ask these in this order and stop at the first yes.

1. Is the decision cheap to reverse within a day?

Yes: async doc with a deadline. No meeting. Copy changes, feature flags, which ticket goes first next week, the name of a variable. If being wrong costs an afternoon, a call costs more than being wrong.

2. Does anyone need to hear tone to avoid an expensive misunderstanding?

Yes: a short live conversation, often voice only, with notes posted afterwards. Performance tension, an apology to a client after a bad release, two leads who keep talking past each other in text. Written words strip out the cues that let people repair a misunderstanding as it happens.

3. Is the problem new and high stakes, with no shared picture yet?

Yes: a timeboxed working session with a written agenda and someone taking notes. A first incident of its kind, a new architecture with safety constraints, a major scope cut in the middle of a release. This is the branch my upload outage belonged to.

4. Will this take more than three written rounds without getting closer?

Yes: meet, but only after a pre-read exists. If the disagreement is already in writing, the narrower checks in when async disagreement needs a live call give a better threshold than gut feeling.

5. Is someone blocked until a single choice is made?

Yes: an urgent call with the smallest group possible, and the decision written down before anyone hangs up.

If every answer is no, stay in writing. Most topics on most days end at question one.

Diagram

What to try before you book anything

These are the cheaper tools, roughly in order of how often I reach for them.

A structured doc with comments. One page: context, options, a recommendation, open questions, and a comment deadline. After the deadline, the owner decides in writing. Most "can we hop on a call?" requests turn out to be requests for this page.

A short screen recording. Walking through a prototype or a bug for five minutes often replaces a thirty-minute call, and the viewer can pause, rewind and watch it at 1.5 speed while their coffee brews.

A fifteen-minute pair on one narrow question. Two people, one outcome: approve this copy, pick this enum name, confirm these reproduction steps. Small enough that it does not need an agenda, specific enough that it ends.

Office hours. One optional slot a week where people can drop in, instead of a dozen ad hoc pings asking for "five minutes".

Status, handoffs, approvals on options that are already written down, and routine planning almost never need a live slot. An end-of-day status update does the job of a standup when the team spans time zones and the work is visible in tickets.

A scope argument that looked like a meeting problem

Here is a typical one. Product wants a feature cut in the middle of a sprint. Engineering says the cut invalidates work already merged. Design has assets half updated. Somebody books a ninety-minute "alignment" for nine people.

Before that invite goes out, try a one-page doc with five headings: what is shipped now (with links), the proposed cut in one paragraph, the impact as a list, options A, B and C with rough costs, and a "decision needed by" time in UTC. Give it a four-hour comment window inside overlap hours.

What usually happens is the decision lands in the comments as "option B, owned by the product lead, ship date moves to the 14th" and no call is needed. When the call does still happen, it is twenty minutes long, because the arguing already happened in writing where people had time to think rather than react.

If the doc fails because feelings are running high, that is question two, and a short live talk is right. Even then, the doc did its job: nobody spent the call discovering basic facts out loud.

Brainstorms do not need to start live

Live brainstorming favours fast talkers and people in the organiser's time zone. I have sat in enough of them to notice that the first two ideas spoken tend to frame everything after. Written brainstorming with a clear criterion, something like "pick one approach we can ship in two weeks", tends to produce a wider list and leaves a record of what was considered.

When an idea really does need people riffing off each other, timebox fifteen live minutes after the written ideas are listed. Start from the list, not a blank board. You spend the overlap on combining and choosing, rather than on quiet people waiting for a gap.

When a meeting earns the slot, keep it small

More than six people with a say in one call usually means no decision. More than eight and it is a broadcast. Cap most decision meetings at twenty-five minutes, and send the pre-read a full day ahead with:

1. The decision sentence at the top ("we choose X, or we slip Y").
2. Links to the actual work, not attachments.
3. Who must speak and who can read the notes later.
4. Who is writing the notes.
5. A hard stop, and the default if no decision is made.

If you cannot fill those five, the meeting is not ready. Delay it, or shrink its scope until you can.

Time zones change the cost again. Overlap hours are scarce, so spend them on questions two and three, not on readouts. A forty-five minute call for six people across four zones can easily cost six broken focus blocks plus four follow-up messages from people who lacked the context to decide. For spreading the inconvenient slots fairly, see timezone collaboration without chaos.

The table I pin in team wikis

When someone books a meeting, ask which row it belongs to. It is a surprisingly polite question, and it often ends with the invite being withdrawn by the person who sent it.

Recurring meetings need recurring reasons

Every recurring call should survive three questions once a quarter. Did the last three sessions change a decision or unblock work? Could the same outcome come from written status? Who pays the worst time zone cost, and is it the same person every time? If the answers are no, yes and yes, cancel it or rotate it. The full audit, with budgets and exit lines, is in running fewer and better remote meetings.

And after any meeting, put the decision where the work lives, within the hour. Who owns the next step, what was decided, what was explicitly not decided. A call without that residue creates folklore, and folklore books the next meeting. The bar is the same one I use for leaving work someone else can continue: could somebody who was not there act on it tomorrow?

Every hour on the calendar comes out of someone's working day, which is already shorter than it looks; planning eight hours into eight hours explains why. So spend meetings like money you earned, not like a way to feel like a team. But do spend them. The most expensive meeting I have been part of was the one I refused to call, while three people typed at a problem none of them could see whole.