Some people suck at their chosen profession. Despite all the enthusiasm and training in the world, sometimes quality and productivity just aren't meant to be. Technical writers are subject to this failure just like everyone else. Your job, as an IT manager, is to hire only the good ones.
Unlike project managers, network administrators and Java developers, technical writers have no formal professional certification to demonstrate their expertise. If you need to hire a documentation specialist, all you have to work with is the candidate's résumé and the person seated across your desk. So how do you tell if the applicant in front of you is worth her weight in gold or should be invited to consider a new career path? Here a few tips to help you weed out the good from the bad-even if you've never hired a tech writer before.
Education and Experience
Until just a few years ago, there was no formal college degree in technical communication. Expect a younger applicant to have some sort of training in technical communication, business writing and composition, or a subject many university English departments call "rhetoric and professional communication." Technical communication programs are becoming more popular in colleges, where they usually offer a more focused curriculum than other majors.
But what about those who started writing long before these degrees were an option? Look for experience-but the right kind. Even if someone has previously had a writing gig, not all writers are well suited for every type of writing job. Journalists and marketing specialists often have a hard time crossing over to technical writing, because it requires a different style of writing. For example, journalists are taught to use the inverted pyramid style of writing, in which the most important and broad topics are covered first, and supporting but less important details follow. Tech writers write in a factual style that usually delivers a polite command, all arranged in a very specific order. When reading a news article, you can leave the story at any point in the article with knowledge. When you read a technical article, you need to read it in a specific order to walk away with predetermined amount of knowledge.
Ask the job applicant questions about specific tasks performed in previous jobs. You're looking for an analytical, succinct and (dare I say it) dry style of writing. Yeah, I know, technical documentation is dull stuff to read. But your writer is conveying information, not entertaining your staff.
You may have other skills that pertain to your specific situation, such as specific software that your future employee needs to use. Don't be dismayed if you don't see that tool on your applicant's résumé. Similar technology skills may illustrate the individual's ability to learn, and that's a much more valuable skill. If your applicant demonstrates knowledge of Word and FrameMaker, it's a safe bet that he can easily adapt to RoboHelp or Flare.
A technical writer should be well versed in both writing and in document layout. Your first contact with an individual's skill is the applicant's résumé. If it's clear, concise and a little unique, it's a good sign. Look for good use of white space and simple but effective text formatting. Even in an age where résumés are received electronically, a conscientious tech writer will take the time to format his résumé accordingly-even in a plain text field.
Todd Murphy, a technical communications supervisor at ITS, an electronic funds transfer company better known as Shazam, has looked at hundreds of résumés. "The résumé and cover letter are my first glance at an applicant's ability as a writer and information designer, so those items are key," he says. "If I had a lot of applicants, I could easily count out those with poorly-written résumés, or ones whose cover letters have glaring grammatical errors."
Someone in my professional circle described a tech writer's résumé that included a five-page cover letter. Yes, five full pages of cover letter. I've often wondered what a person would want to say in a five page cover letter. This is the perfect example of a technical writer not being clear, concise or writing for a target audience. Those are tech writing basics; if your applicant can't have them down in a cover letter, you can safely assume his work won't be much better.
The best part about hiring tech writers is that they can show off what they produce. Ideally, your applicant's samples are relevant to your business. You can review the samples to make sure they are clear, concise and make sense. It's a major plus if you read a document and actually learn something new; that means your applicant is doing his job well.
Ask for samples when you post the job. Pay attention to how they are delivered. On paper? Via e-mail? On a CD? On a website? The individual documents show you a lot about the applicant's writing ability, but the portfolio is also an example of their work. A journalist may bring news clippings or feature stories. A blogger may show personal anecdotes. A tech writer should show off something organized, neat and easy to use.
Ask for samples in the format that is easiest for you to review. If you are looking for someone to work solely online, ask for electronic documents. If you need a print manual, ask for printed versions of the documents.
These days, chances are the writer's samples won't be on paper. Check out the applicant's online presence. Does he have a blog? Volunteer for a professional organization? Do something else with his writing that doesn't get him paid? Take all of these things into consideration.
A good set of samples may include:
Procedural how-tos: step-by-step instructional documents
Project requirements documents
Technical specifications for hardware or software
Training guides, such as a user workbook
Articles from professional magazines or journals. (A few are good, but be wary if this is the bulk of the work submitted.)
Brochures or informational pamphlets-though rarely of the marketing variety.
Some tech writers specialize within the broad category of technical writing. One writer may focus more on procedures while another may focus on training-oriented documents. Some writers focus on API or SDK documentation while others write marketing materials for technical products. Make sure to ask to see samples that pertain to your needs. If you need someone to document help desk procedures, don't hire someone that only shows you training manuals (or can't come up with them if you ask). Many tech writers can write many types of documents equally well; it's up to you to ensure that the person in front of you shows you a specific example of what you are looking for.
Even if the applicant is straight out of college or is trying to make a career change into tech writing, he should have writing samples. If your applicant has no writing samples, and can't produce them after a reasonable amount of time, wave another big red flag. Sure, there are times when writers have to sign legal agreements which prevent them from showing the proprietary information on which they have worked. But a tech writer can always bring something to the table. If your applicant is hesitant to show samples, this is a sketchy situation. Several technical communication managers won't even accept a résumé unless it includes writing samples. ITS's Murphy says, "I would require writing samples or a portfolio that demonstrates their ability to communicate effectively. If no samples or portfolio were presented, I would ask them to provide some and give them a reasonable time frame to submit them to me before making a decision." This is a good policy to adopt and another way to weed out the good from the bad quickly.
Programming Expertise Isn't Necessary
A lot of companies wonder why they can't find programmers who want to write technical documentation or writers that can also program. Let go of this idea.
A good tech writer is not necessarily a programmer. Nor does she need to be the subject matter expert in any technical field. Don't automatically dismiss an applicant who can't write a tuple-unless you want your search to extend over a long period of time with minimal results.
Tech writers that are just as good at programming are like unicorns: You hear lots of stories about them, but you're still not convinced they exist. (Okay, I'm sure some do exist but they're hard to find.)
It's far more important for a tech writer to have good interviewing skills and to ask the right questions. This is how your tech writer will obtain information and interact with the staff. You want someone who can deal with the sometimes odd behavior of IT staff members. It's okay; we know the developers are geeks. That shouldn't bother your tech writer, who should be able to bring even the shyest or grumpiest developer out of his shell and get the information needed to complete her task.
A functioning tech writer and developer team can bring harmony to your IT documentation and your IT department. But remember that each has different skills.
It's important to learn the skills of writing for the audience even if you aren't a professional writer. For another example, see How to Write a Memorable Memo. Tests are Great!
A quick test is the ultimate weed-out tool! A test should last no more than an hour; a half hour will do nicely.
I once interviewed for a contract job which required me to take a five-page test, full of common stuff that a tech writer should know: edit a short piece, write a short piece, identify errors and sketch out a document design. I was lucky; it just so happened that their test was full of questions that were directly related to the specific project for which I was interviewing. The hiring manager could know right away if the candidate-me!-could actually perform the tasks needed to do the job. Another client had me write a piece on a made-up product to get a feel for my writing style. This was a great way to see if I fit with that company's idea of what they wanted from their documentation.
Of course, you do have to come up with the test questions. That can be pretty time consuming, but the test doesn't have to be long; just include questions relevant to the job skills your writer needs. Your test may include a narrative that needs to be whittled down to a step by step procedure, a paragraph to be copy edited and a sketch of what a certain chunk of HTML code would look like on a webpage.
Tests can check out teamwork, too. For example, a great test would be to put a tech writer and a developer in a room together and see if the tech writer can extract a certain procedure from the developer and get it written down in the correct way. A good tech writer will write things down in a way that makes sense to both the developer and the intended audience.
When evaluating applicants, check them against these criteria:
Types of documents written: procedures, requirements, workflows, etc.
Media: work delivered in print and online.
Software skills: word processing, document layout, screen-shot tools, help-document tools, Wysiwyg HTML software.
Media-centric knowledge: A technical writer with a Web focus should have at least a basic knowledge of HTML, CSS and perhaps XML.
Professional activities: involvement in the Society for Technical Communication or another professional organization. This shows at least some effort to keep up to date with the latest trends, though it doesn't guarantee anything (other than the willingness to write a check for membership).
Always take into account the specifics of your own environment! Not every tech writer is the right fit for your department. Only an interview will help you decide this.
JoAnna Springsteen is a project manager and technical communicator based in New York City. She has served as president of the Central Iowa Community of the Society for Technical Communication. JoAnna has been a tech-writing consultant since 2005 in industries ranging from insurance and financial to hardware and public relations. In her free time, JoAnna volunteers her writing skills for the Plone content management system and updates her own blog, where she highlights her writing.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.