A Guide to Meeting Notes

Dan Hughes
March 27, 2023

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! 

Meeting Notes Content  

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: 


a guide to meeting notes

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:

  1. It gives everyone in the meeting a "speak now or forever hold your peace" redo on the decision and acts as final implicit approval if nobody barks.
  2. It ensures you understood the decision and provides a reference for you to process it into the decision log (see below).
  3. It reduces the likelihood that you need to re-discuss the topic and arrive at the same decision again in the future because nobody recalls what you decided!

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. 

Nothing Else 

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.  

Meeting Notes Delivery

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.

Collaboration Platforms  

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.

Get the information where it belongs  

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 guide to meeting notes

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.

Meeting Notes Timing

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.  

When to Take Your Notes

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.  

Processing Your Notes

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.  

"That is not the decision you are looking for."

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!


Dan is the founder of Wittij Consulting. Prior to founding Wittij, he spent a decade in software development before moving into IT architecture, where he created an Open Group recognized architecture method and led delivery of all services for a company specializing in enterprise and solution architecture for 15 years. He is an energetic, thoughtful leader with an ability to engage and motivate people, and has been called a “force multiplier” for his ability to not only deliver great value, but also increase the value and capability of the people around him. Dan is a strong facilitator, able to understand and resolve complex disagreements with diplomacy. He comprehends and communicates clearly both at the detail level and the boardroom summary level to both business and technical audiences. His knowledge of enterprise techniques and technologies is broad and deep, and includes industry expertise in manufacturing, financial services, banking, health care, insurance, regulatory compliance, and NGOs.
Copyright © 2024 Wittij Inc.
crossmenu linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram