Orgflow 6: Notes on Minutes and Communications

Being good at organization is a blessing and a curse. It’s a blessing as it allows you to feel more in control of what is coming on the horizon. It’s a curse because if people find out you can do it well, it can often translate to more work. As in, people tend to give work to those who seem like they can manage it.

In the past few years I have spent a lot of time on service committees and have had the chance to really improve some of my organization skills. The process that started with taking notes during our LSU Music Cognition and Computation Lab’s weekly meeting is now in a much more mature form while helping organize the Musicality and Genomics Consortium and some work last year chairing SMPC’s Anti-Racism and Equity Committee.

There are a few things that I do in order to organize meetings that I think sharing can help others. In particular, I am thinking about several of the graduate students that I work with, as learning to be more efficient in this realm is a great skill to learn during grad school. These ideas align with many of the orgflow and GTD principles that I use, so everything here should be read in context of that.

A common location for all projects

The first piece of advice that I have found invaluable is for each project or committee , there needs to be a single place that holds both capture and actionable items for any stakeholders on the project.

Ideally this document is immediately accessible to all members of the team, possibly pinned to the top of some Slack or Teams channel. Having only one person (a chair, secretary) have access to this might be fine, but sharing it allows all team members to have a location to just dump in things as they come in.

Things should be dumped under a Capture heading. Things are fragmented thoughts, jotted down notes, links, stuff that you know needs be formed into an actionable item or might be valuable reference materials, but exactly what to do with it is not quite clear yet. I also sometimes use this space as a location to dump points that need to be covered in an upcoming meeting (kindling for an agenda) so the dreaded “we are having a meeting but not sure exactly what to do” feeling does not arise.

Above or below the Capture heading is the Actionables heading.

I’ll discuss a bit more of this in detail below, but the main point is that this is a collection of well formed next action steps that have all relevant details in some sort of bullet form.

With this infrastructure in place, only then is it time to have most types of meeting. Why? Because the bounds of the project have at least been determined. If it feels pre-mature to set up this infrastructure, then be careful before committing to a new project!

No agenda, no meeting

Next comes the actual meeting itself, where I hold my hottest take:

You should not have meetings without agendas. No agenda, no meeting.

I first came across via Greg Wilson while doing my Posit tidvyerse training and this belief has now been cemented since it’s common practice at the Music Cognition Group.

In addition to having an agenda, I also strongly suggest having some sort of leader or chair of the meeting, or what I jokingly refer to as the taskmaster. This also is inspired from Greg’s notes above.

The taskmaster’s main responsibility is to make sure all of the points of the meeting that were agreed upon ahead of time are covered in the time allotted for the meeting.

I think it’s good to try to get a reputation as being a bit time obsessed, as it is astonishing how many people (if you are good at this) will message you after meetings to applaud you for making sure meetings does not run over time.

Having an agenda also helps the chair limit discussion to those who actually prepared for the meeting (adding to the agenda ahead of time) and prevents someone from high-jacking the discussion. The post that Greg wrote also talks about several other great points to avoid this type of behavior.

It’s important to note that when picking a taskmaster, power dynamics will be at play and I get why PhD students might not feel good about prodding the conversation along. Though in some ways this is good exercise and space to do it, especially if the goal is to have better meetings.

One of the main goals of the PhD (in my opinion) is to have the PhD student become a peer by the end of their degree, and having this type of responsibility is great for breaking into that mental space since at the end of the day everyone wants to have less, more productive meetings.

Taking minutes

In addition to as chair or taskmaster, someone also needs to take notes.

I often act as both since I find that taking notes helps me stay engaged in the conversation and prefer to limit my talking in meetings, but listening and typing is a skill and to do both at once is hard. Ideally this is a shared responsibility (with everyone having access to the same document during the meeting) but in practice I think it’s better if one person is jotting down what is said.

What gets jotted down?

I find it’s helpful to have a header where who is in attendance is listed along with their initials and the date the meeting happened. Using initials also really helps speed up the process of who says what and ultimately who does what.

When I take notes, I usually make a second outline that mirrors the agenda’s structure, and start noting down anything relevant to the topic.

For example, if I am in a meeting with myself and a colleague (JAB) and we are talking about an upcoming ISMIR submission, the the first item on the agenda might look like:

I. Discussion of Workflow (5 min)

And then the minutes might look like:

I. Discussion of workflow

And this is done for each and every high level heading.

It can be helpful to have some sort of time estimations on the agenda, since some people are known to have no sense of time. More seriously, this also allows the taskmaster to point to the fact that during the meeting if we continue at the current rate, we won’t cover everything we wanted to (or we might end early!).

Collecting actionables

At the end of the meeting you should have a big pile of stuff that looks like TODOs but are not really TODOs.

In the example above, “JAB agrees, notes there is premium access if use UvA log ins” is one of those items. Just reading that, you could kind of guess what needs to happen next given the header and if you live in this world of acronyms, but it’s not crystal clear.

After the meeting, its important to and go through this list and turn each item like this into an clear action item.

For me, an actionable item must have a few key pieces of information:

It should list:

So in the example above:

Now becomes:

Note that what looked like one TODO is really two small things that were implied in the creation of this document.

I find this way of sharing much better than listing this as something like:

Why? Well, to make it explicit there is so much implicit knowledge bundled in “Make ISMIR template”. While this might be fine for teams and tasks that all are familiar with, I think this practice is better for many educational set ups since a lot of time time it’s not always clear what needs to be done and everyone appreciates knowing exactly what it means to complete a task.

Further, making tasks so explicit allows for anyone to do a task, regardless of who it was assigned to. Another person might see this task, realize they have the capacity to do it, and since it’s listed EXACTLY as it needs to be done, then someone else doing it would be a load off of my plate.

Listing exactly what needs to be done in this very small format also prevents any small preferences that need to be accounted for when doing the task. Being explicit allows for better delegation. We want to be able to delegate and work as a team.

This turning of stuff into actionables doesn’t take that long once you are familiar with it. As you get better at it, you can even write out actionables that you hear while taking notes if you always follow the format of:

Which makes the round up process easier.

After the meeting

After the meeting, the taskmaster collects all the actionables, puts them in the shared location where everyone has access, then all team members know what is needed to move the project forward.

Not every task needs to be assigned to an individual person, I also like using the ANY or ALL for WHO, which is both good and bad. Good since anyone can do the task, bad since this can turn into a classic prisoner’s dilemma. I think it’s better to use those sparingly and cultivate a culture around anyone being able to help with any items and maybe just noting if there is a change of who did it.

Once an item gets DONE, instead of deleting it, I prefer to use the ~strike through~ notation.

Why?

Because it’s satisfying to see what is getting done between meetings. It also sets a nice tone for the start of the next meeting to know that items that needed to get done got did (yes! productivity!) and everyone can easily see which items still are hanging or need to be re-negotiated.

A note on bluntness

Though sending your colleagues such a direct list of things to do (especially if you are more junior) can seem aggressive and blunt at first, if you want things to get done, anything you can do to cut down on “what is it I have to do and read” will make having things completed much more likely.

This is especially true if you are dealing with colleagues higher up on the academic food chain whose time and attention is continually splintered.

If you can deliver that needs to be done to people on a silver plate, cut up, and basically chewed for them, it will get done magnitudes faster.

Comment on this post on Twitter

#academia #gtd #orgflow #productivity #tips