Part of my work on writing and publishing Every Book Is a Startup is working on better ways to write and publish books.

The common process for making books looks something like this:

• Author writes
• Editors fix
• Designers format
• Publishers Print

…except that the work moves back and forth between these steps for approvals and there is lots of checking to make sure new errors aren’t introduced as old ones are fixed.

There is a distance between each step. Each person lives in their silo. Each group uses with tools best suited for their type of work. The handoffs and specialization make the process slow and more prone to the errors that are trying to be avoided.

One answer I have been thinking about is speed.

Books have this certain mystique around them. Part of that charm is their slow and deliberate nature. Books take time to write and time to publish. They seems protected from sway of today’s news or popular opinion.  This leads to a vaguely held opinion that going faster compromising the best qualities of books.

All books are not produced slowly. Any publishing professional will tell you about the book that was “crashed” (think about the use of that word for a moment) to meet a cultural moment or immovable date. In the world of technology, publishers have to get books written and published in a matter of months to participate in the cycle short-lived popularity of a technical protocol or programming language. I am more interested in this latter case without the heroics where a faster cadence is maintained on a regular basis.

When you start thinking about speed as the primary metric, things shift. You can make improvements with better scheduling of resources and tasks. That tradeoff increases the time spent coordinating. You uncover a set of bottlenecks that impede faster flow. You might take months out of the publishing process, but the controlled process still takes months.

I want a bigger change. I want months to turn into days or hours. I want a decrease in publishing lead time that is an order of magnitude faster than how we practice today. So many things have to change to allow that.

The files for books need to be generated with technology, not handmade with designers. The technology should know the form of a book – page numbers, chapter headings, folios, footnotes – and account for them. Create them automatically or make them easy to create.

The manuscript needs to be stored safely in a single place. Everyone who needs to work on the book should be able to from that same, safe place. Whether a typo or an added chapter, anyone should be able to make changes and easily create a new version of the files. And if the change negatively affects the book, prior versions should be restored easily.

All of those process changes put the creator closer to the final book they are going to publish.  If there is an error, I probably created it and have the best context for how it should be fixed. Once fixed, I can created a new version themselves.

We don’t even think things like that are possible because Word doesn’t work like that. We send files through email or Dropbox with comments and tracked changes, as we change the file name in an attempt at revision control.

Using a workflow of Google Docs and Leanpub, I can do everything I described.  A new version of my book is created with a press of a button. The whole process takes about two minutes. Two minutes!

Speed is about being fast and reliable. Build systems that are easy to rebuild; where small changes can be made without affecting the whole.

Speed also creates opportunities that you probably never thought before.

What would you do if you could remake your manuscript on command in minutes?