« Oracle to undercut Red Hat support by half the price. | Main | Writing a technical book - Part II : The devil is in the details, beware »
November 1, 2006
Writing a technical book - Part I : What you need to know.
Books are pretty much the bread and butter of most computer professionals, chances are good you have a few close to your work desk. With thousands of titles in stock at amazon and bookstores, how is it that you get into this tech windfall ? Well, after going into this process blindly, let me share a few of the details I wish I knew beforehand.
| [Entry continues to the left and below ad ] |
Find and research a publisher: There are many-many publishers in the tech industry, find one that suits your style. The best bet is to start with a publisher from which you buy your own books, chances are good that if you like their style, you will also adopt the same tone and they in turn will like you as a writer.
But then again don't limit yourself to one publishing company, if you just buy from the No.1 publisher its unlikely they will take on an unknown author, look over publishers who compete in the same space, its normal to see 5 or more publishers producing a book on the same subject, do your research. Every publisher is always looking for good writers, but keep an eye at how established some of the smaller publishers are -- more on this later.
Choose a subject that will be the buzz in 1 year's time or pick a niche market: Most publishers have a beat on what will be the next big tech buzzword or which platforms are due for major revisions. A good starting point is using alpha, beta and bleeding edge versions produced by software vendors, those which you feel will have an important impact on many end users -- your potential buyers.
Timeliness is a big factor, from what I experienced most books in the tech sector take anything from 6 to 12 months from idea to the shelves, so chances are if you see an interesting idea on a mainstream nerd site -- say Slashdot -- there is already a book in progress.
Niche topics -- which was the area I went into -- are rather tricky. The reason is twofold, for one you need to think in terms of content: "Can you really write an entire book on the subject or will it look more like a long essay ?", for the moment lets assume you are an expert on BSD systems for 64-bit architectures and can muster up 400+ pages on the subject, now ask yourself "Will there be 2000+ souls on the planet that will shell-out $30-$40 Dlls for this material?" well, just look at how many BSD books (let alone 64 bit) are listed on amazon -- by the way, these last numbers are not arbitrary, its hard data from my project, 2000 copies and 400+ pages is an average benchmark.
Develop your pitch -- or table of contents preferably -- to the acquisitions editor: This step is critical and should be seared into your brain, every evaluation, every revision, every modification comes back to the table of contents and this is what will give you a contract.
The take away point here is that you really don't need to be a recognized expert on the subject, being a guru on the matter helps of course, but you can get away stitching together a compelling list of subjects that will take any user from novice to expert on the technology, it doesn't matter if you yourself don't have the material down cold, while in the end you will have to become a guru, its just not at this initial phase.
Inside a publisher you may find one or more acquisitions editors, their job is to evaluate and consider every possible book idea. They don't have the final yes or no on a book, but they play a big role in the final outcome. It should be pretty easy to find them, they generally have their email posted on a publisher's web site and if you can't find it, then just call up and ask for the acquisitions editor, they are the first person you will come in contact with.
From my experience, acquisitions editors are techies at heart, they can piece together different subjects along a particular area and have probably been in the tech trenches, this compared to say your typical tech recruiter which knows all the buzzwords but rarely has an idea on how to make a follow up tech question.
Besides inspecting the proposed table of contents with a comb, an acquisitions editor will generally ask many technical questions -- high level as they may be -- to see if you are the real deal in terms of further developing your book idea.
Bottom line: You don't need to be a recognized expert to write a book , if you like the subject enough and are willing to put in the necessary time to elaborate on every knook and cranny related to the subject, you can do it.
Likewise, you don't necessarily need to work with a major publisher -- say McGraw-Hill or Wiley -- these tend to stick with very well known authors, your best shot may be with a smaller publisher, and believe me when I tell you there are hunderds of these, just do your research.
That's it for Part I on getting started, in the next entry I will address issues related to the actual quirks you need to deal with once you get started writing a technical book.
| [Comments below ad ] |
Posted by Daniel at November 1, 2006 12:13 PM
Comments
Post a comment
Track back Pings
Track Back URL for this entry:
http://www.webforefront.com/mtblog/mt-tb.cgi/55.











