Skip to Content

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 🙂
  • 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.
To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

    1. Ulhas kavle

      Hi,

      Please answer this question, if you can.

      Can any one with an SAP experience, write a SAP book or SAP ebook.

      Please advise, whether there are any legal issues.

      (0) 

Leave a Reply