Not Rocket Science (Meeting Edition)
Have you ever been in a meeting that you felt was poorly run?
How about a meeting where you felt you were underprepared because you didn’t fully know what was going to be discussed?
Have you been hesitant to take a holiday on a particular day because you didn’t want to miss what would be discussed in a meeting that day, even though it didn’t require active participation from you?
Have you ever wanted to skip a meeting but you attended it, to be on the safe side that you didn’t miss anything that you may need to know?
Have you ever lost track of why a decision was made in a meeting?
Have you ever spent a large fraction of a meeting wondering to yourself why it was a meeting and not an email?
Have you ever zoned out during a meeting, maybe because someone was speaking for a while without any interruption?
Have you ever felt too awkward to ask someone questions about what transpired during a particular span in the meeting when you zoned out?
Chances are, if you’re anything like me, you’ve at least encountered some of these problems before. Maybe all of them. Meetings are sometimes really good. Sometimes they’re terrible and feel like a waste of collective time.
You know what else feels like a waste of collective time? When the CI is broken due to some failure which was introduced but not checked in PR testing, preventing people from landing their patches. In the context of CI, Graydon Hoare has this fun blog post from 2014: “Not Rocket Science” rule of software engineering. It proposes the following:
The Not Rocket Science Rule Of Software Engineering
automatically maintain a repository of code that always passes all the tests
You can read the post for details, but my takeaway from it is that it
is intended to save collective time at the expense of individual time.
Also, it’s not a particularly genius idea; it requires some setup and work
but it should be doable for many teams.For a more nuanced take on the topic, check out Jane Street’s
Making “never break the build” scale.
I’d like to propose a similar rule for meetings.
The Not Rocket Science Rule of Meetings
Planned meetings of three or more people should be accompanied by shared, written and persistent meeting notes, consisting of an agenda before the meeting, and added minutes after the meeting.
Let me break down the rule piece by piece.
Planned meetings: So this rule applies only to meetings scheduled ahead of time, not to impromptu meetings that may arise, say because you were having some discussion and decided to hop onto a call to hash things out. (Or the in-person equivalent, where you’d discuss things on a whiteboard.)
three or more people: So this rule doesn’t apply to 1:1s. (Although, I do think that 1:1s benefit from having some talking points written down, in some situations, it can be helpful to have a more freeform conversation.)
shared, written and persistent meeting notes:
- shared: The meeting notes should be shared with meeting invitees. (Ideally, I think the default ought to be anyone who could potentially be interested but different organizations default to different levels of transparency.) Note that I’m deliberately saying “invitees” and not “attendees”; if someone is unable to attend the meeting, they should still have access to what was discussed.
- written: The meeting notes should be written down, so that they can be easily stored, searched and cited. For example, this rules out things where the agenda and minutes are communicated orally at the beginning/end of a meeting, but not written down (even if the meeting is recorded and has some automatic transcription).
- persistent: Meeting notes should be recorded in a place where they may be accessed for an indefinite period of time. This makes it possible for people to revisit decisions and rationale later, externalizing organizational memory. For example, this (weakly) rules out using chat platforms like Slack as the primary medium for sharing meeting notes, as chat platforms are notionally ephemeral even though technically they may have infinite storage.
agenda before the meeting, which should at least include:
- What topics will be discussed.
- What questions need to be answered.
- Links to relevant prior discussions for context.
Having an agenda ahead of time has a few benefits: - It lets people decide if they can skip the meeting. This is especially useful for recurring meetings with more than a handful of attendees. - It lets people prepare ahead of time in case they need to. For example, someone may be catching up after returning from a vacation. Or someone may recognize that it would be useful to collect more information for a particular point on the agenda to improve the quality of discussion. - It makes everyone aware that certain points need to be discussed, arguably reducing the risk of too much time is spent on one agenda item to the detriment of other items. (I don’t have hard evidence for this, only a gut feeling)
Note that I am not implying that the agenda must be read by attendees before the meeting. The specifics of that depend on company culture and how busy the attendees are (and if said busyness is culturally an acceptable reason for not reading the agenda before the meeting).
minutes after the meeting, which should at least include:
- What decisions were made, including a summary of the discussion. For example, if a decision was made to do X instead of Y, but there were discussions of pros and cons of both X and Y, then all of those should be noted to provide context.
- What follow-up actions need to be taken and by whom.
More details such as ancillary points that were not relevant to the main discussion may also be noted down, but generally, I haven’t found it worth the effort.
In some cases, I have seen people recommend that someone else other than the meeting organizer should take minutes, so that the organizer can focus on keeping the meeting on track, preventing anyone from taking up too much time or going off topic, and making sure that different people are heard. In my experience with organizing meetings, it is indeed a bit chaotic to try to do both at once, but I try to work around that by:
- Pausing and double-checking with folks whether some notes are correct (these are visible either via screen-sharing or via a shared doc).
- Asking for clarification in case I only half-caught something.
- Defaulting to having the meeting notes editable by all attendees, and at the end, I ask attendees to add things in case I missed something.
- Doing a short polish pass to make the minutes more organized after the meeting. With some practice, I think this works out alright.
Now that I have described the rule itself, let’s revisit the problems from earlier:
Have you ever been in a meeting that you felt was poorly run?
Now, to be fair, the Not Rocket Science rule cannot magically fix a poorly run meeting, but I think that it can provide more structure and reduce the chance the meeting is run poorly in the first place.
How about a meeting where you felt you were underprepared because you didn’t fully know what was going to be discussed?
You can prepare for the meeting because you have an agenda ahead of time.
Have you been hesitant to take a holiday on a particular day because you didn’t want to miss what would be discussed in a meeting that day, even though it didn’t require active participation from you?
Since minutes will be available after the meeting, you can take a holiday without being stressed out about missing something important.
Have you ever wanted to skip a meeting but you attended it, to be on the safe side that you didn’t miss anything that you may need to know?
You can look at the agenda and decide if you want to skip or not. You can skip the meeting while being reassured that you can read the minutes later if needed.
Have you ever lost track of why a decision was made in a meeting?
This should be written down in the minutes.
Have you ever spent a large fraction of a meeting wondering to yourself why it was a meeting and not an email?
Again, the Not Rocket Science rule cannot prevent someone from having a meeting which is primarily communicating information in one direction. Arguably, in certain situations/organizations, it may be valuable to have meetings for largely one-way communication. For example, maybe the attendees are known/expected to miss some emails, but you really do not want them to miss some information.
However, it’s possible that once the agenda is sent out, someone can chime in and ask if most of the information can be sent out via email (or written down elsewhere), and the meeting can perhaps be cut down in duration.
Have you ever zoned out during a meeting, maybe because someone was speaking for a while without any interruption?
The Not Rocket Science rule cannot prevent someone from going off on a long tangent, but I think having an agenda shared on a screen makes it easier to be cognizant of what else needs to be covered. It is still up to the organizer or someone else to step in and put a pause on a monologue before it takes up too much time.
Have you ever felt too awkward to ask someone questions about what transpired during a particular span in the meeting when you zoned out?
Well, you can check the minutes! This should likely have your covered. If it’s not written in the minutes, there are a couple of possibilities:
- It was not important: Well, then it wasn’t too bad that you missed it.
- It was important: Great, you just uncovered a bug in the minutes, and once you have an answer, you can go add that.
So overcoming your awkwardness has some chance of either being completely innocuous or being somewhat helpful.
Since I am a physicist by training and not a thought leader, it behooves me to describe some situations in which this system doesn’t work as well.
- You have LOTS of meetings: Writing an agenda and minutes involves a fair bit of work. Doing it repeatedly can get exhausting.
- You have back-to-back meetings with no buffer time to tweak minutes: In my experience, the time right after a meeting is the best time to tweak the minutes, to add any points that were discussed near the end but weren’t written down, as well as to reorganize the notes in a format that can be easily skimmed and read later.
All in all, I do think that applying this rule is generally a good idea. But yeah, it’s not magic. Also, I have a little bit of experience applying this rule (about 2 years), not a lot. I don’t know what your organization looks like and what it values. I recommend using your best judgement before running other people’s software on your devices. :)