Broadcasting your meeting notes to influence a wider audience
In a previous topic, Sending doc status reports – a tool for visibility and relationship building, I explained how to create and distribute documentation reports. Another tool for accomplishing a similar purpose — that of making others in your company aware of documentation processes, newly published articles, how to work with your team, etc. — is to broadcast your meeting notes after each meeting. Although sharing meeting notes with meeting participants after the meeting isn’t anything new, with a few small adjustments, especially broadening your distribution list to those outside the meeting, your notes can be a powerful way to influence those around you.
The basic process
The basic process of sharing meeting notes hardly needs explanation. It’s mostly just a bit time-consuming and might put you out of your comfort zone. First, you need to determine which meetings you’ll generate notes from. Usually, you have some meetings with partner engineers, meetings with other teams publishing in your dev portal, meetings with your own team, and meetings with some teams for high priority projects. Decide which meetings you’ll distribute notes for. Select the meetings where you focus on docs and topics others might care about.
Each meeting should have an associated meeting doc. You or someone else takes notes during the meeting. (Hopefully, in this same doc, you have an agenda to prime the meeting’s focus and discussion.) Afterward, you type up the meeting notes and send them via email to all relevant groups. The relevant groups are usually broader than the meeting attendees, and that’s part of the strategy. That’s really all there is to it, though I’ve expanded on some more aspects of the process below.
Meeting notes are often more interesting to read
Meeting notes provide a natural story foundation to build around. Usually, meetings involve discussions of issues. In writers’ terms, issues are really conflicts. And as all writers know, conflict drives story, and story engages readers. This is why you might find that typing up meeting notes is more fun than writing documentation reports. You can describe real issues you’re running up against, strategies you took to solve the issues, outcomes, and more.
With each meeting, you’ve got the foundation for interesting content. Now you can shape and leverage this content to provide other themes and messages that you want to get across.
What if sensitive topics are discussed during the meeting?
As with any real issues, the matters discussed might be sensitive. If people are complaining about what a pain it is to work with Frank (who wasn’t in the meeting), you probably don’t want to highlight that in the notes broadcast. You’ll have to incorporate some euphemisms around sensitive topics. For example, don’t write, “Some writers said Frank is impossible and should not be leading the publishing tools project,” but rather “Some writers noted some challenges in collaboration in the beta process with the new publishing system.”
As you get into a rhythm of sharing meeting notes after the meeting, people might begin to recognize that anything they say might be shared with others outside the meeting. This fear can be a detractor for people opening up during the meeting, so make sure you don’t expose anyone in a way that would be inflammatory or embarrassing. For example, don’t write, “John said he can’t stand working with the ACME engineering team because they never review his docs, so he seems to have deprioritized their project.” Instead, tone it down: “Some members noted challenges in getting timely doc reviews; getting ignored until the last day before release can be demotivating and create unnecessary crisis situations.”
On the flip side, sometimes surfacing issues is a good thing, as it forces the issues into open daylight where some action can be taken. It doesn’t make sense to hold everything inside all the time, fuming in silence. One of the purposes of sharing notes is to effect change. If you have an ugly issue to deal with, sometimes writing about it with transparency and honesty is a good approach, even if it ruffles some feathers or induces pain. For example, “Writers were unable to get timely reviews from the ACME engineers, which caused us to shift priorities to groups that value our time and energy more.” A sentence like that might send shock waves into the ACME group, but hey, you wanted change, right?
The structure of meeting notes
The meeting notes tend to have the following basic components:
- Meeting title
- Meeting date
- Meeting attendees
- Meeting description
- Meeting topics and discussions
- Action items
In the list of attendees, use company aliases so that others can get more context. If you just list first names (Dave, Sue, Ashwin), others might not know who you’re referring to. If you have aliases in the attendee list, you can simply refer to people by their first names within the notes.
You might also provide a brief description of the meeting’s purpose. Write this from the mindset that others who don’t know your team, who you are or what you do, etc., will be reading it. Don’t just write “Doc sync” but rather “Doc sync with partner engineers for the ACME project to identify doc needs and issues as well as coordinate review and publishing.”
How long should the meeting notes be?
Remember that others will lack the context of those in the meeting. Even those in the meeting might not have been fully following the discussion and details. Take the time to fill in the blanks. This might mean the meeting notes consist of longer, more narrative summaries. Make the content skimmable with lots of subheadings and short paragraphs. As a tech writer, you know how to structure content so that it’s readable. Use a subheading for every 1-2 paragraphs of content.
Sometimes people provide stenographic-like notes of a meeting, noting what everyone said in a play-by-play fashion. Avoid this approach and instead prefer more concise summaries of the issues and discussion. In short, make it readable.
How do you find the time for this?
If you grabbed time from half a dozen peoples’ calendars, you can probably spend 30 minutes post-meeting doing the write-up by yourself. If you’re busy, you can postpone the task 1-2 days later. The write-up doesn’t need to be a masterpiece, but you’ll probably polish and refine the content more than a non-writer would. Just don’t obsess. Keep it simple and recognize that meeting notes reflect the discussion of the meeting, and that meeting might have been somewhat disjointed and scatterbrained, touching a lot of different topics and points. A write-up that reflects the meeting might need a bit of re-organization and artificial structure to be readable.
Also, recognize that the first few write-ups are the most time-consuming (as with any activity). Once you get into a rhythm and style, the write-up becomes fairly easy. One way to find time is to recognize the value of doing the write-up in the first place. The write-up is a great way to take a closer examination of the meeting and make sure you’ve accounted for all action items and other loose ends. The write-up reinforces that you take the meeting seriously, and that it’s worth everyone’s time to attend.
Overall, strike a balance between context and concision that makes sense time-wise. Expect that readers will likely glance through the notes and see if anything merits a closer read.
How do you decide on who to include in the broadcast?
Who you include in the notes broadcast is how you “manage up,” as they say. This is where broadcasting meeting notes becomes strategic. For example, suppose you have a channel where many groups post their meeting notes and the business stakeholders read them to stay updated across these groups. This means you’ll have some readers who are 2-3 levels above your team. What do you want them to know about your team? About documentation? Raise issues and help them get a better sense of your challenges, successes, and other matters.
For example, suppose you faced challenges in figuring out the context for a new documentation topic. Maybe the documentation covers a new API that doesn’t fit into any specific product’s docs. This product ambiguity is causing confusion in the organization of docs. Maybe a senior leader can share some insights that would help clarify the product direction and fit with other content. And if a senior leader starts chiming in with insights, they’ll suddenly become aware of the docs, what they contain, and that you’ve been working on components relevant to the user experience for the API.
Besides influencing up, you can also include parallel teams (especially those outside your immediate organization) to influence across. Other writer groups might have more insight into processes and techniques that could help you with the issues you face. The challenges your group encounters are likely similar to issues that other writer groups have faced (and maybe solved). Others might have been around much longer and have solutions, so loop them in if appropriate.
How can you leverage post-meeting participation from non-meeting participants?
Ideally, you want to allow those who didn’t attend the meeting to add their thoughts. This is how sharing meeting notes can create a boomerang of information coming back to you and allow you to leverage the wisdom of others. If you keep your meeting notes in Google Docs or other documents that others can comment on, it makes it easy for them to jump in with some comments. Add a short note in the email that invites others to comment on the issues, explicitly inviting them to participate. Sometimes those who didn’t attend might feel they shouldn’t “butt in” to comment on a meeting they weren’t a part of, but if you make the invite to participate more explicit, they might be more inclined.
Are there downsides to sharing issues, frustrations, or problems with others? Won’t that make us look bad/incompetent?
You might think that sharing issues, frustrations, or problems you’re running into isn’t a strategic way to communicate your expertise at authoring and publishing. Suppose you have a laundry list of technical challenges, behavioral hurdles, and organizational culture issues that you’re dealing with. It can be hard to be transparent about these issues and to share them with others. We often want to communicate a facade of expertise.
However, I’ve learned that as a blogger, readers value transparency. We like to see what issues others are facing and how they’re approaching those issues. Reading a blog of someone who always knows how to handle every situation, who always knows the right answers for every problem, etc., isn’t a very interesting read. Dare to be human. That humanity endears readers to your side. In this light, think of your meeting notes almost as a sort of blog entry, detailing your forays against your enemies (that enemy might be processes, technologies, etc.).
What do you do with all of this visibility?
One consequence of sharing your meeting notes is that you become visible. It takes guts to share a meeting write-up with 50 people. Do that repeatedly, and pretty soon they come to know you. This is what happened with my blog, idratherbewriting.com. I rarely go to any tech comm event without running into people who know me (even if I don’t know them). Blogging has made me super visible. Is visibility a good thing? Why would you want to be visible, and what do you do with that visibility?
Visibility for the sake of visibility alone is vanity. Almost no introverted writer wants to be this visible, with everyone carefully seeing your every move and thought. I never wanted to be a “famous” technical writer, if such a description is warranted. However, with visibility comes influence. Your visibility gives you a platform to influence others in ways that those without the platform lack. This is why NBA players often talk about issues outside of basketball — because they recognize that their visibility gives them more influence with people. Their spotlight on national television gives them a platform that many have used to highlight racial injustices.
What will you use your influence for? You’ve earned the influence through your hard work, writing up meeting notes and daring to share them with broad groups. At some point, you’ll need to recognize that you’ve become an influencer and ponder what that means. With my blog, I’ve tried to influence the tech comm community to see API documentation as more than just generating reference material, and to move toward docs-as-code tooling. I’ve also tried to show the many interesting facets and angles of a “boring” tech comm career. But I admit, I don’t actively sit around thinking about influence. I just write articles or record podcasts about issues that matter to me, without thinking of the wider impact. Consequences related to influence naturally follow, which is what I suspect will happen when you broadcast your meeting notes over the course of a year or more.
At any rate, whether you’re conscious of influence or not, consider focusing on your strategic initiatives and other plans. Focus on the issues that truly matter to you, and let the stars align in whatever pattern naturally follows from that. Don’t sit around thinking like a rhetorician, carefully calculating what buttons to push to achieve the desired results. That assumes too much control over influence. But as you develop strategies that matter to your team and pursue them, these topics will naturally surface in your notes and others will become more aware of them. Just making your strategies more visible will help portray your tech comm group as more than just documentarians. You’ll be seen as analytic and strategic thinkers, engaged in important projects to improve the user experience.
Conclusion
As you think about influence, typing up your meeting notes becomes more than just a secretarial task. It becomes a content problem, with a user audience and potential opportunities to influence those around you.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.
144/166 pages complete. Only 22 more pages to go.