This is the second post in a series of blogs where I’ll chronicle the creation of the SAP HANA Essentials book. Starting the Journey.
"You have to be brave to take out that white sheet of paper and put on it words that could be evidence of your stupidity." -- Sol Saks
I’ve been producing books at SAP for 10 years now. Some of them have my name on the cover and lots of my blood spilled on the pages. Some of them, I was just an “invisible hand” behind the scenes, guiding them spiritually along their journey. Some have been massive successes, some have been mildly successful. I’ve done techie books, dummies books, university textbooks, MBA strategy books and even helped a bit with a memoir or two.
With all that background in SAP books, I tend to get quite a few “queries” each month from people inside SAP and within the ecosystem who have an idea for a book and need some advice on how to start. Most of them are so terrified of the mountain it appears that they’ll have to climb, they are paralyzed to even take the first step. So I was reflecting on what it's like to start a book project for the SAP HANA Essentials book, and thought I'd write down how I approach the challenges. Here’s how I explain “how to eat an elephant” to aspiring writers:
- Know the “goals” of the book
- Why are you writing the book in the first place? Hint: fame and/or fortune are both horrible reasons to write a book. Check your ego at the door before starting a book project. I guarantee you’ll be psychologically beaten and bruised by the end and be kicking yourself for thinking it was a good idea when you started. If you’re truly foolish, you’ll divide your meager royalty check by the time you spent on the book and realize that you could have made more money begging for change.
- If it’s to educate or entertain, you’re probably in better shape. The best you can hope for is that exactly ONE person on the planet reads your book and then tells you that they enjoyed it or got some value out of it. My parents and wife have never even read more than the dedication page for any of my books—just to make sure their names are in there.
- For the SAP HANA Essentials book, its pretty obviously about education on a massive scale. SAP HANA is going to be a huge topic for everyone in the SAP Ecosystem for quite a while and there isn't anything out there that covers the Level One knowledge comprehensively. So, I've got to somehow put one together in the next couple of months :smile:
- Know your audience
- If you’re writing a book for the right reasons (typically to educate), then why would anyone want to read it? Do you have some special access to crucial knowledge that isn’t available elsewhere? Will this knowledge benefit a large number of people. How is this going to improve their job/life/croquet skills? Being an “expert” at some topic qualifies you to write absolutely nothing. For all of my books, I’ve had to teach myself the topic before I could explain it in writing to someone else. The important thing is to know exactly WHO you are writing for and WHAT they need to know.
- I've spent a lot of time working with the SAP ecosystem, from the "code monkeys" up to CIOs. Specifically starting SDN, the Demo Jam and quite a few other crazy projects. My audience wants the straight story with as little marketing spin as possible. Real customer examples and solid advice on how to extract business value from HANA will be front and center in the book.
- Know what you want to write
- Nailing down the scope of the book is both the hardest part of the writing process and the most critical. If you don’t have ultra-clear boundaries around what you will and will not be writing, you’ll quickly plunge down the "rabbit hole of never-ending details" and never finish.
- Finding the fine line between Level 1 content and Level 2 content is tricky, but because we're doing the HANA book as an ebook, we can always link directly to Level 2 content if its needed. That way readers aren't upset that we didn't go into enough technical detail or upset that the book was to geeky.
- Create an incredibly detailed table of contents
- This should be the output of the scoping exercise. Typically, my ToC’s are about 10 levels deep. A,1,a,i,etc. For the SAP HANA book, my working ToC is about 30 pages long now. Once you get it that detailed, you basically have to only write a short paragraph for each bullet. More importantly, you know EXACTLY where to start and stop.
- Build a support network of content experts to help guide and review
- Thus far in the SAP HANA book writing process, I’ve pulled in about 75 experts from inside and outside SAP. Some are just reviewers for the final manuscript to give me extra eyeballs and perspectives on the big picture. Some are actually writing first drafts of entire sections of a chapter. It all depends on their level of commitment and bandwidth. However, the general rule is the more eyeballs that see the manuscript before you print it, the better the final product will be. If possible, hire an awesome professional editor to go over the final draft. It’s a service that pays for itself in final quality.
- Keep putting words on the page till its done, then edit the hell out of it until its readable
- Perseverance is truly the only crucial skill you need to finish a book. If you've followed the rest of my advice above, actually putting words on the page is the only big thing left for you to do. Once you've got a completed first draft, be ruthless in the editing process. Slaughter every sacred cow you created, if needed, in order to make it "readable" If you’ve just gone thru the literary equivalent of childbirth, you sure as hell want people to read the damned thing. So, is it “readable” by your audience? Spewing out a bunch of facts haphazardly will result in people hating your book, or worse, putting it on a shelf for an eternity of uselessness. Style and tone matter, at times even more than the raw content. Put as much effort into the way you present the content as you do into the underlying facts. I’ve met some truly brilliant people over the years who can’t string together a single readable paragraph to describe something they’ve invented and patented. Just because you “really know” a topic doesn’t mean you can write a book about it or that anyone would ever want to READ a book about it.
- Our goal is to put out the definitive "first stop for HANA knowledge" for everyone in the SAP ecosystem, so it has to be readable by a wide variety of people in our customers and partners. It should also make finding Level 2 information very easy and a natural next step. If we can do that, then I'm sure we'll meet our goals.
