How I wrote my first non-fiction software leadership book

Posted on Sep 23, 2020

September 23 2020

Around 10 months ago I began work on a new side project to author a book on software engineering leadership. I was confident I went in eyes wide open, knowing it wouldn't be an easy undertaking, but in the end it was considerably harder than I had even imagined. As a retrospective I wrote this post to share the 18 (yes way too many) stages I took when writing my first book "Leading Software Teams with Context, Not Control". In hindsight, I could have easily reduced the amount of stages I went through, however, you always learn considerably the first time you do anything. I'm sure there are many more effective ways to author a book, but as a first time author this is the approach I took (which did evolve as I worked through the project). So yes, you probably shouldn't use this as a definitive guide if starting out on writing your own first book!

Here is a visualisation of % of book completed against hours invested:

Where it all began...

It all started with a relatively innocent Google Doc working a few hours every few days, and ended with a GitHub repo with each chapter in Markdown, a bunch of CSS and an automated pipeline to generate epub, mobi and PDF file outputs for each of the platform I was to publish the book to. Oh, and dedicating 3 hours every night to get this project over the line.

Part 1 - Defining the chapters

Completed: 1%

Time taken: 12 hours

I spent the first 12 hours defining the structure of the book. This involved breaking it down into 20 chapters focused around aspects I believed were important in relation to software engineering leadership. Within each chapter I listed a small amount of dot points on topics I planned to focus on.

Lesson learned: Start with a GitHub repository and use Markdown from the very beginning! Also set yourself up on https://leanpub.com/ - it's an amazing self publishing platform that encourages you to publish early and publish often.

Part 2 - Defining the chapter structure

Completed: 2%

Time taken: 6-7 hours

After analysing a selection of well written books I had previously read, it was important for me to ensure a consistent structure and flow throughout each chapter for the user. I defined a 5 part structure for each chapter to follow. You can think of these as top level headings within the chapter. However, you will notice in my book these headings don't exist, yet each chapter follows that structure :

• What: An overview of the topic the chapter was about
• Why: An explain why this topic is important in relation to software engineering leadership
• Story (optional): An example or story I could share from my own experiences
• How: Approaches on how to implement this topic within your own software engineering team
• TL;DR: 3 important takeaways from the chapter

Lesson learned: After initially spending a few hours on this, I ended up reviewing 6 of the best books I had read and defined a structure that took the best of each.

Part 3 - Brainstorming each chapter

Completed: 5%

Time taken: 40 hours

At this point in time I began drafting out each chapter as a set of more refined bullet points that aligned to each of the structure headings listed above. Spending around 2 hours on each chapter allowed me to get as many details as I could out of my brain and into the Google doc as quickly as possible.

Lesson learned: Choose your language up front and stick to it. I started with English (AUS), then moved to English (US), then later converted it to English (British). Wasn't the best use of time...

Part 4 - Drafting out each chapter

Completed: 15%

Time taken: 80 hours

With each chapter now a set of refined bullet points ranging from 1-4 pages, this part involved bringing each chapter together to represent a roughly formed draft. Each chapter was partially readable and had a level of flow to it. This took around 3-5 hours per chapter. At this point in time I had 18 chapters that were coming together nicely, but had also outlined 12 additional possible chapters as notes down the bottom of the document - which was clearly too many. I had also begun reordering chapters to improve the narrative of the book.

Intermission

At around this point in time my wife and I discovered we had a baby due in 7 months. It was at this point I began to realise I needed to finish this project before then - I now had a deadline. But... as it was still a fair way out, I didn't take the deadline as seriously as I should have. However, in a few months time I would.

Lesson learned: Set yourself a deadline for the project, as well as a deadline for each smaller milestone. Then commit 'X' number of hours per week to dedicate to authoring your book.

Part 5 - Adding in data points and examples

Completed: 24%

Time taken: 80 hours

It was now the time to bring hard facts, data points and career examples into each chapter to back up the claims I was making. For some chapters this was around reinforcing claims I was making from experiences I had had throughout my career. For others it was crawling through my twitter history that I use to share articles I have found value out of over the years, to find the specific content that helped support my books content. This took around 4 hours per chapter.

Lesson learned: Correctly collate and document your books references at this point, not at the the end of the project.

Part 6 - Research break

Completed: 25%

Time taken: 2 hours

At this point as I had the perception I was progressing well. I began to research more tips and tricks around publishing a non-fiction book. One valuable insight I gathered was when writing a book you should start of by draft 4-5 'fake reviews' that you would theoretically like people write about your book once they have read it. This is done in an effort to continually refer back to so you can keep yourself honest in regards to the content you are authoring into your book. You want to write positive and negative reviews. I came up with:

• This book is a great toolkit of practices I can essentially copy and paste into my role as a software team leader.
• I found valuable insights into how to setup specific initiatives I should be orchestrating in my role as a software engineering leader of multiple teams.
• I enjoyed the top 3 summary items at the end of each chapter which helped reinforce key items I need to remember.
• The exercises included within each chapter have been really easy to adopt into my leadership role.
• Although I learned different approaches to managing software teams, this book focused more on leading multiple teams, than a single software engineering team.

A quick break

At this point I was feeling rather positive. I had written most of the book, and had convincing data to back up my content. All that was left was to do a few rounds of clean up and generate an ebook for publishing. Easy right? At this point I thought I was about 65% through the project, in reality I was about 20% through.

Part 7 - Clean up stage 1

Completed: 40%

Time taken: 125 hours

Starting from chapter 1, I began working through each chapter to fix up grammar, improve the flow of sentences, include additional detail where needed and deleted content that was just unnecessary. The first 6 chapters within the book were sequential, whereas the subsequent chapters were all independent and could be read in the readers preferred order. I invested a lot of time attempting to make chapters 1-6 to flow seamlessly so as to not confuse the reader. I spent over 16 hours cleaning up just the first 6 chapters, rewriting, and rewriting more. This is when I hit my first wall, when I began to realise I was definitely not 65% through and more like 20% through authoring this book. I now realised I needed a more structured time investment to progress. I began to dedicate 3 hours, 3 nights a week on this project. Chapters 7 onwards were slightly easier to clean up - but still a considerable amount of work.

Lesson learned: Set up a schedule for time investment earlier on that you can commit to.

Part 8 - Clean up stage 2

Completed: 55%

Time taken: 98 hours

The book was now at around 55,000 words and my Google doc was beginning to struggle from a performance perspective. But I persisted with it (for the moment). Starting again from chapter 1, I began a second pass on improving grammar, removing duplication and general tidy up. I eventually had to condense my first 6 chapters into 5 chapters as it just wasn't working the way I had originally authored it. This took up a lot of time and was mentally challenging. I also ended up deleting an entire chapter (chapter 18 to be specific) as the book was becoming too lengthy and that chapter added the least value. Again, mentally very hard to delete large blocks of content that I had already sunk many hours into. However,  in the end it was the correct decision. At this point I also made the hard decision to remove all other 'potential chapters' that I still had as notes down the bottom of the book. Maybe this will appear in my second book sometime in the future. I spent around 2 hours on each chapter, and again more time refining chapters 1-6.

Lesson learned: It is entirely ok to delete large amounts of content within your book if it will lead to be a better experience for your readers - but yes it will be mentally challenging to do so.

Part 9 - Defining and setting up 'the matrix'

Completed: 57%

Time taken: 12 hours

I was now spending 3 hours each night, 6 days a week authoring this book. I had around 8 weeks to go until the baby deadline would arrive, and I was running very short on time. The few people I was talking about my book with to I would confidently let them know I was tracking well, however, personally I was not so sure. Throughout the previous month, I was furthering my investigation into what makes a great non-fiction book. Again, something in hindsight I should have undertaken at the start of the project. I came to the conclusion that I needed to define 8 measures each chapter should satisfy for the reader. They were:

• Clearly state the problem the chapter was written to provide a solution for
• Provide an actual solution the reader could adopt within their own team/role
• Include two data point facts in each chapter
• Include 1 example or personal story
• Relate to the readers experience to connect with them throughout the book
• Share something important the reader probably wasn't aware of
• Include a call to action and/or summary at the end of each chapter
• Make claims that are as strong as they can be made without becoming false

I put together a simple matrix (eg: table), with those 8 measures above as columns and each chapter as rows so I could track which measures I had accomplished.

Lessons learned: Spend a week or so researching what makes a great non-fiction book before you begin. As well as this create your own matrix to help keep you honest to your readers in each chapter.

Part 10 - The matrix phase 1

Completed: 65%

Time taken: 69 hours

With the matrix defined, I worked through each chapter ensuring it tackled each measure, and where it might not be relevant marked it as N/A. In this phase, I skipped over any item that had a potential to require considerable time investment. I spent around 2-4 hours on each chapter.

Part 11 - The matrix phase 2

Completed: 70%

Time taken: 46 hours

This part involved going back through each chapter and filling in the missing gaps within the matrix. Although some chapters took longer than others, I averaged 2 hours per chapter. At this point in the project, I began to feel as though I had a book that tackled the key problems I was aiming to.

Part 12 - Crafting the title

Completed: 75%

Time taken: 12 hours

I knew I needed to proof read the book again (at least once or twice more), however, I needed a break. I had hit a writing exhaustion wall. It was now time to come up with a title.. Easy right? Ok probably easier than finding a name for a new startup with an available domain name. But still hard! 

I wanted something I could relate to, that would catch the interest of a potential reader. After around 12 hours of brainstorming many different titles and variations, as well as gathering feedback from a few individuals within my network, I settled on "Leading software teams with context, not control". Context over control was a chapter in my book, and it is a leadership methodology I have followed for many years - so it seemed quite applicable.

Lesson learned: Procrastinate on a title until you have one that resonates well with you.

Part 13 - Authoring surrounding chapters

Completed: 82%

Time taken: 17 hours

With a title in place, I now needed to author the surrounding chapters within the book which included:

• About the author
• Why the book was written
• Acknowledgments
• Glossary
• Notes

Lesson learned: References are still as hard and time consuming to create as they were in the university assignment days.

Part 14 - The final proof read

Completed: 90%

Time taken: 56 hours

With the book mostly complete (90%), it was time for the final proof read. I spent just over 2 hours reading through each chapter very slowly, in large font to ensure it flowed well for the reader. I also began using grammarly.com, a great tool to improve grammar and sentence structure.

Lesson learned: Start using the grammarly.com app from the very beginning.

Part 15 - Creating a cover page

Completed: 91%

Time taken: 28 hours

What can I say, I spent too much time finding the 'right' shade of blue. I used a great online tool called figma.com to design the cover page. I ended up creating 4 cover pages for the different stores I published the book to.

Lesson learned: Probably a good idea to outsource this to a freelancer.

Part 16 - Building the epub files

Completed: 94%

Time taken: 46 hours

I had now written the ebook, how hard could it be to create a beautifully formatted ebook? Well first of all if you want any control over your styling you best be using markdown files with CSS. That was 16 hours lost converting my entire google doc to markdown. Then you need a tool to convert markdown to epub. I ended up using pandoc.org - a very handy tool. If you are planning on using pandoc, be sure to read the documentation carefully and add in all the correct CLI arguments to create page numbers, TOC, title page etc... It can't do everything, but it can do enough.

After spending a many days experimenting with different approaches, I ended up scripting what I was doing into a repeatable process to generate epub files on the go. I then spent a few days crafting CSS to carefully format the epub into a well presented and readable format.

This was definitely more time consuming that I had expected, but it was a nice change to jump back into the code.

Lesson learned: Start with markdown, accept that large tables are near impossible to format well in ebooks, and finally script your build process for the different ebook formats and sample formats. I regenerated my ebook over 200 times while testing out formatting.

Part 17 - Professional copy editing

Completed: 97%

Time taken: 38 hours

Cost: Approximately $1,600

Every book requires professional copy editing to perfect it for your readers. There are so many options out there, in the end used the reedsy.com marketplace to find a great copy editor.

Lesson learned: Pre-book in a copy editor, as it took around 4 weeks for me to fit into their schedule once agreeing on terms.

Part 18 - Submitting the ebook

Completed: 98%

Time taken: 7 hours

It was now time to publish my ebook to the relevant online stores. I started with LeanPub.com, then Amazon.com, Apple books & finally Google play. It took some time setting up relevant accounts, tax information, author bios etc...

Lesson learned: Upload your epub to Amazon.com, then download the generated mobi file and use that for platforms like LeanPub. Also mobi will require some minor CSS additions for formatting.

Part 19 - Preparing for print on KDP

Completed: 100%

Time taken: 19 hours

After spending nearly a year authoring my book into an ebook format, why not publish a paperback as well. Amazon KDP (Kindle Direct Publishing) is a great self publishing platform for on-demand printing of paperback books. You need to upload a print ready PDF, with a cover. To do this I converted the epub file into a PDF using 'ebook-convert' which is part of the calibre application. I also needed to inject in additional CSS for print specific styles. Preparing for print is a rather simple process using KFP, the only downside is a 72 hours approval window after each new upload. However, KDP scans your PDF for formatting issues and alerts you to fix before publishing. Once published you can order cheap author copies for your review.

Lesson learned: You can apply specific CSS to your print version, for example page breaks, table styling etc... You will want to do this once you have finished your book though to avoid any unintended formatting issues if you adjust large amounts of copy.

Project complete!

That's it, 10 months, 792 hours later, I had a 23 chapter book with 349 pages, 68,000 words available in eBook and print formats available globally. It was quite a journey, where at multiple points I thought about pulling the pin, but eventually pushed through and completed the book (unlike many other side projects I still have 'in-progress'). All that is left is to promote the book :-)

What were my final take aways?

• Authoring a book is harder and more time consuming than you will ever realise. Go in prepared for this realisation.
• Carve out consistent time out each week, break your project into smaller milestones and set deadlines for each.
• Research aspects of successful books, and draft a plan before starting. Still evolve it as you go though.
• You will learn to correctly spell some of those words that you used to always use spell checker for.
• Automate you ebook and print generation. I probably regenerated my ebook over 200 times, automating the process will be worth your time investent.

If you are interested in a copy of my book "Leading Software Teams with Context, Not Control" you can purchase on here.