The meeting tax: how much time engineers actually lose to bad recaps

Engineering organizations love to argue about meeting count. "We have too many meetings." "We need fewer meetings." "Meeting-free Fridays will save us." This conversation is so common it's a meme.

Almost everyone has the conversation in the wrong terms. The cost of meetings isn't time in the meeting. The cost of meetings is what happens after the meeting ends — or rather, what happens because the meeting didn't end cleanly. Lost decisions. Re-derived agreements. Slack threads asking "wait, what did we agree to?" Onboarding sessions that recapitulate context that already exists somewhere, but somewhere unfindable.

We spent a quarter measuring this on a 50-person engineering org. The number was bigger than we expected. This is what we found.

What we measured

We instrumented an engineering organization for thirteen weeks. The org had 50 engineers, 8 EMs, 4 PMs, and a small SRE team. Standard SaaS company.

We measured five kinds of meeting-adjacent activity:

Time in scheduled meetings. The obvious one. From calendar data.
Slack messages about meetings the sender did not attend. Things like "did we decide X in the planning meeting?"
Slack messages asking for context that was discussed in a meeting. "What's the status on the migration? Wasn't that discussed last week?"
Documents that re-summarize meetings. Notion pages, post-meeting recaps written by hand, decision logs written days later.
Decisions re-litigated. When the same topic comes up in a second meeting because the first meeting's decision was lost or unclear.

We did not try to measure context-switching cost from interruptions, the cost of bad decisions made because someone forgot the prior context, or the morale cost of repeated discussions. Those are real and probably large; we just couldn't quantify them in a credible way.

The visible cost: 11 hours per engineer per week

The obvious number is time-in-meeting. Across the 50-person engineering org, the average engineer spent 11 hours per week in scheduled meetings. EMs were higher — averaging 17 hours. PMs were 22.

If you take this number at face value and multiply by an engineer's loaded hourly cost, you get a familiar "meetings cost us $X per year" figure that internal cost-cutting initiatives love to throw around.

This number is wrong. Not because meetings don't cost time — they do. But because the visible meeting-time cost is the smallest piece of the total cost. The bigger pieces are downstream and hidden.

The invisible cost: another 5 hours per engineer per week

When we tallied the four categories of meeting-adjacent work — Slack questions about meetings, context-recovery messages, post-meeting documents, and re-litigated decisions — the average engineer spent another 4.7 hours per week.

Let me say that more clearly: for every hour an engineer spent in a meeting, they spent about 25 additional minutes dealing with the consequences of bad meeting hygiene. That's almost half a meeting's worth of overhead, after the meeting is over.

Some of it was Slack-flavored:

"Hey, was anyone in the migration sync yesterday? Did we land on a date?"
"I missed the architecture review — can someone summarize what was decided about the auth layer?"
"What did Bob mean when he said we should hold off on shipping?"

Some was document-writing:

Post-meeting recap drafts that took 30-90 minutes to write
Decision logs that were attempted, partially completed, and abandoned
"What we discussed today" emails to stakeholders who weren't invited

And some was re-litigated decisions:

A decision made in week 2 of the quarter, lost by week 4, re-made in week 6 with a slightly different conclusion
Two parallel meetings reaching different decisions because neither knew about the other
A new hire raising a question whose answer was in a meeting from before they joined

The re-litigation category was the most expensive per occurrence: a single re-litigated decision cost the org an average of 90 minutes (the meeting time of everyone re-discussing). But Slack context-recovery was the most frequent — 47 messages per engineer per week, averaging 6 minutes each to write and respond to.

Adding it up

Total meeting-adjacent time per engineer per week:

11 hours in meetings
4.7 hours dealing with meeting consequences
= 15.7 hours per week

That's almost two full days per engineer, every week. At a 50-person org, that's about 785 person-hours per week, or roughly 41,000 person-hours per year. At a loaded hourly cost of $100/hour (low for senior eng in 2026 dollars), that's about $4.1 million per year in meeting-related work.

The cost of the meetings themselves is about $2.9 million. The cost of bad meeting hygiene — the work generated by not having good recaps, searchable transcripts, and clear decision capture — is about $1.2 million.

The first number is a familiar target of cost-cutting initiatives. The second number is almost never measured, almost never targeted, and almost certainly more reducible.

Why the hidden cost is bigger than people think

A few specific patterns we saw that compound the hidden cost:

The "wait, what did we decide?" Slack thread

This is the unit of meeting tax. One person was in the meeting. Three people who weren't there need to know what was decided. The original attendee has to context-switch out of whatever they were doing, re-derive the decision (often by re-reading their own scrappy notes), and explain it in Slack.

We measured 23 of these threads per week across the org. Each consumed an average of 28 minutes of total attention (original asker, original answerer, plus follow-up questions). That's 11 hours per week of pure recovery work — work that produces no new artifact and could be replaced entirely by a well-written searchable recap.

The "are we still doing this?" drift

When a decision gets made in a meeting and never written down, it has a half-life. By two weeks later, half the people who were in the room are no longer sure the decision stands. By a month, most people aren't sure if it was ever decided at all.

This produces a particular Slack pattern: someone says "hey, are we still planning to do the migration in Q3?" and triggers a five-message back-and-forth in which the answer turns out to be "yes" but only after re-establishing the context. We saw this pattern 8-12 times per week.

The onboarding tax

New hires need to learn things. Things that already exist in the heads of senior engineers. Senior engineers schedule "let me give you context on X" meetings, which are themselves meetings, which themselves require recaps to be useful.

We saw senior engineers spending an average of 3 hours per week onboarding new hires through context-recap meetings. With searchable meeting history, this dropped substantially — new hires could search themselves for "why did we decide X?" and find the original meeting where it was discussed.

The cross-team duplication

When team A makes a decision that affects team B, and team B doesn't know about it, both teams independently spend time on it. Multiplied across an org, this is a real cost. We measured 4-6 instances per week of cross-team work that overlapped because the original decision wasn't visible to both teams.

What actually reduces the tax

We tried a few interventions across the quarter. Some worked, some didn't.

What worked:

Auto-generated meeting recaps posted to a central channel. Cut Slack context-recovery questions by about 40%. The recap doesn't have to be perfect; it has to be searchable.
Searchable meeting history with decision graph. Cut re-litigated decisions by about 60% in the teams that adopted it. The act of looking up a prior decision used to cost 20-30 minutes; with a good search index, it costs 30 seconds.
Action item extraction with owners. Reduced "wait, who's doing X?" Slack pings by about 50%.
Pre-meeting context surfaces. Before each meeting, a brief on what was discussed last time and what's still open. Reduced re-litigation in recurring meetings.

What didn't work:

Mandatory hand-written recaps. Engineers don't write recaps reliably under time pressure. Quality collapses within two weeks. We've tried this on three different teams. Same outcome every time.
Meeting-free Fridays. Felt good. Didn't reduce the tax. Engineers just had more meetings on the other four days, plus they had to write more "what's the status?" Slack messages on Friday to compensate. (Separate post coming on this.)
"Just have fewer meetings." Doesn't work as a directive without changing the underlying need. The need that meetings serve — synchronizing context across a team — doesn't disappear when you delete the meeting from the calendar. It just becomes harder to satisfy.

The ROI math

If a 50-person org pays $1.2 million per year for bad meeting hygiene, and a meeting copilot at $49/seat/month costs about $35K per year for that org (assuming 60% adoption), the math is roughly:

Cost: $35K/year
Estimated savings from reducing meeting tax by 30-50%: $360K-$600K/year
ROI: 10x to 17x

This math is suspiciously good, so let's interrogate it. The savings assume that the time recovered actually goes into productive work and not into more meetings. The 30-50% reduction is based on our internal measurements; your mileage will vary. The $1.2 million baseline assumes a US-loaded hourly cost that's higher than many orgs.

Even with conservative assumptions — say, the tool only reduces the tax by 20%, the loaded cost is $75/hour, and only half the engineers adopt — the ROI is still around 6x. Meeting hygiene is one of the highest-ROI productivity investments available to most engineering orgs.

The bigger argument

The familiar conversation about meetings — "we have too many" — misses the point. Meetings are a synchronization mechanism. You can't eliminate the need for synchronization by deleting the meetings; you just push the cost into more expensive places (Slack, individual context-recovery, lost decisions, repeated work).

What you can do is reduce the cost per meeting of synchronizing well. A meeting that produces a clean, searchable recap synchronizes the entire team, not just the people in the room. A meeting that produces no recap synchronizes only the attendees and creates a long tail of recovery work.

The meeting tax is a real number. It's bigger than most engineering orgs realize. And it's reducible — but you reduce it by improving how meetings end, not by trying to have fewer of them.

If you're an EM or a productivity-minded engineering leader, this is the spreadsheet to make. Add up what your team is currently spending on meeting-adjacent recovery work. Compare it to the cost of investing in a copilot. The answer is almost always: invest in the copilot.

We made it. We're biased. But the math holds even if you discount our numbers significantly.