Symposia•The Lone Writer

Many of us feel overwhelmed by the volume of writing we must produce. Even more overwhelmed is the “only writer,” who—like the only child—often has special needs and concerns. By using a few simple strategies, only writers can organize themselves to create well-written, usable, error-free, and technically correct manuals with a minimum of stress. Bonni Graham, who has been there and back, will discuss some of the strategies she has used to become simply “whelmed.”

Once upon a time there was a young technical writer. She and the senior writer at her company were kept very busy guarding the manuals as they traveled through the routing process, beset by dangers from all sides. Suddenly, out of nowhere, the manual caravan was attacked by vicious budget cuts. Soon the young technical writer was the only writer left alive. Frightened and wounded, she gathered the manuals and crept to the safety of a remote office, where she nursed her wounds and vowed that as soon as she healed, she would stand as the protector of documentation everywhere in the building. Any time quality was faced with the threat of compromise, that young technical writer would emerge from her office to become...the Lone Writer (Hi Ho, Silver, and Awaay!).

Parts of that story are true. I was hired straight out of college by a library automation firm called Data Trek (now named EOS International). Soon after they hired me, they “rightsized” the other writer, leaving me all alone, with all of six months' writing experience, and none at all of formatting and page layout. Nevertheless, I managed to produce eighteen moderately good manuals over the next eighteen months.

To do this, I followed three basic steps:

insisted on sophisticated hardware and software (Choosing Silver),
created firm routing and development patterns (Mapping the Canyons), and
worked closely with other departments and their employees to pick up the slack (Finding Tonto).

These three steps proved to work so well that I was able to start focusing more and more on higher and higher quality.

Choosing Silver

If you were a ditch digger, and all you were given was a teaspoon, I don't think even management would be surprised if the ditch took several times as long as expected to dig. Yet many non-writers are surprised to find out that a good word processor and page layout program are crucial to the lone writer. Silver wasn't a mule, and your publishing setup shouldn't be, either.

A word of warning: I work almost exclusively on a PC and am attached to a Windows network—some of this advice will not be directly applicable to Macintosh users.

Hardware

One of the first things I did was prepare a few comparisons to show how much less time things like index processing, printing, and formatting took on a higher-powered computer. If you're expected to produce camera-ready art (or even an EPS file for service bureau output), a processor less powerful than a Pentium just doesn't cut it. If possible, insist on at least a PIII, a Celeron if you can get one (the time savings alone can tip the scales on a cost-benefit analysis).

Also try to get your own hard disk drive and install your tools directly to that. I found that if I just archived my working files on the network drives and ran my applications from the local hard disk, I could work much faster. I also was not as affected when the network went down (which they ALL do, usually at the worst possible time).

Software

The next study I did was to examine the amount of time I spent switching between the program I was documenting and the word processor in which I was writing. I found that I spent an average of 3 hours a day watching my computer exit and load programs. Purchasing Windows [NB: Windows generally comes installed on modern computer; this article is several years old - BG] decreased that time to a matter of minutes. Upgrading to the latest version further reduced it to seconds, in most cases. Purchasing an appropriate amount of RAM decreased it further, regardless of the operating system. If you plan on running two programs simultaneously, ask for 64 Mb — more if you can get it (I use 128 Mb).

Finally, I looked closely at my toolbox. I was using WordPerfect 5.1 for everything. Now I'm a big Word fan—for word processing. Whichever word processor you chose to use, though, be aware that it simply isn't a page layout program. I spent more time juggling frames and fighting with the template paradigm than I did doing almost anything else. I looked at several layout programs and chose Ventura Publisher, which I like a lot. We now use FrameMaker, I was able to cut my layout time by two-thirds. If you only have to write the manual, a layout program isn't worth the money. But if you have to lay it out too, insist on the appropriate software.

Mapping The Canyons

Unlike old TV shows, with their limited sets, Lone Writers cannot afford to ride past the same rock five times in the first episode. Nor can they afford to go tearing down a canyon after hearing a cry for help, only to find that it originated three canyons to the north. You must know exactly where the bottlenecks in the process are and be prepared to counter them.

Routing

My predecessor was a very hands-on micromanager. He didn't really want input, except for the minimum necessary to ensure that the manuals were accurate. I wanted my work seen by as many eyes as possible, for a couple of reasons: I didn't feel that I knew what I was doing yet. No one knows a computer program the way the system designer and primary programmer do. They can spot holes and omissions the way hawks and eagles spot their prey, and with about the same enthusiasm.

It simply isn't possible to proofread your own work. You know what you meant to say, and almost invariably, unless you can afford to set the manual aside for at least a month, your eye will see what you meant to write, not what you actually wrote.

Convincing management of the necessity for routing wasn't difficult—the last two writers had included some questionable humor in the manuals. All I had to do was point out that routing the manuals before they were printed could eliminate the problem. I most carefully didn't point out that I was still the last one to see the pages, and had final say over any edits. When I left that company we had two or three routings included in the development process. I still set up at least that many for my clients today.

Flowcharts

Another canyon to map is the writing process itself. Data Trek's CEO (not a dummy) asked me to write a short manual for one of our utility products. He wanted to know how long it was going to take. “Well,” I said ,"How many steps does the user have to perform?" He replied, confused, “Does that make a difference?” Later that day, I had to explain why this was so funny to my immediate supervisor.

All of us know that it takes less time to write one step than it does to write fifty. But how many of our bosses do? I was, quite literally, the only writer in the company and am frequently the only writer my clients are exposed to. Often, no one else at the company has any idea of what I do all day. If you create a flowchart of the process you must complete for each manual, you can eliminate a lot of this confusion and strengthen your estimates.

Finding Tonto

Even the Lone Ranger didn't have to go it completely alone. Tonto was an effective second pair of eyes and ears. Lone Writers need this, too. Data Trek had made it patently obvious that they were not going to pay for another writer. There are, however, ways around this.

Society for Technical Communication

Go to STC meetings. Even if all you do is gripe and listen to other writers griping, at least you know your problems are not totally unique—other people have faced them and survived. I've gotten suggestions on fixing a number of problems from other STC members. Sometimes just talking about writing to people who don't need the writing process explained to them can help you solve the difficulty yourself.

Other Employees

Cultivate ANYONE in the company with ANY writing experience, then convince your supervisor (and theirs) that some overtime compensation would not be out of line to get the product released on time. I've used people from marketing, product support, product development, and administration to help meet deadlines. Be very careful choosing who you work with and what you give them to do. The one time we hired a contract writer, I misjudged the person's ability to lay out a page and ended up recreating the entire manual. Give simple text creation to those you're least sure about—editing is easier than redoing.

Students

Try to find student interns. Yeah, you have to teach them, but they're another warm body who already understands writing. Do not underestimate this. Make sure, though, that you have actual writing projects to give them—don't assume that you're getting a personal secretary to do your grunt work and make your coffee. Most programs are very strict about the kinds of work interns are supposed to be doing. In other words, writing and laying out the boring but necessary little projects is okay, but sharpening your pencils and doing your photocopying isn't.

Other People's Workloads

Finally, make friends with people outside your department and use their specialties to help you. The biggest change in my workload came about because the designer, the lead programmer and I were in cahoots. Software development usually goes through four stages: initial coding, alpha testing, beta testing, and release. At Data Trek, the writer used to be brought into the development cycle during beta testing. When I left, I was receiving specifications from the designer and code from the lead programmer, and could begin writing as soon as there was enough code to let me see the program procedures. This allowed me to finish a first draft in time to hand it to the alpha testers—so the manual was tested, too. I could route the manual and make the edits in time to have a version ready for beta testing—so the manual was tested by users. I could route the manual again, and have it ready for final routing and release almost as soon as the software was ready. I was no longer a development stumbling block, nor did I have to produce a complete manual in the last week before release.

Don't think of yourself as being alone. With a little creativity, you can be the director of a much bigger process, escape being a “cog,” and avoid offending or threatening anybody.

Conclusion

I've come a long way from the terrified, inexperienced writer I was five years ago. I still have a long way to go (no I have to learn management of my own team!), but I'm much, much closer than I would have been if I hadn't been pushed out of the nest so abruptly. A friend of mine jokes that I got five years of experience from Data Trek—I just did it in two and a half.

The most important things to remember are to be open, creative, and prepared. Openness will help you accept help when you need it and let you be just “whelmed” and not overwhelmed. Creativity will solve more problems and get more done than all the overtime in the world. Preparedness will allow you to see when the other two strategies are most needed.

Hi Ho Silver, and awaaaaay!

About the Author…

Bonni Graham began writing as the "Lone Writer" for Data Trek, Inc., a library automation developer. She then moved on to Easel Corporation's ENFIN Technology Labs, working on object-oriented client-server development environments ("OO-La-La"). Currently Bonni owns a documentation business, Manual Labour, with clients like Hewlett-Packard, Kenwood USA, Nissan North America, Xerox Document Sciences, and i2 Technologies.

Copyright © Information
This article may not be republished or redistributed by any means or under any circumstances whatsoever without the express written permission of the copyright owner, Bonni Graham. Single copies of this article may be reprinted for private use and for review purposes only. Excerpts from this article may be reproduced, provided the reproducing author/editor makes the appropriate citations referencing the article's original author and date of publication.
Copyright © 1993 Bonni Graham; updates copyright 2000, Manual Labour, Inc.