Why IT books need to be different

You know, I've read more IT books than most of the human race has, at least fifty. And most of them don't work for me for two reasons: they're too complete and too correct.

Here's the subject of some recent books I've read and their size:

These book tried to describe everything there is to know, exactly and completely. It is another example of what I call ETF: Excessive Technical Fastidiousness. And you know what? I didn't really read them, thoughtfully, from cover to cover. I dipped and skimmed. There is an admirable trend in some of them to summarise the core concepts in the preface - I like that. I read the preface and the rest goes on the shelf.

For most of these books, they stand as a magnum-opus monument to their author but beyond that I'm not sure exactly how much they contribute to the industry in practical terms. Writing like this certainly shows how knowledgeable the writer is, BUT HOW USEFUL IS IT? A common theme of recent posts here has been that people don't read any more. Who's going to read all those pages and actually absorb what's in them? Almost no-one.

A few buyers are serious wonks who read it.
A few are less serious wonks like me who scan and dip and skip.
Many more are wishful thinkers who hope to read it one day but never will.
And I'm guessing a few just want it on their office shelf.

The rest want the book as a reference. And some of them are reference books, like USMBOK or Architecture and Patterns for IT, but most aren't. The intention is that you will read them. They tell a story, build a case, develop a theory. They aren't for looking up.

I wrote a 50-page book to describe the whole of service management. That may have been a bit too far the other way on the spectrum, but it was a useful exercise and I hope a lot more people will actually achieve the goal of reading it all and absorbing some of it.

Most of my books are short. That's not because I'm a lazy author ... ok that's part of it but it is also because I want them that way. I want to get to the heart of the matter, to the nub, to the Core Practice, the really useful bits. I want to distill the advice I'd give to a friend over lunch who has a new ITSM job.

In my father's day he needed to read half a dozen books to get the essential knowledge to manage a data centre. The modern world is faster changing and far more complex and advanced. I have over eighty printed books on IT, I don't know how many digital ones, and I could have hundreds more. They need to be rapidly digestible.

So I feel most books are too big. My other concern is that they are too perfect. When I read some of the advice - MOST of the advice - I think "90% or 95% or 99% of organisations aren't going to do this". They just aren't. Not in the real world. Best practice is an idealised model of what the world would look like with infinite time and money. To reach the moon shoot for the stars. Best practice is the stars. And that's a useful function I guess, to have the best-case model. But if that is all you have, you'll drive people away. It's not real. It doesn't speak to the common man. It does not describe life in the trenches, not outside the Fortune 500.

I don't want to write the definitive last word, I want to write a survival guide. That's what people need and that's all most of them are going to read.