Okay. I have another meeting article to get off my chest before returning to geekier solution architecture topics. I realize that meeting "judo" seems slightly out of my lane, but solution architecture is primarily a facilitation activity. That means managing meetings effectively is essential to being a solution architect. I covered some ground in prior articles, discussing scheduling meetings and running effective meetings. Still, one area left to cover is the humble meeting note - which I affectionately call the "recap" - often maligned and almost always underutilized. Let's get to it!
I often see meeting notes that are huge court transcriptions of everything that took place during the meeting. That dense narrative is only useful for defense when something goes wrong. Somebody can dig back through the transcription and find who was to blame and what someone missed. Most automatic meeting note generators create similar run-on transcriptions: so don't think they save you the effort of creating good post-meeting summaries.
Instead, if you want to leverage your meeting recaps for success instead of post-failure blame, your meeting recap should include the following information:
First and most importantly, the meeting recap should focus on any actions that resulted from the meeting. Each action should be numbered, clearly include who is responsible for the action, succinctly describe what that action is, and provide a target date for the action to be completed.
Another pro-tip here is that the action should be assigned to one and only one person, identified by name. I worked for many years with someone who used to say, "if multiple people own an action, then nobody owns the action." If multiple people are involved in completing the action, one should take the lead, and you can reference the additional people in the action description. I like to bold the action owners' names, so they POP!
The second thing that should be in your meeting recap are any decisions made during the meeting. You capture these for 3 reasons:
I also typically put the decisions I want to capture in the same numbered sequential list as the actions. The decisions should be brief, concise, and to the point.
The last thing I capture in the meeting notes is... nope: that's it! I guess if additional information is needed to remind people what took place during the meeting or to highlight some of the conversations, you can add super brief summaries of those, but only as a last resort. Keep this additional context setting to a minimum. Similar to creating solution architecture diagrams, anything in that meeting note that is not mission-critical to communicating your message (in this case, the actions and decisions) is a distraction that obfuscates what you are trying to communicate.
The delivery channel for your meeting notes will depend on how your organization shares information. There are many different modalities to publish the notes listed above.
My recommendation is that you want the whole thing to be as lightweight as possible. Your focus shouldn't be a beautifully formatted and structured document, it should be how you get those decisions to whatever decision log you have and get those actions onto someone's task list as soon as possible. That means expediency is important!
Email is still the great equalizer at most organizations where I work, so email is the most common modality for delivering the message. In that case, clearly and concisely use that numbered list as I indicated above. I always preface with reference to bolded action owners and add a "let me know if I missed or misconstrued anything." You need attendee buy-in on your recap - you may be the scribe, but the contents of the recap belong to all participants. I usually do a "reply all" on the meeting invite, as then the date and time of the meeting are automatically there, and I add my summary recap.
However, if your company works with some knowledge management tool, your notes can go there. This could be anything, including platforms like Confluence or Teams. Whatever collaboration platform your team is familiar with would be an acceptable delivery mechanism for your meeting notes. I would still alert your meeting attendees using the accepted notification channel for the meeting - e.g., an instant message or an email.
While the meeting notes provide a useful point-in-time summary of a discussion and share it out for feedback, it is important to get the information where it belongs as soon as possible. If there is a task tracking tool used by individuals or the organization, the tasks would go there. If there is a decision log someplace, the decisions should go there.
A set of meeting notes should always be a temporary staging area for the information en route to its final destination. This means if you make a decision in the meeting that affects your solution architecture, you should immediately update that architecture work product to reflect whatever the outcome of that decision was.
Meeting notes are not documents of record, so I would be careful about leaving information there too long. It is mostly to rapidly confirm with the discussion attendees that you correctly understood the outcome of the meeting and get validation from them.
The ideal time to deliver meeting notes is the moment the meeting ends. Much like atomic material, meeting information has a half-life and degrades over time.
The ideal time to deliver meeting notes is the moment the meeting ends. Much like atomic material, meeting information has a half-life and degrades over time. The longer you wait between the meeting and sending out your notes for validation from the people who attended the meeting, the less likely they (and you!) will remember the key points of the discussion to validate the notes.
The sooner you get them out, the more likely the meeting is still fresh in everyone’s mind. when everything is fresh in the audience's mind, they can also hit the ground running on the actions instead of trying to recall the context later.
The best practice is to capture your notes during the meeting. In many cases, you can even do it live, where people can see the notes, to get instant validation that you understood and heard correctly. It is a skill that you need to practice and get good at, however, so it can be a little nerve-wracking at first.
Note that you don’t want to do it live and in front of everyone if you cannot do it quickly because it frustrates the audience. But you do want to build the skills so that you can quickly capture that meeting information and send it out immediately following the meeting or as soon as thereafter as possible.
If you need time to process notes, be careful about stacking so many meetings that you end up forgetting exactly what you meant by your notes after the meeting when you go to put more concise notes together. You may then have to go back and listen to a recording, doubling the time you spend on the activity. In summary, if you take notes during the meeting, give them a quick clean-up, and send them out right after the meeting, it is better for you and for your audience.
Much like that I think solution architects miss an opportunity when they don't utilize risk to drive better decisions, I also think they miss the opportunity to guide the conversation when they don't jump in to capture meeting notes.
Since any solution architecture is a series of decisions, meeting notes provide a solution architect with a little more control to guide those decisions and ensure decisions are clear.
Even beyond the architectural benefits, everybody likes well-run, effective meetings and recognizes the value of people that can make them happen. So mastering these meeting skills doesn't just help with solution architecture design but can be a career booster!
