Death by Meeting

It was the end of a day of back-to-back meetings. Andrew and I were unwinding by the pool table in the break room. "I feel spent," I said. "Really? I'm pumped," returned Andrew. We both smiled. It had been a good day. A very, very good day.

The reason I was exhausted wasn't because we had spent the afternoon in mind-numbing checkbox-ticking agenda-filling meetings. It was because we had spent the better part of the day in a series of highly focused working sessions. Out of the six hours I spent in meetings that day, I don't think a single minute could be classified as "wasted time."

In fact, this is the norm at Revolv. I'd like to say that it's because we don't really have meetings, but that's not the truth. The truth, I've come to realize, is that our meetings are just well designed and well implemented.

In his book Death by Meeting, Patrick Lencioni explains that meetings aren't an organizational evil that should be overcome. Rather, the meeting is a critical function of any company. It is (or should be) the space in which important decisions are made. (If you've never read the book, I highly recommend it. Honestly, it was more engaging than the last few novels I read.) Lencioni's primary thesis is that meetings can and should be engaging and interesting. Like the plot of a movie or TV show, meetings should have tension and conflict.

Lencioni suggests four different kinds of meetings:

• A daily sync-up
• A weekly tactical meeting
• A monthly strategy meeting
• Infrequent (quarterly, bi-annually, or yearly) retreats

Lencioni is speaking primarily to executive teams, and our group of engineers is definitely not in that category, but I have been surprised to discover that our meetings break down along the same lines.

We use scrum-style meetings to sync up. We don't do this every day anymore. But we do it three times a week. These last minutes, and are highly focused on yesterday, today, and tomorrow.

Once a week we have a tactical meeting. The focus of this meeting is the mechanics of our current engineering schedule. We talk about challenges, progress, and pressures both internal and external. We talk about releases, support issues, and features. The meeting is always fast-paced, and everyone participates.

On the tactical side, we also have ad hoc topical meetings (as Lencioni suggests, but doesn't assign a name). When, for example, a complex modification to code is needed, we will often set up a meeting to discuss the implications and develop a process for solving the problem. These meetings, too, are highly focused, and do not veer off topic.

Our strategy meetings are probably less frequent than Lencioni's suggestion. We probably do them once or twice a quarter, often after a major release. For example, we kicked off the new year with a cluster of strategy meetings. And they have been absolutely fantastic.

Our strategy meetings run basically as Lencioni would suggest:

• Focused: Each meeting covers only one or two topics,
• Conflict-oriented: We use these meetings to address topics that we tend to have different opinions about, and we expect disagreement.
• Driven: We always make it clear why the problem we are trying to solve is important to our product. And we only have meetings about important things.

Even while we don't come out of every one of these meetings with unanimous agreement, we do come out with a clear path forward. From that point on, we can focus on the tactics of implementing the strategy, and not rehash the same differences over and over again.

Back to the pool table discussion with Andrew: At the end of the day, I was tired because I had laid it all out in the meetings. I was tired because I'd been active and engaged for hours. Andrew, too, was probably tired. But he was energized because we'd addressed some pretty major topics. And we had come out of the meeting with plans. Big plans. To me, this is what the end of a day of meetings should feel like.