Whether you are filling a full-time staff position or a temporary one, it is important to recognize the core skills required of a low-maintenance, quality technical writer.  In almost all of my hiring there has been the opportunity for team feedback, one-on-one interviewing and sample submissions, but even with all of this input and analysis it is easy to skip over the fundamental abilities required to be a successful writer:

1) Disciplined - writers are like distance runners.  You should have evidence that the candidate writes regularly and consistently, regardless of the climate and various external factors (budget, morale, work-load).  There is much to be said about someone who can shut-up and write without a lot of drama or excuses because there are always plenty available in the technology world.  A writer needs to tune out all of the surrounding noise and focus on banging out the content at the keyboard to consistently produce technical guides.  There is also the review and revision process.  It takes discipline not just to get a first version together, but also to revise the text to a higher-level offering.  It is a painful process to re-open a document and mince words to the satisfaction of product management, marketing, and engineering.  Only a writer with discipline is willing to work through multiple iterations of text and regenerate the pdf again and again.  Leading interview questions to capture candidate’s level of discipline:

• How often do you actually write? 
• What conditions/time of day/etc make up your ideal writing environment? 
• What is the first thing you do when you get into the office in the morning?
• How do you know your text is ready for a review? 
• How many reviews/revisions do you usually endure?

2) Organized - being organized is not just about a clear desk.  As technical systems have gotten increasingly complex there is a need to be able to properly organize large volumes of interrelated steps across documentation sections as well as separate guides.  With little guidance from others, the technical writer is left to decide the proper order of steps as well as how to divide them between mandatory and optional, initial set-up vs. maintenance, and basic vs. advanced topics.  While these decisions may seem unimportant, they can make a mess of an otherwise straightforward process if put into the hands of a disorganized planner and thinker.   There are frequent jokes that users never read the docs, but the docs are in fact used and often at critical points in the installation and upgrade process during a time-limited system maintenance window.  Normally, the user turns to the documentation as a last resort, because he or she has exhausted all other means of guidance or the support line is unavailable.  (Maintenance windows are always during off hours.)  The frustrated and isolated user expects these documents to be well put together and direct them quickly to the relevant section and address their needs.  Since you, the manager, do not want to be brought in for every decision about the organization of the guides, you must hire someone who will be able to consider the ramifications of their text organization and provide the structure that is appropriate to your users.  Leading interview questions to indicate how organized the candidate’s mind is:

• How do you approach an assignment?
• At what point do you consider the TOC, Index, etc? 
• How do you decide what content belongs in the appendix? 
• Have you previously been responsible for designing a complete set of guides?
• When fitting new content to an existing text where do you start?
• Do you get input from users?  How do you collect that input?

3) An Active Listener – writers must interview many different resources repeatedly to get the level of detail required for proper documentation.  A good listener will be able to pull together the information that was provided by technical resources and assemble it into a proper guide, but it requires an inquisitive, active listener to get the level of detail necessary to provide good documentation.  Tenacious listening perhaps is best.  That means not accepting the information from the technical expert because they are so wise and impressively obtuse, but actually comprehending and questioning the information provided.  It’s important the candidate can do this in a polite and calm way or they will be shut out of future information exchanges.  With a degree of finesse and respect the candidate must be able to push through the initial level of detail to one that will allow the final documentation to stand on its own.  This will prevent any last minute delays just prior to shipping because a documentation gap is found at the eleventh hour.  It will also reduce technical support investment and engineering escalation hours down the line due to reduced call center volume.  Leading interview questions to determine the candidates listening skill level:

• What do you bring with you to technical information exchanges?
• When was the last TOI (Transfer of Information) session you attended? 
• What questions did you ask? 
• Did you follow-up with any prior to submitting the draft for review?
• How do you pursue complex topics with subject matter experts?

4) Battle Scarred – good technical writers are in the fray.  No technical document should be written from the design spec or marketing requirements so the writer themselves must be battle scarred from installing and reinstalling pre-release software.  It is not enough to describe the behaviors of the product, but the writer themselves must have stumbled through the processes without much of a guide in order to write a text that will benefit the reader. Only a writer who actually uses the product will be able to delve into the context and provide the user with the information required to make important configuration decisions.  Everyone has read documentation that stated only the obvious and provided no background on the ramifications of the setting, “Check the selection box to enable advanced language analysis.”  Only a writer who cares enough to question and actually play with the settings will explain in the documentation why a user may want to have “advanced language analysis” on or off.  Leading interview questions to gauge how hands-on your candidate is:

• On your last project how did you get access to the product you documented? 
• Have you ever started an installation manual from scratch? 
• Where did you start? 
• How often did you have to re-install?
• Did you get build notices?
• How many bug reports did you file against the last release you documented?
• What were the late changes you made to the documentation as a result of product updates?

While all around experience is definitely a factor as those who have managed to live on their technical writing skills clearly have chops, I encourage you to include these additional skills in your selection process as they will reduce the ‘hands-on’ time you’ll need to invest as a manager and provide a much superior documentation set.  I have had the pleasure of working with several highly effective technical writers and these four traits are not only common, but also very strong in each of them.