Being an employee of a large company crept up on me, like a frog getting slowly boiled in increasingly hot water. All of a sudden, I realized that I was spending most of my days in big meetings and small meetings, 1:1s and “status updates”, meetings where everyone tried to get a word in and silent ones where where everyone read each others’ “snippets” for the week. When I first left the big company life for a smaller startup, I was reminded that the problem wasn’t just in big tech.
Some companies do not suffer from an overproliferation of meetings: law firms, consulting organizations, heathcare firms. For service companies, the meeting is the work. But product companies — whether you’re making widgets or bits — should think of meetings as a cost of coordination.
Meeting overproliferation won’t stop a company from getting started, but will stop it from enduring. It’s a problem of success, and it’s a natural state of entropy as the company scales. In the beginning, there are no meetings: it’s just a mind meld between early team members who are all working in the same tiny room. Over time, formal “meetings” take shape, but they’re used sparingly. When the company hits 50+ people, meetings can be at risk of overpowering productivity.
Bad meeting cultures all flow downstream from a slow deterioration of company culture in favor of the average business norms in mediocre companies. In one terrible manifestation of meeting culture, every employee is in constant meetings where no work happens. In another terrible manifestation of meeting culture, every employee fights to get into meetings because they’re where the real decisions are made. In some ways, you can’t live with them nor can’t live without them.
I had never seen a guide to meetings that made sense till I stumbled upon an old document at Stripe that suggested a set of guidelines for meetings. This set of guidelines felt like the exact right way to operate your company or team, but only possible if someone was actively preventing the natural state of meeting entropy and overproduction. When it was my turn to run a team, I resurfaced that same set of principles and operated my team with those norms. When I’m advising friends who run teams and companies about putting the right meeting culture in place, I find myself bringing up these same principles over and over.
Here they are:
Meetings are a tool to be used with caution. Whenever you call a meeting, first think about whether you're calling it for the right reasons, or if the task you’re trying to accomplish could be resolved in another meeting or async. Meetings are useful because they increase the communication bandwidth between the involved parties. But like many useful tools, they have pitfalls: they cause interruptions in people's days, they demand attention from all participants even when people aren't needed the whole time, and they don't create value on their own (that is, the value is created by subsequent actions to build or do things).
Meetings are good for navigating implicit space. If there is unequal distribution of context such that reasoning together would be useful, meetings can be the most effective way to do that. It’s a nice way for everyone with a picture of one part of the elephant to put all of the pictures together. However, if everyone shares the same context, emails are often a much more effective tool for driving agreement.
Meetings should not be a tool for asserting priorities. Important initiatives should only get meetings if they need them. Putting a meeting on the calendar is not a way to ensure that an important thing gets worked on — in fact, it can be counterproductive to progress.
Meetings require prep to be useful, and if you’re attending the meeting, you should do the prepwork: it’s a part of your responsibilities. If you think it’s onerous/unnecessary, give the feedback on the prepwork to make things better. If nobody’s doing the pre-read/people are coming to meetings unprepared, it should be confronted as an issue. Getting people into the same room has a high bar for “usefulness” — everyone silently typing on their computer is not useful.
Devon Zuegel had a great guideline for the minimum bar of meeting prep time for meeting attendees: .10(meeting length * number of attendees). If I’m attending a 30 minute meeting with 3 total attendees, I should prep for a minimum of 9 minutes. If I’m calling the meeting, I’d make that 25% of the meeting’s duration: I should prep for ~23 minutes.
We should always be ready to iterate on meetings. Watch out for meetings which are going in circles, or are not clearly tied to making some action happen as a result. They likely should be culled.
Meetings should never be an exclusive forum for information sharing. You don’t need to be at the meeting to simply “learn about something.” Information should be shared in writing, and it's usually worthwhile writing up notes and sending them out via email — people really appreciate being able to keep up-to-date, and it's also good to record decisions or action items for the future.
Meetings where the exclusive purpose is “status sharing” should be culled. Sharing information should be an asynchronous behavior. “Everyone is silent, reading and typing” in a meeting of more than 3 people is an explicit sign that the meeting needs revision.
Make sure meetings have all of the people needed to make a decision or actually implement the thing. If you’re a required attendee, it’s your responsibility to go, move the meeting, send a deputy, or respond. There's nothing worse than coming to a decision in a meeting, but then realizing an affected party was left out, leading to reversal or revision of the decision.
Balancing this, try to limit the number of people in a meeting. Go to a meeting because you'll add to it (or, especially in your early days, learn something from it). It’s fine to say that you’ll add nothing to a meeting and designate someone to represent your view. Don't go to a meeting because of ego.
For decision-making meetings, try to walk away with an emphatic decision that's clear to everyone present. If there are outstanding dependencies before making the final decision, make sure that the decision tree has been determined in advance.
Meetings to build team camaraderie are special — they often don’t need to adhere to many of these rules. We should be extraordinarily conservative on how often we have “meetings” exclusive to this purpose, and how much time we dedicate to this alone. One good “correction mechanism” is to think about whether this needs to be a “meeting” or could be channeled into something more fun that isn’t formally a meeting (team hangout, team lunch, team demos, fun offsite) instead. “Fun” sessions are a much better way to build camaraderie! (If you adhere to the Kathy Sun School of Management, “hardship” is an even better way to build camaraderie, so go organize a team hackathon or ice climbing adventure.)