The longer I spend as a technical writer, the more I become discriminate about the technical writing books and publications I read. I stopped taking the academics in technical writing seriously a long time ago and made every effort to align myself and my documentation to the business — the people that pay my check — versus the theories of some professor who faces everyday in the safe predictable confines of the classroom. This means, I am very happy after reading Technical Writing Management: A Practical Guide by Steven A. Schwarzman. He writes this book from practical experience in a tone that should resonate with both long time technical writers and those still coming up through the ranks.
The book lays out some of the more practical aspects of technical writing that are lost in academia like aligning yourself (as a solo technical writer or manager of a technical writing group) to the business, and educating your company (without causing programmers and engineers to flashback to freshman comp class). It also lays out compelling reasons why a technical writer needs to understand technology in order to write about it. The idiot as a user advocate is an industry myth.
He also spends a good bit of time in the book about hiring writers. Hiring technical writers is a topic near and dear to my heart and while I don’t necessarily agree with his views on testing writers, he provides a methodical approach that can help non-writers hiring technical writers or senior technical writers new to management and hiring. Unfortunately, my experience with testing writers includes a number of poorly designed out of context tests and working with a writer or two who sailed through testing but were utter flops when it came to real writing projects. The best (and often times the most challenging) interviews have been with non-writer hiring managers – while experts in their own field – who needed to bring in a writer to handle their documentation requirements. Moving forward through the interview process meant demonstrating my experience as a technical writer and telling them how I could align myself and their documentation to the business while being a minimum drag on their developers and other resources.
Another solid part of the book is his coverage of the scheduling and estimation of document projects and schedules. His coverage of the subject is well written and accessible to both technical writers and non-technical writers alike and draws from the Software Development Life Cycle (aligned to business, not academia).
The technical writing community needs more books like this one and Richard Hamilton’s Managing Writers to offset the academic writing, which sometimes pollutes the technical writing profession as a whole. Non-writer and trained writer managers alike can benefit from this practical guide if only to gauge and validate their own opinions on the field.
If you are seeking a book about technical writing management that isn’t seeped in academia then I highly recommend this book.
Have you read Technical Writing Management?