If humans are truly social animals with an innate need to interact with others, then why do we hate meetings so much? And if meetings are bad, then why do we find extended offsite sessions even more brutally intolerable? With offsite planning season soon upon us, such questions are worth asking and answering…and just maybe…offering some tips to ease the pain.
First things first, meetings are unbearable for thousands of reasons. But they all come back to one simple idea: opportunity cost. We’re all busy, with far more responsibilities than time to manage them. And we’re haunted by the excruciating realization that time spent in meetings could be far better invested in other pursuits. But what if that didn’t have to be the case?
Much has been written about ways to make meetings more effective, with innovative companies like Google, Amazon, and Bridgewater each having its own unique approach to meeting management. This post attempts to contribute to that impressive body of work by offering one simple tactic that has consistently helped improve our own meetings and offsites over two decades and many businesses.
We call it a “pre-mortem,” and it’s based on the concept of a “post-mortem.” A post-mortem is an examination of a dead body to determine the cause of death. In the context of business, a post-mortem is a common project management practice in which a critical retrospective is performed to learn what went right and (primarily) wrong in a given initiative. In other words, what was the cause of death? We’ve taken that same concept and put it at the beginning of the process when hosting a meeting. A pre-mortem pre-emptively asks the uncomfortable question: what could possibly kill this meeting?
The way it works is simple: the meeting leader starts the meeting by asking each attendee what would make the session an abject failure for them. Then, each person let’s fly with their worst fears about how the meeting could turn into a slow-motion car crash. The meeting organizer captures the shared comments on a large, visible white-board or sticky-note. Next, the group takes the time (usually 10-ish minutes) to discuss the comments, often with clarifying questions and conversations about how these failures might occur…and what can be done to avoid them. Importantly, the group commits to work together to avoid the negative outcome. The meeting ultimately commences and proceeds in an otherwise typical manner, with the pre-mortem being the last item revisited (again, for about 5–10 minutes) prior to adjourning. We’ve found the results of this to be…well…really good. Is it magic? No, nothing is. Does it help to make meetings far less brain damage? Absolutely.
Before offering some thoughts on why this tends to work, let’s first explore a “dirty dozen” of the comments that commonly appear on these lists. In no particular order, responses include:
There are countless other issues that people have with meetings, but this is a pretty good representative sample.
Now…why is this approach so effective? One undeniable reason is that naming problematic behaviors or practices tends to put people on notice — don’t be this person! More than that, it gives us a spoken, commonly, acknowledged, up-to-the-minute benchmark against which to hold people accountable if they violate the boundaries. This also provides a language and a tool to gently call people out when they do fall afoul (it’s easy to simply point to the sticky-notes when someone flagrantly blows through item #7). More than any of these though, people in growth businesses tend to “hate to lose” far more than they “love to win.” Said another way, it’s not enough to enumerate what GOOD meeting practices are — people won’t change their behavior to meeting that threshold. But no one wants to be the person who obviously fails to live up to basic standards of meeting professionalism. So they tow the line…and the collective behavior change makes for massively improved meeting outcomes.
Give it a try some time; and please let me know how it goes, what you learn, or how we can further refine and improve this approach.
