Tech Comm’s Place in the Choir

By | 2011/12/15

All God’s creatures got a place in the choir
Some sing low and some sing higher
Bill Staines

Birds on a wire

A place in the choir

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 , 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:

  1. 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?
  2. 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?
  3. 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?
  4. 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?


4 thoughts on “Tech Comm’s Place in the Choir

  1. Tom Johnson

    The point that resonates most with me in your post is that technical writers are just one voice in a choir of others. There are a lot of other people producing help information — information also comes from the community, from support centers, from social media, and elsewhere. I think too often we technical writers presume that we’re the sole information creators. Good post.

  2. Kai

    Oooh, this is too good to be true! I’ve been singing in choirs for over 15 years and been a tech writer even longer, so this resonates with me on several levels. 🙂

    Based on my experience in choirs, I think my job as a tech writer is threefold:

    – Join the choir and support the weakest voice. I’m a baritone which means I’m too high for a bass and too low for a tenor. It also means I can join either one as the music requires.

    – Make sure we have arrangements that “work”. The music needs to be accessible to the audience and suitable for the hall we sing in. It’s no use to put out music that only works for the 2 dozen people in the front row. Unless it works for most people in the hall, we need to change the arrangement: Separate voices so they’re comprehensible; slow down; weed out some artful counterpoint which obscures the melody; etc.

    – Make sure the hall “works”. I don’t need to own or build the hall, but it needs to make the audience feel comfortable, and it needs to be suitable for singing.

    1. Mark Baker Post author

      Hi Kai,

      Thanks for the comment. I think your vision of the job makes a lot of sense. I know that when I was moderating the OminMark User’s Group mailing list, that there would be times when Boffin McGenius from the engineering staff would answer a user’s question in a way that was brilliant, but incomprehensible. I wrote a bunch of “What Boffin is saying …” posts to bridge the gap. My job was not to be the Diva, but to make sure the audience — the whole audience — got to enjoy the show.

  3. Pingback: Technical Communications Poll: Demonstrating the Value of Tech Comm

Leave a Reply