# Which meetings should a team cancel? **too many meetings** are a sign to cancel meetings that repeat visible status, have no decision owner, include people who do not contribute, or produce outputs nobody uses. Audit recurring meetings by purpose, total participant cost, and actual result. Cancel one before redesigning another. Keep the meeting only when live interaction creates value that a written update or smaller conversation cannot. ## What are the clearest signs of meeting overload? The clearest sign is not complaints alone. Look for engineering work pushed into evenings, design done between calls, repeated agenda items, and decisions delayed because the right people were too busy attending unrelated sessions. Calendars may contain open fragments that appear available but are too short for difficult coding or analysis. Fragmentation is a delivery constraint. Another sign is passive attendance. If most participants could miss the meeting and read three sentences later, live attendance is probably serving visibility rather than collaboration. Managers sometimes invite broadly to appear transparent. Real transparency comes from accessible decisions and context, not requiring everyone to witness how the information was produced. - Cancel status meetings that repeat a trusted work system. - Cancel recurring meetings whose original project has ended. - Remove listeners who neither contribute nor need immediate context. - Combine sessions that make the same decision with different audiences. - Decline meetings without a purpose, owner, or expected output. ## How should a team audit recurring meetings? List every recurring meeting for a representative month. Record its purpose, owner, length, participants, expected output, and where that output is used. Calculate participant hours, but do not rank only by size. A short meeting at the center of every morning can damage focus more than one planned monthly review. Ask participants privately what they would lose if each meeting disappeared. Sample actual results. Read notes from the last three sessions and identify decisions, resolved risks, or changed actions. If no record exists, ask the owner what happened because of the meeting. Some valuable conversations leave light documentation, but a recurring event should still produce a recognizable effect. Habit is not evidence. ## What should replace cancelled meetings? Use the smallest method that preserves the need. Status can move to a written update. A decision can move to a short proposal with a deadline for comments and a call only for unresolved disagreement. Office hours can replace mandatory attendance when people need occasional access to a specialist. A recorded demonstration can serve people across time zones. Do not replace every meeting with an endless chat stream. Written communication needs an owner, structure, and closure too. State the question, deadline, decision maker, and final result. Otherwise engineers check messages constantly and lose the focus time the cancellation was meant to restore. Asynchronous work is a method, not an absence of design. ## How do you prepare a meeting review? Preparation should make the decision easier without scripting every word. The owner should state the purpose, the expected calendar decision, and the evidence participants need. Engineers should receive context early enough to think. A meeting invitation that only names too many meetings asks everyone to spend the opening minutes discovering why they are present. A short note with the question, current facts, and constraints gives the group a useful starting point. The owner should also decide who must attend. Invite people who hold relevant knowledge, will make the decision, or will perform the resulting work. Everyone else can read a summary. If a database migration affects one service, the engineer who owns that service matters more than a broad audience chosen for visibility. Smaller groups expose disagreement faster and leave fewer people waiting for a conversation that does not require them. ## What should happen during a meeting review? Begin with the purpose and the current question. Do not spend ten minutes reading material that participants could have reviewed before the meeting. Ask for missing facts, test assumptions, and make uncertainty visible. When an engineer says an estimate depends on an unknown integration, record the unknown and assign an investigation. Do not turn uncertainty into a confident number merely because the calendar demands one. The facilitator should protect useful participation. Invite people closest to the code before senior voices settle the answer. Stop side discussions that matter to only two people and give them a separate owner. When the group repeats a point, summarize the disagreement and ask what evidence would resolve it. Facilitation is not about equal speaking time. It is about getting the knowledge needed for a sound calendar decision. ## How do you finish a meeting review? End with explicit outcomes. Name decisions, owners, open questions, and the next review point. An action without one owner is a hope, and an action without a date is easy to forget. The summary should be short enough that an engineer returning from leave can understand what changed. Put it where the team already tracks work rather than creating another private document. A meeting can feel energetic and still produce no movement. Check that every commitment connects to the purpose. If the group discovered that no action is needed, record that decision too. Clear closure prevents the same debate from returning through chat, another meeting, and several 1 on 1 conversations. The aim is shared understanding that survives after participants close the call. ## How can a manager tell whether too many meetings helps? Judge the ritual by work outcomes, not by attendance or enthusiasm alone. Look for shorter decision delay, fewer repeated questions, clearer ownership, and less surprise during delivery. Ask engineers whether the event gives them context they could not get more cheaply. A ritual can receive friendly feedback while consuming the exact focus time the team needs to solve difficult technical problems. Review the cost as well as the benefit. Six engineers in a one hour meeting spend six hours of team capacity, plus the interruption around it. That cost can be worthwhile for a critical architecture decision or incident lesson. It is wasteful when the meeting only transfers status already visible in the tracker. Managers should make that comparison openly instead of treating recurring calendar space as free. ## What should change after the first month? Run the practice long enough to see ordinary conditions, then review it with the team. Ask what decision became easier, which part repeated existing information, who was missing, and who did not need to attend. Change one variable at a time, such as length, frequency, preparation, or attendance. That makes the result easier to interpret than replacing the entire routine after one frustrating week. Keep a small written agreement. State the purpose, participants, inputs, expected output, and cancellation rule. New engineers can then understand why the ritual exists instead of copying behavior without context. Revisit the agreement when the team, product, or system changes. A practice that helped five people working on one service may fail when fifteen people support several domains. ## How do you keep a meeting review humane? Respect attention and time zones. Do not make early morning or evening attendance the quiet price of being influential. Rotate unavoidable inconvenience, record decisions, and provide a real path for written input. Remote engineers should not have to interrupt more loudly to be heard. People need enough pause to think, especially when the topic includes conflict, failure, or a difficult commitment. Managers should watch power. A junior engineer may notice that a proposed cache will hide stale data but hesitate after a principal engineer supports it. Ask for concerns before announcing your own view. Thank people who reveal risk. The team learns what is safe from the manager's response in that moment, not from a value written on a slide. ## How should too many meetings adapt under pressure? Pressure is when the design of a ritual matters most. During a release, incident, or urgent customer request, teams often add meetings and abandon preparation. That reaction can create more noise when attention is already scarce. Keep the purpose clear, shorten the participant list, and increase the precision of decisions. If circumstances require a temporary daily check, give it an end date instead of letting emergency cadence become the new normal. After the pressure passes, inspect what happened. Ask which communication prevented delay, which interruption created confusion, and whether decisions reached the engineers who needed them. Include people who carried support and review work, not only visible project owners. Their experience often reveals hidden cost. Update the agreement while details are fresh, and remove temporary practices that no longer earn their place. ## Frequently asked questions ### Which meetings should be cancelled first? Start with recurring status meetings that repeat a tracker, meetings with no decisions or actions, and broad sessions where most people only listen. ### How do you calculate the cost of a meeting? Multiply meeting length by participant count, then consider preparation, context switching, time zone burden, and delay to focused work. ### What should replace a cancelled status meeting? Use a concise written update with progress, risk, decisions needed, and an owner. Create a smaller live discussion only when a decision requires it. ### How can a manager cancel a meeting safely? Explain the purpose that still matters, name the replacement path, cancel a trial period, and set a date to review whether any important need was missed. ### Should every meeting have an agenda? Every meeting should have a clear purpose and expected output. A short agenda helps when several questions or decisions must be covered. Related: [team rituals that help](https://isilta.com/blog/how-to-run-team-rituals-that-help/), [standup that is not status](https://isilta.com/blog/how-to-run-a-standup-that-is-not-status/), [protect team focus time](https://isilta.com/blog/how-to-protect-focus-time-on-a-team/).