The Hidden Cost of Too Many Meetings: When Collaboration Starts Slowing Engineering Teams Down

What a meeting costs beyond the hour

Meetings aren’t the enemy. Some of the most useful hours I’ve spent as an engineering leader were in a room, or on a call, with the people who needed to make a decision together. I’ve also watched calendars fill up until engineers, product managers and designers had less time for the work those meetings were supposed to support.

Most people know the arithmetic: a one-hour meeting with eight people uses eight hours of working time. I used that number in when process helps, and it still undercounts. Someone prepares for the meeting. The half hour before it rarely goes to anything that needs deep concentration. Someone writes up what was decided, and if the right person wasn’t there, a follow-up meeting gets scheduled to cover the same ground.

The cost I think gets missed most is waiting. When a question can only be answered at Thursday’s sync, work that runs into that question on Monday either stops for three days or carries on based on a guess. Neither shows up on anyone’s calendar, and the guess can turn into rework that does.

The real cost of a meeting includes the preparation, the context switch on either side, the notes and follow-up meetings, and the work that waits for the next scheduled slot. For engineers, the largest cost is often the focused time a meeting breaks up, which is much harder to see than the hour itself.

How meetings pile up

Almost every meeting starts with a good reason. A project misses a deadline, so a weekly status meeting appears. Two teams ship changes that conflict, so a sync gets added. Someone hears about an important decision after the fact, so future invitations go to more people. Each of those made sense on the day it was created.

Six months later the deadline is long past and the teams have been reorganized, and the meeting is still on the calendar. Recurring meetings are easy to create and awkward to cancel, because cancelling one can sound like saying the problem is solved or the organizer’s meeting wasn’t useful. Invite lists only grow, since leaving someone out feels risky and adding them feels free.

Underneath much of this is an assumption that more communication means better communication. A team can spend hours in meetings every week and still be unclear about who decides, what’s in scope and what changed since last Tuesday. What I care about is whether the people who need information get it when they need it, in a form they can act on.

What the meeting is standing in for

When a team’s calendar is overloaded, I find it more useful to ask why each recurring meeting exists than to cut meetings across the board. A lot of them are compensating for something else. Status meetings exist because there’s no reliable place to see progress. Requirements sessions keep happening because stories arrive without the business rules, which I wrote about in why good user stories are hard. The same decision gets discussed in three meetings because nobody owns it, so the group keeps reconvening to talk about it again.

Cancelling a meeting without fixing what it covers usually just moves the problem. Status questions turn into direct messages, the requirements discussion happens halfway through a pull request, and within a few weeks someone schedules a new meeting with a different name. That’s why I’m wary of blanket cuts and meeting-free days used on their own. They change the calendar and leave the cause in place.

Too many meetings are often a symptom of deeper organizational problems: unclear ownership, requirements that arrive incomplete, decisions nobody owns, and low confidence in how work is progressing. Fixing those reduces meetings more durably than cutting meetings directly.

When a meeting replaces trust

Some meetings exist because a leader doesn’t have confidence that the work is moving. That’s understandable. If the last project surprised them, they want to see the next problem coming. A recurring meeting is still an expensive way to get that visibility, because it pulls the whole team in so that one person can feel informed. Engineers notice when the check-ins grow after every missed date and never shrink after a run of good ones.

I don’t think every status meeting signals a lack of trust. A new team, a new leader, a high-stakes launch or a rough patch can all justify closer check-ins for a while. A good standup also helps the team coordinate with itself, which has little to do with oversight. I’ve written about how process can build trust and how trust should earn autonomy, so I’ll keep to the part that’s specific to meetings.

Where possible, visibility should come from the work: clear owners, honest written updates sent before anyone asks, a board that reflects what’s actually happening, and demos of working software. When those exist, the meeting can get shorter or go away, and that change tells the team their reliability was noticed. When oversight stays heavy no matter how a team performs, people learn that the meeting is about control, and some of their energy goes into preparing for it instead of into the work.

Three free hours aren’t three hours of work

An engineer with three hours between meetings rarely gets three hours of development. Hard engineering work starts with building context: reading the code, holding the data model in your head, tracing a request through several services to see where it goes wrong. Debugging often means keeping a few hypotheses alive at once. Architectural thinking needs enough time to follow an idea far enough to see where it breaks. An interruption throws much of that away, and rebuilding it takes time that nobody budgets for.

A calendar with scattered 30-minute openings leaves room for email, a code review or a small fix. It doesn’t leave room to start something difficult, so the difficult work slides to the evening, to next week, or gets done in fragments, which is when I’d expect subtle mistakes to slip through. Paul Graham described this in an essay as the difference between a maker’s schedule and a manager’s schedule: managers work in hour-long slots, while people who build things need at least half a day to get anything substantial done. A single meeting in the middle of the morning costs a maker more than the hour it occupies.

The same thing happens across a week when priorities keep shifting, which I wrote about in what context switching actually costs. Meetings are the version of it that happens inside a single day.

Fragmented time is expensive for software engineers because difficult work depends on context that takes time to build and is easily lost. A day of scattered 30-minute openings leaves room for small tasks, while debugging, design and complex features need longer uninterrupted blocks.

Choosing how to communicate

Plenty of problems don’t need a meeting. Clear acceptance criteria answer questions before anyone has to ask them. A written technical decision stops the same argument from being reopened every quarter. Smaller stories need less coordination to deliver. A pull request discussion keeps the conversation next to the code it’s about. An asynchronous update can replace a round-the-room status report, and a direct conversation between the two people involved often settles something that would otherwise go to a group meeting.

Asynchronous communication has costs too. A thread can run for a day of back-and-forth messages on something two people could settle in five minutes on a call. Disagreement in text tends to harden, because tone gets lost and everyone answers the most pointed sentence. Across time zones, every round trip can add a day.

So I try to choose by the kind of problem. Information people need to read, and decisions they’ll need to find later, belong in writing. Ambiguity, disagreement and tradeoffs that need several people’s judgment usually go faster in a conversation, with the outcome written down afterward. When a thread has gone back and forth a few times without getting any closer, a short call is almost always cheaper.

Meetings that create clarity

Engineering doesn’t operate on its own. Product managers, designers, QA and engineers all need to understand what they’re building and why, and some of that understanding only forms when they talk. I’ve been in situations where a complicated requirement or UX design could have been simplified with an early conversation. A short discussion before development can save days of building and testing something more complex than the user needed, which is the kind of question I described in can we make this simpler for the user?

The difference I look for is between meetings that create clarity and meetings that relay status. A clarifying meeting changes what people do next. It ends with a decision, a smaller scope, an answered question or a risk someone now owns. A status meeting mostly passes along information that could have been read. A simple test is to ask whether anyone will work differently after the meeting. If the answer is no, it probably belongs in writing.

Clarifying meetings also tend to be small. They need the people who own the question and the people who can answer it, and not everyone who might find it interesting.

Leaders can be the biggest source

As engineers move into management, their calendars fill with meetings, and a fair amount of that is the job. Coordination, hiring, planning and one-on-ones all happen in conversation. The risk is that a leader’s meeting-heavy schedule quietly becomes everyone else’s schedule.

It usually happens with good intentions. A leader who wants to stay informed asks for a quick sync. Each request feels small from where they sit. From the team’s side, it’s one more interruption in a day that already had several. A question from a manager in chat also tends to feel urgent even when it isn’t, because people drop what they’re doing to answer the person who writes their review. I have to remind myself of that, and I don’t think I’m unusual. It’s a version of the bottleneck problem I wrote about before: there, decisions queued behind my calendar, and here the team’s focus pays for it.

What helps is reading what’s already written before asking, batching questions instead of sending them as they occur, and saying when something can wait. It also helps to attend fewer of the team’s meetings. Teams often decide faster without the most senior person in the room, and the ones who need my input know how to get it.

How I think about meetings now

I don’t have a rule for how many meetings a team should have. It depends on the team, the work and how much uncertainty is around. Before I put a meeting on someone’s calendar, or when I look at one that’s been recurring for a while, I ask:

1. What decision needs to be made?
2. Who actually needs to take part?
3. Could this be resolved asynchronously?
4. What happens if we don’t have this meeting?
5. Will this meeting unblock work?
6. Is this a recurring meeting that has outlived its purpose?
7. Are we solving a problem, or discussing it again?

The fourth question is the one I find most revealing. For a recurring meeting, the honest way to answer it is sometimes to skip it for a couple of weeks and see what breaks. If nothing does, it was probably habit.

A useful meeting should produce clarity, a decision, an action or stronger alignment. Not every meeting needs a formal outcome, though. One-on-ones, mentoring and conversations that build working relationships pay off over months, and judging them by the action items they produce misses the point. I wrote about why that time matters to me in why I enjoy mentoring. Those are usually the last meetings I’d cut.

Short answers