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:

Selecting tools 200 pages
Metrics 200 pages
CMDB 300 pages
Doing ITIL 300 pages
Planning ITIL 300 pages
Managing portfolios 350 pages
Running a project 300 pages [that one is different: PMs are the kind of people who just might read it all]
ITIL 2000 pages!!!

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.


The Web as an Option for Better IT Book Material

Hi Rob,

I think this is a great perspective. People in our industry want to get right to the heart of what they need, as quickly as possible.

This being said, the fact remains that the infinite volumes of detailed material that exists will always be important to someone who will want to dive deep into the details. What makes a great "expert" in his or her field (any field) is that, while they know how to get to the heart of a matter very quickly, such experts also know the details. And, let's face it, you don't become an expert reading just the short and to the point books. You're an expert because you took the time to read all those books you're complaining about! LOL

(I'm sitting here in amazement as you've reminded me to think back on all the different Math, Science, Engineering, Coding, Object-Oriented Programming, and Patterns books I've consumed... just in the last decade. What a trip!)

One thing I personally find amazing about the utilization of solutions like Google Analytics for web content analysis is that you can track and analyze people's reading patterns and behaviors. On our own site, we watch patterns that show people drilling rapidly to get to what they want, spending a significant amount of time reading, drilling rapidly to new topics, spending more time in those new focused areas, and so on. While I love books and grew up as a "book nerd", I see the value of the web to achieve the hybrid that is a combination of the short and succinct view that you're describing, in addition to the ability to continuously drill deep and far into details and related material, as needed. We won't even get into the fact that advanced sites will layer in things like interactive media, social networks, etc., to make the learning experience even more powerful that books can ever be, by themselves.

So, I think an option to your original premise of "IT books need to be written differently", is that the web offers the opportunity for a hybrid approach that allows you to offer up powerful summaries, while also being able to go deep, go wide, etc., at your discretion. Whether or not sites are actually written this way is another matter, altogether. But, the opportunity is there, nonetheless. For me, trying to build a site that meets this criteria, as best as possible, has been an amazing learning experience.

As for books, themselves... They appear to be a dying breed, as it appears to be easier to make money, over the long term, on web sites that simply publish the content of would-be books for free and for open use, reaching, both, larger and more targeted audiences.

Anyhow, I hope this adds value.

My Best,


Frank Guerino, Chairman
The International Foundation for Information Technology (IF4IT)

The Value of Books

You make some interesting observations about the value of books. I've felt much the same, sometimes, reading a whole book and wondering whether it was really worth it. Often there is much that's obvious and a lot of repetition.

I'm not sure what book you read on metrics, and I can only comment on my own, but, in writing the two books I have written on metrics, my aim has been twofold:

- Get across the important practical stuff that you need to know if you're actually going to use metrics in anger
- Provide sample metrics to help during the definition stage

That's because I've written them to be what I'd want to have had, in the field, when I had to design metrics and found that the cupboard was bare - the books I could find were worthy enough about why metrics were important, but they didn't help practically and didn't offer useful examples.

I have found electronic reference books most useful. I'm always referring to, and getting useful information from, the ITIL V3 books. When I had the paper copies of the ITIL V2 books, I looked at them much less - a prospective customer once asked me why my books looked so new if I was consulting them all the time! ( actually I'd had to replace them, shortly before, which was useful in framing a reply!).

Books have to have the audience in mind.


Metrics books tend to be more of a reference, so I can live with the length - they are not such a good example of what I am on about

Stuart Rance made a good point on Twitter: "that's why we wrote the KEGs" (Key Element Guides, ITIL pocketbooks). The KEGs are an interesting example. Perhaps all authors of a book over 200 pages should consider writing an accompanying 50 page pocket book too.

the obvious next step

Having written the key guide perhaps an author should ask whether the 200+ page version is still needed in book form.
James Finister


I want to be able to like comments. Can you implement http://disqus.com/welcome/ ?


I could. Disqus works with Drupal 5. Users would need to register with Disqus as well as with my site and to authenticate to both (the single signon feature will cost me US$3600 per year).

What would be the benefits, to readers and to me? (NB cool features aren't benefits)

I like these comments.

I like these comments. :)

There. And that didn't cost you $3000+ ;)

It's just cool features

I like Disqus but I think all it would really offer is a like button and a few extra profile bits. I've just added Intense Debate to my site but only because I'm too slack to pay Akismet to catch the comment spam. Intense Debate has Akismet built-in and it's still free, plus it has the thumbs-up button for comments.


James nailed it in a word: "worthy".

I have an idea for a brilliant new business venture. To deal with this modern phenomenon of nobody having time to read, I'll rewrite the books in concise form at 50 pages or less and sell them. I'll call them...um... "readers' digests". Nobody thought of that before.

Easy reading

Hence my focus on white papers, or eBooks as I prefer to disguise them as, with practical steps in the content.

ITSM Books

I agree with so much of what you say about the majority of currently available ITSM books Rob - that's why, I guess, my first ITSM book is a succinct 64-pager, and inexpensive to boot. This will also be the size of the subsequent books in the pipline. I too want people to be able to read - easily - the whole book, find it understandable, and be able to apply the content without too much pain.

if you are real doer, then

if you are real doer, then you don't need that many pages. but think about others - project managers, technical writers, etc. Someone needs to present high-level diagram, some has to put together service design package and read critical success factors or similar. those books are written so that even if you need one chapter from the book and lazy to find specific one (pocket guide or similar), you can pretty much always get it from the big book. I also don't like waste of pages for generic descriptions but I believe there are people who really read this and even use it somewhere


Amen to all of the above. Personally I think ITIL lost its way with v3 because it no longer had a clear sense of who the intended audience was. I was asked to review the text of a book on governance the other week that was so "worthy" that I actually fell asleep before the end of the first chapter.

Too many IT texts are written like the worst sort of software manual - they tell you what each item on each menu does but not how to use the software to do the things you are going to need to do in real life. There are even less IT texts that make you question whether you need to change your way of working as an IT manager.

James Finister

Key to writing succinct books

Skep - agree. As the author of the USMBOK and someone who had never written a book before that one - I asked for guidance on where to start...

Some great advice was offered by writing coaches online, including Ron Pramschufer (Google him), amongst many. In essence, take the time to classify write down the purpose of the book in the form of 10 or so related questions it will answer, and for whom. If you find you have many more than ten, and perhaps a never ending list of questions (as in my case) you might be writing a reference book.

When it came to my other books, the practitioner guides, although references, I found myself asking a similar set of ten or so questions and this became the format for a common table of contents. It provided consistency for readers across the four guides published so far (management of incidents, problems, changes and configurations within a service organization). Each of these guides is constrained, sorry designed, to fit within 150-175 pages, using a 10x6 format (size matters here when estimating pages), and including 20 or so diagrams, an index, and preface.

When offering a diagram, if it has arrows, and pointers at the end of arrows, its polite to either mark up each arrow with some word indication what is flowing across the arrow, or describe the operation in supporting text. Else - leave the diagram out!

I'll admit, writing a shorter book is much more difficult because you really need to focus on a few key questions.

ITIL seems to have fallen foul of so many writing 'best practices' - it tries to combine telling stories, with editorial opinion, and 'best practice' guidance. As for diagrams, I wish I had a dollar for every arrow in ITIL that was missing a label, or supporting explanation.... At best, this causes instructors and consultants heartburn as they conjure up explanations in response to client questions. At worse, customers make up the explanation and go live with it....

Syndicate content