Factory Creates Opportunities for Data Insights

The artificial intelligence expert at a major clinic was already loaded down by responsibilities for three teams. When he was tagged to provide updates about a cloud project for the organization’s internal blog, he seemed overwhelmed. And, he had good reasons. First, when would he find the time to write? And second, what would he write or where would he begin? Fortunately having someone available to him for ghostwriting the technical blog post was just the answer.

There are many ways to do write for someone else. But, for me, ghost writing a technical blog post is simple. See how my process makes it easy on everyone.

Keep the author in control with options

I needed to make this process as painless as possible for the author. At the same time, I needed to ensure he stayed in control of the content. So, I presented him with a few options to him:

  • Write a rough draft that I can edit and make sure it fits the organization’s criteria and audience needs.
  • Write a bulleted list of key points that I can present in an interview format for him to expand on each point.
  • Join me in a meeting to discuss the key information and why they are important for the audience to know.

Fortunately for both of us, he chose the meeting option.

Create a back up

Before we started our meeting, I informed our AI expert that I’d like to record the meeting for accuracy in the written version. I assured him that the only person that would listen to the interview was me. And, when I was finished with it, I would delete it. Fortunately, he understood and agreed.

It’s important to make the points about accuracy, privacy, and security of the recording. I had one author who refused to let me record our conversation, making it much more difficult to ghost write for her.

Because the project was new and everyone was learning about it, I didn’t prepare any set questions in advance apart from a few points I knew the post had to address. My plan was to simply start a conversation about what he was working on.

Write it down

Because I had recorded the conversation, I was able to write about two-thirds of the article with no problem. The last part of the conversation started to get into parts of the project that couldn’t be made public. That proved to be problematic when writing because I knew we couldn’t reveal those details.

So, when I emailed the Word draft to him, I asked him concrete questions for more input to help direct the last part of the post. He agreed the first two-thirds were in good shape with only minor corrections. But, for the last third, he scrapped what I had altogether and came back with completely new information. In technology, things change quickly so the new information was just what we needed to complete the post.

After he sent me his changes, I added the finishing polish, and returned it to him for final approval. At the same time, I sent the draft to the executives on the project who wanted final approval on all posts. Once I received approval from the author and the executives, I submitted the post for publishing.

Publish the post

After the link to the blog post went live, I sent it to the author, my marketing communications team, and the executive leaders to forward to their teams. I also posted the blog to an internal group on Yammer. Promoting content as much as I was allowed was a good habit I got into when working in IBM developerWorks. As a contractor on this particular team, I wasn’t allowed to post any more than those two places.

At the time, this particular post gained the most likes of any content published about the project. Take a look at the post for yourself.