TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Karen, it's been my experience that the fundamental qualification is being able to do the appropriate research and writing. The details such as the tools you've used and the esoteric inside knowledge are less important. Still, every time I interview for a position or have my resume tossed in the "other" pile I get the feeling that HR or some agency is looking for an "exact" match on the basis of resume checkoff points, rather than actual writing ability. A well-written, conceptual resume can work against you, and a sloppy one full of buzzwords can get an interview. I mean, for instance, like troubling to write Unix, Linux, Solaris, and AIX, where just Unix should do. And then with HTML, SGML, XML, XHTML, instead of "markup". Yecch!
Many managers actually have a good understanding of what's involved in tech writing. Where I'm working now I was introduced to a manager, and when he found out I was the new tech writer he said, "I hate to do that stuff." I replied, "I think it's fun." He said, "Good!"
One of the keys in managing and staffing is to arrange things so that your workers think work is fun. It's not easy, of course, because much work ISN'T fun. But when interviewing for that position where they want a writer with "help" experience that we don't have, the reply of, "Ooh, ooh, I'll finally get a chance to do that?" just might work better than, "No, I've never done anything like that." (I don't know how to have the presence of mind to accomplish such happy exchanges, though. My negativity usually shines through.)
Every position I've ever had in tech writing has involved working with technologies and tools that differed from what I was using before, and I've found it very, very hard to get that idea past the gatekeepers. "Doesn't have Visio. Toss him out." That the process is automated just makes it worse.
Karen Murri asks:
>
> Most of my background is in manufacturing and I've documented some pretty
> intense manufacturing control systems. It's much the same -- writing-wise --
> as IT. You document screens or the tasks you accomplish with the screens or
> both. But, the development processes and environment seems (based on what I
> see you folks talking about) quite different. If an interviewer asks me if
> I've ever written help (to which I have to say no) or user manuals (that's a
> more ambiguous answer), I know I won't get the job.
>
> So my questions ----
> Can I successfully sell my controls experience as IT experience? Would YOU
> hire someone with controls background for software documentation jobs? If so
> -- how do I phrase it or sell it or whatever? What are the key words and
> phrases that would show them I'm capable of the work?
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today! http://www.webworks.com/techwr-l
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
---
You are currently subscribed to TECHWR-L as archive -at- infoinfocus -dot- com -dot-
