Larkware
We get up early so that you don't have to.

Advice for Writers, Part 7

By Mike Gunderloy
Friday, September 05, 2003

A lot of my writing has been in collaboration with other authors. Sometimes this has worked very well indeed, sometimes it hasn't. Here are some thoughts on how to make your collaborations go a bit more smoothly.

The most critical advice is to make sure that all of the authors involved have the same expectations for who will do what, and when it will be done. My all-time least-pleasant co-authoring experience involved an author who apparently thought that deadlines didn't apply to him, and who turned in all his work late (and crappy). You can avoid having that experience with the same author twice simply by never working with the jerk again, but it's best to avoid having it even once. A good set of scheduling worksheets can help out a bit here.

Another thing you can do is to make sure you start on a short project instead of a long one. It's a lot easier to decide whether you want to keep working with a particular person when you're jointly developing a five-page article then when you're trying to write a 500-page book. It's also much easier to write something with one co-author than with two, three, or more.

I've seen three basic models of collaboration. All of them can work, but you need to be aware of the differences, and you need to be sure that all authors agree on which model you're using.

The first model I call loose collaboration. In this model, each author is responsible for their own part of the book, and takes that part from start to finish: outlining, writing, author review, and galleys. With this model, each author can focus on a particular part of the topic, and learn it in more depth. You can also finish the book much more quickly, since two sets of chapters are being written in parallel. The disadvantage to this model, though, is that coordination becomes a problem. If you refer to something that will be discussed in chapter 17, and you're not writing chapter 17, you'd better make darned sure that your co-author knows to cover it there. It can also be a problem to get a consistent authorial voice with this model; there may be jarring changes between the two sets of chapters.

The second model I call tight collaboration. In this model, each author works on the entire book. Normally in this model my scheduling worksheet will identify the lead author for each chapter. That author writes the first draft and then passes it to the other author to finish. The second author polishes the chapter, fills in any missing material, and submits it to the publisher. I find that it works well in most cases to alternate lead authors, so that both authors do the hard work of first-drafting about half the chapters. I also like to switch at the galley proof stage, so authors are reading each other's galleys; this seems to catch stubborn errors. Tight collaboration tends to lead to cohesive and well-done books, in my experience. But it's more work than loose collaboration and doesn't speed up the book-writing process any, which may make it economically marginal.

Finally, there's the specialist model. This happens when the two authors are chosen for having distinctly different strengths. If you're doing a book with C# and VB .NET samples, it might make sense to bring in a specialist just to handle the language that you're not most comfortable with. I've also been involved several times in salvaging stalled books: taking a pile of chapters in various states of completion, finishing them up, and getting the whole ready for publication. This model works well when both authors agree about the division of labor and their respective strengths.

When you're contracting for a joinly-authored book, there are three things to make sure you see in the contract:

  • Book credits (whose name goes first on the cover, and whether it's "Joe and Mary" or "Mary, with Joe", or what)
  • Split of advance checks
  • Split of royalties

The splits need not be 50-50, and they need not be the same (for example, one author might get 30% of the advance but 50% of the royalties), but everyone concerned had better agree on them up front!

Mike Gunderloy is the lead developer for Larkware and author of numerous books and articles on programming topics.

Home