Professional Technical Writing Careers -- Answers to Questions, by Cheryl Landes
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.
What preparation did you have for your current job?
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.
What preparation do you wish you would have had before entering your profession?
More technical knowledge, although I am constantly learning new technologies. Our field is changing constantly.
What skills do you consider vital in your line of work?
- Curiosity—A thirst for knowledge and for figuring out how things work.
- Flexibility—Not being resistant to learning new tools to accomplish the job and helping clients within their budgetary and company limitations.
- Communicating clearly—This not only applies to writing, but in all aspects of our work. We need to communicate clearly to our clients, the subject matter experts, and anyone else who is involved in our projects. Clear communication extends even to those who are not involved in the projects. For example, think about the people who process our paychecks and the support staff who direct us to the office supply stash or other resources we need for our projects.
- Being proactive—Writers tend to be introverts and often we don't take the initiative. It's critical we do so, whether we're consultants or regular, full-time employees. I think this has also created a public relations problem on how valuable we are, because in many cases, no one knows we exist.
- High ethical standards—This applies to doing what we say we will, but at the same time, questioning certain requests that can place employees, contractors, and even the company in a compromising position. An example that occurred on one my contracts was when the firm who placed me in the company wanted me to finish the project early so that I could work on a project for the firm on the client's time. In other words, the firm that hired me would bill the client for work I was actually doing for the firm. I no longer work for that firm.
What tools (including computer software) do you use most in your job?
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.
Referencing the previous question, what are some of the ways in which you use those tools in your work?
- FrameMaker—Creating long technical documents (engineering and operations manuals). These manuals are usually published and distributed in PDF. Many of my clients are small companies or start-ups, so they do not use single sourcing or produce online help.
- InDesign—Used mostly for marketing materials, such as newsletters, white papers, and case studies. More companies are starting to use InDesign to produce user's guides, which can then be exported to EPUB and PDF. My publisher clients also use InDesign to create print books and eBooks. In addition to my work as a technical writer, I edit and index non-technical books for trade publishers.
- Word—This is my primary editing tool for clients. Before the text is laid out in a desktop publishing program, I edit the text in Word with the track changes feature turned on. The author reviews the text for approval, and then the text goes to the graphic designer for layout. If I am also the desktop publisher (which usually happens for technical writing project), then I will lay out the content after my edits are approved by the author.
- Confluence—More companies that produce software for internal use or APIs/SDKs are publishing their documentation on wikis. A wiki interface is built into Confluence, so it's a natural choice for companies who use this system. The wiki can be customized to meet the company's needs, if they have someone how knows how to work with the back-end code.
- Photoshop, Illustrator, and Visio—For creating and cleaning up graphics, when needed. Lately I've also been using a free tool called Greenshot for taking screenshots.
Do you use visuals in your work? If so, what kind of visuals and how are these visuals generated?
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.
What does your typical work day look like?
I don't have a typical work day. Every day is different.
About what percentage of your time on your job is spent actually writing (as opposed to researching, training, designing, etc.)?
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.
How much of your time is spent collaborating with others?
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.
What types of collaboration do you engage in with others?
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).
In what specific ways do you work with others (technicians, designers, developers, editors, users, technical illustrators, etc.) in your job?
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.
What are your major sources of satisfaction in your job?
The variety of projects, along with the unlimited opportunities and challenges in learning new things.
What are your major sources of complaint in your job?
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.
What was your biggest surprise when you first entered the field?
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.
What was your biggest learning curve when you first entered the field?
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.
What is a vital piece of information you would pass along to someone new to the field regarding what a technical communicator/professional writer should strive to do in their work?
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.
What is a vital piece of information you would pass along to someone new to the field regarding what a technical communicator/professional writer should strive not to do in their work?
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.)
What important tip would you pass along to someone who is interested in freelancing (either part-time or full-time) in the field?
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!
If you had your pick of any job in the world, would you still choose to be a technical writer? Why or why not?
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.
About Tom Johnson
I'm a technical writer / API doc specialist based in the Seattle area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.