On August 3rd, 2019, I found myself at the front door of a large suburban home in Redwood City, struggling to enter the correct key code. It was four in the afternoon — the house was backlit by a golden Californian sun floating in a deep blue sky — and I had a week’s worth of clothes and equipment in my backpack. Eventually, my friend Alena opened the door, saving me from further embarrassment. She’d been there an hour already, she explained, but everyone else was still in transit.
It was Day Zero of our Book Sprint, a writing marathon that had been in the works since earlier in the year when we first started kicking the idea around in Oslo. We had a shared interest in writing a non-technical Bitcoin book for “everyone else,” and given that we all had full-time professional commitments, it seemed like the only way it was ever going to happen was through some aggressive time-boxing.
And so it was that the Book Sprint was born. We were going to write the darned thing in four days.
The good news was that the house that they’d picked for this activity was pretty amazing, and between the apartment-sized kitchen, the gym, and the outdoor jacuzzi and pool, I saw no problem at all in holing up for a few days.
Eight Angry Bitcoiners
By the evening, the entire team had arrived, and it was a lovely assemblage: I was from Manila, Alena Vranova from Prague, Timi Ajiboye from Lagos, Alejandro Machado from Medellin, Jimmy Song from Austin. (Alex Gladstein, Alex Lloyd, and Lily Liu were from the Bay Area, so they had slightly shorter commutes.)
That night was the last time any one of us was going to be relaxed or cozy, as the days that followed were among the most intense I’d experienced since my TV production days in my early 20’s.
I was sharing a home with some of my favorite people in the Bitcoin community, but that wasn’t necessarily because we all thought alike. This was immediately evidenced by our conversations about who this book was meant for. Alex G wanted to write it for US millennials who read The Economist, I wanted to write it for Asian business-folks with healthy bank accounts. The only point of commonality was that it should be non-technical, and focus exclusively on the socio-economic aspects of Bitcoin that made it so revolutionary.
Initially this intersect was best demonstrated by our working title, Why Bitcoin Matters, which implied a far more intellectual treatise than what we eventually went with. After much debate, the title The Little Bitcoin Book won out, although people’s comfort levels with it only normalized after we added the subtitle “Why Bitcoin Matters for Your Finances, Freedom, and Future.” I thought it was a great title, one that doesn’t assume any familiarity with the subject matter other than its name. It took two days to come to that conclusion though, and on hindsight, that was one of our easier negotiations.
Over the next few days, we deliberated, argued, and cajoled at varying decibel levels — on everything from the proper capitalization of the word “bitcoin,” to how much space we should allocate for other cryptocurrencies, to the presence of the Oxford Comma, to whether or not the Bretton Woods agreement should be highlighted in our historical narrative. We were eight people from five different continents and cultures, and we were all used to being the smartest person in the room, as one of our house guests observed. There was no way it was all going to go smoothly.
Here’s what having eight opinionated editors working on the same document looks like
Indeed, there were several moments where things felt fragile enough that I wasn’t sure we could move forward, but there, I believe the time constraints made a huge difference. With just a few days available, everyone was more willing to come to the table and talk it through.
But — spoiler alert — we finished it.
The Publishing Dilemma
It was evident from Day 1 that we were not going to be able to publish this book through traditional means. It simply didn’t make sense to spend a week writing a book, only to then wait a year for a publisher to pick it up. Granted, the traditional route does have its merits — a book advance and marketing reach being the most significant.
Ultimately we decided that there was enough “personal brand” energy between the eight of us to make up for the lack of formal channels, and profiting from a book advance was also not a huge motivating factor. The size of the potential readership was of utmost importance; everything else, less so.
That left us with one path: Amazon.
This universality of access does bring with it some obvious drawbacks … not the least of which is that if everyone can publish a book, just about anyone will. To wit: the self-published category on Amazon isn’t exactly replete with Ian McEwans or Michael Lewises.
But the advantages were numerous and quite frankly, game-changing. We could have a perfect-bound, bookstore-quality paperback in our hands within just a few days, and readers could order their copies and have them shipped anywhere that Amazon infrastructure could reach.
Mentioning the dates really emphasizes the point here:
We all arrived at the house on August 3rd, and officially kicked off the Book Sprint on August 4th, Sunday. Just two weekends later, on the 18th of August, retail copies of the print book were delivered to Jimmy’s house in Austin. By the next day, copies were in transit to the Czech Republic, Nigeria, and the Philippines.
We went from conceptualization to global distribution in 14 days. If that kind of time-to-market doesn’t make you think twice about waiting for that Penguin Books call-back, I don’t know what will.
Just Do It Yourself!
The skeuomorphic cover design used familiar and tangible elements (leather stitching, satin fabric, note paper) to introduce something unfamiliar and intangible (Bitcoin).
The team used Google Docs as our primary writing platform, so everyone could see changes in real-time. Google Docs has a very simple styling system: everything that isn’t “normal” body text is either a Title, a Subtitle, or one of a series of Headings.
It doesn’t actually matter what those styles look like within your Google document; what does matter is that when you export it as DOCX, those style names are retained. That means that when you import the DOCX file into your Adobe InDesign layout, you can hook on to those same style names and override them with your final book formatting, as long as you use similar names in your Paragraph Styles definitions. This is a tremendous time-saver and saves the book designer having to hand-select and restyle each element every time a new draft of the book is imported.
The Problem with Ebooks
Ironically, I struggled with the Kindle ebook production process. I couldn’t find any reliable tools to automate the workflow in the same way as InDesign. I experimented with a Kindle plugin for Microsoft Word, which allowed me to take our Google Doc and produce a Kindle-compatible ebook in seconds. Unfortunately, the output left a lot to be desired. There were plenty of styling problems — the Word format has a bad habit of hiding a lot of dross that only shows up when you try to convert into a different format — and when I tried previewing it on the Kindle Previewer app, it didn’t actually match what the end-users were seeing on their devices.
I also tried the official Kindle Create app, which didn’t give me more control but did allow me to pick from a couple of handy themes that styled our book globally with one click. Again, styling and text-encoding issues were everywhere, and we couldn’t seem to get output that matched what the Kindle Previewer was showing us.
Finally, I decided to just hand-code the whole thing in HTML and CSS, which is really all that an eBook is, anyway. The EPub format is actually just a ZIP archive containing HTML, XML, CSS, and image files, and you can unpack any EPub file by just changing its file extension to zip.
Google Docs can export directly into both HTML or EPUB formats, but I found neither output to be particularly satisfying, as both had the same massive code chaff that would make maintenance and future updates really challenging. I reasoned that with a far simpler, hand-made codebase to work off of, there would be fewer rendering issues and styling inconsistencies.
In order to accomplish this, I had to first export our Google Doc into Markdown (there are a number of plugins for this), which gets rid of everything that isn’t directly related to the text. What you end up with is a thoroughly cleaned manuscript that still has the essentials like headings, emphasis, and links, but no styling information and no metadata.
After I had resurfaced, I had an HTML project with over 24,000 words in it. I uploaded the whole thing to a Github repository so I could share the extent of my mental disorder with my co-authors.
As is typical with run-and-gun processes like our Book Sprint, delays were caused by externalities more than anything else. We went through a number of last-minute changes during our second week, refining some sections, or integrating errata in others, and Amazon takes 24–48 hours to review each new version. I think we lost about 4 days in aggregate just waiting for Amazon’s QA team to get back to us, and unfortunately there’s no way around this. (Other than to just get it right the first time, of course.)
Once the print book is approved and “live,” it can be ordered and shipped within a few days to any of the Amazon country hubs. Countries like the Philippines or Nigeria are obviously a bit further out, so shipping a large batch can take as long as 10 days. Given that our book is less than a month old, this seemed like a very reasonable waiting time.
Future Optimizations (or, How to Publish a Sequel?)
With exactly one Book Sprint under our collective belts, it’s probably not reasonable for me to pontificate on the exact recipe that will work for other teams. But I do have some thoughts on how I would approach it if we were to do this again.
- Have a professional editor on your team. A handful of our production delays were due to the fact that we were still receiving third-party edits while we were building the print and ebook editions. Having an editor reviewing the work during the Book Sprint itself would have helped streamline the output considerably and kept the voices consistent.
- Enforce formatting guidelines, or use Markdown. Because each author was working on their own chapters or sections independently, bringing it all together caused a lot of clashing formatting that needed to be manually adjusted. I’m not sure what Markdown-powered app I would use for collaborative writing (perhaps Notion?) but I believe the extremely restrictive formatting capabilities of Markdown would go a long way towards making our text-merges a lot less painful.
- Establish rules early on. Seeing as this was our very first attempt, it’s obvious that we didn’t know what we didn’t know. Other than the chapter breakdowns during Day Zero, I would also probably include an hour of discussion around certain fundamentals. Some are mechanical, like following the basics of the AP stylebook, or establishing the proper capitalization of the word “bitcoin.”
Others are tactical: how do we deal with narratives featuring our own brands, or brands of our direct competitors? How do we tackle issues around other cryptocurrencies? Do we even want to mention them?
Still others are high-level and strategic: is the book an objective resource or an opinionated one? Do we want people to buy Bitcoin as a result of reading this book, and if so, how is it not construed as investment advice?
All of these questions were answered as we were writing and editing, and on hindsight, could have been identified much earlier on in the process.
I’ve worked on a lot of projects in the five years that I’ve been in the Bitcoin industry, and our week in Redwood was one of the most engaging I’ve ever experienced. I’m grateful to have been part of this amazing team and I think I learned more in those hundred hours than I have over the last hundred days.