What makes a good technical writer?

Many years ago, when I was a technical writing team lead at Mercury Interactive (now HP Enterprise), I needed to temporarily replace a great writer on my team who was about to go on maternity leave. (That writer now has my old job.) Several of the writers I interviewed made excellent personal impressions, but none of them passed the test I’d created earlier, after I identified that we did not have a good way as a department to compare writers interviewed by different team leads. We had all administered writing tests, but they varied, so it was hard to compare results. Our tests included asking our candidates to create:

  • Instructions for an alien on how to use a phone.
  • A user guide outline, introduction and procedure for Wordpad. (I did this test when I was interviewed).
  • A user guide outline, introduction and procedure for the sample flight-booking application included with WinRunner, the leading functional testing tool for Windows applications.

We finally standardized on the last test.

I also introduced another test, to find spelling, grammar, and layout inconsistencies in a sample chapter where they had been deliberately introduced.

My purpose was to evaluate what I saw at the time as the three mandatory skills for technical writers:

  • technical aptitude/ability to learn quickly
  • writing ability
  • attention to detail

It’s not always easy to find this combination of skills in a single person.

Now that I am older, more experienced, and perhaps even a little bit wiser, I would want to find out even more about a prospective technical writer. I would want to know how outgoing and proactive a writer is, and how well he or she would fit into the team and company culture. These soft skills are important for several reasons:

  • Many development organizations do not have a culture of automatically sharing information with technical writers. Writers need the self-confidence and the personality to track down and talk to business analysts, testers, and developers, who often would rather be doing something else. It’s easier to get information from these people if you build personal relationships with them first. And it’s easier to build those relationships in the first place if you’re not a complete introvert.
  • When you talk to the people who design, build and test the product, you understand the context for using a particular feature of a product. This is the “Why?”. Sometimes, depending on the product and the writing audience, including the “How?” is also important. When we writers understand the context, we can explain it better. And when we encounter something that is especially hard to explain, we can often figure out which changes would improve usability.
  • Development and testing managers are often too busy to think about documentation until the product is ready to ship. The writer often must be very assertive to politely remind other team members to answer questions and review drafts in a timely fashion, so that the docs will be ready to ship or deploy along with the product. If a writer is really lucky, sometimes a development manager or project manager, who commands more authority, will see this as part of their job and help with this.

It’s difficult to evaluate a writer’s soft skills in an interview environment, or even with standardized tests. Although you can ask questions during an interview, an experienced writer is often savvy enough to know the right answer, even if he or she might act differently in a work situation. Here are my suggestions:

  • Ask for peer, non-writer references, such as BA’s, testers, and developers. When you contact those colleagues, what do they say about their interactions with the writer? Is the writer proactive, or reactive?
  • Closely review samples of a writer’s work. In addition to the standard descriptions of an interface, is there added value about the “why” of the functionality that is explained?
  • Ask the writer for examples of input into products they have worked on — how was the input offered, and how was it received? If the writer never had input into a product, this might be a red flag, depending on the circumstances.

The best technical writers do more than just explain how to use your product: They become part of your team, improving your product and explain why to use it.

October 31, 2017 update: I love what Tom Johnson, one of my favourite tech-writing bloggers, has to say about how to evaluate technical writers. Although in his initial blog post, he was opposed to writing tests, he posted an update about how they can be useful, in his words, to identify candidates who “pose as technical writers but really lack the skills.” I couldn’t agree more strongly.

Tests helped me weed out several candidates who interviewed well. Sadly, I have sometimes had the misfortune to work with writers that were not sufficiently screened.

Check out: http://idratherbewriting.com/2008/03/13/10-alternate-tests-for-evaluating-technical-writing-job-candidates-a-list-for-hiring-managers/