When people talk about developer productivity, they usually talk about frameworks, AI tools, CI speed, or engineering velocity. They rarely start with the most obvious leak in the system: meetings. But if a developer is spending ten hours a week in meetings, that is not a side issue. That is the workweek being carved into unusable pieces.
The raw time is only half the story
Ten hours sounds bad enough on its own. It gets worse once you include context switching. A thirty-minute meeting does not only cost thirty minutes. It costs the interruption before it, the ramp back in after it, and the subtle decision not to start deep work because a meeting is coming soon.
That is why teams can look “only moderately meeting-heavy” on paper and still feel chronically behind in practice. The schedule is fragmented long before the meeting count becomes absurd.
Why teams accept it
Because every meeting sounds defensible in isolation. This standup is just fifteen minutes. This planning session is important. This sync might unblock something. This retrospective is healthy. This review needs all the stakeholders. The calendar fills one reasonable explanation at a time.
The problem is cumulative. Nobody experiences the total system at the moment the invite is sent. The developer experiences it as a week where concentration never fully arrives.
What to do instead
The answer is not “ban meetings” as a slogan. It is to stop using meetings for the jobs that visible work can do better: status reporting, lightweight updates, and passive awareness. Let those live in a shared written system. Save synchronous time for decisions, disagreement, and genuine collaboration.
Teams do not usually need to become better at meetings. They need fewer meetings doing less trivial work.