The Efficient Meeting Hypothesis

This is a minor departure from my typical topics, but was something I wrote for work and wanted to share more widely.

Meeting efficiency drops off sharply as the number of people in attendance climbs. A meeting with two or three people is almost always a good use of everyone’s time. If it’s not, the people involved simply stop meeting. Meetings with 4-6 people are worse, but are still generally OK. Meetings with more than 6 people in attendance (counting the organizer) are almost universally awful.

Why are meetings inefficient?

People do not exchange opinions the way machines exchange information. As the number of people grows, so does the number of different opinions, the number of social status games being played (consciously or not), the number of potential side conversations, etc. Achieving consensus gets harder.

In my experience, six people is the limit for anything resembling a useful caucus-style meeting. Above six people, it’s less likely that a given topic (at a given level of abstraction) is of sufficient interest to everyone present. Tangential topics drift so far that by the time everyone has had their say it’s hard to get back on track. Side-conversations start to occur regularly. People who naturally think and speak slowly simply won’t get to speak at all since there will always be somebody else who speaks first.

Why don’t people exit useless meetings?

People mainly stay in useless meetings for two reasons:

  • a variation of the bystander effect where everyone assumes that somebody else must be getting value from the meeting, and nobody wants to be the first to break rank
  • a fear of missing out, because the topics discussed at useless meetings are often so variable (due to tangents and side conversations) it’s hard to know if maybe this will be the moment where something relevant is discussed

How to run an efficient meeting

Keep it as small as possible, and always under 6 people.

How to run an efficient meeting with more than 6 people

You can’t. But if you really think you *have* to…

Give your meeting a rigid structure. Note that this does not just mean “have an agenda document that people can add to ahead of time”. At the minimum you need:

  • A moderator whose only job in the meeting is to moderate (either the meeting organizer or somebody explicitly appointed by them).
  • A talking stick or some digital equivalent. Basically: an explicit process for deciding who gets to speak, and when. A good moderator can manage this entirely verbally for medium-sized groups, but it’s hard. Something explicit is much better.
  • A formal meeting structure and topic, set in advance.

Again, a structure does not just mean “an agenda” or “a slide deck” but some common conversational rules. Here is a list (definitely not exhaustive) of common or useful meeting structures:

  • Stand-Up: each person in turn gets a fixed amount of time (enforced by the moderator) to present to the group.
  • Presentation: one person presents for the majority of the meeting, and then (optionally) holds a question/answer session afterwards.
  • Ask-Me-Anything: the moderator works through a list asking pre-curated questions to specific people.
  • Parliamentary Procedure: this would typically be Robert’s Rules of Order.

Some common pitfalls:

  • Never try to make consensus-based decisions in a meeting with more than 6 people. If a decision has to be made then you must either:
    • Have a smaller meeting. OR
    • Appoint one person the decision-maker in advance, in which case the meeting is actually about presenting and arguing to that person, not the actual making of the decision. OR
    • Use a majority-rules process (typically a vote), in combination with a more parliamentary structure (Robert’s Rules of Order or others).
  • The moderator absolutely cannot talk about anything other than the meta-level (moderating) unless they also hold the talking stick. Ideally the moderator has no stake in the actual topic of the meeting to begin with.
  • The moderator cannot be “nice”. Shut down tangents and off-topics aggressively.
  • Avoid automatically-recurring large meetings like the plague. They shouldn’t be frequent enough to bother auto-booking them to begin with, and the manual process will make it much easier to stop holding them when they are no longer useful.

Theoretical Fun

The company I work for, like many other tech companies, has a thing where you get to spend a certain amount of your time working on projects of your own choosing. The most well known-example of this is Google’s now-defunct 80/20 rule but there are plenty of others.

This past week I had an opportunity to do some of this, and ended up brushing off my very theoretical computer science roots and digging into some graph theory in order to solve a very practical problem. Of all the things I get to do in software, this is far and away my favourite, and I had a blast working out the possible solutions.

In my career so far I’ve been lucky enough to have several opportunities to solve problems of this nature and then build out the solutions, and even publish some of them to talk about. It is extremely rewarding work. There are of course a few I can’t talk about as they are still internal, but here’s a sort of “hall of fame”: two other problems that I had a ton of fun solving at a computer-science-theoretical level and also resulted in really awesome (and sometimes popular!) practical solutions.

Wheel-of-Fortune Memory Allocator

https://github.com/eapache/wof_alloc

Arguably the overarching project here was Wireshark‘s wmem framework which I also designed and built, but while wmem was a lot of fun to work on it wasn’t particularly novel; it was just another memory pool library with a few minor tweaks to suit Wireshark’s use case and migration path. However, Wireshark’s unique memory allocation pattern demanded a custom allocator algorithm which I eventually extracted into this library.

As far as I can remember this was the first practical problem of this nature that I got to take the entire way: from identifying the problem, designing the solution, to building and shipping it, and I am forever grateful to the Wireshark core team for trusting a (at the time) university student to go and rewrite the deepest foundational layer of the project. At just under 1000 lines of pure C this allocator has been shipping in released versions of the project for 5 years now effectively unchanged, and the standalone version gets a fair number of hits on GitHub.

Sarama Async Producer

https://github.com/Shopify/sarama/wiki/Producer-implementation

A little while later, my first major project at my current job was to write a golang client for the Apache Kafka platform. Like wmem, a lot of it was pretty standard work (in this case implementing message formats and managing TCP connections). However, the design of the producer implementation was another one of these instances of theoretical fun. The requirements on a performant Kafka producer are complex and varied, balancing messages and batching across topics and partitions and brokers, while also maintaining message order in the face of partial failures and retries. I can’t tell you how many evenings I spent wandering around in a fog, stopping occasionally only to make tweaks to weird hypothetical flow diagrams on my whiteboard.

To a certain extent this project was less practical than the allocator; the reference java implementation was open-source and would have been fairly straight-forward to copy, but I did it myself for two main reasons:

  • I was working in Go, which provided me with very different concurrency primitives and indicated a very different design.
  • I was young, and not as aggressively pragmatic at the time.

To a certain extent it was also less successful; it has continued to evolve over the last four years and there are still parts of the design that I’m not entirely happy with. That said, it’s also far and away the most complex single algorithm I’ve ever built, and judging by Sarama’s popularity, it’s doing its job just fine in practice. I even managed to get a conference talk out of it.

GraphQL Warden

https://github.com/rmosolgo/graphql-ruby/issues/1333

If you recall my recent post on what I’ve been working on recently for my “real” job, it won’t surprise you that my most recent project is tangentially related to that. This one hasn’t been built yet (and my own pragmatism means it may never get built) but even from a design perspective I had a lot of fun with the process here. I definitely got way too excited when I realized that I could represent the two halves of the process as symmetric reachability problems in a graph-theoretical isomorphism of the schema.

And just maybe, the next time I get a chance to spend some “me time” at work, I’ll write an actual implementation of it!