Technical Writers as Subject Matter Experts

According to Wikipedia, a subject matter expert (SME) is a person “who is an authority in a particular area or topic.” When a company engages a technical writer, in addition to working with the actual product he or she is documenting, the writer must rely on the SME as the source of all knowledge, the one person who can explain how the system works and, perhaps more importantly, why it works that way.

When we start working on a new software system, for example, we often work closely with SMEs in the initial plunge into the product so we can get a better understanding of why the system was designed the way it was. These sessions usually start with the problems the business was having that the software we are documenting is supposed to solve. For me, it’s some of the most interesting time I spend on a project because I get to have conversations with real people (as opposed to cussing Microsoft Word for not doing what it’s supposed to do – but don’t get me started).

But these sessions are also enlightening because I learn how businesses operate and make money, for me a special esoteric pleasure. This knowledge certainly makes for interesting cocktail party chatter – “Did you know that criminals in Africa and parts of Europe are using gas explosives now to break into ATMs?” Not that this benefit isn’t worth the time and effort. It certainly is. But what happens is that as I learn more and more about the system and begin to understand more about it and its purpose in the business, I become a subject matter expert on my own.

How does this happen? Let me explain.

As I learned in my first composition course, if you don’t understand what you’re writing about, chances are no one else will either. This is so true in technical writing. If the writer doesn’t completely understand what he’s writing about, the person who ultimately tries to use the material is in a world of trouble. How often have you frustratingly slammed a manual shut after looking up a field definition, only to find something as banal and useless as “enter the number”? Of course, you have no idea what the number is or where to get it – which is why you consulted the manual to begin with!

What I’ve learned over the years of reviewing and editing others’ works is that if the writer doesn’t understand the various components of the system and therefore doesn’t know himself where the “number” he’s instructing the helpless reader to enter comes from or what it does, whatever “documentation” he’s producing is useless. A truly unhappy situation.

A case in point: A company recently engaged us to work on a new application it was preparing to launch. We have worked with this client on many other projects over the years and, in the course of our labors, have gained a very broad and thorough understanding of the client’s business operations and industry. On more than one occasion during our involvement with this new project, our understanding of “how things work” at the company has helped move the project forward by either involving other people at the company who can quickly remove roadblocks, or providing in-depth explanations on ancillary systems that are affected and need to be changed to make it possible for the new application to run properly. In other words, through our knowledge of having documented the company’s products and services, we’ve become the SMEs. For the new hires at the company, with little exposure or experience in the industry, we become a trusted partner for explaining why some things work the way they do and how to navigate change.