Why Writing a Tech Book is so Hard

I’ve written a couple of dozen traditionally published IT books. I’m super-proud of like four of them. If you’re considering setting out to write a traditionally published book, know that it’s hard. Here’s why.

First, you’re going to have a huge time investment. You probably expect that, though. But what you may not have thought about is that, even if the publisher pays you $0 in advances, the publisher is investing tens of thousands of dollars in your project, before a single sale is made.

They’ve got to pay the salaries of people like acquisitions editors and development editors, manuscript layout people, marketing people, general office staff, and themselves. They have to pay copy editors, who may be contractors. They often foot the bill for producing an index, which is still a necessity in a paper book, since it can’t support Ctrl+F. Even though most of those people will be working on multiple projects at once, the share of their time spent on your book is expensive.

The publisher also has to pay for the entire print run of the book, usually several thousand copies, to be printed, shipped in, and warehoused.

Books aren’t huge profit generators. A book with a $30 cover price will be sold wholesale to Amazon for just $13.50. Printing the book may each $3.50 of that. An author on 10% royalty takes just $1, and the publisher has to live with maybe $9 to keep their business afloat. It’ll be less in reality because I’ve not even gotten into the middleman distributors, Net-120 payment terms, and all the other crap that eats down what a book can return.

(Yeah, few tech authors get rich on one book. The people who do it full-time write a lot of books, and make their money a dollar at a time on each.)

So as the author, you’ve got to put in a ton of effort to justify your business partner’s investment. That means it’s not enough to simply be a technical expert in whatever it is you’re writing about – you’ve got to sink an enormous amount of time and effort into planning that book. That’s something that, in my early days of six-books-a-year, I’m guilty of not doing my best at. It probably wasn’t until Managing Windows with VBScript and WMI that I spent a proper amount of time thinking about questions like:

  • “What was it like when I was learning this for the first time?”
  • “Forget what I want to teach – what does the reader need to learn? What are they attempting to do in life, and what outcomes are they aiming for?”
  • “What analogies and stories do I need to concoct to explain these concepts in a way most people can relate to?
  • “What dangers do my own perspectives bring into this that won’t be widely shared?”

And so on.

It’s incredibly easy to get it wrong. When I wrote the first Windows PowerShell: TFM for SAPIEN Press, we had the advantage of working with a print-on-demand company that massively reduced our initial investment. Still, looking back at the outline, I cringe. It was a VBScript book, written in PowerShell. It was about programming, ignoring the shell’s value as… a shell. It’s a huge reason I stepped away from writing books at all shortly after, and it wasn’t until I set out to write the Month of Lunches books that I felt more confident of being able to sit down and justify a publisher’s investment.

The first MoL book took two years to outline. And even then, I got it a bit wrong, as you can see in the differences between the first and second editions. And I had the advantage of actually using my own book to teach classes, which really exposes you, as an author, to what works and what doesn’t. Most authors don’t have that privilege, so they’re essentially flying blind.

Today, I lazily rely on Leanpub for most of what I write. I can completely reorganize a book, if I need to, and that’s happened for The PowerShell Scripting & Toolmaking Book, and it happened a few times when Adam Bertram and I worked on the original The Pester Book manuscript (much of which Adam retained when I needed to turn the project entirely over to him). Even though a lot of those books end up on Amazon, it’s through their print-on-demand Kindle Direct Publishing program, so it’s still say to just upload a new manuscript if you realize you screwed something up. Which I routinely do.

I’m in awe of authors like William Stanek who, in the Microsoft space, has somehow churned out well-organized, well-written books for decades. I realize that I write fast, and I now have the experience to do a fairly good outline, but Stanek has just always been that way, I think.

So as an author considering writing a book, ask for help. Get help at the outline stage. Get a lot of it. I’ve collaborated with other Month of Lunches authors on their outlines, was happy to do so, and like to think that I was able to make a positive contribution to their work. Really thinking about the sequence your writing will take is massively important, and it’s really, really hard to put yourself in the shoes of someone who doesn’t know those things. Being able to “think as them” is the key to a great teaching book.

Don’t take all this as discouragement: remember, you can always self-publish on a platform like Leanpub and then sell the book to a “real” publisher, if you want to. Writing a book is hard, but it can also be very rewarding. Sometimes, the things that are most “worth it” are indeed very hard; for me, at least, books are in that category.

One thought on “Why Writing a Tech Book is so Hard

  1. Jim Edwards

    Don “Mr. Jones” I like your writing style much, it’ s very conversant. For me, your content is super clear and easy to comprehend, (even the dense subject matter I have to 4-wheel through. That was all to say thanks man! V/r, Jim E

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.