The Q&A below is from an email interview I held in early April 2019 with a student from my alma mater, York College of Pennsylvania. I’ve updated a few of my answers with addendums, and threw in some Dilbert comics for good measure. Many thanks to Blayde Alcabes who conducted the interview. (Update: I just learned that Blayde recently launched his own editing service. Check out his website here if you’re interested.)
1. How did you initially become involved with the technical writing and editing field?
I first learned about the field in my senior year of high school. On a dark and stormy night over dinner (okay, maybe it was not dark or stormy, but it was night and dinner was being eaten), I was discussing writing-related career options with my Dad, and he told me that there was this strange breed of writers out there called “technical writers.” Shortly after that I learned that the mother of one of my friends was a technical writer. To give me an idea of what the job was about, she let me edit one of her software instruction manuals and do some basic copy writing. By the time I got to college, I knew a few things about the field and was keen to get deeper into it. I managed to snag an internship as a technical writer in my junior year, where I composed and edited technical marketing materials for a small healthcare IT firm. I stayed with the same firm when I graduated, and took on increasingly complex technical writing projects and roles after that.
Post-Interview Update: I was obsessed with literature and creative writing in high school, and those interests propelled me to want to make a living out of writing. However, I wasn’t at all confident I could pay the bills by writing fiction, hence why technical writing intrigued me so much. The other thing that drew me to the field was the challenge of researching a technically complex subject, and explaining it in writing to a non-expert who has a question to ask or a problem to solve. If that is the kind of challenge that gets you going, then technical writing could be a great career option for you.
2. What have you learned about editing through your internship and work experiences?
This is probably stating the obvious, but I think it’s best to do digital editing with tracked changes and comments as opposed to hand-written markup (which was still a thing when I was in college — I guess I’m getting old). Live editing tools like Google Docs and Microsoft Word online are truly awesome for editorial collaboration. And of course the more you know about the subject, genre, and audience of what you’re editing, the easier it is to offer substantive feedback in addition to comments on grammar and mechanics. Dr. Zerbe’s wisdom [Dr. Zerbe is one of the professors who taught me at York College] about never making an edit that you cannot justify to the writer is true: you must able to argue—in writing and in person—for why your suggested changes are better than the alternatives.
Next painfully obvious point: Always have a style guide on hand, and define or update a company- or project-specific style guide as you go along. For the technical writing / editing field, the Microsoft Style Guide is an excellent place to start (and it’s now available online!). It contains useful explanations about the writing and organization conventions that work best in print and online documentation, and how to accommodate users who are accustomed to web and mobile technologies.
That said, a style guide can only go so far when you’re commenting on gray areas of clarity and meaning. In such cases, it’s a good thing if you can back up your points with general writing principles, as well as examples from respected sources of technical documentation. I think any technical editor would be helped by studying how some of the reputable tech companies out there—Google, Microsoft, Apple, etc.—publish their documentation.
(3a.) How is being a freelance editor different than working in a full-time position at a company?
I’ve never been a freelance editor per se, but I came close to it when I worked as a remote, part-time technical writer in my final year of college. The difficulty with freelancing is that you can feel distant from the subject matter experts and employees of the company whose knowledge matters, and you will typically have a lot less context about whatever it is you’re documenting. If you need to ask questions or conduct an interview, you need to hound the people who can answer you. Freelancers also miss out on the camaraderie of full-time employment. Which is to say: as a full-time employee it’s easier to build great working relationships with the people whose opinions and input you need, and to offer them your own services in return. You’re also better positioned to accumulate and expand your knowledge of the subject matter over the years.
On the flip side, freelancing gives you more freedom and lets you try different projects, and no doubt exposes you to different sorts of tools and documentation problems to solve. It’s not my jam, but I can see why other writers prefer that path.
(3b.) Do you have any recommendations for those interested in freelancing careers and opportunities?
Perhaps the most important thing (beyond actually obtaining clients— a subject I’ll leave aside given my lack of experience) is the ability to research and get up to speed as quickly as possible. At the beginning of a freelance project you’ll likely have a lot of questions, so you’ll need to act like an investigative journalist who’s under an intense deadline to pry the answers you need from subject matter experts (SMEs) who don’t know you (and may feel they have higher priorities than to answer your questions). Don’t be fazed by that. Hone your question-writing powers! Go after those SMEs using every available channel! Bring a voice recorder to your interviews! Break their will to avoid you!
(4.) What are some of the most difficult aspects of writing and editing technical documents? How do you recommend addressing these issues that persons in the field may encounter?
I’ll break my answer here into a few parts.
First is the research aspect of what you’re documenting. Sometimes it’s hard to get time from the SMEs. Sometimes you don’t have access to a demo or test environment. Sometimes people are delayed in responding to you or think you’re dense for asking certain questions. To overcome that, you need patience, respect for other people, a thick skin, and (as I mentioned above) the tenacity and information-gathering skills of a journalist who can proactively explore every possible avenue for obtaining knowledge.
Secondly, depending on how much information you need to produce or revise, the writing and editing process can be overwhelming. If there’s a lot of content, you’ll have a big organization challenge on your hands. What’s the best way to structure all the information? What’s the ideal information architecture? One of the most useful conventions in the industry is to approach organization with a task-based, modular approach, where you organize your topics into discrete, standalone chunks of content. Another useful approach is to think in terms of “every page is page one”: your users may arrive at your content in unpredictable ways, so you need to write and design your content to accommodate that possibility. Both approaches often go hand-in-hand.
The last big challenge I’ll mention (though there are plenty more related to things like content reuse, single-source publishing, and the complexity of the tools you use) is related to maintenance. You should always try to write and design documentation that will be easy to update in the future. You should also think of how to evaluate whether your content is performing well. Since you often can’t talk directly to your end users, it can be difficult to know if your content is solving the problem it was meant to solve. Ideally you could do user testing and have access to web analytics to help with this. Doing peer reviews with various types of readers and getting anecdotes from the Customer Support group at your organization are other essential strategies.
Post-Interview Update: There is of course another enormous challenge that tech writers face, which is being able to articulate their organizational value to the people who control the budget. The stereotypes about our role as mere grammar nerds, typists, and note-takers are slow to die, I’m afraid. The good news is that the tech comm community has been talking about its value proposition for years now, with answers ranging from “we help knowledge flow through the company!” to “we can support sales and deflect customer support calls!” to “we describe things in plain English!” It’s important to get conversant on the subject. See this in-depth blog series for a good start.
Admittedly, tech writers bear some blame in reinforcing the stereotypes about them. So much technical documentation is useless because it states the obvious, or is grammatically correct yet opaque. I’ve seen docs that list the elements of a software interface and define in brief what they do, but that sort of detail is not usually what users care about. Users care more often about why they should choose one option instead of another in the context of a given task or decision. One of the most important questions a technical writer can ask is, what does your reader need to know, and why do they need to know it? For some tips to that end, check out this great article at Techwhirl.
(5.) Based on your professional experience, how would you describe the physical setting(s) and common culture of the technical field? What are some tips to succeed within the environment?
I’ve been in government and commercial software company settings that were quite different, both physically (layout and design of the office) and culturally (dress code, interpersonal dynamics, tone of corporate communications, stuff like that). One was rather closed, with lots of cubicles and a more formal culture in which you didn’t have a laptop and thus you couldn’t move around very easily. The other was more open, with standing desks and no cubicles, and much more dynamic and “startup-y” culture in which everyone had a MacBook. Whereas the more closed culture felt restricting, the more open culture could be chaotic and distracting. So there are pros and cons to each type of setting. What transcends them is your team dynamic, i.e., how well you get along with your colleagues. As a technical writer, or more generally as a tech professional, I think the best way to prepare for your future work environment is to be flexible and sensitive to the ways that your colleagues prefer to collaborate. Some people like email, others like direct messages, and others really like to hold off-the-cuff brainstorming sessions. Become a pro at all these methods — and also at checking calendars, setting up meetings and video calls, and holding whiteboarding sessions when you need to. Perhaps one of the biggest misconceptions about technical writing and editing is that there is (or should be) quite a lot of collaboration and interaction with other people.
Post-Interview Update: One other observation, building off the whiteboard idea above. Tech writers who are comfortable sketching pictures and communicating their ideas in visual terms will, in my opinion, have an easier time collaborating in the tech world. Engineers, product managers, and designers tend to think in visual terms, whereas writers and editors generally prefer verbal and written means of collaborating. If you can master both, you’ll have a much easier time clarifying your ideas and reaching agreement with your peers as you work together. Take a look at The Back of the Napkin if you’re interested in a book that might help you here.
(6.) Do you have any specific advice for standing out among other applicants during a job search (and/or other employees as a member of an organization) in the context of a technical position?
Why, yes I do: I published an article about it! You can see it here: “How to Be an Amazing Tech Comm Job Applicant: Tips from a Tech Comm Hiring Manager.”
(7.) Is there any other information related to the technical writing and editing field that you would like to share? Do you have any general advice for those pursuing careers after college?
I can think of some other things, but a good deal of it is covered in the above article, so I’ll just end on that note.
Post-Interview Update: One final suggestion I have is to read up on how people actually search for information on the web, and how they perceive and conceptualize the content they find. The web has radically changed how people ask questions, and more and more documentation is being written for web and mobile formats. Excelling as a tech writer in the digital age will be hard if you still tend to think of documentation primarily in terms of books and PDFs. Mark Baker’s Every Page is Page One is one of the best books I’ve read that explains what all this means for tech writers. Two other really excellent books are Information Architecture for the World Wide Web and Don’t Make Me Think: A Common Sense Approach to Web Usability.
Richard Rabil, Jr. 