So What Does a Tech Writer do, Anyway?

So Just What Does a Technical Writer Do? And How?
For crying out loud – how many more times will I have to answer that question? “What is technical writing? What do you write? Where do you get the information from? Who do you give it to? Do you have to be a journalist/creative writer/poet/literature major to do that?” And my favorite, the never ending questions on “How does the flibbertijibbet feature work in Word software?” (...which I frequently can’t answer because most of the true ‘heavyweights’ in technical writing use Framemaker for technical documentation)!
Well, in answer to the question about what fields technical writers start in, there is no one, easy answer. People come to technical writing from many backgrounds; most of us “fall” into it. We discover that, like in the case of writing for a software company, it pays pretty darn well. (At least it used to before The Great Recession.) I came to technical writing through teaching. And that is what I have discovered – that technical writing is most like teaching. It is the art of taking the complex, mastering it (yourself), and then breaking it down into easier-to-understand, manageable segments and pieces, so that others can understand it.
Most of my experience with technical writing is with software companies, which have their own nuances. So that is the type of technical writing I will discuss. I’ve done some of the other types – resume writing (yes, it's a form of technical writing), writing for engineering disciplines, and writing up safety manuals (policies and procedures etc.) And I have a ton of grant and proposal writing experience as well, which are tangential to technical writing.
Technical writing does not need any creative lilt or flair. Just an ability to analyze your audience, write to their level, learn the subject, dissect it into its component parts, and then start writing as though you were a guide leading others up a ladder – rung by rung, step by step. Sounds easy. And for people who have a knack for it, like me, it is. For people who don’t have a knack for it, don’t despair. There are some guidelines you can learn to get you started.
1)          If you can, pick a software company that makes software you can really dig into. I mean, when you work with it, it feels like little brain teasers – little puzzles of modules to be mastered. I’ve found that if the software I am documenting is too easy, too boring, or just not interesting to me, I get bored. Restless. If you’re really a tech writer wannabe, I can’t understate the importance of truly relating to the software. It’s like a psychological thing.
2)          Now to get started. There are myriad ways to get information. First and foremost, your company ought to put you into a training class to learn the software. Push for this.
3)          You will soon learn that programmers consider tech writers to be a nuisance. They are the “creme de la crème’ of the organization and have so many more important things to do than talk to you. The best thing you can do for your reputation with them is to make your questions as minimal and discrete as possible. To do this, I would suggest cracking the software yourself. Play with it. Follow it. Read the Help (if you’re lucky enough to have any). Write down each question you have. Then you can go to whomever and ask discrete-item questions, Instead of saying “Teach me the flibbertijibbet module.”
4)          No, programmers don’t like to talk to tech writers. (Remember Tina the Tech Writer in Dilbert?) Try to connect meetings with food. Put a candy dish on your desk. This will assure that at least the programmers with a sweet tooth will stop by to chat each day.
5)          There is a maxim that says, the more people you talk to, the better your documentation will be. Let me say that again. The more people you talk to, the better your manual will be. If you only talk to the programmers, you will get one point of view. One angle on the material. If you then talk to marketing, you will be shocked at the information you get – that you would not have and could not have gotten from the programmers. Then you move on and talk to the product consultants (also called trainers). These will be your best bet – anyone who is client facing. They know how the software is actually used, what features frustrate people, where the design flaws (woops I mean features – ha ha) are. What things the users find easy and what things frustrate them. The best information you get will come from these people.
6)          Now, if you are lucky enough to have them, look at the training guides. The benefit of this is, where the Help sometimes, often times I should say, gets behind, the training guides have to stay current. And the information in them must be “proven” accurate, because there is some trainer in the wings, having to teach with it, and not wanting to look stupid in front of a group of people.
7)          Now you will want to look at the current Help. Is it any good? Well, probably not. Most Help is not that great. And there are reasons for this. The first reason is, in a software company, the tech writer is essentially a few levels higher than pond scum in most people’s minds. I’ve even heard it said (by a programmer – and Artificial Intelligence expert) that you don’t need documentation if the User Interface is designed well enough. Well that may be for something like MS Notepad, but won’t work for industry software that requires hours of codes be set up to get the software to function, giving a desired output.
8)          The second reason Help is often not great is that, well, good tech writers are hard to come by. Essentially you need to be a person who can handle technical material, but at the same time, who can write. If you have this combination of traits, then rejoice! You, like me, are a rather rare bird.
9)          And yet another reason tech writers are so hard to come by is that they are probably in another field – or at least in another type of company. You see, well, think about it. There is nowhere to go in the software company for the tech writer. It’s kind of like being an employee at a doctor’s office. You’re not going to be promoted and become the doctor, and you, as the tech writer, will not be promoted and be a programmer or the CTO. At many software companies, there is just a tech writer and there is no manager. So as far as moving up? You’re s.o.l.
10)          A word about Help, and how people feel about it. I have worked in some 9 companies, and in every single one of them I heard (before starting work there and during) “The Help is not helpful. The Help doesn’t help.” I never worked anywhere where I didn’t hear this. And when I served as an Officer for the Society for Technical Communication (everyone who’s anyone in the tech writing field is a member) my colleagues all expressed the identical thing. Now, why is that?
11)          Well, aside from the reasons above, if you take a gander at studies done on Help systems and user behavior with respect to Help, you quickly learn that in general, user behavior is such that people don’t like going to the Help. They don’t’ like to stop what they are doing and open a new window. It’s that simple. Call it inertia. Call it laziness. But people just don’t like to stop and go over there. They want to continue looking at the part of the UI they are looking at. So this is why of late, you have seen and will continue to see on an increasing basis, the move to “context sensitive Help” – which is more recently terms “point of use Help.” Learn not to take this too much to heart. When people say they can’t find things, pick their brains further, at every chance you get, and incorporate their suggestions at every turn. I have gotten some of my most inspired ideas from user feedback. But at the same time, when you hear the old familiar groan “The Help doesn't help,” know that this is just an occupational hazard of the world of tech writing.

12)          Do you know anything about document design? If you don’t, you should. There is a whole “Information Design” field of study, with an associated organization. Better yet, read up on the field of typography. Check out some of the texts on typography. You’ll be shocked to learn, as I did, that, for example, all caps actually decreases readability. And that you should be judicious in the use of color in technical documents. Black on white type is the highest contrast and therefore the most readable. Remember, this is technical documentation. Cold, hard, just the facts, ma’am. Your goal is not aesthetics. Your goal is to make it such that information can be found, retrieved, and absorbed in the least amount of time possible. Period. Not to wow people with colors.

And speaking of fonts. I know all the new fonts that come with your ever incrementing MS Office suite are dazzling, but technical documentation is not the place to try out every new font, on each of the headings. The last thing you want to do is make your document look like a ransom note.
13)          A word about Word. The truth is, the real “heavyweight” tech writers don’t like to use Word for documents. Well, OK, some do. But they are the minority. When you really become a die-hard  tech writer, you can, should and must learn Framemaker (Adobe). Get a copy of the software, if you can (sorry, it ain’t cheap) and if your current employer does not have it fight like mad for them to buy it. It does things that leave Word in the dust – which non tech-writers have no appreciation for – like multi-nested numbering, alternate headers, subheaders and footers on front and back, odd and even pages. Word will choke on these and will drive you nuts if you have to sit there all day doing long documents.
14)          Now, as far as doing Online Help – the old standby is RoboHelp. It’s been around for many years, and is the new iteration of the old ForeHelp, which was bought then bought then bought then bought again. But there are many other good ones out there now. Flare, by MadCap is actually programmed by a large number of the ex-RoboHelp programmers – so you may try that package instead of Robo. Robo has been off=shored to India; when Adobe bought RoboHelp many jumped ship and formed another company, MadCap. So you may find Flare much more to your liking. There is also Doc to Help (easy to learn – has a lot of good features) and a few others.
15)          Don’t be afraid to be repetitious (to an extent) in this type of writing – technical writing. You may find yourself writing, many times “To do nnn, follow these steps:”, or “ From the nnn menu, click mmm.” It’s ok – and actually desirable – in this type of writing,
It’s been said, “It’s easier to be an editor than a writer. Truer words were never spoken. Can you take criticism (scrutiny)? If so, the field can be a blast.  Your work will be visible to the whole world, at all times (this is good and bad). Don’t be afraid of it. Not, it is not only  “heads down” work; you can use both your extrovert and introvert skills, for a fine balance inside of work and out.