Writing books is hard. Collaborating without an effective plan can make it much harder.

It’s okay to argue about ideas, structure, terminology, tone, case studies, or audience. Those arguments are productive.

It’s not okay to argue about who’s editing which version when — that’s just a stupid waste of time. Even so, I see so many projects get bogged down in that crap when the writers and editors could be spending their time on actual content and idea questions.

The value of process and version control discipline is proportional to the number of collaborators. For example:

• One author, one editor: you likely don’t need an elaborate process.
• Two coauthors, one editor: you’d be better off with a carefully planned process.
• One author, one ghostwriter, three other people contributing: process discipline is essential if you don’t want to waste time.

Simple but essential tips to avoid version control madness

These are the general principles you’re after:

• To avoid wasted effort, everyone agrees on content plans before a writer starts writing.
• To avoid endless draft revisions, everyone reviews a draft before a writer starts rewriting.
• To avoid “ping-ponging” between points of view, everyone works together to resolve as many conflicts as possible before drafting or revising.

Here are some tips that can help accomplish these goals:

• One person maintains all the tools, shared directories, and plans for the book. That’s typically the primary writer. In ghostwriting projects, I’ve argued that it this project manager should be the ghostwriter.
• Conduct an early planning meeting to nail down the audience, the idea, and the table of contents. Hassle those out in real time, not over email or Slack. An all-day in-person planning meeting is best, even if it requires some travel.
• Design and agree to a drafting and review process, and stick to it. Settle this before you get started drafting anything.
• Store files in a place where everyone can see and edit them. If there are two or more people reviewing each drafted chapter, use Google Docs or Microsoft Office with sharing features. (I’ve worked in both, and while Microsoft’s Track Changes markup features are better, Google’s collaboration features are superior.)
• Meet (most likely, virtually) before each chapter and agree on what question it will answer, what the main concepts are, and where the source material will come from.
• After writing a chapter, invite all required reviewers (editors, coauthors, others with a stake) to review it by an agreed-upon deadline, using redline markup features and commenting on each other’s edits.
• Don’t rewrite a chapter until all required reviewers have reviewed the document. (That is, don’t revise based on feedback from a coauthor, then revise again based on feedback from an editor, then revise again based on feedback from a publicist, etc.)
• For the first chapter you write, you may want to revise multiple times based on feedback — to settle questions of tone, establish main ideas, and find glitches in the review process. But for subsequent chapters, blaze ahead with new chapters before rewriting earlier chapters. It’s better to get the whole manuscript together before rewriting, rather than attempting to perfect each chapter seperately.
• Limit the number of “I get last view” type reviewers (for example, PR staff, your boss’s boss, your ghostwriting client’s spouse, or your publisher). Early on, give them a polished chapter and table of contents to react to. At the end, give them the whole manuscript with instructions that comments must be limited, on a short deadline.

If you plan ahead, you won’t hate yourself later

Version control screwups make you hate yourself, your collaborators, and your project — avoid them and you can concentrate on quality instead of stupid technical issues. In my experience, once you establish these ground rules, you can deal with almost any content issue without tears.

Collaborators who won’t obey these rule are agents of chaos. Propose the rules early to identify such problematic partners. And if they insist on being chaotic, fire them or exit the project. (I’ve left tens of thousands of dollars behind when I found a client behaving this way — and I’ve never regretted it.)