A few years ago, a colleague handed me a copy of Death by Meeting by Patrick Lencioni and said something like, “Read this before you run another meeting.” I did, and I have not run a meeting the same way since.

Lencioni’s book is short, written as a business fable, and easy to dismiss if you are looking for an excuse to do so. I almost did. But underneath the storytelling there is a clear, uncomfortable argument: most meetings are bad not because people are bad at meetings, but because nobody has decided what the meeting is actually for. We schedule the hour, we show up, we talk, we leave. Sometimes work happens. Sometimes it does not. We blame the calendar.

After reading it, I started asking a single question before I would agree to call a meeting, attend one, or let one of mine run past five minutes without a clear shape: what is this meeting for? (I had been thinking about meeting culture for a while; an earlier post on productive business meetings was the first time I tried to put it down on paper.)

The principle I came back to

Over time, the answer collapsed into something I can say in one breath. Business meetings must result in one or more of three things: solve a problem, make a decision, or share knowledge. If a meeting cannot honestly claim at least one of those, it should not happen. If it claims all three at once, it is probably two or three meetings pretending to be one.

This is not original to Lencioni. He makes a more elaborate case in the book, with different meeting types for different purposes. But the three-part test is what stuck with me, and what I have used for years now to discipline my own calendar and the calendars of the teams I lead.

The test is useful precisely because it is so narrow. “Status update” is not on the list. “Touch base” is not on the list. “Get everyone aligned” is not on the list, because alignment is an outcome, not a meeting type. If the only thing a meeting accomplishes is that people now know what other people are doing, that is sharing knowledge, and most of the time it can be done in writing, asynchronously, in a fraction of the time and at a fraction of the cost.

How I apply it at the Times

In the newsroom and across our technology organization at The New York Times, my calendar can fill itself faster than I can defend it. The default in any large organization is to add meetings, never to remove them. Every new initiative wants a weekly. Every cross-team dependency wants a standing thirty minutes. Within a quarter, your week is solid blue and you have not had a single hour to think.

So I started doing a few specific things, all of them traceable back to Lencioni’s book and the three-part test.

The first is asking, before I accept any new recurring invitation, which of the three the meeting is for. If the organizer cannot answer, I either decline or I propose we replace it with an email thread or a shared document. Most of the time the organizer is relieved. They scheduled the meeting because that is what people do, not because they wanted to be there.

The second is converting hour-long meetings to thirty or forty-five minutes by default. An hour is not a unit of work; it is a default in the calendar software. Most decisions and most problem-solving conversations either resolve in thirty minutes or get stuck and need a different format. Stretching them to sixty rarely improves the outcome. It just delays the moment when we admit we need more information.

The third is protecting time on my calendar that is not a meeting at all. Time to think, to read, to write, to plan ahead. I have come to believe this is one of the most undervalued kinds of work an executive does, and one of the easiest to give away. If I do not put it on the calendar, it will not happen, because someone else’s meeting will appear in that slot within hours.

Sharing knowledge is the most abused category

Of the three legitimate reasons to meet, “share knowledge” is the one most often used as a fig leaf. Almost any pointless meeting can be re-described as knowledge sharing. It is the loophole.

I try to apply a stricter version of the test for this category. Knowledge sharing justifies a meeting only when the knowledge requires interaction to land: when people need to ask questions in real time, when the material is sensitive enough that you want to read the room, when a demo needs reactions, when a teaching moment benefits from back-and-forth. If the knowledge can be conveyed by a memo, a recorded walkthrough, a wiki page, or a well-structured email, the meeting is theater.

There is a related point I have come to feel strongly about. When people are in a meeting, they should be in the meeting. Open laptops and phones in the room, on average, make people less aware of what is happening around them, less aware of the interpersonal dynamics, and more likely to make poor decisions. If the meeting is worth holding, it is worth attending. If it is not worth attending, it should not be on the calendar.

What changed

What changed for me after reading Lencioni was not a method. It was a willingness to be a little impolite about meetings. To ask, in front of people, what we were trying to accomplish. To end early when the work was done, and to extend or reconvene when it was not. To say, sometimes, “I do not think this needs to be a meeting,” and to mean it.

It costs something to do this. People sometimes feel pushed when you ask the question. The first few times you cancel a recurring invitation, the organizer takes it personally. But the cost is small, and the savings, in time and in attention, compound quickly. A team that meets less and decides more is a team that ships more.

If you have not read Death by Meeting, you can finish it on a flight from New York to Chicago. You will not agree with all of it. I do not. But it will leave you with a sharper question to ask yourself the next time you are about to send an invite or accept one. That question alone has been worth the price of the book a thousand times over.