I am constantly reflecting on the answer to this question: How can I draw upon the enthusiasm, intelligence, and skill of willing volunteers all around me to take our organization's site to the next level? This goal mostly relates to my involvement in my organization's technology blog, which has about 80 volunteer writers.
In my post about what I learned during 2011 as a technical communicator, I wrote:
Community collaboration is extremely tough to pull off. I can't just assign a volunteer writer a topic and let them run with it. I usually have to either gather the information from a subject matter expert or connect the volunteer with a subject matter expert — and then see them through the process with more hand-holding than I want to provide. Still, community volunteers can generate momentum by the sheer number of assignments I have to follow through with. Overall, I have no idea how to engage community volunteers in an effective way, but I think I can eventually figure a strategy out. (See What I Learned About Tech Comm During 2011.)
In response to this post, Saul Carliner added the following insightful comment:
But the challenges of working with “volunteers,” is one that is rarely mentioned when discussing SME-authored and user-generated documentation. Having had worked with volunteers in a number of sectors over the years–from work-related ones to community ones–the issue of volunteer management is one that still challenges all of them. Incentives and clarity help, but not always in the way intended. Even in areas that have years of experience with volunteers, it's more of an art than a science. Just because we've moved to community-based approaches to documentation and the wikipedia has been successful doesn't mean that other ventures don't involve nurturing.
The last sentence particularly stands out. Yes, many social ventures (such as Wikipedia and Digg) have been hugely successful. But that doesn't mean applying the volunteer model to tech comm is a process or technique we understand. It's an art, and one that most community managers still struggle to figure out.
The topic isn't just limited to volunteer engagement. SME-authored documentation, as Saul mentions, also fits into this genre.
In a series of questions I responded to on Ugur Akinci's blog, I reflected at length on what is the most significant change in the field of technical communication. It fits right in with collaborative efforts and social intelligence. Here's an excerpt of my response:
QUESTION (3): What is the single most important change that you see in the technical communication sector since you first became a technical communicator?
... The greatest transformation yet to come is to drop the single-author paradigm of technical writing and to embrace the way information flows on the web. ... For years help authoring has consisted of one person (or just a few people) writing help material. When content comes from one person, the content is usually limited in perspective, accuracy, and applicability. Writing needs to become much more collaborative, and not just from inside the corporation, but outside as well. Documentation is never finished. When I log off for the day, someone out there may be contributing to the documentation, making it evolve, adding sections, correcting errors, expanding on special cases, and so on.
It's engaging to come into the office in the morning and review the latest changes to the wiki, to find that someone added a new section, or a new page. We no longer have documentation as static, standalone files that are written in haste by one technical writer and then “finished” as he or she moves to the next project. Documentation is a living, breathing body of information – like the web. The web is in constant flux. It's full of a whole landscape of people – trolls, spammers, forum champions, lurkers, relentless volunteers, bloggers, programming whizzes. All of these people, like characters in a circus, come together on the same stage, interacting with each other in rich, multifaceted ways. Sometimes these interactions are exciting, other times they're frustrating. But either way, documentation evolves to become more web-like in the ebb and flow of information.
This ebb and flow of information is what I find most rewarding about technical communication. Information no longer emanates from one source but rather connects into a greater body of people. This is the genius of the web. The web thrives because of this content interaction — one person building on the ideas of another in collaborative, interactive ways. (Read the full interview on Ugur Akinci's blog.)
Let's come back to the original question. How can you harness the enthusiasm and talent of volunteers in productive ways? The answer to this question wouldn't just be a neat technique to enhance productivity; it would change everything about my job.
The problem is not content strategy; it's content tactics. The strategy is clear: draw upon the talent and enthusiasm of willing volunteers to write high-quality content. The details of how remain a mystery. Let me continue my brainstorm.
Several main challenges make this a difficult problem:
Now that I've outlined the challenges, let me also outline what I've learned about volunteer engagement:
I recognize that my brainstorming and analysis is specific to my own volunteer situation, and one situation may vary dramatically to the next. Hopefully the tactical plan I form may be of interest to others who work in other volunteer situations, even if the details vary. Given the challenges and known principles, what would work well for success?
Here's are a few potential first steps:
Step 1. Create a body of work that volunteers can do. This means crafting assignments that are important and worthwhile. Creating a body of work may be the most difficult of all steps, as this requires me to add detail and potentially outlines to topics. Sometimes I may only have an idea for a story, or a name to contact, not an actual story in hand. But having a tenuous idea doesn't work well for volunteers, who may be playing guessing games at what I want. The details of the assignments need to be clearly spelled out. Each writing assignment needs to have a basic level of clarity to be something that users can actually accomplish. Contact points, key messages for the article, length, tone, and other details should be clearly defined.
Step 2. Personally invite volunteers to act. The second step would be to personally invite volunteers to work on the tasks they're assigned. The invitations should ensure that the writing assignment is a good fit for the volunteer (that is, matching the volunteer's strengths and interests), that the volunteers have a good idea of what you expect, and the due date.
Step 3. Regularly review, track, and follow-up with assignments. It would be a good idea to review all the items stored in the system (in my case, JIRA) on a daily basis so that I don't let some assignments languish and become forgotten. Volunteers may run into insurmountable issues and challenges; they may realize the assignment isn't a good fit for their interests. By following up and checking in regularly with volunteers, I also demonstrate the value and importance of the assignment.
Step 4. Have volunteers edit volunteer writing. This is one of the steps that I've never implemented, but it might be good to have volunteers edit other volunteers' writing. Writing often needs successive levels of editorial review. I could provide some quick comments and feedback, and then either have the volunteer make revisions or pass it to another volunteer to make edits, and then potentially to another volunteer. This way by the time the writing falls on my desk, it's already to a level that is near publication quality. In some situations, I could ask SMEs to write content and then pass it along to volunteer writers to edit.
Step 5. Communicate regularly. Without regular communication, people lose interest. They quickly drop off. The communication also helps build trust, and people may feel as if they're learning more from discussions. It's not possible to build a lively community without regular engagement through e-mail and other online interactions. Perhaps contributing an e-mail a day may go a long way toward building trust and helping volunteers feel that they're getting a lot out of the experience.
No system works if one doesn't use it. These five steps aren't rocket science. I could probably have a decent amount of success implementing them. The problem is maintaining regular activity, sticking with the system week after week, especially when other, higher internal projects get in the way. This is perhaps why breaking the tactics down to even a more concrete, daily to-do list might be a good idea.
I'm interested to hear what strategies you use for managing volunteer writers.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.