I’ve commented before on how the unbridled passion for SEO has created a subculture of commoditised writing, where brokers are offering ridiculously low prices for “articles” sometimes paying as little as $1 for 200 words. No-one who lives in a western industrialised nation could afford to work for those rates, but there appear to plenty of people in less economically developed areas who do take on this sort of work. That’s one way of devaluing writers and writing.
Many of my colleagues work in software development, as I have done for a large part of my technical writing career. The tension in being a technical writer in a software development team often stems from tight timetables – you need to write a user-facing document for an application that might not yet have a user interface, or even any working features. Someone expects the features coding, the interface design, and the well-written user manual or online help to be ready to ship at exactly the same time. Other tensions stem simply from programmer arrogance. If I had a pound for every software developer I’ve met in my technical writing career whose whole attitude was “I’m far too important to waste my time answering questions from a mere technical writer” I’d probably be able to retire. These are both ways in which writing is devalued.
This week I came across a new way of devaluing writers and writing at work. It was a job description for a post in the marketing department of a reputable European firm, and the job role included creating product collateral including white papers and fact sheets, and writing newsletter content. A classic “Marketing Writer” role you might think, but you’d be wrong. The job role also included “organising events” (which translates to “making phone calls for the marketing team”) and “supporting lead generation activities” (which translates to “answering phone calls for the marketing team”). The title for this job was “Marketing Co-ordinator”, and goodness knows what else this poor person would be expected to do. Writing marketing collateral? Oh, that’s something you can do while you are waiting to make your boss his next cup of coffee.
p>





David, you make some good points here. It seems to me that many IT companies only value technical ability. Documentation is an afterthought. Also gone by the wayside are training, mentoring and simply being ‘nice’ to one another in the workplace.
Another easy way to devalue technical communication is to place developers in charge of defining how and what makes the doc possible. For example, the exercises that best describe software from an instructional design point of view are often role-based, and require a subtle understanding of how the application will be used by people in different roles, in a business context.
QA testing is about stress testing the application to ensure it is coded well. The QA tests (and data) are written with a different perspective, Simply saying ‘all you need to do is look at the QA tests’ is developer-itis.
Worse, it leads to project plans where the documentation is considered as having the same lifecycle as the code.