I recently participated in a discussion on LinkedIn where another writer posited a question about the best Technical Writing tool. My immediate thought was that my most important tool was ‘listening.’ If you are a technical writer, you probably already know how important listening is. Although, I have met more than a few tech writers who just write what they hear without really listening. If you are an aspiring tech writer, listening is a skill you should develop as quickly as possible.
Notice in the previous paragraph, I made the distinction between hearing and listening. This is a major distinction. Most of our information is gathered through interviewing various sources, primarily the Subject Matter Expert, or SME-pronounced smee, like the pirate. The only problem with this is that most of the SMEs don’t speak any language but their own. That means we have to learn to speak SME. Unfortunately, the SMEs don’t all speak the same language either so you have to learn the language of each individual SME.
Not only do we have to learn to speak SME, we have to be able to listen between the lines. By this I mean that the SME may be saying words you can understand but those words don’t fit with what you are documenting. So, you have to backfill. When the discussion seems to be veering in an unfamiliar direction, you have to stop the SME and ask for more information, more what, why, and where. This can sometimes make you feel like an idiot, usually because the SME is looking at you like you are an idiot but my recommendation is to just smile a nice vacant smile and keep probing. And, don’t worry. Feeling like an idiot will seem normal in no time.
One way to be certain you have heard what the SME intended to say is to reword the information and say it back to the same SME. They will frequently recognize that you repeated what they said but it really wasn’t what they meant to say. What? Yeah, it gets confusing.
All of this seeking and listening can be time consuming for both you and the SME. My best advice is to write first and question later, when that is possible. So, if you can write topics from requirements or specifications, do that. Or write topics from your own observations of the user interface or technical documents. Or write topics based on all the bits and pieces you picked up at meetings, if you were lucky enough to be invited to meetings.
Why write first? I have found that most SMEs find repeated personal interviews to be intrusive and a waste of their time. If you can cobble something together on your own for the SME to read and speak to, the SME will easily be able to see if you are on the right path and correct you if you are not. You may even get lucky and get it right the first time saving both of you some unnecessary effort. If you are way off base, the SME still has something substantive to use while straightening you out. In any case, most SMEs appreciate the fact that you are making an effort on your own.
When not to listen to SMEs requires some experience, as well. Some SMEs fall in love with their own prose and want to see it word-for-word in the final copy. They really think that they are the writers and all we do is type it into the final format, whatever that is. If you don’t handle these SMEs carefully, you may have the devil’s own time getting information out of them again. Blame your edits on space or the editor or suck it up and admit you have to earn your keep somehow.
Two other sources of excess word creep you need to not listen to are the requirements engineers and the marketing folks. Some of the requirements writers and engineers not only want to tell the end user how to use their product but the logic behind the user interface and what it offers. When this happens, you can try to explain that end user wants to stay in ignorance of how the sausage was made. Or, you can just put one finger of each hand in each of your ears and start singing while they are talking. This usually works but it can also make future encounters a bit tense.
As for the Marketing types, you should out that the current marketing must have worked because the end user already bought the product and further marketing blah-blah is probably not necessary.
In any case, listening beyond hearing, listening judiciously, and not listening to every SME or marketing director who fancy themselves technical writers, are learned skills that are a part of every technical writer’s toolbox. Use them wisely.