I came across quite a few recruitment ads in the papers and job announcements in mailing lists that ask for a technical writer. It is good to see that the demand for my ilk has shot up. What\u2019s appalling though is the emphasis that the companies place on a tool: \u2018should be acquainted with \u2018ALL\u2019 features of FrameMaker\u2019 or \u2018experience in writing for semi-conductor chips a must\u2019. Related Links:<\/strong> write to me: Suman@sumankumar.com<\/p>\n
\n
Here\u2019s my take:<\/strong>
\n
My complaint is very few of them actually are bothered about writing skills. I know that writing skills alone don\u2019t make a good technical writer. A good perspective of technology and writing (to an audience) skills do.
\n
I\u2019ll speak for the IT industry: A tech writer should NOT be code-phobic. She should have excellent interviewing skills. Should be a friend. Should have a lot of patience (your SME<\/acronym> can get on your nerves I am telling you). She must die for her users\u2026 (your boss may slap your back and say \u2018atta girl! It\u2019s looking great.\u2019 But if your user doesn\u2019t understand what you\u2019ve written or can\u2019t navigate through your documentation, it is not a blot only on your skills, but also on the product). So writing to an audience is something that I\u2019d look for when I am hiring a technical writer.
\n
Let\u2019s go for the tools now: <\/strong>
\n
Tools change. Say that again aloud. And learning a new tool doesn\u2019t take time. I am positive that any good technical writer can pick up FrameMaker in a week\u2019s time. But being an expert at it? Go for a desktop publishing person man.
\n
I have no problems understanding technology; the APIs, the chips, the front-end processing, the database\u2026 I\u2019ll understand it all. I\u2019ll interview your SMEs, I\u2019ll study code, and I\u2019ll move mountains to ensure that the technical nitty-gritty is translated into something that your user understands. But don\u2019t go \u2018a technical writer with expertise in FrameMaker, RoboHelp, XML, SGML, HTML, Java, C++\u2026\u2019 Gimme a break will ya?
\n
I am not saying that a reasonable level of expertise in popular (they wont remain popular for long though) tools is not required. What I am saying is, if your candidate were good she\u2019d be comfortable in most of the tools. If she\u2019s not an expert in FrameMaker or Snag IT don\u2019t write her off for god\u2019s sake. Don\u2019t pin your technical documentation to a tool. Pin it to a person. A person that understands the trade, the users\u2026 as I said, if need be that person will pick up your tool.
\n
Also, it\u2019d be nice if your technical writer knows how to break the rules. I mean I know a lot of writers who guard the English Grammar with talibanistic zeal. If I were you, I\u2019d bother about the \u2018usability\u2019 of the error message than its grammatical integrity.
\n
Let\u2019s summarize it: <\/strong>Don\u2019t confuse writing and publishing. They are two different domains. A good writer needn\u2019t be a great publishing expert. Look for a person with a good technical perspective, impeccable writing skills, user-focus and integrity. If I can\u2019t (wont) stand up for my user, I can go home. So my dear reader, the next time you go shopping for a technical writer, remember \u201cTools change.\u201d
\n
If you listen to me you\u2019ll get yourself a \u2018Future-proof\u2019 technical writer. If you didn\u2019t you got yourself a Johnny. And I won\u2019t be surprised. \ud83d\ude09<\/p>\n
\n
FrameMaker<\/a>
RoboHelp<\/a>
SnagIt<\/a>
AuthorIT<\/a>
Irfanview<\/a>
HTML Kit<\/a>
Swish<\/a>
\n
[Note: <\/strong>There are a million tools out there. I have listed what I use.<\/small>]<\/p>\n