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

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 Amazon.com, 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 🙂