Software skills for aspiring technical writer

July 23, 2014 6:23 PM

How do I know I’ve taught myself enough technical writing software (number of programs and my abilities therein) for potential employers to take me seriously?

I’m working toward becoming a technical communicator, preferably in computer-related subjects, mostly Internet and software. Currently, I’m building a portfolio of sample documentation (eg: explaining a complicated technical subject in 10ish pages, a how-to guide, etc). I have no experience with the software a typical technical communicator would use, such as FrameMaker or Adobe Acrobat. (However, I intend to learn in my free time.) I *have* written various documents at my job in nuclear power. Here are some examples:

Wrote daily articles on radiological safety for Outage newsletter (6 days a week for 3 months)

Assembled Powerpoint presentation with pictures and explanations of how portable water heater benefited the site’s boric acid program.

Contributed to Dosimetry Investigation Project. Conducted Outage investigations and wrote Condition Reports for Electronic Alarming Dosimeter (EAD) alarms, lost or broken EADs, and Personnel Contamination Events (PCE).

Wrote roll-up report for PCEs (41 pages of data analysis with graphs) and EAD alarms (15 pages of data analysis with graphs).

Wrote White Paper on Apparent Cause Evaluation (ACE). Searched Condition Report database to reconstruct department issues and identify apparent causes and contributing causes.

Edited ALARA business plan content and inserted graphics based on department data.

Revised reports for clarity and grammatical correctness.

Edited and formatted department Policy.

Took and edited meeting minutes.

Composed department memos.

Note: My Bachelors and Masters are both in English. I’m in the United States.

Could I find a paying in-house job in technical writing using only this work experience? I’m guessing the answer is ‘no,’ but I’d still appreciate the confirmation. With that said, which software would be best to know, and how in-depth? How do I know I’ve taught myself enough for employers to take me seriously? I don’t want to delay unnecessarily. What I really need is a list of tasks I should be able to perform with the various software. Perhaps there’s something useful floating around online?

On an unrelated note, I’m definitely going to join the STC but want to have my portfolio ready and at least rudimentary knowledge of some software. This way, I have something to show people I’m networking with.

Thank you for guiding me on the latest leg of my technical writing journey.

posted by glass.hourousha to Work & Money (6 answers total)

I would drop everything starting with "revised reports for clarity and grammatical correctness." That is not technical writing.

Could I find a paying in-house job in technical writing using only this work experience?

Highly distorted opinion. A lot of tech writing has moved to India and the Philippines so finding the first gig is going to be hard, you want to target a large company where oursourcing has already happened and they're re-growing some on-shore skills.

For context, we are actually looking to hire a techwriter now (bay area); most of our contacts have recently switched jobs, the market is pretty hot.

What I observe about most tech writers interviewed is that the ones who have resumes emphasize tools in the Framemaker/etc, sense tend to be the most disappointing interviews; by that I mean that these are typically the ones where the phone screen reveals that they wrote whatever it was they produced without understanding; mostly prettying up what the team gave them.

When you interview a programmer you ask them to describe how systems they worked on worked - even the parts they did not write themselves - and you look for a sort of comprehension that they understood the big picture. When we interview these writers they mostly describe the process of creating material but have no understanding of their content (or at least none visible).

There's another group OTOH which is the rockstar pile. These are people who have written content for real and understood the context of the content, the reader, the goals of the content, and so on, rather than having taken content and post-processed it. These guys - when they mention SW it's about having ancillary skills. These are the people who you want to write installation guides, hardware guides, process documents, API documentation, command guides, concept guides, etc.

The real rockstars are the ones with enough other skills (scripting, mostly) to reduce manual wasted time. And who understand that copying and pasting things into and out of shared versions of documents are a waste of time. And who understand revision control.
posted by rr at 8:54 PM on July 23, 2014 [6 favorites]

First, I agree with everything that rr says.

What I'll add is that when I was a tech writer at a ~300 person software company, our manager valued experience over pretty much everything else, and I think this was standard for more established firms in the software industry. I am no longer in the software industry or a tech writer, so I can't speak to current practices, but from talking with other writers and editors I think it's always been a difficult field to break into. Established tech writers can have very long and full careers. There's little churn and long term positions don't come up frequently. Also, there's a lot of social networking in the industry, and that seemed to be at least as important as a good writing portfolio, especially for contract positions, which at our firm often went to a stable of known, established writers.

When we interviewed outside writers for open positions in our department, we were looking for writers that either had a particular skill set we lacked (such as designing and authoring a Help system), or who had already established that they could work well independently and while meeting critical deadlines. Knowing how to use FrameMaker or how to write in a multi-user environment were important skills for actually doing the job, but questions about those sorts of skills rarely were given weight up in our interviews. Yes, this was a disconnect...

So...be prepared for a lot of rejection. It IS a hard field to get into, but it can be rewarding once you make it in. My advice would be to put as much effort into networking with established writers as you do into your portfolio -- seriously. When you're trying to land a tech writing gig, who you know is almost as important as what you know.
posted by mosk at 10:22 PM on July 23, 2014 [1 favorite]

I would drop everything starting with "revised reports for clarity and grammatical correctness."

I agree with this, although I think you could keep that experience on your resume by consolidating it into a single line such as "Edited business plans, reports, and departmental policies". I wouldn't mention anything about meeting minutes or memos; that's too much like secretarial work.

With that said, which software would be best to know, and how in-depth?

This is a hard question, because there are so many options out there. I don't think it's very important to know the mechanics of how to do X, Y, or Z in a specific program; rather, it's important to know what different tools are used for. For example, FrameMaker is a desktop publishing tool, while Flare is a help authoring tool, while Author-it is a help authoring tool and a CCMS. They're suited to different tasks.

But doing everyday stuff as an end user is pretty much the same in all of them; you open files or create new ones, you edit them in a WYSIWYG editor, you stick them in the folder/book/manual/help system/whatever where they belong, you click a button to generate PDFs/HTML/whatever. Of course, there are many more advanced things you could do—create output templates, automate tasks via scripting, etc.—but they're not really everyday work, and not necessarily something I'd want a brand new employee to be doing anyway.

Companies tend to say they want applicants to have experience with whatever tool their tech writers are using, but I think this is mostly an attempt to weed out people who need a lot of hand-holding when learning new software. Basic skills are so transferable between tools that I've never had a problem landing jobs where they use software I've never seen before. Like, if you know I was using Vasont at my last job, then you can expect me to be able to do basic tasks in Author-it. If you know I was using Author-it, then you can expect me to be able to understand source control in Flare.

I'd recommend trying the free trial version of Flare. It's fully featured and, if I remember correctly, they give you a couple of dummy projects to play with. And you don't have to set up any source control to get started. You could also try a trial version of an XML editor such as XMetaL. I know that when I was moving from the world of Word/FrameMaker to the world of DITA, I had to learn how to work in an editor that really enforced the proper use of XML. I had to change some habits.

A lot of tech writing has moved to India and the Philippines

This hasn't been my experience, even at companies that have outsourced much of their software development and testing to India (see also this thread). I think it depends a lot on your location.
posted by neushoorn at 1:21 AM on July 24, 2014 [2 favorites]

Came here to say the last point of what neushoorn said; companies have discovered in the last several years that sending English writing overseas is more trouble than it's worth.

Perhaps you should consider getting a Certificate in technical writing? I did this, even though it was boring and I've been writing since I was old enough to hold a pencil. No employer looking for someone with technical writing experience would look at my resume without that.
posted by Melismata at 6:56 AM on July 24, 2014 [1 favorite]

Nthing the idea to focus more on networking and people skills. Interview skills, too. I was hired for a tech writing contract where I'd never even heard of the writing software, but I came with a solid referral. Definitely pick up some software and version control techniques to show that you can, but know that there's a sea of technically knowledgeable tech writers out there who are just awful people to work with. This can work to your advantage.

You can set yourself apart if you are able to:

- Be someone who's generally enjoyable/useful/helpful to have around (and not cause headaches)
- Shed your ego
- Understand and demonstrate end-to-end processes from varied user perspectives
- Get a project done without being a total pain to the PM, subject matter experts, and legal
- Self-edit, submit useable copy, and not hassle the editor
- Deliver on deadline
- Maintain an interest in the company, the products, and the people you work with

Also, and this is important: Tech writing for software and online (and I've done both) requires a solid grasp of QA. There is never enough QA to go around, and if you do it right, your writing job will essentially be up to half QA: testing, reading the design documents, making sure this button goes to that spot, seeing what happens if you enter a null value. QA people are good friends to have. You are on the same team.

I was once not offered a job because the hiring manager felt I wasn't someone who would really get into the product and try to break it, which I discovered later through a friend was really important to them because they'd had some QA gaps in the past. I was devastated. I learned my lesson and now make a point to demonstrate that curiosity in my interviews.
posted by mochapickle at 8:30 AM on July 24, 2014 [3 favorites]

Response by poster: Thank you very much, everyone. I'm so grateful for your thorough, well-thought-out replies.
posted by glass.hourousha at 8:46 AM on July 24, 2014