Meeting hygiene for remote engineering teams

Remote teams schedule more meetings than colocated ones. It’s not because they’re less productive. It’s because the default coordination cost of a quick tap on the shoulder doesn’t exist, so the meeting invite becomes the shoulder tap. The result is a calendar that fills with 30-minute syncs that could have been a Slack thread, and an engineering team that spends more time talking about work than doing it.

Meeting hygiene isn’t about abolishing meetings. It’s about making each one justify the collective time it costs. A 30-minute meeting with eight engineers costs four person-hours. You’d notice if someone spent four hours on a feature that got thrown away. Apply the same scrutiny to the meeting itself.

When a meeting should actually happen

Most meetings happen because someone felt uncertain. A PM isn’t sure if the timeline is realistic. An engineer isn’t sure who owns the failing integration test. A designer isn’t sure if the component they mocked up handles the edge case someone mentioned in Slack. These are all real coordination needs. The mistake is defaulting to a meeting as the first tool for resolving them.

A meeting is the right tool when three conditions are true. First, the decision requires real-time back-and-forth: you can’t type out positions and converge on an answer asynchronously because each response changes the shape of the next question. Second, the group is small enough that everyone in the room can contribute: more than six people and at least two are just watching. Third, the outcome is a decision, not a status update. If the meeting ends with “we’ll circle back on this,” it should have been a doc, not a meeting.

Here is a practical test. Before sending a calendar invite, write down the decision you expect the meeting to produce. If you can’t name it, you don’t have a meeting. You have a discussion that belongs in a doc or a thread. If you can name it but you could also get to it with two async rounds of comments on a short doc, write the doc.

How to run a meeting that ends on time

Once you’ve decided a meeting is necessary, the structure determines whether it costs 30 minutes or 60. Here is what works across remote engineering teams at the 10-to-100-person scale.

Send the agenda ahead, and make it specific. “Discuss the caching layer” is not an agenda. “Decide: do we use Redis or a CDN edge cache for the user preferences endpoint? Options doc linked. Expected outcome: pick one approach and name an owner for the spike” is an agenda. The second version tells people whether they need to be in the room and what preparation is required. People who show up without reading the options doc can’t contribute meaningfully, and the meeting owner should feel comfortable tabling the decision until they do.

Default to 25 or 50 minutes, not 30 or 60. The five or ten minute buffer between meetings isn’t just politeness. It’s cognitive overhead recovery. When back-to-back meetings fill a calendar, engineers context-switch from a design discussion to a sprint planning session with zero gap, and the quality of the second meeting suffers because everyone is still mentally in the first. Hard-stop the meeting at 25 or 50 minutes, and let the remaining minutes be breathing room.

Assign a note-taker who is not the meeting owner. The person running the meeting should be focused on the conversation, not on transcribing it. The note-taker captures decisions and action items, not a transcript. At the end of the meeting, read the decisions and action items aloud. If the action item doesn’t have a specific owner and a “by when,” it’s not an action item. It’s a hope.

Share the notes in the same channel where the meeting was coordinated. If the invite went out in the project’s Slack channel, the notes go there too, within ten minutes of the meeting ending. Notes that live only in a meeting-specific doc that nobody subscribes to are effectively lost. A three-line summary with decisions and owners in the channel where people already read is vastly more likely to be acted on than a formatted page nobody opens.

Killing the meeting that should have been a doc

The hardest hygiene practice is also the most important: canceling meetings that aren’t earning their slot. This is hard because nobody wants to be the person who says “this meeting is wasteful” and risks looking like they’re not a team player. But a recurring 30-minute sync with ten attendees costs five person-hours per week. Over a quarter, that’s roughly 65 hours. That’s two solid weeks of engineering time burned on a meeting nobody will say out loud is unnecessary.

The lightweight way to audit: every quarter, list every recurring meeting your team attends, count the attendees, and ask two questions in a poll. “Does this meeting still need to exist?” and “Could the same outcome be reached with a doc and an async comment thread?” If more than a third of attendees say they’d rather have the time back or that async would work, kill the meeting. Replace it with a shared doc where updates go, and watch whether anything breaks. In most cases, nothing does.

One-on-ones are the exception to most meeting-killing advice because they serve a purpose that doesn’t fit a doc: building a relationship, surfacing problems before they become crises, and giving someone uninterrupted access to their manager’s attention. Don’t cancel one-on-ones unless the direct report explicitly prefers async check-ins. The cost of a missed signal is higher than the cost of 30 minutes.

Remote meeting hygiene isn’t a one-time cleanup. It’s a habit of asking, before every invite, whether the meeting is the cheapest way to get to the outcome. Most of the time, it isn’t. A doc costs less. A thread costs less. The meeting is a tool for when the back-and-forth actually needs to happen in real time. Treat it that way, and your calendar stops being the bottleneck.