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.
Re: Follow-up to question about getting feedback from users
Subject:Re: Follow-up to question about getting feedback from users From:Keith Hood <klhra -at- yahoo -dot- com> To:techwr-l -at- lists -dot- techwr-l -dot- com, David Farbey <dfarbey -at- yahoo -dot- co -dot- uk> Date:Fri, 25 Sep 2009 06:09:53 -0700 (PDT)
--- On Fri, 9/25/09, David Farbey <dfarbey -at- yahoo -dot- co -dot- uk> wrote:
...snip...
> In his closing keynote address to TCUK09 yesterday, RJ
> Jacquez of Adobe
> pointed out that Technical Communicators are well placed to
> lead the way
> in engaging with customers - many of us are already
...snip...
This observation pushed my curmudgeon button. It may be true. It is also irrelevant, because the number of companies that will allow tech writers and documentation personnel to communicate directly with customers is vanishingly small. In too many companies, technical documentation work is viewed as a commodity - it's something the company buys a package of if and when they need it. Its practitioners are regarded as flunkies who are supposed to simply churn out the papers the company needs; they are considered unsuitable for doing something that matters to the bottom line, like talk to the suckers - er, customers - who actually cough up the money the company wants.
There is some justification behind the idea that technical information personnel should not be allowed to interface directly with customers. Or that such interfacing should be limited in duration and scope. How many programs that train people to create technical documents also teach things like business etiquette and the art of schmoozing a customer? How many tech writers have the necessary skills for talking to customers who may be nervous about the costs or the project parameters? Any time someone talks to a customer you have to be concerned with making the right impression, giving the customer a warm fuzzy feeling about the company and its work, and most technical information people are not well adapted for that. Some got into technical writing because they have the kind of mentality that is better suited to banging out man pages than to interfacing with customers, and the vast majority of them have no training or experience in dealing with customers.
That's my take on the matter; your mileage may vary.
Free Software Documentation Project Web Cast: Covers developing Table of
Contents, Context IDs, and Index, as well as Doc-To-Help
2009 tips, tricks, and best practices. http://www.doctohelp.com/SuperPages/Webcasts/
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
