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 think we're getting a little far afield from what is normally considered
"politics" and "turf wars," in the sense that those terms are commonly used.
The kind of politics I think most of us who've been in this business a long time
find disgusting are the kind that look or sound like "I can't give you that
because you don't need to know," or "you don't need to know that because your
audience shouldn't care about that" or words to that effect. Case in point:
last year we had a contract with a major computer manufacturer who was releasing
a new system and needed tons of manuals written, aimed at developers. The major
architecect of said system was also writing a big third-party book about the
system, with the company's blessing. Getting this person to give us information
we needed for the company manuals was uncomfortably political, because this
person wanted to keep the "best" information for his own book.
Robin Whitmore wrote:
> What distinguishes a good manual (or any piece of info) is that it explains
> WHY you have to do things a certain way to achieve a goal. <snip> If I don't
> tell the user WHY they should use styles instead of simply formatting
> individual words, or WHY they may want to create templates, then they won't
> learn a good deal of the program's functionality. It is this WHY that can be
> difficult to extricate from developers.
That isn't the kind of turf paranoia I think most of us have referred to. In
many cases like this, there's a simple misunderstanding of exactly who the
reader/user is and what he/she really needs to do the job. Sometimes the best
answer for that is some usability sessions.
The kind of politics I was talking about, the kind that a lot of contractors
avoid wherever possible, has more to do with power plays by various groups
within a company, with information being held hostage to the tussle. At stake
may be such things as which developer group has control over a whole project, or
in companies where there are multiple groups of technical writers which writing
group services a particular division. A really simple version of politics can be
the discussion between a tech writing group and an instructional development
group over who's going to develop certain material. At the core of the
disagreement may be such things as continuing recognition, budget authority,
etc. Most of us would rather simply get on with the project and let the
managers duke it out for control.