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.
I'm not talking about documentation, with all due respect.
I'm talking about skills we have that we've developed along the way of our careers as Technical Communicators, but that, either individually or in certain combinations, can be applied to higher-level challenges that might have nothing to do with documentation.
The two best ones I've heard so far are analytical thinking (Monica -- this is actually perfect) and researching (Robert).
You're not going to put "Analytical Thinker" or "Researcher" at the top of your resume (usually -- that second one might be appropriate for some things), but you can apply your skill of analytical thinking, or researching, or both, to a VP's particular challenge that might have nothing to do with documentation or technical communication.
This is what I meant by "transferable skills" from our skill set.
Thanks,
Steve
-----Original Message-----
From: Peter Neilson [mailto:neilson -at- windstream -dot- net]
Sent: Tuesday, September 06, 2016 4:06 PM
To: mbaker -at- analecta -dot- com; techwr-l -at- lists -dot- techwr-l -dot- com; Janoff, Steven <Steven -dot- Janoff -at- hologic -dot- com>
Subject: Re: Transferable skills of a Tech Writer
On Tue, 06 Sep 2016 18:49:07 -0400, Janoff, Steven <Steven -dot- Janoff -at- hologic -dot- com> wrote:
> But that pigeonholes you into being a communicator.
>
> What I'm trying to get at is skills that might transcend that, but use
> pieces of what we know and can do from the foundation of our roles.
I've told this story before, but it may be helpful here:
Product Mgr: "When is the software going to be ready to ship?"
Dev Mgr: "As soon as Laura (tech writer) stops finding bugs in it."
TW Mgr: "Are you saying that you would prefer the customer to find the bugs?"
Dev Mgr: "That's not what I meant at all!"
I have occasionally had to ask, "Would you prefer me to document according to the project plan, or to the design specs, or to the written code, or to the way I think the product should work?" The answer is usually not pleasant, sometimes suggesting that I should stick to writing.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | http://techwhirl.com
