Nobody repealed it. There was no meeting about ending it and no announcement. It was simply true in week two, mostly true in week five, and by week nine the people who were there when it was announced had stopped mentioning it, because mentioning it made them the difficult one.
Why meeting policies fail is a diagnosable question rather than a mysterious one, and there are four causes. Each leaves a different mark on the calendar, and each needs a different fix — which is why relaunching without finding out which one you had tends to produce the same death at about the same week. Do the autopsy first. It takes an hour.
Run the autopsy before you relaunch
You need eight to ten weeks of calendar data spanning the announcement — four weeks before, and everything after. Team calendars, not your own. Then four questions.
- Did the total meeting load actually fall? Count person-hours a week — duration × attendance — for the four weeks before and the four weeks after. Not the number of meetings.
- If it fell, did it stay fallen? Plot it by week. The shape tells you almost everything.
- How many exceptions were granted, and by whom? Count the meetings that sat inside the protected time after week one. Then check who booked them.
- Can you find the policy in writing? Look where a new starter would look. Not in a channel history — in the place a person who joined last month would actually go.
Four answers, four causes. They are not mutually exclusive, and if you have three of them, the policy was not going to survive regardless of how it was rolled out.
Cause one: exception creep
The tell. Load fell in weeks one and two, then climbed back week by week until it crossed the old baseline somewhere around week six to eight. The exception count rises steadily, and the exceptions were granted by several different people, none of whom knew about the others.
This is the most common cause and the most mechanical. An exception granted in advance, in writing, as part of the policy is a rule. The same exception granted in week three, verbally, to somebody with a genuinely urgent and genuinely reasonable problem is a precedent — and the next person cites it, with slightly less urgency, and the person after that cites them.
Nothing in that chain is unreasonable. That is what makes it hard to stop: there is no point at which someone did something indefensible, and so there is no point at which anyone could reasonably have said no.
The fix is the exception list written before launch, closed, with a named person who adds to it or refuses. Not a stricter policy. The same policy, with its exceptions decided in advance and its list visible.
Cause two: nobody senior was ever inconvenienced
The tell. The exceptions are not spread across the team. They cluster around two or three people, and those people are senior. Load fell for individual contributors and did not fall at all for anyone with reports.
A policy that senior people are structurally exempt from is not a policy; it is a request made of everybody junior. Teams work this out in about a month, usually without discussing it, and the way they signal that they have worked it out is that they stop enforcing it against each other.
The specific thing that was missing is a visible moment: somebody senior wanting a meeting inside the protected time, and not getting it, in public. One of those is worth more than any amount of announcing. Without it, the junior half of the team has no evidence that the rule binds upwards, and the rule asks them to decline a director on their own authority.
The fix is not a message about commitment. It is arranging, deliberately, for the first senior request to be refused where the team can see it — and for the senior person to say in the channel that they were refused and that it was correct. If you cannot get that, you cannot get this policy, and that is useful to know in week one rather than week nine.
Cause three: it was never written down
The tell. You cannot find it. The announcement is in a channel, eleven weeks back, in a thread. Anybody who joined since has never heard of it. The load graph shows a fall that decays gradually with no clear inflection, tracking headcount change rather than any event.
This one is the cheapest to fix and the easiest to diagnose, because the test is literally whether the document exists somewhere a new person finds without asking. A channel message is not a document. A slide from an all-hands is not a document. The thing you need is a page with the rule, the exceptions, the owner and a review date, linked from wherever the team’s working agreements live — and if the team has no such place, that is the actual finding, and it is bigger than the meeting policy.
A policy that moves work out of meetings also depends on that written layer being read rather than merely existing. That is a separate failure with its own shape, one level down from this one, and it is worth checking for before you conclude the meeting policy was the problem.
The fix is a page, an owner, and a line in onboarding. Thirty minutes.
Cause four: the load compressed instead of shrinking
The tell. Total person-hours a week are flat — within a few percent of the baseline — while the protected time is genuinely clear. The policy worked exactly as written and bought nothing. The remaining days are visibly worse: longer meeting runs, fewer gaps, Tuesday and Thursday booked solid.
This is the cause the vendor posts do not carry, because it is the one where the policy was followed and the outcome was still bad. Meetings do not get cancelled by a no-meeting day. They get moved. If the work that generated them has not changed, a Wednesday with nothing on it is paid for by a Tuesday with nine hours on it, and the team ends up with the same load at worse fragmentation than before.
The reader who was told to protect a day and ended up with four worse days is the reader this site exists for, and the honest answer is that the day was the wrong instrument. A protected day redistributes load. It does not reduce it. Reducing it means killing or shrinking specific recurring meetings, deciding who actually needs to attend, and moving the status meetings into writing — three things that are harder than announcing a day and are the only things that work.
The fix is to do the reduction first and the protected day second, as the thing that locks in a gain you have already made. In that order it holds. In the other order it is a redistribution with a launch announcement.
Why meeting policies fail: the diagnosis table
| Cause | The tell on the calendar | The fix |
|---|---|---|
| Exception creep | Load recovers week by week; many exceptions, many granters | Closed exception list written before launch, one named owner |
| Nobody senior was inconvenienced | Exceptions cluster on senior people; load fell only for ICs | One refusal of a senior request, in public, acknowledged |
| Never written down | No findable document; new starters have not heard of it | A page with rule, exceptions, owner, review date; a line in onboarding |
| Compression | Total person-hours flat; remaining days worse | Cut the recurring load first, then protect the day |
If the load never fell at all, even in week one, you do not have any of these. You have a policy that was announced and never started, which usually means the announcement did not say what anyone was supposed to do differently on Monday.
Relaunching, and when not to
Three conditions. If you cannot meet all three, the better decision is to leave it dead and do something smaller.
- You know which cause you had, from the calendar rather than from an impression.
- The specific countermeasure is in place before the relaunch, not promised as part of it.
- Somebody senior has agreed in advance to be the visible refusal.
If those hold, relaunch it and say plainly that it is a second attempt and what is different this time. Teams forgive a second attempt that names the first failure; they do not forgive one that pretends to be the first.
If they do not hold, do not relaunch. A policy that dies twice is much harder to revive than one that died once, and the second death teaches the team that this category of change does not work here — which costs you the next attempt too. The smaller thing that works without any policy: pick the two most expensive recurring meetings from the person-hour ledger and cancel or shrink those two. No announcement, no name, no rollout. Load falls and nothing can die.
It is also worth knowing that the most visible no-meeting-day policy there has been was ended by the company that ran it, publicly, for stated reasons — the detail is in what the evidence actually says. Ending a policy on purpose, with a reason, is a different outcome from this post’s subject. It is the respectable one.
What month six looks like when it held
Useful as a target, and as a check on whether yours is actually alive.
The exception list has three or four items on it and has been added to once. Somebody can produce the document in under a minute. At least one person remembers a specific occasion when a senior person was told no. Total person-hours a week is lower than the baseline and has stayed lower for four consecutive months. And the thing nobody predicts: the policy is boring. Nobody mentions it, not because they have forgotten it, but because it is simply how the calendar works now and there is nothing to say about it.
A policy that people are still enthusiastic about in month six is usually one that is still being enforced by enthusiasm, which runs out. The version that survives is the dull one.