About Writer Resources

We are pleased to offer several resources, particularly targeted for aspiring technical writers. Please note that the contents of this page express the personal views of Laurie Pearce, President of Words That Work, and are not meant to represent the views or experience of any particular group or organization.

For more technical communication resources, be sure to visit the STC Toronto Chapter.

 

Frequently Asked Questions About Technical Communication 

The following questions are ones I have frequently been asked over the years by would-be technical writers. The answers are entirely personal opinion, and are not meant to represent the views of any other group or individual.

How do you get into this business anyway?		In my experience, most technical writers with even five years of experience and over got into the business by accident. I doubt if few of us thought "I want to be a technical writer when I grow up". We essentially invented the field, and that was acceptable in those days. Now that the field is a little better defined, certificate courses have begun springing up. Do you need to have a certificate to get a job? Well, if that’s the only thing distinguishing your entry-level application from the next person’s, chances are good the person with the certificate’s going to get the interview. Of course, experience trumps education any day, but if you’re just starting out, you have to be aware that you’ll be competing with graduates of such programs. Keep in mind that the skills of technical writing are, to a certain extent, "soft" skills that aren’t easily measured or even discerned. Employers like concrete things like certificates, which is why sometimes the job ads often don’t both to mention skills like good writing and clear analysis, and focus on tools instead.
What’s the best kind of training to take?		I don't endorse any particular program - you should perform some market research, and ask the program coordinators questions about class size, hands-on work, tools, placement success and the like. Try to talk to graduates of the program and get their assessment.
Are all the jobs in the software industry?		No, it just looks like that sometimes. There are many, many other jobs for technical writers, in all kinds of sectors. The dominance of the technology-related jobs, software in particular, is in part because there’s so much growth in that sector, and in part because technical writing is accepted as a job in that area. For example, 10 years ago I might have had to convince an employer that having developers produce their own documentation wasn’t a good idea, and that a professional writer had a contribution to make. I don’t have to argue that any more - it’s a given. In other areas, the writing may be seen as part of a different job (for example, a consulting engineer’s report may just automatically be written by the consulting engineer, and the engineer’s company can’t see that anyone else has something to contribute).
What software tools do I need?		Use discretion when deciding about tools. Not all tools are needed in all sectors of the technical writing business (that is, you may be able to work quite well as a Policies & Procedures writer with just Word as your tool). A survey of job postings for the software industry show you generally need knowledge of Adobe FrameMaker, Microsoft Word, a help authoring tool, some sort of HTML authoring tool, a graphics package, and possibly a presentation package (at a minimum). Many companies offer downloadable "demo" versions of their packages so you can try them out.
What’s the big deal about FrameMaker?		FrameMaker is an industrial-strength desktop publishing package. It’s designed for publishing book-level documents, and so is suited for technical writing. It has lots of high-level control, allows you to show or hide certain text based on conditions (useful for keeping text for two audiences in a single electronic file) and many other cool features. It seems to have become the de facto standard for print documentation. It’s also designed so that the files it produces can be read by FrameMaker on other platforms, which makes it popular. I have clients who have Frame on UNIX and who have no trouble reading my Windows-produced files. I even used to exchange files between my Macintosh and a client’s "Next" computer (remember those?).
I think I already have what it takes to be a technical writer. How do I transfer my skills?		If you’ve worked in any aspect of writing in your professional or academic life, you may indeed have very transferable skills. However, keep in mind that it may be hard for an employer to see the relevance of your experience. If you show them a 30 page report, however brilliantly executed, and they are looking to hire someone to produce a user guide, they’re not likely to be able to make the connection themselves. You need to work hard at making the connections for them as much as possible. You might put the emphasis on the process, how you gathered information from multiple sources, how you revised it several times, and the like, rather than on the product. Look for opportunities to add to your portfolio through volunteer work. If you’re a student, maybe you could write a guide for new users of the computer lab, or for new students on campus. If you’re not a student, maybe you could write a procedures manual for a volunteer group you belong to. If you have some sort of specialized knowledge, try to capitalize on it. Think of the types of documents you could imagine writing, then find out who writes them. Is writing considered a job in that field, or simply part of another job? Make some phone calls to companies in your area of expertise and see what opportunities might be available.
Where else can I get help?		Consider joining the Society for Technical Communication, an international professional organization for writers, editors, illustrators, managers, students, and trainers who are involved in technical communication. To visit their head office site, click here. If you are in the Toronto area, why not come out to a meeting or our very active local chapter? Non-members are welcome to attend a meeting or two before joining. To visit the Toronto chapter web site, click here. In cyberspace, you might consider joining the technical writers’ newsgroup. To go to a site that lets you check the archives for past topics, and for information on subscribing, click here.

 

Recent Career-Oriented Articles Published in the Toronto STC Chapter Newsletter 

The following articles have been published in the Communications Times, the monthly newsletter of the Toronto chapter of the STC (Society for Technical Communication). The Toronto chapter offers a variety of networking and educational opportunities for new technical writers - to go to their site, click here. Articles include:

• Building Your Portfolio
• Presenting Your Portfolio

Building Your Portfolio

You're probably already aware of the importance of your portfolio. But how do you build a portfolio if you're not working as a technical writer, or are working in an environment where, for whatever reason, what you produce isn't usable in a portfolio? Here are some suggestions for creating samples that showcase your ability to organize information well, to write clearly and concisely, and to address audience issues. A printed example lets you show off your design sense. An online example lets you demonstrate that you truly know Winhelp or HTML.

Write Something Original

The old advice of "write what you know" works for technical writing as well as fiction writing. Keep in mind that, although writing the instructions for how to tie your shoelaces, or how to diaper a baby, are challenging, they don't give a professional feel. Be sure you've got a clear idea of the audience and the purpose of your writing before you begin. If the results can be useful to others, all the better - you may be able to involve other people in a review and/or test of your document. Here are some suggestions for drawing samples from your personal life:

• how to choose a daycare
• how to plant a perennial garden
• how to find the best banking service plan.

Here are some suggestions drawn from business life:

• how to send a courier package
• how to get your expenses reimbursed
• how to write a job description

If you're particularly interested in software documentation, you could write a manual explaining how to use a freeware/shareware product you are familiar with. If you want to help your local chapter, you could write a guide on how to choose a technical writing program.

Re-work an Existing Document

You should have no trouble finding a "before" version of a particularly weak manual - most commercial products come accompanied with one. The public sector is also a good source for documents in need of help (the publication that purports to explain the recreation programs available in my area is virtually unusable). Include both the "before" and "after" versions in your portfolio.

As another suggestion, write a sub-set of an existing document. This is particularly useful for software documentation. For example:

• how to use Notepad to write a memo
• how to use Excel to put together a departmental budget
• how to use Word to create an invoice.

Presenting Your Portfolio

A few months ago, I wrote an article giving some suggestions on expanding your portfolio. This article deals with making your portfolio work for you in an interview.

The biggest single piece of advice is simply this - don't leave anything up to the imagination. Don't simply place your material, whether it be an over-sized artists' portfolio or a set of bound books, in front of your prospective employer and sit back. Make every piece tell a story, preferably a story that you can relate to what you know (either through good research beforehand or from information picked up in the interview) about the employers' requirements.

Here are some suggested ways to find a story for your portfolio samples:

• to illustrate your resourcefulness, describe one or two of the challenges you faced on the project, and how you overcame them - for example, "this document had to be produced in three weeks, with very little input from management, so I found I had to...."
• to demonstrate your work habits and processes, describe the process involved in producing the document - for example, "based on my audience analysis, I produced a table of contents and then..."
• to highlight a particular skill, draw attention to some particular aspect of the document - for example, "much of the original material for this manual was written by developers with relatively weak English skills - I managed to trim their prose by about 25%..."
• to show that you're always willing to learn, point out one or two things you would like to do differently - for example, "I didn't have enough time to expand the index as much as I would like - if I were revisiting the project, I'd try to double the length of the index first, then..."
• to demonstrate proficiency with a particular tool, explain one or two particularly tricky aspects of the document - for example, "because this product was being marketed under a variety of names, the product name you see here is actually a variable…"

Before you tell your story, though, be sure to make your role in the production of the sample clear. This helps the employer focus on the aspects of the sample that truly reflect your abilities. It also prevents some embarrassment, such as if, after hearing the design praised highly, you then have to confess that you were working with an existing design. Be sure to state what you were given to work with, what the results were designed to achieve, and for what type of audience the document is intended.

To prepare for an interview, analyze your portfolio samples for their story-telling potential. This may help you identify an area of weakness for your portfolio, where you lack a sample to back up your claim of a particular skill or interest. Make a list of the key points for each item in your portfolio, and be thoroughly familiar with it before your interview. Presenting your portfolio with confidence will, I'm sure, make you an even more attractive candidate to a prospective employer.