Book review – Managing Writers by Richard L Hamilton

I’ve just finished reading Richard L. Hamilton’s new book entitled Managing Writers, A Real World Guide to Managing Technical Documentation”. It’s a good read, with useful information for managers, writers and technical communicators alike.

Book review - Managing Writers by Richard L Hamilton

Book review - Managing Writers by Richard L Hamilton

I enjoyed the book, so I thought it might be a good idea to write up some of my thoughts and see if anyone wants to discuss them and the book. So here goes.

The book is an interesting mix of management techniques on the one hand (such as how to write a business case, or how to motivate people) and technical writing domain knowledge on the other hand (XML technology, content re-use, etc).

Even if, like me, you’re one of the many technical writers who want to stay technical writers and not move into management, I think you’ll find a lot of good information in Richard’s book. Most of us manage our own projects to a large extent. Also, it’s good to have an insight into what our managers are up to ๐Ÿ™‚

Things I especially enjoyed in the book

The early section on the “elements of technical writing” is an excellent introduction to the complex and fascinating world of technical documentation. If your managers have never been technical writers themselves, get them to read these nine pages. With any luck, they’ll become so involved that they’ll read further.

One of my favourite bits is where Richard introduces the “black art” of scheduling:

“Schedules are the closest thing to a โ€˜black artโ€™ that you are likely to deal with as a documentation manager. The good news is that as a documentation manager, you will rarely set schedules; the bad news is that you will rarely set schedules.” (Page 14.)

Why the bad news? Because someone else sets your schedule for you. Ah yes, that rings a bell ๐Ÿ™‚

Richard has some excellent insights into and tips for handling performance reviews. This is a topic close to my heart, because I think we have not yet found a good way of doing performance assessments, bonuses and objectives. Personally, I don’t think that the “top 5” mechanism works and I feel strongly that, if you need to use top 5s, they should not form part of an individual’s performance assessment. I think setting top 5s does not fit well with agile methodology unless you’re willing to adjust the top 5 goals at the drop of a hat. That makes them fairly arbitrary, and not a good marker for measuring a team member’s performance over an extended period of time.

For me, the rankings and ratings used in performance assessments are demotivating, demoralising and usually unfair. It’s weird and depressing to be judged as “meeting expectations” or “exceeding expectations”, let alone anything less than that. Some companies even declare an arbitrary percentage allowed for the “exceeding expectations” category e.g. only 10% of staff can gain this accolade. Huh? In the company where I work at the moment, everyone is a high achiever and everyone works hard. Management science needs to take this into account in some way.

On the subject of bonuses, I think all staff members should receive the same amount when the company does well. Not the same percentage of salary, but the same amount of actual money. (The only exception would be perhaps a ratio for part-time workers.) I understand that market forces decree that certain job descriptions get a higher salary. But I feel that bonus schemes should recognise that every part of a company is equally important in getting the company where it is.

To sum it up: I think our management gurus could work on finding a better way of doing all the things mentioned above. I can see that we haven’t found a good alternative yet. But we should! What do you think?

Getting back to Richard’s book ๐Ÿ˜‰ he has some excellent things to say about focusing on and capitalising on a person’s strengths in a performance assessment (page 77). He also makes some great points about the problems with rankings and ratings (page 87).

The book also offers a concise summary of the agile environment and its potential impacts upon documentation (page 97). There’s advice on how to look like a profit centre rather than a cost centre (page 173) based on the fact that documentation is (part of) the product. This too is something all technical writers feel strongly about.

On the technical side, there’s a good summary of the differences between DocBook and DITA XML and how to assess which of the two would suit your project (page 189).

There’s a lot more in the book too. If you’ve already read it or if you read it after ploughing through this blog post, let me know what you think of it!

Details of the book and how I found it

The book is called Managing Writers, A Real World Guide to Managing Technical Documentation, written by Richard L. Hamilton and published by XML Press. Richard has a blog about the book and related matters.

Thank you to Anne Gentle for blogging about the book. That’s how I first heard about it. So I bought it from, to try it out for myself.

Now I’m going to pass it around the office. Andrew, one of the Atlassian technical writers, has already announced he’s first in line ๐Ÿ™‚

About Sarah Maddox

Technical writer, author and blogger in Sydney

Posted on 10 April 2009, in technical writing and tagged , , , . Bookmark the permalink. 8 Comments.

  1. You’re welcome! I’m glad you could get a copy for yourself. I love how a wry sense of humor is preserved even in the pages of a book. ๐Ÿ™‚

  2. Sarah, great review. I’d like to excerpt the opening paragraphs in my blog ( and then link the rest to this page if you don’t mind? Keep up the good work. Best regards.

  3. Sarah,

    Thanks very much for taking the time to read and review Managing Writers. And thanks to Anne for reviewing it and bringing it to Sarah’s attention.

    As you noted, the book is not just for managers; I wanted to provide information that would also be useful for technical writers and managers in other disciplines who happen to have a connection with technical communication (which is, arguably, most managers in high tech companies).

    • Hi Richard,
      In your book, do you discuss optimial ratios for product managers/developers/qa engineers/ to tech writers, in an agile dev environment? If yes, I’m pledging to purchase your book today!

    • Hi Richard,
      In your book, do you discuss optimal ratios for product managers/developers/qa engineers/ to tech writers in an agile dev environment? If yes, Iโ€™m pledging to purchase your book today!

      • Emily,

        I wish I could say yes, but unfortunately (at least for this particular sale:) the answer is no. That’s for a couple of reasons. First, I’m not sure there is an optimal ratio for any particular environment (Agile or not). The nature of the subject matter, the skills (or lack thereof) of the team members, external requirements on the documentation (e.g., government requirements), and co-location (or not) of the team members, among other factors, all have an impact on the composition of the team.

        The second reason, and one possibly more pertinent to your question, is that while I discuss Agile methodologies and compare Agile and “non-Agile” methodologies, that discussion is not an in-depth treatment of Agile. I suspect there’s a book (or at least a long article) that should be written on the topic, but I haven’t seen one yet.

        I hope that helps.

        Best Regards,

  4. Hallo all and thank you for your comments ๐Ÿ™‚

    Anne, you’re so right — the light notes in Richard’s book are part of what makes it a good read.

    Uqur, feel free to quote a couple of paragraphs from my post in your blog and then link to the rest of the post. Thank you for the offer.

    Richard, it’s great to have you dropping by to read the review. I agree that most managers in high tech companies have at least something to do with or some dependency on technical communication. What’s great also is that many forward-looking companies realise this and are starting to beef up their technical writing departments and build bridges between technical writing, marketing and sales.

    Cheers, Sarah

  5. I am so glad I found it. It is easy to understand and fun to read.
    Love your writing style and the design of your blog, your blog is great thanks for the info

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: