Book review: Talking about machines

Talking About Machines is a book I have been wanting to read for some time. It is a study carried out by Julian E. Orr of photocopier service technicians - early 1980’s I think. That might not sound very exciting but the findings are. Basically, Orr discovered that what is important is what the engineers do on the job, not what their managers think they do. Classroom training is OK but you really learn what to do on the job, a lot of it verbally from your immediate team - and this team is more important than the corporation.

If that sounds obvious then maybe it is, but why do we so often ignore it?

Anyway, I’ve been wanting to read this book because references to it keep cropping up. I think I first heard of it reading some of John Seely Brown’s papers - most likely Organizational Learning and Communities-of-Practice but I can’t be sure. (If you haven’t read that paper then do so, if free at that URL so you have no excuse.)

So, a sense of interest and duty lead me to this book. True, it is significant, it is important but... well, it is also somewhat long winded. Still it pulls some important truths about the nature of modern work.

For example: we think of technicians as people who show up, look at the fault, fix the fault. We believe they just do it. In truth it there is a lot more to it than that. For a start, the same technicians have to deal with users of the machine, the social setting of the machine and the inaccuracy of the information the machine gives them.

OK, here’s the truth. I read the first few chapters and the last chapters, I skimmed or missed the ones in-between. As I read it I increasingly felt I was learning little new to add to what I had read in the references to it. Perhaps if I had read more I would have found more new stuff.

Two bits do stand out.

Early on Orr notes that while we may study a problem, we may even train for a problem when faced with it we may fail to recognise it. This rings true, how many case studies did I read in business school were the problem was obvious? Why didn’t the (far more experienced) people in the case study spot the problem and the solution? Why they didn’t notice it was a problem they already knew?

Perhaps you don’t spot the problem because at the time you don’t have all the information you need. Perhaps you don’t spot it because you arr too close to it, or too remote from it. Perhaps you don’t spot it because, well there are any number of reasons. This idea has got me thinking, how many problems I face now are ones I’d know the solution to if they were presented as a case study?

Second, toward the end Orr says:

“The management of the corporation ... has pursued a strategy of de-skilling through the use of directive documentation. This does not actually deprive the workers of the skills they have, however; it merely reduced the amount of information given to them.”

I run across de-skilling regularly, so many company strategies, products or procedures are aimed at de-skilling people, but do they really de-skill? Or are management fooling themselves? Most likely they just shuffle the skills a little.

So many software tools are aimed at deskilling a job, yet how often are we repeating the mistake Orr describes? Rather than invest in tools perhaps we should be investing in people, rather than “de-skilling” them we should be re-skilling them. All too often managers are prepared to invest in a tool but not in training.

(And what of the tool makers? A complicated job may result in a complicated tool, people end up needing training on the tool. Tool makers need to ensure people get this training to use the tool effectively and demonstrate the value to the purchaser. But, if what you learn in the classroom isn’t much use, how are we to train these people?)

Summary then:

Orr’s book is worthy read and has some interesting insights. I’m sorry I couldn’t read it all but it was just too slow. Maybe I’ll come back and cherry pick the remaining chapters - umm... I’ve said that about books before, it rarely happens!

The book shows us that technical work is much about the social environment, learning doesn’t happen the way we like to think it does, and strategies that sound good don’t always work they way we thinkg.