Search results

Part 2: Initial attempts and failures with workplace content

Series: A hypothesis about influence on the web and the workplace

by Tom Johnson on Jan 24, 2022
categories: technical-writing

In my previous post, I explained that anyone can create content and broadcast it on the web, gathering up an audience and building a reputation of expertise. I wondered if these techniques could be implemented in the workplace. In my initial attempt to create content in the workplace, I focused on two efforts: (1) creating documentation reports and (2) sharing meeting notes. The efforts sort of failed because I neglected some web fundamentals.

Documentation reports and meeting notes

In my first attempt to start creating content in the workplace (outside of regular docs), I started creating documentation reports because a senior leader asked for them. Most groups that reported up submitted reports of some kind, as is common in many companies. I was more than willing to assemble and share reports about documentation because I wanted docs to be seen as an equal with other groups. Then later, I started sharing meeting notes as well.

I wrote about these two formats and practices here:

I sent monthly doc reports diligently for about six months, and meeting notes after about 7 or 8 meetings. The doc reports were quasi-newsletters and contained sections such as these:

  • New articles published in the developer portal
  • Metrics and analysis about page and site traffic
  • Notes about writing efforts and experiments
  • Documentation needs and requests from partner-facing groups

Meeting notes contained summaries of the issues discussed, intended for someone who might not be familiar with the topics or discussion.

At first, I thought these communications were working well. However, because I was just sending this content over email, it was hard to track opens and reads. Occasionally, someone would reply “Thanks Tom” or “Great report” or similar. I made sure the distribution included both meeting participants and other non-participants whom I deemed relevant to the issues discussed, with the intent of keeping others informed about doc efforts and status.

Low engagement

I had high hopes for engagement from sharing meeting notes since I’d spent time adding many more details and context to make them understandable to those outside the meeting. I felt that meetings focused on issues, which might make for more interesting writeups. However, I didn’t see much evidence of engagement. Eventually, someone also told me my meeting notes might not be getting the readership I wanted.

To gauge readership, I decided to do a test. Instead of putting all the content into the email, I listed bullet points of the meeting topics discussed, followed by a link to the meeting notes in a Google Doc. I used a link tracker to gauge clicks on the link.

It turns out my colleague was right – only about 5 people actually clicked the link. This made me rethink the type of content that others might find engaging. I realized that meeting notes were probably a low-value form of content, and probably not worth the effort of the more detailed writeup and summarizing of issues that I’d been doing. Most meeting notes that other groups shared were unintelligible unless you were already familiar with things anyway.

I also started to rethink the readership of my documentation reports as well. These reports were getting long (and newslettery), and I hadn’t been getting much feedback on them either. What if the reads were equally abysmal, just like meeting notes? What if I was spending an inordinate amount of time preparing doc reports that no one was reading? I didn’t really know because I wasn’t tracking clicks, page views, or other metrics. I was writing in the dark.

The failure of email as a communication channel

While thinking about whether doc reports and meeting notes were having any engagement, someone pointed out the shortcomings of email as a communication channel within companies. Many people’s inboxes were just streams of unread emails from the dozens of lists or groups they followed.

For example, one time an engineer shared his screen during a meeting, and for a brief few seconds his email appeared on screen – it was nothing but endlessly unread email. Many people seem to use chat tools exclusively for times they want a response. This engineer in particular preferred to communicate over chat tools and our issue tracking system.

Email tends to get overused in corporations as a means of communicating everything. In my personal email, I get about 20 messages a day. In my work email, I get at least 200 messages a day, if not more. I subscribe to a lot of different groups, most of which are filtered into various folders automatically and skip my inbox. But even my inbox is a firehose of incoming information. If I see an email in the evening, chances are I’ll have trouble finding it in the morning. If an email arrives in the morning, I probably struggle to locate it in the afternoon. It’s really that bad, and I don’t even receive the amount of email that others do. To stay in the loop, we over-subscribe to email channels and end up being flooded with messages.

What happened to everything I’d learned on the web?

In distributing content in the workplace, I realized that I’d forgotten all the techniques that I’d learned on the web with my blog. Stuffing all content into a long read, sending only an email rather than leading people back to a website, not actively tracking clicks, not analyzing web page analytics, not organizing the content on any navigable site for later readers – it’s no wonder my approach didn’t have much success.

I knew that I’d failed with my doc reports and meeting notes. I decided to re-evaluate my approach by refocusing on web fundamentals.

Next post

Continue to the next post in this series: Five basics for building an audience on the web.

About Tom Johnson

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.