How to Hire a Technical Writer - for the Non-Writing Manager

Very often, companies place the management of technical writers under non-writing managers in departments such as Engineering, Design, Marketing, etc. Not that these managers aren’t good at what they do, its just that when it comes to hiring and managing technical writers, a different set of skills is required. Let’s face it. Hiring a technical writer can be difficult, even if you are one. Where do you find good technical writers? What should you look for? How can you spot a good writer from a bad one?

While you may be tempted to use the same services that you use to locate engineers or other technical employees, this is not the best option for locating highly qualified technical writers. Cattle call comes to mind, but let’s not disparage our good friends at the placement agencies. They do provide a valuable service. However, I would recommend using your local chapter of the Society for Technical Communications (STC). Most of these chapters have job boards where you can post employment opportunities. There are also many internet-based communities specifically for technical writers. Techwr-l has over 3,000 direct subscribers worldwide and is a great resource for all things pertaining to technical writing. There are also tool specific communities as well. Posting job opportunities on these sites gets the word out quickly and allows members in your area to decide if they have the required qualifications for the job.

But before we get too far ahead of ourselves, let’s stop and review what exactly technical writers do. Often times the hiring manager has had no experience working with a professional technical writer and is not really sure exactly what it is they do (other than write). It’s ok, you can admit it if you’re one of these managers. That’s why we’re here.

Nature of the Work

According to the U.S. Department of Labor, Technical writers put technical information into easily understandable language. They prepare operating and maintenance manuals, catalogs, parts lists, assembly instructions, sales promotion materials, and project proposals. Many technical writers work with engineers on technical subject matters to prepare written interpretations of engineering and design specifications and other information for a general readership. Technical writers also may serve as part of a team conducting usability studies to help improve the design of a product that still is in the prototype stage. They plan and edit technical materials and oversee the preparation of illustrations, photographs, diagrams, and charts.

Qualifications

Increasingly, technical writing requires a degree in, or some knowledge about, a specialized field—for example, engineering, business, or one of the sciences. In many cases, people with good writing skills can acquire specialized knowledge on the job. Some transfer from jobs as technicians, scientists, or engineers. Others begin as research assistants or as trainees in a technical information department, develop technical communication skills, and then assume writing duties. Knowledge of a second language is helpful for some positions.

Ok, so now that we know what technical writers do and where to find them, what exactly should we be looking for in a technical writer? You may be tempted to look for someone with experience in your industry. But, be careful not to fall into this trap of hiring someone who “knows what you know”, or more clearly, has similar expertise in your field or industry. While some knowledge of your industry can be helpful, it should not be a primary qualification when hiring a technical writer. Regardless of how much they know of your industry, they will still need to learn your particular product should you hire them.

So what should you look for in a technical writer?

A good candidate should be able to:

• Design documents for both hardcopy and online use
• Design documents that can be easily updated and revised
• Write instructions that are easy to understand

Document Design

A well-designed document is more than just a pretty book. It should be just as easy to maintain and revise, as it is easy to read and understand. Poorly designed documents will create extra work for you. Maybe not immediately, but at some point when you must update, revise, or localize the document. The poorly designed document will come back to haunt you. When interviewing your technical writer, try to get some ideas about how they organize their documents and source files. Well-designed documents are not only pleasant to read and use, but are also easy to maintain and manage. And as your needs grow, well-designed documents will easily grow with you. It is the structure of the document that, more than the writing, determines how easy it is to update. A good writer can find and fix a poorly written paragraph in a few minutes, but a poorly structured document can take weeks or months to repair.

So how do you determine if your candidate can properly design a document? Look no further than their resume or CV. This should be the pinnacle of their ability. After all, this is what they can produce with no deadlines and unlimited resources. Not exactly the conditions most documentation is written under. So, safe to assume that anything they write under your employ will be of reduced quality. Start by having all candidates send their resume or CV in Microsoft Word. Unlike pdf or text files, a Word file will give you a behind the scenes look at the candidates document design and formatting abilities in all it’s glory (or horror).

Begin by looking at the basics. Take a look at the document as a hardcopy or online with all layout features turned off. Turn off layout features such as paragraph markers and table gridlines.

A well-designed resume looks well balanced on the page. Information should be easy to locate and pleasant to read. Look for clear margins and consistent use of white space, as well as consistent alignment of each page element (headings, paragraphs, lists, etc.).

Now lets look behind the scenes. Turn on all formatting marks and table grid lines in Word. Just like a good car, a document may be nice to look at, but if it hasn’t been built properly, it’s going to cost you in the end. Take a look at how the author created the document. If it has been formatted using tables, look for proper alignment of the columns. If formatted using tabs, there should only be one tab marker between each text element. While the use multiple tab markers is a relatively minor offense, misaligned table columns is a serious flaw.

Now, lets determine how the author created white space. Multiple paragraph returns of varying size and distance should be a red flag. A document with white space but no paragraph markers or tables is the mark of a good document designer. Next check the spacing between words. If the author uses multiple spaces to create horizontal white space, remove them from your list.

Similarly, page breaks are a telling detail. If the author uses paragraph returns to create page breaks, they have no knowledge of even basic document design and are not someone you want creating your documentation.

Samples of Work

Have your candidates bring in samples of their work to the interview. Don’t worry if the samples aren’t “technical enough.” The same skills are used to create cooking instructions as those used to document software development kits. We’re looking for basic, universal technical writing skills.

Front Matter and Cover

Take a look at the front matter and cover. Ask the candidate questions regarding document numbering, version tracking, copyright information, and page numbering. While the writer may not have had the freedom to change this information, their opinions regarding these issues are important. Turn the pages. The left-hand pages should be either a continuation of previous sections or should be left blank. New chapters should never start on the left-hand page. Flip through the document until you get to the last page of the last chapter. If the last chapter ends on a right-hand page, the next left-hand page should be blank except for the header and footer. Flip through the document and scan the page numbers. Are they sequential? Check the page number on the right-hand pages. It should always be an odd number. Any problems with page numbering should be regarded as serious design flaws.

Go to the TOC and check a few of the entries verifying that the headings are worded exactly as the headings they refer to, and that they appear on the specified page. If the TOC says that the heading “Introduction to Software” appears on page 20, go to page 20 and verify. Since most desktop publishing software automatically generates the TOCs, any errors can indicate that the candidate hand-coded the TOC. This is a serious design flaw and indicates that the candidate does not know how to properly use the tools. This kind of design flaw will create extra work each and every time there is a revision or update to the document. Unless you are willing to train this candidate, do not hire this person.

Now read a section of the document. Is it easy to read and understand? Is it confusing and difficult to understand? Information should be concise and easy to find and understand. Just remember that problems with the documentation may be caused by a poorly designed product and not badly written documentation.

Ask the candidate to explain how cross-references were created. Most desktop publishing software have tools to automatically generate cross-references, hand-coded cross-references are a serious design flaw and should be considered a major red flag. Do not hire this person unless you are willing to provide major training.

Inexperienced Technical Writers

Candidates with little to no technical writing experience don’t necessarily need to be rejected out of hand. If your company uses well-designed templates and you have the time to closely supervise the new writer for the first few months, an inexperienced writer can grow to be a valuable asset. The main hurdle with the inexperienced writer is the lack of knowledge with the desktop publishing software. If you don’t have well-designed templates, this can lead to the major design problems as described above. The inexperienced writer may not have much to show you. But, letters, articles, and even gratis work documenting open-source software all show initiative. Read these samples carefully to determine how they formulated their thoughts. You may have a diamond in the rough and with a little training, a valued member of your team.