There is a meeting I have sat in more than once, at more than one company, under more than one name. Half an hour, every week, most of a team. The first half is status that everybody already had in a ticket queue. The second half is the part that actually matters: somebody says "wait, I thought that was pushed to next sprint," and two people who would not otherwise have spoken that week find out they have been working from different assumptions for over a week.
If you cancel that meeting, you delete the status recap. You also delete the only place those two people find out they disagree. The recap was waste. The disagreement was the thing keeping the project on the rails, and it was never on the agenda.
This is why meeting-reduction initiatives go badly. Someone counts the hours, multiplies by loaded salary, and produces a number that makes leadership flinch. The meetings get cut. Later the same coordination failures appear somewhere else, usually as rework, missed handoffs, or a rise in escalations that nobody connects back to the calendar change. The cost moved. It did not leave.
I learned this on a machine floor first
Before any of the IT work, I ran manual machines and wrote CNC programs. The thing that scares you in that job is not a crash. A crash is loud and you fix it. What scares you is a setup that is subtly wrong and runs clean, part after part, until somebody at inspection checks a dimension and you find out the whole run is scrap.
The stated problem is always the parts. The fault is almost never the parts. It is the fixture that got bumped, the offset nobody re-zeroed, or the operator on the previous shift who knew the stock was running heavy on one end and had nowhere to put that information except the next guy's ear. When he was off sick, the knowledge was off sick too.
That is a handoff with no design in it. The part travels. The context does not. Every organization I have worked in since has some version of the same gap, and the recurring meeting is very often the thing people built by hand to patch it.
What the NOC taught me about which signals matter
In network and security operations you learn fast that an alarm is only a claim that something might be information. Most of those claims are wrong. Watch a monitoring console for one shift and the volume of events will convince you nothing could possibly be that broken, which is the point: the operator's real job is deciding which handful deserve a human at three in the morning. Do that badly and you get alert fatigue, which is not laziness. It is what happens after the same channel wakes you up for nothing enough times.
The fix is never "send fewer alerts" as a blanket policy. You work out what each alert is actually telling you, whether anyone can act on it, and whether the thing it reports is already visible somewhere else. Some alerts get deleted. Some get thresholds. Some get routed to a different team who cared about it all along. And a few, usually the quiet ones nobody had been looking at, turn out to be the only warning you get before something expensive.
Recurring meetings behave the same way. They are a channel, and the name on the invite tells you nothing about what moves through it, any more than an alert name tells you whether it matters.
Support work taught me the same lesson in a different accent. Years on phones at Gateway and later GoDaddy, thousands of calls, and the most reliable pattern in all of it was that the stated problem was rarely the actual fault. The customer says the printer is broken. The printer is fine. Something upstream changed and nobody told them. A recurring meeting is a stated problem, not a fault.
The diagnostic: ask them all separately, then compare
Here is the thing I actually do. Before the meeting, go to every attendee individually. Not in a group thread, where they read each other's answers and converge. One at a time, in whatever channel they will actually reply to. Ask what problem the meeting solves, and what breaks if it stops happening tomorrow.
Then put the answers side by side. What you are measuring is the spread.
When everyone gives you a version of the same sentence, the meeting has a job and everyone knows what the job is. That is worth knowing, though it is not a verdict. Agreement that a meeting is a status report does not make the status report necessary, and I have watched a room converge beautifully on a purpose a document would have served better. Convergence tells you the thing is legible. You still have to ask whether it earns the hours.
Wide spread is the more interesting result. I am not going to dress a composite up as a case study, so take this as the shape of answer you should expect rather than a transcript: the organizer describes a decision forum, two attendees describe reporting status upward, one person says this is where they find out about changes that affect their work because nothing else tells them, one admits they have no idea why they are invited and have never spoken, and one gives a very specific answer about a recurring category of problem, which turns out to be why the meeting was created in the first place, by someone who has since left.
Every one of those answers is correct from where that person sits. Nobody is confused. The meeting is doing several jobs for several people and was never designed to do any of them; it picked the jobs up one at a time, and nobody ever assigned them.
Now the part most write-ups of this method leave out. Self-report is a weak instrument, and I have just spent a section arguing that a channel's own claim about itself is not evidence. People rationalize their own calendars. Someone will give you the answer they think their director wants, and the person whose presence quietly stops bad decisions is exactly the person who will never claim that. So cross-check. Look at who actually speaks in the last three sets of notes. Look at which decisions in the past quarter can be traced back to that half hour. Look at what happened the week it got skipped for a holiday, which is the closest thing to a free experiment any organization runs. Where the stated purpose and the behavior disagree, trust the behavior.
Nor is this free. "It only costs a couple of days of patience" is the least true sentence I could write here. Going to eight people one at a time to ask whether their director's recurring meeting should exist is a visible political act, and the organizer will hear about it by lunch. So tell the organizer first, before anyone else, and tell them the truth: you are trying to find out what the meeting is carrying so that nothing gets dropped if it changes. If you cannot say that honestly, do not run the diagnostic. You are building a case rather than measuring one, and people can smell the difference.
The Kahneman, Sibony and Sunstein work on noise gave me some of this framing and I want to be careful not to stretch it. Their subject is variability in judgments that should agree against a shared standard. Eight people naming different functions for one meeting is not quite that. It is one object doing five jobs, which is a different failure, and the honest word for it is accretion. I keep the noise idea nearby anyway because the instinct is the same: variability you can count is pointing at something structural, and counting it beats arguing about it.
Handoffs are where the information dies
Ticket systems make handoffs look solved. They are usually not solved. A ticket carries the request. It does not carry the constraint the first team worked around, or the approach they tried that failed, or the reason the request is shaped the way it is. That context lives in somebody's head, and the recurring meeting is where it leaks out by accident.
Which is why "just write it down" fails as advice. Writing things down is only a mechanism if it has four parts: an owner, a format, a trigger, and a place people already go to read it. A wiki page with none of those is storage, not a mechanism, and information you make optional stops moving.
So specify all four before you cut anything. For status: the owner is the team lead, the format is the same four fields every time, the trigger is end of day Thursday, and the place is the channel the people downstream already have open, not a page they would have to remember to visit. For decisions: the owner is whoever called the decision, the format is what we chose, what we rejected, and what would make us revisit it, the trigger is the moment the decision gets made rather than a weekly roundup, and the place is the project record people already open when they are confused. If you cannot fill in all four, you have not replaced the meeting. You have deleted it.
I spent years in third-party risk, assessing other companies from the outside, and the same gap showed up over and over. One assessment sticks with me. A company had a written procedure requiring a security review before any new vendor got production data access. The document was real and current. When I asked how the last three vendors had come through, the review had happened after contract signature in two cases and not at all in the third, because the person who used to kick it off had changed roles. The trigger had been him, not the process. Owner, format and place all existed. The trigger walked out the door with him.
Some meetings should survive
I want to be blunt about this because the anti-meeting genre is usually dishonest about it.
Some conversations only work live. Where the disagreement is not yet articulated, you need people in a room, because writing requires you to already know what you think. Where trust is the actual output, the meeting is the output. And the one where a junior engineer hears how a senior one reasons through a problem is training that happens to be scheduled as coordination, and it does not survive the move to documents at all.
The test is not whether a meeting is efficient. It is whether the thing it produces could exist without it. So run the diagnostic, collect the spread, build the mechanisms with all four parts, and then do the step everyone skips: run it that way for a defined period and measure again. Count escalations, count rework, count the handoffs that came back. A recommendation nobody tests is just an opinion in a nicer font, and I have been wrong before about which half of a meeting was the waste.
Sometimes the answer is to change nothing. If the spread is tight, the behavior matches what people say, and nothing cheaper carries the same load, leave it alone and go find a more expensive problem.
And sometimes you genuinely cannot tell which job the meeting was doing. I have looked at attendance, notes and the decision trail and still not known. The only honest thing to say then is that you do not know, and that removing it is how some organizations find out. If you do it anyway, put a date on the review and have somebody watching for the failure. The person who has never spoken in that meeting gets their half hour back either way, and of everything here that is the one part that was always free.