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.

This post is a model, not a study. We have not run a secret experiment on a real company, and you should be suspicious of anyone who tells you they've precisely measured this — the invisible costs are, by definition, hard to instrument. What follows is a worked example you can run on your own org. Every number below is an assumption, clearly labeled as one. Swap in figures that match your team and see what falls out. The value is in the method; the specific numbers are illustrative.

What to measure

Imagine you set out to model this for an engineering organization. Consider a 50-person org — say 50 engineers, plus a handful of EMs, PMs, and an SRE team. A standard SaaS company.

There are five kinds of meeting-adjacent activity worth accounting for:

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

There are costs this model deliberately leaves out: context-switching cost from interruptions, the cost of bad decisions made because someone forgot the prior context, and the morale cost of repeated discussions. Those are real and probably large, but they're hard to quantify credibly, so the model treats them as upside it doesn't count.

The visible cost: assume ~11 hours per engineer per week

The obvious number is time-in-meeting. For the sake of the model, assume the average engineer spends about 11 hours per week in scheduled meetings. (Managers usually run higher — plug in your own figure; EMs and PMs often sit at 17–22 hours.) If your calendar exports say something different, use your number.

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.

That figure is misleading on its own. 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: assume another ~5 hours per engineer per week

Now add the four categories of meeting-adjacent work — Slack questions about meetings, context-recovery messages, post-meeting documents, and re-litigated decisions. As a working assumption, say this adds up to another ~5 hours per engineer per week. This is the number most orgs never estimate, and it's the one most worth challenging with your own data.

Let me put the assumption more concretely: suppose that for every hour an engineer spends in a meeting, they spend 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. Whether it's really 25 minutes, 10 minutes, or 40 minutes for your team is exactly the thing to sanity-check.

Some of that overhead is 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 is document-writing:

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

And some is 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

In this kind of model, re-litigation tends to be the most expensive category per occurrence — a single re-litigated decision can cost the org well over an hour (the meeting time of everyone re-discussing). Slack context-recovery is usually the most frequent: even a handful of these messages per engineer per week, at a few minutes each to write and respond to, compounds quickly.

Adding it up

Total meeting-adjacent time per engineer per week, under these assumptions:

• 11 hours in meetings
• ~5 hours dealing with meeting consequences
• ≈ 16 hours per week

That's roughly two full days per engineer, every week — if the assumptions hold for your team. At a 50-person org, that's on the order of 800 person-hours per week. Over a year, call it ~40,000 person-hours. At an assumed loaded hourly cost of $100/hour (a placeholder — many orgs are lower), that's in the neighborhood of $4 million per year in meeting-related work.

Split that into two buckets. The cost of the meetings themselves is roughly the time-in-room portion. The cost of bad meeting hygiene — the work generated by not having good recaps, searchable transcripts, and clear decision capture — is the meeting-adjacent portion, which in this example lands around $1 million per year.

The first number is a familiar target of cost-cutting initiatives. The second number is almost never estimated, almost never targeted, and — importantly — almost certainly more reducible. That asymmetry is the whole point of running the model.

Why the hidden cost is bigger than people think

A few specific patterns compound the hidden cost. These are qualitative — the mechanisms are what matter; the frequencies are yours to fill in.

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.

Count how many of these threads your org generates in a typical week, and estimate the total attention each one consumes (original asker, original answerer, plus follow-ups). It adds up fast — and it's pure recovery work that produces no new artifact. A well-written, searchable recap could replace almost all of it.

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. Most teams see some version of this several times a 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.

Estimate how much time your senior engineers spend onboarding new hires through context-recap meetings. With searchable meeting history, a good chunk of it can move to self-service — a new hire searches "why did we decide X?" and finds 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. Watch for instances where cross-team work overlapped because the original decision wasn't visible to both teams.

What actually reduces the tax

Not every intervention works. Here's what tends to move the number and what tends not to.

What tends to work:

• Auto-generated meeting recaps posted to a central channel. Cuts down Slack context-recovery questions. The recap doesn't have to be perfect; it has to be searchable.
• Searchable meeting history with a decision graph. Reduces re-litigated decisions. Looking up a prior decision drops from tens of minutes to seconds when there's a good search index.
• Action item extraction with owners. Reduces "wait, who's doing X?" Slack pings.
• Pre-meeting context surfaces. Before each meeting, a brief on what was discussed last time and what's still open. Reduces re-litigation in recurring meetings.

What tends not to work:

• Mandatory hand-written recaps. Engineers don't write recaps reliably under time pressure. Quality collapses quickly once the novelty wears off.
• Meeting-free Fridays. Feels good. Rarely reduces the tax. Meetings just pile onto the other four days, plus people write more "what's the status?" Slack messages on Friday to compensate.
• "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 (a worked example)

Here's the model taken to a conclusion, with every input labeled as an assumption. If a 50-person org carries roughly $1 million per year in bad-meeting-hygiene cost (from the illustration above), and you compare that against a meeting copilot priced at, say, $40 per seat per month — in the ballpark of real meeting-copilot pricing — then at ~60% adoption you're looking at something like $30K per year for the org. The rough shape:

• Assumed cost: ~$30K/year
• Assumed savings from reducing the meeting tax by 30-50%: ~$300K-$500K/year
• Implied ROI: roughly 10x to 17x

This math is suspiciously good, so let's interrogate it hard — because a clean 10x should always make you suspicious. Every number in this section is illustrative. Real numbers vary widely, and yours will be different. Specifically:

• The savings assume that recovered time actually goes into productive work and not into more meetings. That's a big assumption.
• The "30-50% reduction" is a hopeful estimate, not a measured result. No one has run a controlled trial on your org.
• The $1 million baseline rides on a US-loaded hourly cost that's higher than many teams pay, and on the ~5-hours-of-hidden-work assumption, which is the softest number in the whole model.

So discount it. Even with conservative inputs — say the tool only reduces the tax by 20%, the loaded cost is $75/hour, and only half the engineers adopt — the ROI in this example still lands somewhere around 6x. The point isn't the exact multiple. It's that the hidden cost is large enough that even pessimistic assumptions leave meeting hygiene looking like one of the higher-ROI productivity investments available to most engineering orgs. Run the model with your own numbers and see whether that holds.

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 real, and it's usually bigger than most engineering orgs realize — but it's reducible. 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 build. Add up what your team is actually spending on meeting-adjacent recovery work — using your numbers, not ours — and compare it to the cost of investing in a copilot. Do the arithmetic honestly, discount the rosy assumptions, and see where you land. For a lot of teams, the copilot pays for itself many times over. We build one, so we're biased — which is exactly why you should run the model yourself rather than take our word for it.