In the spring of 2022, a product team at a mid-size SaaS company was three sprints behind on a feature their largest customer was waiting for. The engineers weren’t blocked on code. The design was done. The spec was signed off. What was blocking them was a one-hour “alignment sync” that recurred every Tuesday and Thursday, had nine attendees, produced no decisions, and had been running unchanged since the previous fiscal year.

Nobody had scheduled it recently. Nobody could remember who originally did. It just existed, like a load-bearing wall nobody wanted to touch.

The Setup

The company had grown from twelve people to about sixty over two years. In the early days, the all-hands-style check-in made sense. Everyone needed to know what everyone else was doing. Context was sparse, stakes were high, and the conversation was genuinely useful.

By the time the team had scaled, the meeting had calcified. The original attendees had mostly moved on. Their replacements inherited calendar invites the same way they inherited Slack channels and Jira boards: without context, without questioning, and with the implicit assumption that if it was already there, someone must need it.

The Tuesday and Thursday sync wasn’t just two hours a week. For the three engineers on the team, it sat in the middle of the morning, the best focus window most developers have. By the time they context-switched back into the codebase, made meaningful progress, and then stopped again for lunch, they’d recovered maybe ninety minutes of real work out of a four-hour block. What task-switching actually does to your focus is a familiar story: the cost isn’t just the meeting, it’s the recovery time around it.

Multiplied across a team of three, running twice a week, the meeting was consuming something closer to fifteen hours of productive work per week than two.

What Happened

The team’s engineering manager finally surfaced this during a retrospective, not as an indictment of the meeting, but as a genuine question: what decisions has this meeting produced in the last month? She asked everyone to look at their notes.

The answer was zero. The sync had become a status recitation. Each person reported what they were working on. Nobody was surprised by anything they heard. The information was already visible in Jira, already summarized in a Friday async update, already accessible to anyone who wanted it.

She proposed a simple experiment: cancel the meeting for four weeks, replace it with a standing async update in Notion that each person would take ten minutes to write on Tuesday and Thursday mornings, and schedule a thirty-minute live call only when someone explicitly flagged a decision that required synchronous discussion.

The pushback was immediate. A VP worried that the team would lose visibility. A project manager was concerned that issues would fall through the cracks. One senior engineer admitted, candidly, that the meeting was the only time he reliably knew what the other engineers were doing.

That last concern was the honest one, and it pointed to a real problem: the async update system that was supposed to surface this information wasn’t working. People weren’t reading the Friday summaries. The Jira board wasn’t being maintained. The meeting had become a compensating mechanism for a broken information flow, not a valuable activity in its own right.

Diagram comparing a tangled meeting-centric information flow with a clean async information flow
The meeting wasn't creating alignment. It was masking a broken async system.

The manager agreed to address both problems. She rebuilt the async update format so it was scannable in two minutes (three bullet points: what shipped, what’s blocked, what’s next). She made Jira hygiene a sprint commitment, not an afterthought. And she cancelled the standing sync.

Why It Matters

The feature shipped in the next sprint. That’s the easy part of the story. The harder part is understanding why it took a retrospective to surface something that had been quietly draining the team for months.

The answer is that nobody owned the cost. The nine attendees each spent two hours a week in this meeting, but those hours were distributed across nine calendars, nine managers, nine budget lines. No single person felt the full weight of it. The team’s collective loss was invisible in any individual’s reporting.

This is how wasteful meetings survive. They don’t feel expensive to any one person because the cost is socialized. The engineer who loses a morning focus block doesn’t bill it to the meeting. She just ships less, and that slowness gets attributed to something else: complexity, scope creep, unclear requirements.

There’s also a status dimension that’s easy to underestimate. Recurring meetings with senior stakeholders can feel like visibility, like proof that your work matters. Cancelling one can feel like going dark. The VP’s concern about losing visibility wasn’t irrational. It was just pointing at the wrong solution.

What You Can Learn

This story isn’t really about one bad meeting. It’s about a pattern where meetings become the default infrastructure for information flow, and then nobody questions whether they’re the right infrastructure.

Here’s a practical way to run the same audit on your team.

First, pull every recurring meeting on your calendar and ask one question: what decision or output did this produce in the last four weeks? Not what information was shared. What decision was made, or what action was taken, that required the people in the room to be in the room at the same time? If the answer is nothing, that’s your candidate.

Second, separate the meeting from the underlying need. The Tuesday sync existed because people needed visibility into each other’s work. That need was real. The meeting was just a poor solution to it, one that had been grandfathered in from a smaller, less documented organization. Before you cancel anything, identify what the meeting is actually doing and find a better way to do it. Cancelling the sync without fixing the async information flow would have just moved the problem.

Third, run the experiment with explicit criteria. Don’t just cancel a meeting and hope for the best. Define what success looks like. The manager in this case said: after four weeks, we’ll check whether the async updates are being read, whether decision latency has increased, and whether anyone has flagged something that fell through the cracks. If those checks fail, the meeting comes back. That framing made the experiment feel safe, which made the VP say yes.

Finally, watch for compensating mechanisms. When a meeting disappears and the underlying need doesn’t get addressed, people compensate with something else: more Slack messages, longer emails, informal check-ins that aren’t on anyone’s calendar. If you see that pattern emerge, it’s a signal that you cancelled the meeting but didn’t solve the problem.

The deeper lesson from this team is that meetings don’t just consume time. The badly-designed ones consume focus, which is the thing that actually produces software. A two-hour meeting in the wrong place in the day isn’t two hours of lost productivity. It can be six, once you account for the context-switching on either side. The real problem with meetings isn’t that they happen, it’s that we accept the wrong ones without auditing what they actually cost.

The Tuesday and Thursday sync had been running for over a year before anyone asked that question. Your calendar probably has at least one meeting that hasn’t been questioned in just as long. Pull it up. Ask what decision it produced last month. You might find the same ghost sitting in the same chair.