How is meeting toil different from "work about work"?

"Work about work" is the broad category of coordination overhead—status-chasing, duplicated effort, and hunting for information—that Asana estimates eats 60% of the workday. It's the slice of that overhead tied specifically to meetings, and it comes with a sharper test: if a machine could do the task just as well as a person, it's toil and should be automated. (We cover the wider problem in our piece on work about work.)

How much time do teams waste on meeting busywork?

Estimates vary, but the signals point the same direction. Asana finds unnecessary meetings cost the average worker 157 hours a year, and that 60% of the day goes to work about work. Microsoft reports knowledge workers are interrupted every two minutes—275 times a day. Even recovering a fraction of that time is worth a hard look at where your meeting busywork hides.

Can AI eliminate meeting toil?

AI can eliminate a large share of it—specifically the information-transfer tasks like note-taking, summarizing, and tracking action items, which are repetitive and automatable by definition. What AI shouldn't do is make the decisions, replace candid discussion, or stand in for the human judgment a meeting exists to produce. Use it to remove the busywork, not the conversation.

How do you measure meeting toil?

Borrow the SRE approach. Estimate what share of your team's collaboration time goes to manual, repetitive, no-enduring-value tasks, and set a ceiling—Google's teams cap toil below 50%. Audit a typical week, label each recurring task as either real work or toil using the automatability test, and track the ratio over time as you automate the toil away.

Meeting Toil: The Busywork Eating Your Team's Week

Q: What is meeting toil?

Meeting toil is the repetitive, automatable busywork that surrounds meetings—taking notes, writing recaps, chasing action items, posting status updates, and re-explaining context to people who missed the call. The term adapts "toil" from site reliability engineering, where it means manual work that keeps a system running but adds no lasting value. It keeps your meetings functioning but never moves the actual work forward.

The average knowledge worker is interrupted every two minutes during core hours—roughly 275 times a day—by a meeting, an email, or a ping, according to Microsoft's 2025 Work Trend Index. But the meetings themselves are only half the story. The other half is the quiet pile of repetitive work that surrounds every meeting: writing the recap, chasing the action items, updating the tracker, re-explaining last week's decision to the person who missed the call.

Software engineers have a name for this kind of work. They call it toil—and they treat it as a problem to be measured and engineered away, not a fact of life. Meeting toil applies that same idea to how your team meets. It's the manual, repetitive, automatable work that keeps your meetings running but never moves the actual work forward.

This article breaks down what meeting toil really is, why distributed teams generate more of it than anyone expects, how to spot it with a simple test borrowed from site reliability engineering, and a practical playbook to cut it down for good.

What Is Meeting Toil, Exactly?

Toil is a term that comes from Google's site reliability engineering teams. In the canonical SRE handbook, toil is defined as work that is "manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows." It's the operational busywork that keeps a system running but never improves it.

Meeting toil is that exact definition pointed at your calendar. It isn't the meeting where a real decision gets made. It's the scaffolding around it—and it carries the same six fingerprints:

Manual. A human types the notes, copies the decision into Slack, and pastes the tasks into the project tool by hand.
Repetitive. The same recap, the same status update, the same "quick sync to align" happens every single week.
Automatable. A machine could capture and summarize most of it just as well as a person.
Tactical. It's reactive—"we'd better schedule a call"—rather than a deliberate use of anyone's time.
Devoid of enduring value. When you finish writing the recap, the project sits in exactly the state it was in before.
Scales linearly. Add more people, more time zones, and more projects, and the busywork grows in lockstep.

Amazon's engineers use the same framing. The AWS Well-Architected DevOps guidance tells teams to "identify repetitive, time-consuming tasks, referred to as toil," and automate them with only a "limited allowance for manual work." If that standard is good enough for the systems running your product, it's good enough for the meetings running your team.

The Hidden Cost of Meeting Busywork for Remote Teams

Here's the uncomfortable math. Asana's Anatomy of Work Index found that knowledge workers spend 60% of their day on "work about work"—coordination, status-chasing, and duplicated effort—rather than the skilled job they were hired to do. Unnecessary meetings alone cost the average person 157 hours a year. Atlassian's State of Teams research adds another layer: teams waste a quarter of their time just searching for answers they should already have on hand.

Now factor in distance. Distributed teams generate more of this busywork than co-located ones, and the reason is structural, not cultural. In an office, a lot of coordination happens for free—a hallway question, a glance at a whiteboard, an overheard answer. Remote, every one of those informal exchanges has to be made explicit: scheduled, typed, recapped, and stored somewhere. The invisible work becomes visible work, and visible work becomes the coordination tax every distributed team pays.

That's the painful irony in Gallup's latest engagement data: fully remote workers are the most engaged of any group (31%, versus 19% for fully on-site). They want to do great work. But too much of that energy leaks into the busywork of keeping everyone aligned. Meeting toil is where remote teams quietly lose their best hours.

How to Spot Meeting Toil: The Automatability Test

The fastest way to find it is to run every recurring task through one question from the SRE playbook: could a machine do this just as well as a person? If the answer is yes, it's toil—and a human shouldn't be the one doing it.

Run that test across a normal week and the repetitive meeting tasks practically raise their hands:

Taking notes during a call instead of being present in it.
Writing the recap afterward and pasting it into three different channels.
Chasing action items—the Thursday "just following up on this" messages.
Status updates—the weekly meeting that exists only so everyone can say out loud what a dashboard already shows.
Re-explaining context to the two people who missed the call.
Copying decisions from the conversation into the doc, the tracker, and the ticket.
Scheduling and rescheduling the recurring sync nobody wants but nobody cancels.

None of these is the actual work. They're the friction around the work. And notice how many of them are pure information transfer—moving the same decision from one place to another by hand. That's the most automatable category of busywork there is, and it's exactly the kind of repetitive task Slack's own automation guidance tells teams to hand off so "people can focus on strategizing and problem-solving instead of copy-pasting all day."

How to Eliminate Meeting Toil (Start With a Budget)

Google's SRE teams don't aim for zero toil—that's impossible. Instead they set a budget: toil should stay below 50% of anyone's time, and the rest goes to work that makes future toil disappear. In practice, the average lands around 33%. Borrow the discipline. Decide what share of your team's collaboration time is allowed to be busywork, then drive the number down. Here's how to reduce meeting busywork in four moves.

Make context a durable artifact

Most meeting toil exists because context is trapped in someone's memory or a call that already ended. The fix is to give every working session a single, persistent home—a shared canvas where the discussion, the diagram, and the decision all live in one place. When the context is durable, you stop paying the re-explaining tax: the person who missed the meeting reads the canvas instead of booking a catch-up. This is the core idea behind tools like Coommit, which keep the video, the canvas, and the record of what was decided together rather than scattered across five tabs.

Let AI capture the record, not a human

No one should be typing notes during a conversation they're supposed to be part of. Contextual AI that listens to the call and watches the canvas can produce the summary, the decisions, and the action items automatically—turning the single most common piece of meeting busywork into a background process. The goal isn't a transcript nobody reads; it's a clean, structured record that writes itself. We go deeper on this in our guide to the AI meeting participant.

Replace status meetings with async updates

The recurring status meeting is meeting toil in its purest form: manual, repetitive, and devoid of enduring value. Most of them can become a short async post that people read on their own schedule, leaving live time for the sessions where something actually gets decided or built. Our breakdown of working sessions versus status meetings and the case for no-meeting days both push this further.

Automate the follow-up loop

Reminders, tracker updates, and "did this get done?" nudges are textbook automatable tasks. Wire them up so milestones, owners, and deadlines update themselves instead of generating another round of manual chasing. Every loop you close automatically is busywork you never have to touch again.

The Busywork You Shouldn't Automate

A word of caution, because the SRE concept comes with one. The goal is to automate toil, not judgment. Some things that look like overhead are actually the work.

Don't automate the decision itself—a human still has to weigh the trade-off and own the call. Don't automate candor, the unscripted moment when someone says "I don't think this will work." Don't automate the relationship-building that turns a remote group into a real team. AI should take the notes so people can have the conversation, not replace the conversation with a summary of one that never happened.

The test still holds: if a task is repetitive and creates no enduring value, kill it or automate it. But if it requires human judgment, trust, or creativity, protect it. Cutting meeting toil isn't about meeting less for its own sake—it's about spending the time you do meet on the things only people can do.

Conclusion

Meeting toil is one of those costs that never shows up on a budget line, which is exactly why it grows unchecked. Every manual recap, every status meeting, every re-explained decision is a small tax—and on a distributed team, those small taxes compound into entire workweeks. The teams that pull ahead in 2026 won't be the ones that meet the most or the least. They'll be the ones that ruthlessly automate the busywork around their meetings and protect the human time underneath it.

Start this week: pick your three most repetitive recurring meetings and run each through the automatability test. You'll likely find that the meeting matters and most of the work around it doesn't. That's your meeting toil—and now you know how to cut it. If you want the video, the canvas, and an AI-written record in one place to make that easier, that's exactly what Coommit was built for.