How is a technical writer different from a “regular” writer or an administrative assistant? I’m rarely asked this question, but I know people think it by how they act toward what I do and how they treat non-technical writers and assistants, whom they assume can also do what I do. So I thought an explanation might be necessary. “Technical Writer” is not in the career path of an administrative assistant. They are two completely different careers. (However, I did work briefly as a “Technical Assistant” while in college. I taught a professor how to upload and maintain her online journal. She paid me with her grant money.)
There are numerous resources on the web that explain what a technical writer does. This one will give you a general idea of what I do: http://en.wikipedia.org/wiki/Technical_writer. The Bureau of Labor Statistics Occupational Outlook Handbook also has a detailed description of what technical writers do, but doesn’t really explain the “technical” part of the job title very well. The general description is “technical writers must be able to understand complex information and communicate the information to people with diverse professional backgrounds.” If that was all you read or knew about technical writing, you might think that anyone who can write can be a technical writer. You would be wrong. If you are talking about “secretaries” documenting complex software and hardware equipment, you would be very wrong.
I’ve worked in many different technical industries as both a technical writer and as an electronic technician. Therefore, I take offense when a company hires someone as a technical writer who, while perfectly capable of writing well, has no skill whatsoever that could be considered technical. I’ve worked with many a “technical writer” who was not at all technical—and some who could barely write. Fortunately, most people who actually want to be writers have a desire to learn the rules of writing formal documentation. However, many of them learned to write academic papers, and that is often a very different audience than those who read technical papers.
People who have resorted to reading the “help” available with the software or hardware product that they’re using are already frustrated with the product, have a specific task or question in mind, and want to “get in and get out” of the help and move on. They don’t want to read your flowery prose full of descriptive adjectives and they don’t want to parse your 20-word sentences full of multisyllabic words to figure out what the heck you’re trying to say. (Your professor isn’t reading your essays anymore, so there is no need to impress her.) All the user wants to know is “click here to do that,” and sometimes, “why should I click there?”
When I document a software product, in addition to reading the requirements and the functional description (written by a product manager or engineer), I have to actually use the product the way a user would. That means I have to install it. I also have to install, update, and maintain virtual images—sort of an operating system within an operating system. For example, before I install my company’s software that is being developed, I need to install an “image” of Windows 2008 on my desktop, and it has to be updated, patched, configured, and so on. That way, if the software product I’m installing messes something up, I can reset the image rather than rebuild my whole computer. If I had to ask an engineer to install the software for me every time they released a new build, I wouldn’t have the job for long. If I were documenting how to install a piece of hardware, how to align a circuit board, how to cable up a bunch of cabinets, and so on, it’s much easier to write about it—and more accurate—if I’ve actually done it.
The software that I document at my current job is used to transfer files all around the world, so I also need to know about networking, LANs, WANs, TCP/IP, SFTP, which ports are the defaults, what is “localhost,” etc. I’ve taken classes in Windows administration and network administration, and I have an A+ Certification for both hardware and software. I didn’t “need” that to do my job, but it certainly makes it easier and lowers the learning curve when new features come out. Technical aptitude, if not the specific knowledge, is one of the important traits a technical writer must have.
One thing I love about my job is that I’m always learning new things. As new features are added to the product (e.g., support of IPv6, CAC cards, AS2), I have to read what the product manager has documented, and do my own research so that I can understand it. You *can* try to edit what the subject matter experts (SME) give you by identifying the nouns, verbs, and so on, but unless you really understand the subject, you could make it more confusing to the user. You can always send it back to the SME for review after your edits, but you can save yourself and the SME time if you make an effort to research and understand the subject matter.
When I worked at a bank, my job was to provide procedures to the telephone bankers for how to use their software—software to which the writers were not provided access! So based on the reckoning of my fellow technical writers who used to be telephone bankers (not writers, technical or otherwise) or current telephone bankers, or managers (who may or may not have used the product at some time in the past), I was supposed to write procedures for the telephone bankers to use when on the phone with customers. Does that make sense? The telephone bankers for whom we were writing the procedures were supposed to be my SMEs! It would have been super easy for the IT folks to install a virtual image on our computers or in a networked location, install Siebel and other banker tools on it with dummy data, and let us click and double-click our brains out so we could understand what we were writing about. But that was considered 1) a security risk (even with dummy data) and 2) over our heads. So they considered us too stupid to understand the software that we were supposed to document!
Why would they think that? Not only because they didn’t understand how technical writing works, but also because most of the people they hired as technical writers were neither technical nor writers—they got a job at the bank in high school, had worked there ever since, and got the technical writing job because they had banking experience and seniority. A few of them could write, but none were tested in any way to determine if they could write before they got the job. One of the managers told me that these former bankers had “tribal knowledge” that was important to understanding the procedures. I can teach you proper banking procedures, which are pretty black and white. I can teach you rules of grammar, sentence structure, and how to write a proper procedure. I can’t teach you all of the little nuances of applying those rules that become instinctive after writing in your job for a long time. I can’t teach you how to think critically, how to troubleshoot software issues, and all of the little nuances of technical work that I’ve learned by doing it over and over again in my career.
Some people have a technical mindset and some just don’t, just as some people are good at customer service, which I’m not. Before hiring a technical writer, give them a basic writing/grammar test AND a test of their technical skills. There are many, many writing and grammar tests available online for free. If you already have a technical writer in house, I’m sure she’d love to write a test for you! The technical skills test doesn’t have to be complex. There are many resources online, both free and not so free. I’ve taken tests that are directly related to what I would need to know on the job for which I was applying. Any of your engineers can come up with one—but please let your technical writer edit it!