Guest Post: Tech Writing Careers -- The Raw, Unvarnished Truth

by Tom Johnson on Nov 4, 2008
categories: technical-writing

Last week a student emailed me with some questions about technical writing. I didn't have time to respond, so I forwarded the questions to the Techwr-L listserv, where 6-7 people responded. One of the responses, from Keith Hood, caught my attention. Keith unfolded what one might refer to as the "dark side of technical writing." His response is thought-provoking, and it will make you look carefully at your projected career path. Keith is a technical writer in Texas with 18 years of experience.

What steps do you take when writing a document?

Theory: In this order -– identify and define the audience to know their needs for information, develop the requirements for what it needs to cover, work out the review/approval process, plan the structure of the document, work out a coverage plan that says what to include and the level of detail to supply, arrange to have someone else proof and edit, run the doc through the approval process, apply changes from that process, archive it.

Practice: Get told what the boss wants, find out there's not enough time to do it right, try to throw together some kind of doc development plan in your head, find an existing document that you can use as a template and start cramming stuff into it, simultaneously run around trying to drag information from subject matter experts while you try to build a finished document from scratch, the boss reads it and sends it to the customers, the customers nitpick over it like feuding little old ladies, the boss blames you and has you rewrite it.

How do time and budget limitations affect your writing?

In every imaginable way. You have to deliver on time and in budget if you're going to have a good enough reputation to get your next job. Sometimes that means you have to leave out things you want in the documents. You have to prioritize what the reader *really* needs. And like it or not, you have to supply what the man who signs the checks wants, even if you know it's the wrong thing.

How much time do you spend writing?

The writing is the smallest time block. More time has to be spent in fact checking, in discovering if the information you have from the SMEs is current, and in digging information out of the network support group who don't want you to create that network diagram because they figure the less everyone else knows about the network, the safer their jobs are. The most important thing you can do is learn how to deal with people, so you can more easily get information from them. No matter how good you are at writing, you can't do the job if everybody dislikes you and they won't talk to you when you need to ask questions about the equipment you have to document.

How and when do you revise and edit documents?

Constantly. Which is a problem. There is almost never any support –- you almost never have an editor to back you up. Sometimes your work has to go straight to a customer without even going through your boss first, so the process of checking and proofing and editing everything has to be an ongoing process. And you should NEVER try to edit your own work. You get to a point you see things so often, they don't register on your mind anymore. You have places in the content where you know exactly what you mean, but it won't be clear to someone who's not as familiar with the material as you are, and they won't get it, but you've read it so many times you've lost the ability to see it differently. Usually, because you're almost always working alone, revising and editing has to be a constant thing every minute, and that slows down everything else.

How did you acquire the skills you use for your job? Did you take classes or have on-the-job training, etc.?

I had one class in the tech school where I got an AA in electronics. Followed by 18 years of experience. I very seriously doubt anyone could fall into tech writing accidentally these days. The number of jobs has been seriously reduced and the competition has become a lot more fierce. Nowadays, especially for someone who doesn't have a track record, being able to show lots of relevant training is probably terribly important in getting the first (couple of) job(s). And study tech subjects other than tech writing. Take classes in Java and database design. It will make your dealings with the subject matter experts easier because it proves you have the brains to understand what they do, and it makes it easier to understand how to get the information you need.

What steps did you take to get to the position you are in now?

I stumbled by accident into my first tech writing job in 1990 and stuck with it.

If you're thinking in career terms, the problem is never getting the same type of job. Employers always hire because of your last two or three jobs. The problem is if you decide you've had enough of tech writing and want to try something else. People don't look at your resume and wonder if your 8 years of experience as a tech writer would make you a good production manager. If you do think about doing something other than technical writing, you have to make the change early enough that you don't become over specialized.

Everything I write from here down applies to some extent to every high-tech industry. A little less in companies that actually manufacture things, but very much so in software companies.

Here is the raw, unvarnished truth: If you want to make a life as a technical writer, you must sustain yourself by your enjoyment of writing, because you cannot get any satisfaction from your work any other way. For you there will not be the kinds of rewards that others can expect. Raises, promotions, company perks of some kind - forget them. You won't see them. Technical writing will always pay significantly less than engineering or a type of work that is more central to the company's business.

Technical writing is no longer considered a skilled IT field. It was, up until the tech stock crash of 2001. Now, technical writing has been commoditized. Since the tech bubble burst, companies have been doing everything they can to get leaner but still shovel out as much or even more product. The single largest expense (at least for software firms) is payroll. Payroll expenses are very much a function of time needed for product development. So, companies have been dedicatedly finding the absolute minimum number of people they can keep on hand and still be able to function. Cutting personnel costs has become one of the top 5 maxims in high-tech companies. This is why "outsourcing" and "offshoring" became industry standards.

Nowadays, tech writers are a dime a dozen. Companies hire them as needed and discard them when the immediate need is past. Companies will hire programmers and DBAs and QA personnel as regular employees because they have a direct effect on the process of turning out marketable product. But tech writers do not. So when a company reaches a point where it needs to field a help system or some other kind of documentation for customer use, they'll hire a TW on a 6-month contract and when it's over, he's out the door.

In late 1999 my boss, the VP of product development for the company, told me, half-joking, that technical writers were considered a necessary evil in business. He said the job description would not exist at all if it were not for the fact that customers expect documentation. Companies don't want to have to hire TWs because they are a drain on the company's resources. They have to be paid, housed, and given equipment and support, but what they turn out does not contribute to the value of the product. And since then, his words have been proven by every other place I've worked.

Think about the career progress in tech writing –- there really isn't any. If you are a programmer or engineer, you could have a career path something like this: Engineer > Team Leader > Project Manager > Product Line Manager > Director > VP of Engineering/Product Development > CEO.

A business type or sales could expect a career path something like this: First job > Lead > Region/Product Manager > VP Sales/Marketing > CFO/CEO.

Another IT type like a DBA could expect something like: DBA > Lead Designer > Network Manager > IT Division Manager > CIO > CEO.

Tech writer? Well, to begin with, today almost all technical writers are hired individually and are individual assets for totally separate departments in the company. And that's if it's a fairly large company. A lot of tech writing gets done for fairly small companies where you're the only tech writer they'll ever have. If they do ever hire more, it's because they have projects come up for which they need documents, so they'll hire someone to support that particular project for however long it lasts, and then that writer is out the door.

To have a chance of advancement in tech writing as a TW, you must work in a company which is large enough, and old-fashioned enough, that it has a hierarchical structure related to document production. Such companies are scarce today and getting scarcer. Most such structures for documentation today will be found in government agencies, which opens a whole new can of worms. So if you get hired by a company that has a documentation structure where there is some chance of advancement, how much advancement can you expect? Well, after you've worked there several years, you may become a team leader, and run a group of 3 or 4 people. After several more years, you may have a shot at becoming the documentation division manager. And after that, nothing.

There is no path upward from that. Nobody gets promoted into upper management because he's a good writer. And nobody ever gets promoted because he's good at managing writers. The upper levels do not consider tech writing important and no matter how good you are at meeting schedules or dealing with problems or fiddling the budget, experience with documents is absolutely meaningless when it comes to deciding who becomes the new VP. What matters is perception of dollar value to the company.

A few years ago, Wired magazine had an article about problems common in database management. It pointed out that one of the worst problems was, there is usually a lack of good documentation. But the same article recommended that the way to handle such problems was during the design phase, and to set up the databases in such a way as to minimize the need for documentation. It basically said that doing a lot of work to ensure good documentation was not cost effective in the long run, because management cares that you give them their data on time, and they don't care if you do it with or without documentation. The article ended with the oh-so-true observation, "No one ever got promoted for having good documentation."

One reason most business people care nothing about documentation and what goes into making it is, they think nothing of writing. They are sure it's easy. They can write -- they've seen themselves do it. They have no idea just how awful they are as writers, but they think writing is easy so they have no respect for someone who does it for a living.

Also, and more important, tech writing (documentation) is not seen as contributing to the bottom line. There is no way for a writer or a writing department manager to claim that his work made a verifiable difference to the figure at the bottom of the profit/loss statement. And for that reason, anyone connected to documentation will always be considered a necessary burden, at best.

As you go through life you will find upper level management who used to be tech writers themselves. But in every case, you will find they did not go from tech writing to management. They sidestepped. They got out of tech writing and into programming or business analysis, and *then* they started climbing the corporate ladder. The plain fact is, the career advancement ladder for technical writers has maybe one and a half rungs. There is no such thing as a career in technical writing; there is only a succession of jobs, some of which last longer than others. If you want a chance at a true career, which includes the chance to do different things and rise to a better position, either get out of technical writing or don't enter it in the first place.

Good luck.