Last week, I hung out with a lot of technical writers. It was fun. They were from around the world, and they came with some interesting points of view. And with some interesting foreign microbes. Or something. I caught a cold. I think I'm better now. Then again, I thought that yesterday for a while, too. Ah, technical writers, spreaders of knowledge and disease. So I read this book Information Development. It doesn't talk so much about the disease angle, but it covers plenty.
This book is a guide to managing technical writers. You can't teach all of that in just 600 pages. This book is a catalog of things to consider. A few paragraphs about each. Some factors to balance. By following the advice in this book, you could run a great shop or a terrible one. One prejudice does shine through plenty: the author really wants your company to have just one writing organization. Well, maybe she has other prejudices, too. I mostly noticed this one because I disagreed with it. But I do agree with her prejudice towards minimalist writing. She's got a good piece of anecdotal evidence on that (and on the difficulty of measuring the effects of good technical writing):
...the team decided to drastically reduce the volume of the documentation [of an existing product]...
Since the goal was to increase the usability of the documentation, the team members waited with "bated breath" for the results. Once the documentation was released, they were somewhat surprised to learn that the number of customer calls had increased significantly, rather than decreasing as they had expected. However, once they investigated the reasons behind the increase, they discovered that the customers were calling to point out errors in the documentation. In fact, the errors had been in the documents for years. Only with the reduced number of words were the customers reading and finding the mistakes. The result of their innovation was impressive. Customers were using the documentation actively, apparently for the first time.
How many people can possibly want to read this book? How many large technical writing organizations are there out there? I would guess not so many, but apparently there are enough to make a worthwhile market for this book. Maybe that's why the book wants to guide us towards forming big teams of writers--drum up demand for the next version.