Too Many Meetings at Work? It's Rarely the Meetings

I’ve noticed something across the teams I coach: when ad-hoc meetings pile up, work in progress tends to pile up with them. I wanted to know if that was a real pattern or something I was reading meaning into, so I went looking at what other people had observed and whether the reasoning held up. The more I sat with it, the more I think I had the causation backwards.

My first theory was that ad-hoc meetings were the problem. They open up new topics outside whatever structure a team already has, the kind most frameworks build in on purpose. Scrum, for instance, caps its formal events at roughly 4.5 hours over two weeks. Whatever framework a team runs, something similar tends to exist: a fixed amount of time set aside for discussion, and no more.

What I think is actually going on

The meetings are usually a symptom, not the cause. The root of it is a team taking on too much in the first place, without the discipline to ask what should stop to make room for it.

Here’s the sequence as I see it now. A team commits to more than it has said no to. When something new comes up, instead of asking what already-committed work needs to give way, the team adds the new thing on top. Work in progress climbs. The team’s structured time, built for a certain volume of work, stops being enough to hold all those open threads together. Ad-hoc meetings start filling the gap, pulling people out of focused work to coordinate items the formal events were never sized for. Those meetings cost focus, and focus is exactly what’s needed to finish what’s already in flight. Less of it finishes. More stays open. The cycle feeds itself.

This is also where a chicken-and-egg question I kept getting stuck on resolves itself. Does the ad-hoc meeting create the overload, or does the overload create the ad-hoc meeting? I now think it’s rarely the meeting. It’s almost always what a team quietly agreed to take on without agreeing what would step aside for it.

The context-switching cost is real. Research on task-switching shows every switch carries a genuine cognitive tax, not just a scheduling one (Rubinstein, Meyer and Evans’ work on executive control is a good starting point). That part of my original theory stands. It’s just downstream of the real problem, not the source of it.

What should stop

Jeff Bezos’s framing of decisions as one-way or two-way doors is useful here, not for deciding whether a meeting should happen, but for deciding what gives way when something new does come up. Most of what’s already committed is a two-way door: work that can be paused or resequenced without real damage. One-way doors, genuinely costly to delay or undo, are rare enough that they shouldn’t be the default reason to keep adding to an already full plate.

Not every ad-hoc meeting fits this. Some come from something entirely outside a team’s control, an incident, a customer escalation, and would happen regardless of how disciplined the backlog is. But for the pattern I was originally trying to explain, meetings that seem to multiply and quietly drain focus over time, this feels like the more honest explanation.

Where that leaves me

The practical question isn’t really about the meeting on your calendar. It’s about whatever your team already said yes to before that meeting existed, and whether anyone asked what should stop to make room for what’s new. I’d like to know if that lines up with what you’ve seen too.

comments powered by Disqus