All God’s creatures got a place in the choir
Some sing low and some sing higher
Traditionally, technical manuals have been written as if they were the only source of information on a product. Of course, the manual was never really the only source. There have always been neighbors, friends, colleagues, retailers, user’s groups, and professional associations to learn from as well. But access to these other sources of information was not universal, and those groups themselves had to learn from somewhere — information had to propagate through the network before it became available to the ordinary user, and the propagation was usually quite slow. It was reasonable, therefore, for users to look on the documentation as their principle source of information, and it was reasonable and necessary for the documentation to be written as if it were the sole source of information on a product. Not any more.
The web has changed all this. All those other sources of information are now immediately available to everyone on the web. More importantly, information now travels through this network of enthusiasts and mavens pretty much instantly. Those voices, once isolated, distant, and sometimes tentative are now a great chorus echoing around the world, often taking up the tune even before the product they are singing about has even been released. Tech pubs today is, at best, one voice in that choir. At worst, it is a superfluous voice, no longer needed, and not worth paying good money for when we have a chorus of proficient unpaid amateurs to sing for us.
Commenting on my post Why documentation analytics may mislead, Tim Penner suggested that I might not be giving mavens enough credit. Not only do mavens pass on what they learn from manuals, Tim suggests, they also figure out a lot of it for themselves and pass that information on to others as well. I’m certain Tim is correct, in fact, I know from personal experience that he is, since I saw this in action many times when I was running the OmniMark User’s Group list. In my previous post, I was confining myself to discussing how a manual could have more influence than its web analytics might suggest. But there is no doubt that the user community also generates a huge amount of new information that they never learned from the docs, or from the vendor in any form.
In this way too, then, we are but one voice in the choir. Not only are we not the only voice singing the songs we wrote, we are not the only ones writing songs. And, truth to tell, we are often not the ones writing the most popular songs.
Some hard questions to face, then:
- Should we continue to sing solo, aiming to create a complete documentation set by ourselves and generally pretending as if the voices of the choir were not ringing outside our windows, or should we acknowledge the value of the choir, give up our solo career, and join our voices to theirs? A couple of points to consider as you ponder this one:
- Is your management going to be willing to pay you to sing by yourself when there is a choir outside that, frankly, sings a lot louder, sometimes better, and with a larger repertoire?
- Might you not be well advised to figure out how you can contribute to the choir and make it better before your bosses decide that it sounds just fine without your help?
- If you do decide to join the choir, what part will you sing? Should you sing just to the newbies (who may not be plugged into the product community yet and may not know where to hear the choir), should you focus on the stuff that the choir can’t handle, like reference material, or should you, as Tom Johnson suggests in his post Misleading Documentation Metrics, focus more on singing to the mavens, leaving it to them to teach the song to the rest of the choir, while adding harmonies and variations as appropriate (what in music is called “the folk process”). Some points to ponder:
- Will the part you take really add value to the choir (and therefore, by extension, increase revenue to your company) or are you just trying to sing your own favorite songs? As the only person getting paid to sing, you may have to consider that you best serve the choir and your employers in a less glamorous role.
- How will you demonstrate to your employers that you are actually adding value, both to the choir and to the bottom line?
- Will you be a chorister, or will you insist on being choirmaster. I hear a lot of technical communicators saying that if they are going to have anything to do with community authored content they are going to have to put it though their own quality control process. What you need to remember is that the choir may already have a choirmaster, or choirmasters, and they, quite frankly, may have more authority with the audience and the other members of the choir than you do. You might be much better off going in humbly as a member of the chorus and proving your worth to the rest of the choir. Then maybe they will elect you choirmaster of their own free will. Points to ponder:
- Who really gets to define quality in this choir? You may be the professional musician whose ear is offended by a voice that is a quarter-tone off. But the choir, and its audience, may prefer a lusty shanty sung with enthusiasm to your virtuoso lieder.
- Does your management understand the value of the choir, despite its occasional taste for bawdy songs? Have you made sure your bosses have the right expectations about your role in the choir?
- Will you provide the hall? If you are thinking about engaging your community by creating socially-enabled documentation, you may be doing your choir a real service by providing them with a great place to sing. On he other hand, they may already have a long-established venue. Points to ponder:
- You do not own the choir. It has existed for a long time before you started to pay any attention to it. If you try to change how it works, all you may do is split the choir and cause acrimony and division.
- Your role in the choir is to provide it with what it needs to work better. That won’t be the same thing in every case. You need to be pragmatic, not dogmatic, about the role you play.
As Scott Able has recently pointed out, technical communication is going through a period of great change. Sometimes the greatest change is the hardest to see. But I suspect there is no greater challenge for tech pubs in the coming decade than to understand its place in the choir.
Not everyone will have the same kind of choir to deal with. Some may still be singing virtually alone. Others may have a huge choir whose habits and traditions it would be foolish to challenge. Others still may have a golden opportunity to harness the power of a somewhat amorphous group of singers to create a more powerful and professional sounding chorus. What about you? Are you and your department ready to take your place in the choir, or do you intend to sing solo a while longer?