The Meeting Tax
Quantifying how much productive time your team is actually losing
Every software engineer has had that Wednesday.
You know the one. You open your calendar in the morning and it looks like a game of Tetris played by someone who has never seen an L-shaped block. Standup at 9:15. Refinement at 10. A “quick sync” at 11 that is never quick. Lunch, if you’re lucky. Then a sprint review, a cross-team alignment and a 1:1 squeezed into the last hour of the day.
Somewhere between all of that, you’re supposed to write code. Or think. Or heaven forbid, solve an actual problem.
Welcome to the meeting tax. It’s the silent killer of engineering productivity and almost nobody treats it with the seriousness it deserves.
Let’s get nerdy for a moment.
In computer science, there’s a well-known concept called context switching overhead. When an operating system switches between processes, it doesn’t happen for free. The CPU has to save the current process state, load the new one, flush parts of the cache and warm up again. The switch itself takes time and the performance cost is often larger than you’d expect because of all the cache misses that follow.
Human brains work the same way, except worse.
Research from the University of California found that it takes an average of 23 minutes and 15 seconds to fully return to a task after an interruption. Twenty-three minutes. Now think about that engineer with six meetings spread across the day. Each meeting isn’t just 30 or 60 minutes of time. It’s the meeting itself plus the context switch tax on both sides.
A 30-minute meeting in the middle of an afternoon doesn’t cost you 30 minutes. It costs you roughly 75 minutes once you account for the wind-down, the meeting itself and the ramp-up to get back into whatever you were doing before. That’s not a rounding error. That’s a 2.5x multiplier.
If your engineers have four meetings a day, you’re not losing four hours. You’re losing something closer to five or six hours of effective deep work. On an eight-hour day, that leaves maybe two hours of actual focused building time. And we wonder why estimates slip.
Here’s where it gets interesting.
Meetings aren’t inherently evil. I want to be clear about that. Some meetings are genuinely useful. A well-run design review can save weeks of wasted effort. A good retrospective can change how a team operates. A difficult conversation handled in person (or on a call) can resolve what would otherwise fester for months in Slack threads.
The problem isn’t meetings. The problem is that we’ve built a culture where scheduling a meeting is the default response to uncertainty.
Someone doesn’t know what’s happening? Meeting.
Two teams need to agree on something? Meeting.
A stakeholder wants visibility? Meeting.
Nobody read the document you shared? Believe it or not, also a meeting.
It’s like malloc() without free(). We keep allocating meetings but we never release them. The calendar fills up. The garbage collector never runs. Eventually the whole system starts thrashing.
In operating systems, thrashing is what happens when the system spends more time swapping between processes than actually executing them. If that metaphor doesn’t perfectly describe your average Tuesday, I don’t know what does.
I’ve worked in teams where people spent 60 to 70 percent of their week in meetings and then wondered why we weren’t shipping on time. The answer was staring at them from their own calendars.
Let me share a pattern I’ve seen play out multiple times. A team starts a new quarter with ambitious goals. Energy is high. Then meetings begin to accumulate. Alignment meetings. Status updates. Steering committees. Check-ins on the check-ins. By mid-quarter, engineers are coding in the margins of their day. Early mornings. Late evenings. Weekends. They’re putting in more hours but producing less.
Leadership sees the declining output and responds predictably: more meetings to figure out what’s wrong. The irony writes itself.
At some point someone bravely suggests “meeting-free Wednesdays” and for a week or two it works, until someone books a “critical” meeting on a Wednesday because it was the only slot that worked for everyone. The dam breaks. Wednesday returns to normal. The experiment is declared a failure.
The truth is, meeting-free days are a band-aid. They treat the symptom, not the disease. The disease is a culture that doesn’t value uninterrupted time. That treats calendar availability as a resource to be consumed rather than protected.
If you want to actually fix this, you need to start thinking about meetings the way you think about technical debt. Because that’s exactly what they are. Organizational debt.
Every recurring meeting that no longer serves its purpose is debt. Every “just in case” sync is debt. Every meeting that could have been a Loom video or a Confluence page or a well-written Slack message is debt. And like technical debt, it compounds. One unnecessary meeting becomes three because people start scheduling pre-meetings and follow-up meetings to compensate for the first meeting being unfocused.
Here are a few things I’ve seen work in practice.
First, make the cost visible. Most people have no idea how much their meetings actually cost. Do the math for them. If you have 8 engineers in a room for an hour, that’s 8 engineering hours. At a fully loaded cost of, say, $150 per hour, that’s a $1,200 meeting. Ask yourself: did we get $1,200 of value from that hour? If the answer is no, that’s not a meeting. That’s a slow bleed.
Second, apply a “two pizza” rule to meetings, not teams. Amazon’s two-pizza rule was about team size, but it applies beautifully to meetings. If the meeting has more than eight people, it’s almost certainly a broadcast, not a collaboration. Turn it into a slack message. Or a recorded video. Or a document with a comment thread.
Third, default to 25 minutes instead of 30 and 50 instead of 60. This isn’t just about giving people a bathroom break between calls (though that matters more than anyone admits). It’s about creating a forcing function for focus. When you know you only have 25 minutes, you skip the 7 minutes of small talk about the weather and get to the point. Parkinson’s Law is real: work expands to fill the time available for its completion. Give it less time.
Fourth, require an agenda. No agenda, no meeting. This single rule eliminates a surprising number of meetings because it forces the organizer to actually think about what they want to accomplish. If you can’t articulate the purpose of a meeting in three bullet points, you don’t need a meeting. You need to think more.
Fifth and this is the hardest one, protect your team’s maker schedule. Paul Graham wrote about this years ago: managers operate on a manager’s schedule where a meeting is just another block in the day, but makers (engineers, designers, writers) operate on a maker’s schedule where a single meeting can blow up an entire afternoon. If you’re a leader, your job is to be the shield. Take the meetings so your team doesn’t have to. Batch the necessary ones together. Fight for contiguous blocks of deep work time.
There’s a deeper philosophical point here too.
We’ve built an industry that confuses visibility with productivity. Being in meetings makes you look busy. Being available on Slack makes you look responsive. Having a packed calendar makes you look important. None of these things correlate with actually shipping software that works well and solves real problems.
The best engineering work I’ve ever seen happened when teams had space. Space to think. Space to experiment. Space to sit with a problem long enough to find an elegant solution instead of a quick hack. You can’t create that space when every hour is pre-allocated.
I sometimes think about the great works of computer science. Dijkstra didn’t discover his shortest path algorithm between a standup and a sprint review. Knuth didn’t write The Art of Computer Programming in 25-minute increments between syncs. These things required deep, sustained, uninterrupted thought. We don’t all need to be Dijkstra. But we do need to respect that the same principle applies at every level: good work requires focus and focus requires time.
Here’s my challenge to anyone reading this who supports a team or runs an organization.
Open your team’s calendars. Not yours. Theirs. Look at next week. Count the hours of meetings for each engineer. Multiply each meeting by 2.5 to get the true cost in focus time. Now look at what’s left. Is it enough? Is it enough to do the work you’re expecting them to do?
If the answer makes you uncomfortable, good. That discomfort is the beginning of change.
The meeting tax is real. It’s measurable. And unlike actual taxes, you can do something about it. You just have to decide that your team’s time is worth protecting.
Stop scheduling. Start cancelling.