The Cancelled Meeting Nobody Writes Down

PublishedAugust 25, 202615 min read

Every capture tool wakes up when a meeting happens, so the meetings that carry the most signal, the ones that keep getting cancelled and pushed, are exactly the ones that leave no record. A repeated non-event is data, and most work memory throws it away without noticing it was ever there.

The one on your calendar that keeps moving

There is a meeting you own that has not actually happened in a month. It is still on the calendar every week. It gets dragged to a different slot on Monday, or cancelled on Thursday morning with a one line note, crazy week, let us pick it up next time. Next week it does the same thing. If someone asked you when it last ran, you would have to stop and guess.

Now ask what your notes tool knows about that meeting. Nothing. It records meetings that happen, and four cancellations in a row are four absences, and an absence has no transcript, no summary, no action items and no card in the archive. The loudest recurring thing on your calendar for the last month is the one thing your work memory holds no record of.

That is backwards, because the repeated cancellation is usually the most informative event in the whole sequence. A meeting that runs every week and goes fine is telling you very little you did not already know. A meeting that will not stay on the calendar is telling you a great deal, and it is telling you in the one format nothing in your stack is built to hear.

Capture is triggered by the meeting, not by the calendar

Every tool that records meetings works the same way underneath. Something starts. A call connects, a room fills, a transcript begins. The tool wakes up because an event happened, does its job, and files the result. No event, no wake up, nothing filed. This is not a defect in any particular product. It is what capture is.

The consequence is a specific and permanent blind spot. The system can only ever hold a record of meetings that took place. The set of meetings that were supposed to take place and did not is invisible to it, and that set is not random. It holds the 1:1 a manager has quietly stopped showing up to, the project sync that has had nothing to report for three weeks, and the decision review that keeps getting pushed because nobody wants to be the one who decides.

So the archive has a shape. It is dense where things are working, because working meetings happen and get recorded, and it thins out precisely where attention is most needed, because trouble often shows up first as a meeting that stops happening. The record is most complete about the things you least need it to remember.

The dog that did nothing in the night-time

This has a famous illustration. In Arthur Conan Doyle's 1892 Sherlock Holmes story Silver Blaze, a racehorse is taken from a stable at night and the trainer is found dead. Holmes cracks it by attending to a non-event. When an inspector asks whether any point deserves his attention, Holmes points him to the curious incident of the dog in the night-time. The inspector objects that the dog did nothing in the night-time. That, Holmes replies, was the curious incident.

The stable dog did not bark, which meant the intruder was someone the dog already knew. The clue is not a thing that happened. It is a thing that should have happened and did not, and it is invisible to anyone cataloguing the events of the night, because it is simply not among them. You cannot write down a bark that never came.

A calendar full of meetings is a night full of events. It is easy to review what happened. The dog that did not bark is the meeting that did not run, and it is hard to notice for the same reason: it is not on the list of things that occurred, and every tool you have is a list of things that occurred.

A meeting that is working produces no signal

There is a sharper version of this from organizational research. Karl Weick, who spent decades studying how hospitals, aircraft carriers and firefighting crews avoid catastrophe, has a name for what reliability actually is. He calls it a dynamic non-event. A system that is working produces nothing. A reactor that does not melt down produces no event. A flight that lands like every other flight produces none either. Reliability is the continuous absence of failure, and absence is the hardest thing there is to keep paying attention to.

Weick's argument, made directly in a 2011 paper whose subtitle is the production of dynamic non-events, is that this invisibility is the whole problem. People attend to events, and a working system is a non-event, so the effort that keeps it working goes unnoticed until the day it stops. In his framing, the trouble begins when a non-event suddenly becomes an event. By then the quiet stretch that was the actual warning is already over.

A recurring meeting that keeps running is a dynamic non-event in exactly this sense. Nothing about it asks for your attention. The information is in the transition, the moment the meeting starts not happening, and that transition produces no artifact at all. The healthy state and the early failure state look identical in your archive, because both are made of the same material, meetings that were captured, right up until the meetings stop and the archive just goes quiet.

The reason written on the cancellation is not the reason

When a meeting is cancelled there is usually a line attached. Crazy week. Let us push to next sprint. Can we take this async. These lines are polite and they are almost never the real reason, which is the point of them. A meeting gets cancelled once for a hundred small logistical reasons. It gets cancelled four times running for a much smaller set of reasons, and the note is written specifically so it does not have to say which.

Statisticians have a precise way to talk about this. Donald Rubin, in a 1976 Biometrika paper that set the terms the field still uses for missing data, drew a line between data that is missing at random and data that is missing not at random. Data is missing at random when the reason it is absent has nothing to do with what it would have said. It is missing not at random when the reason it is absent is bound up with the value you cannot see. His result is that in the first case you can ignore the gap and work with what you have, and in the second case you cannot, because the pattern of what is missing is itself carrying information.

A cancelled meeting is missing not at random. The reason the record is absent is the exact thing the record would have told you. The 1:1 is off the calendar because the manager is avoiding it, and the avoidance is what a good 1:1 record would have surfaced. You cannot treat these absences as clean gaps to skip over on the way to the meetings that did happen. The gap is the finding.

One cancellation is noise, four is a sentence

None of this means every cancelled meeting is a crisis. Most are exactly what they say they are. Someone was travelling, a launch ate the week, two calendars could not agree. A single cancellation carries almost no information, and treating it as if it did would make you insufferable to work with and wrong most of the time.

The signal lives in the repetition, and repetition is exactly what no single instance shows you. Week one, the meeting moved. Week two, it moved again. Each week on its own is a reasonable one line note that nobody would flag. It is only when the notes are stacked that the shape appears, and by default they are never stacked, because there is nothing to stack. Four absences do not sit next to each other anywhere. They are four separate moments where nothing at all was written down.

So the unit that matters is not the meeting, it is the series. The question work memory should be able to answer is not what happened in Thursday's sync, it is how many of the last six Thursday syncs actually took place, and it should answer that as readily as it answers what got decided in the ones that ran. That means treating a recurring slot as a thing with a history and an expected cadence, so the difference between expected and actual is something you can query instead of something you have to happen to remember.

Three honest readings of a meeting that will not stay

Once you can see that a meeting has been cancelled four times running, there are really only three explanations, and they ask for different things.

The first is that it is over. The work the meeting existed for is done or dead, and the cancellations are the team voting with their feet before anyone has said so out loud. The move is to end the meeting on purpose, which is a different act from letting it sit on the calendar in a state of permanent maybe. The second is that it is stuck. The work is alive but blocked, and the meeting keeps getting cancelled because there is nothing to report, which feels like a reason to skip and is actually the reason to hold it, since a blocked project that stops meeting loses the one venue where the block would have been said aloud. The third is that it is being avoided. The meeting is a hard conversation, a struggling report, a decision nobody wants to own, and the repeated deferral is the avoidance made visible. This is the reading where the non-event matters most and is least likely to ever be looked at.

You cannot tell which of the three you are in from a single cancellation, and often you cannot tell from inside the situation at all, because the person doing the cancelling is the least neutral reader of their own pattern. What you can do is notice that the pattern exists. That is the entire problem, because the pattern is the one thing that leaves no trace.

Show it to the person, not to a dashboard

There is a wrong way to build this, and it is worth naming because it is the obvious way. You could point a system at everyone's calendars, count cancellation rates, and hand managers a leaderboard of who skips their 1:1s. That is surveillance, it will be read as surveillance, and it will teach people to hold hollow meetings to keep their numbers clean, which destroys the exact signal you were trying to read.

The version that works points the same fact at the person who owns the meeting. The manager who has cancelled a 1:1 four times is usually the last to notice they have done it, because each cancellation was a separate reasonable call on a busy morning. A quiet note to that person, you have not actually held this in a month, is a prompt to a human being who can then decide what to do with it. The same fact is a tool in one place and a weapon in another, and the difference is only who gets to see it first.

This is a specific case of a wider rule about work memory. A record of what is not happening is more sensitive than a record of what is, because it sits closer to intent, and intent is the thing people are most entitled to control. The right default is that your own gaps are visible to you before they are visible to anyone above you.

Where Driffle fits, and what it does not solve

Driffle captures meetings without putting a bot in the room and turns them into searchable work memory, and the same substrate that makes the meetings that happened searchable is what makes the meetings that did not happen legible. If a recurring slot is a first class object in the record rather than a fresh unrelated event each week, then how many of the last six instances actually ran becomes a question the record can answer, and the ones that did not run show up as gaps in a known series rather than as nothing at all.

What it does not do is tell you which of the three readings applies. Over, stuck and avoided look the same from the outside, and sorting them is a judgement about your own team that no record makes for you. What the record does is get you to the point of asking the question, several weeks earlier than you would have arrived on your own, and that is most of the value here, because the failure is almost never acting on the wrong reading. It is never noticing there was a question to ask.

It also does not remove the need to keep holding the meetings that are a non-event only because they are quiet. A weekly sync that runs every week and is a little dull is doing its job, and the lack of drama is the point of it. The goal is not to treat every gap as an emergency. It is to stop treating gaps as nothing.

A check worth running this month

Take the recurring meetings you own and, for each one, count how many of the last six scheduled instances actually took place. Not how many are on the calendar. How many happened. If you cannot answer without guessing, that is the first finding, and it is the finding this whole piece is about.

For any meeting that ran three or fewer times out of six, write down which of the three readings you think applies, over, stuck or being avoided, and then do the single thing that reading calls for. End it, unblock it, or have the conversation. Do not leave it in the maybe state, because the maybe state is the one that generates four more weeks of silent absence and no decision.

Do this once and you will find at least one meeting that should have been ended a quarter ago, and at least one you have been quietly avoiding without having admitted it to yourself, which is exactly the thing the record was never going to volunteer until you went and asked it a question shaped like an absence.

Sources

FAQ

Isn't a meeting that gets cancelled usually just a scheduling problem?

Usually, yes. A single cancellation carries almost no information and you should not read anything into it. The claim is narrower and only about repetition. When the same recurring meeting is cancelled or moved most weeks over a month or more, the pattern stops being logistics and starts being a signal, and it is a signal that lives nowhere, because each cancellation was recorded as nothing. The point is to notice the run, not to treat every skipped meeting as meaningful.

How is this different from just looking at my calendar?

The calendar shows what is scheduled, not what was held. A recurring meeting that is cancelled every week still appears every week, and a series of cancellations and reschedules is hard to reconstruct from the calendar after the fact because each change overwrites the last. The calendar also cannot tell you which cancellations mattered. Answering how many of the last six actually happened needs the recurring slot treated as one object with a history, which is a record question rather than a calendar question.

Doesn't tracking cancelled meetings turn into surveillance?

It can, and that is the wrong way to build it. Counting cancellation rates across a team and handing the numbers to managers is surveillance and will be treated as such, and it pushes people to hold empty meetings to protect their stats. The version that works shows the fact to the person who owns the meeting first, because they are usually the last to notice their own pattern. A record of what is not happening sits close to intent, so the default should be that your own gaps are visible to you before anyone above you sees them.

How many cancellations count as a real pattern?

For a weekly meeting, three or more missed out of the last six is a reasonable line to start looking, which is roughly a month. Fewer than that and one unusual stretch dominates. For a monthly meeting the same idea holds over a longer window, so two or three misses in half a year is worth a look. These are thresholds for asking a question, not verdicts. The number tells you to look, and a human decides what the pattern means.

If a meeting keeps getting cancelled, should I just delete it?

Sometimes, but not by default, and deleting on reflex throws away the information. A repeated cancellation has three readings. If the work is genuinely over, ending the meeting is right. If it is stuck or being avoided, deleting it removes the one venue where the block or the hard conversation would have surfaced, which is the opposite of what you want. Work out which of the three you are in before you decide, and only then end it or reinstate it deliberately.