Book review: Thinking for a Living

One of the regular features of this blog is that I review the books I’ve read. Not all of them, on the whole I only really write about the “serious” books I’ve read, so you don’t get reviews of novels, cook books, etc. that I read. Before I turn to the latest book I’m conscious that every time I review I book I seem to like it. If a book reviewer doesn’t criticise a book once in a while are they really objective?

I’d like to be really critical of a book once in a while but in truth I just don’t tend to read books I’m not going to like. I tend to spend some time choosing books - I read other book reviews, online and in the press and I read what the book says about itself.

So, I hope you’ll forgive me if I seem to ready too hand out praise for books. That said, on with the show.

To train journey to and from St Ives over Easter allowed me to finish off Thomas Davenports Thinking for a Living. I’d been looking forward to reading this book since I read a favourable review in the FT a few months ago. I liked the book but I did find it a little disappointing. I suspect my disappointment might be more due to me than the book. For much of the last four years I’ve been reading lots about knowledge management and organizational learning. As a result I didn’t find a lot that was new to me in this book.

The situation may well be different if your new to the subject, or looking for a starting point. As such this would be a good place to start, and given that Tom Davenport has been a major contributor to the subject area over the last few years it probably makes sense to start with his latest work than one of the older volumes.

What is perhaps new is that Davenport turns and directly addresses the question: “How can we make knowledge workers more productive?”

Now this question goes straight back to Peter Drucker, indeed one may characterise it as Drucker’s challenge, as Davenport reminds us:

“To make knowledge work productive will be the great management task of this century, jut as to make manual work productive was the great management task of the last century.” Peter Drucker, Age of Discontinuity, 1969.

Davenport sets out to address this question - indeed I agree with him and Drucker, I also accept the challenge. In doing so he does offer us some advice and stories of what others have done but you aren’t going to come away from this book with a “35 things to do to make your knowledge workers productive” - actually, to be fair I don’t think such a list is possible but I’ll leave my explanation for another day.

So, what does Davenport tell us?

Well, he accepts that the Knowledge Management Systems (KMSs) pushed by software companies and consultants in the 1990’s are not the answer. However he does see a role for technologies, specifically communications (e-mail, telephone), Wiki’s and search - although the jury is still out on Blogs.

He also accepts that it is not about process - practice is perhaps more important. (I'll write more about this as I progress though my current book Talking About Machines.)

Davenport also suggests “after action reviews”, or, as we in the software development community know them retrospectives. Now in the development community lots of us know about retrospectives, lots of us think they are good but few do them. And when they are they aren’t necessarily as effective as they could be. According to Davenport this situation is pretty common, we could all use retrospectives more effectively.

Another idea that rings true with software developers and their managers is HSPALTA - “high smart people and leave them alone.” This is a prevalent management technique the software arena, too many people - managers and developers alike - are only too happy to say “its the people who make the difference” and under this cover do nothing. We have to get away from this idea that because we did it like that yesterday we’ll do it like that today and tomorrow.

Overall though Davenport's main insight is that knowledge workers are not homogonous. Different solutions apply for different groups of knowledge workers, e.g. scripting might work in a call centre but don’t try it with a consultant. This might sound like an obvious statement but until its made it perhaps isn’t so obvious - the label “knowledge worker” can hide a multitude of sub-divisions.

Before I close this review I do want to commend the author for good referencing and some actual research. When he discusses ideas form other authors he tells you who they are and were they said it so you can track back to their original work on the subject. Nor is he shy of discussing his own research findings.

What makes this unusual is too factors: first, as I’ve said before, books from Harvard Business School Press tend (ironically) to omit these details, second, the book is still very readable.

So on balance: if your new to the subject of knowledge work and knowledge worker productivity this is a good place to start. If your familiar with the subject you’ll probably still get something from this book but don’t expect all the answers.