An Interview About Technical Writing

This is a special podcast for Carly Finseth at Clemson University who is thinking about entering the field of technical writing and wanted to ask me a few questions. After I recorded the podcast, she was kind enough to transcribe it. I polished up the transcription a bit so that it would be more readable.

How did you make the career transition from academia and teaching to technical writing?

I taught basic writing courses to university students at The American University in Cairo for a couple of years. I also taught composition as a graduate student at Columbia for two years. Teaching writing is okay, but grading student essays was never fun. It was something I really hated. And at times it was okay — but by and large I felt like I was just justifying Bs and C, having to explain why these essays were poor, how to improve them, and so on. But that wasn’t what I wanted to do. I wanted to actually be the writer, not just teach others how to write. So I transitioned into professional writing.

For a while I did copywriting, which was all right, but it didn’t make a whole lot of money. And there’s a certain truth element that’s often missing in the copywriting role. Finally I decided to go into technical writing because it paid better and I thought, well, alright, I’ll try it. And it turned out to be a great fit.

Are you happy with your decision to work in technical communication? Why or why not?

By and large I think I’m pretty happy. Technical writing combines my love of writing and technology. I also enjoy working on projects in IT settings with other people engaged in the same work. That aspect of it that can be really rewarding.

It’s not entirely satisfying, though. It can be a little boring and can lack a little bit of excitement. I mean, you’re not out there saving somebody’s life in an emergency room. You’re not winning a case for some poor person being evicted. You basically sit at a computer all day writing instructions or figuring out how something works, and you occasionally interact with people. It depends on your role, it depends on the project. Some projects are a lot more fun than others, but by and large it is a good choice and I’m happy with it.

Could you tell me a bit about the first technical writing project you ever worked on? What were a few of the challenges – or successes – you faced when first starting out?

I started my tech writing career at a financial institution and, of course, one of the first applications I documented was a financial application. I remember the senior writer who was training me coming over and telling me that I needed to explain individual steps for printing a document. I was blown away by the level of detail I had to include. I couldn’t just assume people could figure things out from a few basic notes (e.g, To print the document, click the Print button). It really had to be detailed instruction (this is something I challenged later).

The other thing she told me is that subject matter experts are somewhat busy and that I needed to save up my questions. That’s something I also challenged later — you can’t have that passive, timid mindset all the time. Sure it’s good idea to save your questions when you’ve got a bunch, but never be afraid of approaching somebody for the information you need.

What advice would you give –- if any -– to those looking to start, or transition into, a career in technical writing?

I wrote a post about this, called 7 Steps to Getting a Job in Technical Writing. The first step is to get a degree in something related to technical writing, usually a degree in English with an emphasis in technical writing. If you have a writing degree, great. But you need to ground yourself in the basics so you know what you’re doing.

After that, get some real experience doing technical writing, because you’re not going to find a job unless you have actual samples of projects you’ve completed. Learn some of the tools. Put together a portfolio. Start a blog. Move to where the jobs are. And volunteer in the STC.

I elaborated on each of those steps in the post. I’m giving a talk about these points later, on October 8th, and I’ll definitely record that. But basically, those are the steps I would suggest. And of course it depends where you are in your career. If you already have a career, the steps to transition into technical writing may be different. My seven steps are intended for students still in the university.

How would you describe your duties on the job? What might a typical day at work for you “look” like?

The typical day thing is hard because days aren’t typical. You do a lot of different things at different points in a project. You may go through like a writing phase, a learning phase, a design phase, a configuration phase (especially with context-sensitive help). I don’t chunk out my days at one-hour intervals doing all these different things. I get in the mode of doing something and spend half the day on it.

For example, here’s how I spent yesterday. First I had to review a handful of presentations for an internal conference. (Sometimes you have to review materials others create.) Then I spent the latter part of the day configuring a relationship table, which is a set of related links for topics. I made sure each page on the user interface had context-sensitive help. I realized that some of the pages I configured weren’t the right pages that I wanted to show up in the context-sensitive help, so I had to add some help topics.

I also spent some time troubleshooting a technical glitch. Whenever somebody clicked the help button, it opened a new window, which is what I wanted, but if they didn’t close the help window and instead clicked the help button again, a new window appeared on top of the previous window, resulting in multiple help windows. So if they clicked the button five times, they would get five different windows open. I tried to figure out how to fix that. Since I don’t really know much JavaScript, it was a little hard. I can code a JavaScript link, but to try to sit there and troubleshoot an advanced JavaScript problem is over my head.

That kind of troubleshooting is typical — trying to get your help to look right, whether it’s troubleshooting something in your help authoring tool or your page layout tool, or whatever — is common. You can spend a lot of time troubleshooting various problems.

What software programs or other technology do you use on a regular basis?

Tools are always a hot topic, but I have decided on MadCap Flare as my help authoring tool, Adobe InDesign as my page layout tool (which I use for shorter documents), and Snagit for screenshots. When I create video tutorials, I use Camtasia studio. I also work with SharePoint. Sometimes I’ll use Photoshop if I’m doing something advanced with graphics. I’ll use Visio if I’m trying to illustrate a workflow or something. On my blog I of course use WordPress. I use most of those tools quite frequently. (I don’t have WordPress at work, but I’m hoping to get an installation going and try to do something there.)

Could you describe a recent challenge you’ve been presented with at work and how (if possible) you were able to overcome it?

I recently discovered that somebody was planning to send out a guide for working with Joomla to build a country website. The guide was just written by a non-writer, somebody who was more of a coordinator. The guide wasn’t very good, and I basically said that. I said, Look, this isn’t good. The guide needs to be rewritten. The instructions aren’t in numbered steps. A lot of details are missing. It doesn’t look very professional. And so of course I ended up having to rewrite it myself, and it took about three weeks. But I felt pretty good about the end result, and I think overall the people using those instructions will be grateful.

It can be a constant challenge to get people in your organization in the mindset that technical writing needs to be done by the technical writing team rather than the project manager or intern. When you have a large organization, it’s easy for people to be unaware of your team, unaware of what you do. They don’t want to be burdened by your process. They sometimes want to just write it themselves in Microsoft Word and get it done — and they don’t realize that it’s terrible. It’s a constant challenge trying to get people in the mindset that the documentation — the manuals, the instruction, the video tutorials, quick reference guides — need to be done by the tech comm department.

What is one of your favorite success stories from working in technical communication? Anything substantial or particularly rewarding that you’ve been able to work on thus far?

I think the way you determine whether something is successful is if you release an application and it takes off. You may just be the technical writer on a team, but you’re also contributing other things. You’re contributing towards usability, you’re interfacing with customers, you’re making sure that things work right. You’re part of an entire team that is building and producing software. If the software is successful, you’re part of that success. We had an internal application at my work that was really successful and it did take off and lots of people started to use it. If you’re not bombarded with a bunch of questions by users, if they’re able to search and find the answers and learn for themselves, that’s also a success.

Do you pursue any continuing education opportunities – either required or optional – for your job? If so, what type(s)?

I do try to keep up with blogs, articles, conferences, and other types of published information. I definitely try and keep up. But official courses? No. There’s a sense of distrust that a lot of people in the industry have about people in the academia. Whether academics are out of touch or not, I don’t know. I’ve seen studies debunking that myth. I’ve also heard academics say they feel out of touch with the current issues in the workplace. So going back to the university to learn how to improve in the workplace isn’t always an idea that’s appealing.

How do you feel that your education did – or perhaps did not – prepare you for your current job? Are there any courses you wish you would have taken or skills that you should have mastered but didn’t? Any regrets?

I have a degree in English and a degree in creative writing. The second one is a Masters degree, the first a Bachelors. Neither prepares you a whole lot in terms of what you’re going to do. You could say that the analytical abilities to assess and comprehend larger structures of text and manipulate them is helpful to you as you organize help topics in a large project. So sure, there’s crossover. In an English degree, you definitely learn grammar and how to write. In fact, just having the love of writing is helpful. But really, as a technical writer, you’re not writing essays, you’re not doing creative writing. You’re not doing literary analysis.

Are these activities truly helpful in preparing you for technical instructions? A little. You need a basic command of the language and good common sense. But if I were doing it again, I would have probably double-majored in English and graphic design or computer science.

Madcap FlareAdobe Robohelp

This entry was posted in beginner tips & careers, general on by .

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, DITA, and more. If you're trying to keep up to date about the field of technical communication, subscribe to my blog.Email

2 thoughts on “An Interview About Technical Writing

  1. Pingback: An Interview About Technical Writing – Technical Communication Center

  2. Pingback: STC Rocky Mountain Chapter - Newsletter » Blog Archive » Interview with Ruth Gaulke, President, STC RMC 2009-2010

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>