Why Unnecessary Meetings Drain Developers' Productivity and How to Fix It

Stack Overflow recently released a series of research reports indicating that many companies hold "unnecessary meetings" that could be streamlined. Their analysis, citing SurveyMonkey data, shows that 32% of programmers consider some meetings completely unnecessary and could be replaced by an email.

The reports also reference a study by Professor Thomas Fritz at the University of Zurich, which found that over half of developers view company meetings as "unnecessary". Additional research by Otter.ai and Professor Stephen G. Rogelberg of the University of North Carolina reports that such meetings cause frustration and anger among programmers.

One finding states that at least one‑third of meetings are deemed unnecessary, and excessive low‑quality meetings can negatively affect developers' perception of their work and cost companies an extra $25,000 per employee annually.

Stack Overflow notes that Shopify eliminated all meetings with more than three participants, saving 320,000 employee hours.

Companies should avoid meaningless meetings; if meetings are required, they must have clear agendas and be kept short. All participants should communicate directly and clearly, with defined decision paths, to keep focus on the meeting itself.

Why pulling developers into meetings is costly

Developers often follow a "Maker's Schedule"—large blocks of uninterrupted time for deep work—while managers typically use a "Manager's Schedule" with hourly slots. For makers, a single meeting can destroy an entire afternoon, fragmenting focus and reducing output.

When a manager's schedule forces a developer into frequent meetings, it acts like an exception being thrown: it forces a context switch and disrupts the work mode.

Although both schedules can function, conflicts arise when they intersect. Smart leaders recognize that makers need extended, uninterrupted periods to be productive.

Paul Graham, author of *Hackers & Painters*, describes how Y Combinator operates on a Maker's Schedule, allowing founders to reserve large time blocks for deep work while still accommodating necessary meetings.

To reconcile the two schedules, the author reserves several large time blocks each week for founder meetings, using a custom program to batch meetings together, ensuring that the rest of the day remains uninterrupted.

Historically, Graham also split his day into a night‑time coding block and a daytime business block, effectively maintaining both Maker and Manager schedules.

Understanding the clash between Maker's and Manager's schedules helps both sides compromise: developers can accept essential meetings, while managers learn to respect the cost of breaking deep‑work periods.