Technical communication professors often ask students to interview a professional technical writer to get a better sense of the field. The following responses are from Cheryl Landes, a professional technical and marketing communicator. Cheryl owns her own company, Tabby Cat Communications. The questions come from a student at Missouri State University.
I think the best way to answer this question is in terms of the preparation I had for entering the technical communications field. When I entered the technical communications field in 1991, no college programs for technical communications existed. Most writers came from journalism or English programs. The University of Oregon, where I received my bachelor's degree in journalism, offered one technical writing class. I took the class as an elective, but back then, I never expected to become a technical writer. When I was in college, I explored as many writing disciplines as possible—mostly out of curiosity, but also as career alternatives. In the Northwest, it's very difficult for new college graduates to break into journalism.
Journalism attracted me, because I enjoy writing and am curious about practically everything. I also discovered that I loved playing around with computers. When I attended the University of Oregon, desktop publishing was introduced with Apple's release of the first Macintosh computers. Shortly after the Macintosh was introduced, Apple donated Macintoshes to several colleges, including the University of Oregon's School of Journalism. It was a smart marketing move for Apple.
After that, the University of Oregon purchased Macintoshes for a brand new computer lab in the student union. I signed up for an independent study class to learn more about PageMaker, which was among the first GUI-based desktop publishing programs on the market. From there, I continued expanding my computer skills.
During my third year at the University of Oregon, I worked as a secretary for the teachers union at Lane Community College. As part of my job, I wrote and desktop published newsletters on the Apple IIe, the predecessor of the Macintosh. The Apple IIe did not have a GUI, so I had to learn commands to create the newsletter layout, insert graphics, and format text. It was like putting together a jigsaw puzzle, which is among my favorite activities.
I also took a BASIC programming class as part of my course requirements for a radio broadcasting program at Lane Community College. The University of Oregon offered only one broadcasting course, in which we wrote scripts for radio and television. The Lane program gave us hands-on experience in the radio studio as a DJ and behind-the-scenes production, so I took courses in the broadcasting program at the same time as I worked on my journalism degree at the University of Oregon.
More technical knowledge, although I am constantly learning new technologies. Our field is changing constantly.
This varies by client. During the past year, the most common tools I have been using are FrameMaker, InDesign, Word, and Confluence. See the next question for more details.
Yes, I use visuals. The type of visuals I use depends on the client. If I am writing software documentation for end-users, I create the screen shots. If the documentation is for software developers, then I rarely include visuals, because developers just want the basic information, and then they'll jump in. For them, the less fancy the documentation, the better.
If the documentation is for hardware or equipment, usually a mechanical engineer who creates drawings in AutoCAD provides the drawings. When I am creating marketing materials, a graphic artist provides drawings, or someone from the marketing department will provide photos. In some situations, I have taken my own photos with permission from the company. The latter happens often when I am writing case studies for a client.
I don't have a typical work day. Every day is different.
This varies by project. Currently, most of my projects are editing, document maintenance, and embedded indexing. The document maintenance requires writing new procedures periodically, but mostly I'm updating sections that have changed with feature upgrades.
This depends on the project and the client's corporate culture. In agile environments, I've noticed collaboration to be much higher than in other situations. At the same time, some environments that are not agile can be high in collaboration, simply because of the nature of the project. Then at other times, I am handed a project and I finish it without any collaboration. Usually those are editing projects in which I have no contact with the author because of the client's setup. In those cases, I will insert questions and comments (recommendations on how something should be rewritten) in the document, and the client forwards this information to the author to make a decision.
Again, this varies by project but can include regular team meetings, status checks, information-gathering sessions (interviews and in-person document reviews when there are a lot of questions).
This also varies by project and the company's needs. Often I work directly with technicians and developers, because they have the information I need to complete the projects. I rarely work with an editor, because I am usually the editor. I also rarely work directly with users, unless the target audience is developers or field technicians. Most of my current clients fall into those two target audience camps.
As for technical illustrators, it depends on the type of graphics that are included in the documentation. Generally when I am documenting hardware, technical illustrators provide drawings to me from AutoCAD, and then I convert them into the format I need. For software, I create my own graphics—mostly screen shots and sometimes flowcharts created in Visio.
The variety of projects, along with the unlimited opportunities and challenges in learning new things.
As a contractor, my biggest complaint is the “shoppers” who vanish. It's common for potential clients to contact me directly or an agency with a large project. After a lot of going back and forth, which often involves a lot of work in estimating the number of hours for completing a project, I never hear from them again.
Recently I spent almost 10 hours estimating the scope of work on a very large project through one of my agency clients. Two weeks have passed since I submitted the estimate, and we have not heard from the source about when or if I will start the project. We would appreciate the common courtesy of a follow-up, even if the answer is “no.” It's the correct and professional thing to do.
As someone who fell into technical writing, my biggest surprise was how well my journalism skills fit. Not having a technical background is a benefit, because I can see information from a different perspective and ask questions that no one else can or will. It's because others who are involved in the projects see only a small piece of it because of their backgrounds and orientation. This works well, and my skills actually complement the others on the team, regardless of the size.
I don't recall having a big learning curve. However, when my first technical writing job was cut during a major restructure, I spent a lot of time catching up on technology. I took classes whenever possible during my first job, but none applied to what I was doing at the time. Also, the company did not change quickly because of the nature of its industry. When I was laid off, I invested my severance pay into a six-month program at a software learning center and took every class it offered. Two months into the program, I was hired as a contractor at Microsoft. That contract lasted two years, and I moved to another one as soon as the first one ended. This pattern continued for four years.
Be flexible. Technical writing is not sitting down at a desk and writing 40 hours a week. You're spending much more time on research (using the products and talking to people to gather information), editing and rewriting, and often desktop publishing or posting information on a wiki or other online system. In many cases, you're also learning new tools on the fly.
One mistake I often see is that technical communicators want to write solely from specifications but not actually use the product when they have access to it. Writing the steps and taking screen shots while you're using the product results in far superior technical documentation than creating it from a spec. It also helps you understand the product better, which is obvious in your writing. If I don't understand what I'm writing about, then the users won't either. (That said, there are some rare occasions when I don't have access to the product, such as when I work for two of my clients who manufacture products for the military. Then I ask a lot of questions from the subject matter experts to help me understand it. They appreciate the questions and respect me for showing a genuine interest in the work that they're doing. This also improves our working relationships.)
Some technical communicators may disagree with me on this, but I am a strong believer in not specializing in one tool or industry. I have seen many technical communicators work themselves out of a career during the past 20 years from specializing narrowly. I have survived as a freelancer by having a wide variety of skills and learning tools that the typical technical writer does not use. Our field changes so rapidly that even when a particular trend appears to heading in a positive direction, sometimes it fades within weeks or months. During the dot-com era in the late 1990s/early 2000s, trends could disappear within days or hours!
Yes. I love the challenges of technology, of learning new things—even if I never use the information again—and as a freelancer, the flexibility.
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. Topics I write about on this blog include the following technical communication topics: Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, and certificate programs. I'm interested in information design, API documentation, visual communication, information architecture and findability, and more. If you're a professional or aspiring technical writer, be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.