When You Can Do This Job Working from Home

Many people want to take the online course we offer on this Web site, ‘How to Do Tech Writing,’ because they think they can work from home as a Technical Writer.

Some of our most experienced technical writers do work on projects for our clients from offices they have set up in their homes. But they, and our clients, encounter many problems when the writer does not work on site most days.

Before you can write a set of instructions useful to those trying to figure out the product, you have to learn:

When you have to write instructions for the users of BEA’s WebLogic, for example, it may take you weeks of meetings, interviews, reading previous documentation, and actually meeting current WebLogic users to understand who you’re writing to, what they already know and don’t know, what they do with the application, what instructions they’ll need, and in what order.

Technical writers find out all of the above by interviewing the Product Manager, Marketing people, attending meetings, learning lots of new buzzwords and acronyms, and finally, playing with the product.

Our writers who work from home have a heck of a time getting access to the software or hardware they’re trying to explain. When the Writer lives in another city, they end up writing about a product they never saw, touched, or had the opportunity to examine, photograph, or ask detailed questions about. Talk about writing in a cave, and not knowing what you’re writing about!

You can’t see or use the product at home. Usually, the Client’s firewall prevents you from accessing the Beta version of the software. OR, if the Company agrees to send you the software files, they’re too big to e-mail to you, even zipped.

Our writers who work from home have to schedule a time to go into the Client Company, get into a lab, examine, use, and eventually test the instructions they wrote against the real system. They have great difficulty scheduling such meetings. The people inside the Company have their own work to do and don’t want to leave their desks to usher around a technical writer. That’s not their job. Frequently, the people inside the Company cancel appointments to bring in the Technical Writer.

If you work inside the Company every day, you encounter none of these problems.

Each Technical Publications Department has its own templates, style guides, fonts, system for storing drafts, checking documents in and out of the Company repository, and backing up.

Your hard drive can crash, working from home. Lightening storms, power surges, earthquakes, or theft can also lose your backup drive. If you cannot open a large user guide or Help file, you can’t send it to a printer or the printer cannot open it. ready and due to go to print the next day. Your Client then misses their software release date.

If you work on site, the Company has your user guide stored within their system and backed up safely. Also, Help files and user guides with lots of graphics become impossible to e-mail, due to their size. Someone then has to build an FTP site for the off-site Writer to put his or her files so that the Client can access them.

Tech writing departments usually have a production person to help prepare files for final launch onto a Web site, PDF, or CD ROM, they have an on-staff Editor for proofreading (and sometimes developmental editing), and they give their writers access to a graphic artist to produce clean, polished graphic illustrations.

Working at home, you can’t get any face time with the above support personnel. They don’t know you, they never see you at meetings, you can’t drop by their cubicle, and you don’t have a working relationship with them.

When you never, or very seldom, appear inside the Client Company, meet the Manager, any of the other writers, use the software, or have one live meeting with any subject matter expert, the Company often cancels your contract after one deliverable. Often, the instructions a Writer produces completely off site do not reflect any first-hand knowledge of the software or hardware, what it actually does, and how it actually works. This may vary from a spec, which sometimes off site writers write from.

Successful tech writers communicate well in person, as well as on paper (or on screen).

The first technical writers, who worked for the Department of Defense in the 1970s, could succeed even if they spoke little, did not attend meetings, and could not express themselves very well.

Now, technical writers attend meetings frequently, explain their documentation plans to others, develop a relationship with engineers and get important information out of them. We can always tell when a Writer produced a user guide without learning the product, first hand. Such instructions do not give the user what the user needs, to use the software successfully.