This post was written by Andrew Davis, Manager of Talent for Content Rules.

As a former tech writer who recruits truly technical tech writers in Silicon Valley, I sympathize with the predicament of anyone needing to hire tech writers with software development expertise. I am the first to admit that most technical writers’ resumes are aspirational when it comes to the software development tools and technologies they claim to know. Candidates with truly deep understanding of current software technology are very rare. (I know a handful and have no problem keeping them very busy.)

So what’s a hiring manager to do?

Here’s what I look for to assess whether candidates are as effective as they claim for API, SDK, and developer tutorial documentation projects:

  1. Programming experience. There’s no substitute when it comes to knowing what your audience knows.
  2. Sympathy for an impatient user. No one reads reference docs for pleasure.
  3. Excellent listening, research, and information-organizing skills.
  4. Humility, curiosity, and tenacity.
  5. Command of the tools, both for replicating the development environment (to run the product) and for authoring the content.
  6. Deep sense of responsibility, both to the audience and to the product development team.
  7. Excellent writing skills. Without a strong knowledge of (and respect for) the language, and a tireless internal editor, the best of intentions and most rarefied of technical skills get wasted.

On a resume, these traits can be hard to discern. Besides evidence of working with the technologies being documented, I look for repeat engagements with clients or long tenures with employers, ideally with a track record of increasing responsibility as an individual contributor. I also look for accomplishments that reflect a serious work ethic; sometimes (especially in the chaotic world of software development) there’s no substitute for raw, sustained effort.

Don’t misunderstand; I’ve sent clients the resumes of candidates who lack some of these traits. But I’m known for my candor; I tell the hiring manager up-front about my experience with the candidate, and where I sense their weaknesses lie — and what to do about them (for example, allow time for an editorial review).

No one’s perfect, and in the dev-doc world the main imperfections (aside from lying about what they understand) boil down to pride and atrophied social skills. I know almost no API writers, for example, who’ll agree to work onsite for more than a day or two a week. I know none who’ll work for the same prices as their less-technical peers (even if they’re not using their geek know-how on a given job). Like most tech writers, they don’t like meetings, particularly of the frequency required in an Agile environment, and they don’t like interruptions. More than most tech writers, they enjoy the illusion that they know as much as their SMEs, but get defensive when asked to prove it.

Many hiring managers are tempted to hire SMEs who say they can write. And most tech writers have had to clean up the result. Unless such a person has been trained to pay close attention to what the audience knows and doesn’t, and has a gift for organizing information (to say nothing of all the other skills professional tech writers possess and use daily), you’ll be disappointed. There’ll be just as many calls to Tech Support.

If subject matter expertise is crucial and you can’t find the all-in-one resource you need, pair an articulate SME with a smart, capable writer and let them both do what they do best. Hire someone who wants to learn about your product and whom you have a good chance of retaining (assuming the product you’re documenting will evolve). Give them incentives to stick around; tech writers warm to teams that respect them, want their input, and say “thank you” occasionally.

If all this sounds like too much work, call me. Content Rules solves challenges like yours every day and would welcome the chance to introduce you to “geek doc” tech writers who’ll make you proud.

Val Swisher
Latest posts by Val Swisher (see all)