Image source: http://mindshift.kqed.org/
“Writing is easy: All you do is sit staring at a blank sheet of paper until drops of blood form on your forehead.” — Gene Fowler
The image this quotation brings to mind?the solitary writer struggling to fill his page?is dated in more ways than one. There?s no disputing the underlying truth that writing involves more work than one might expect, but these days it rarely involves a physical page, and it isn?t always a solitary activity. Collaborative writing is the ever-increasing reality in a wide range of professional settings.
The conversation about collaborative writing often pays close attention to the tech tools available to manage process or to the pros and cons of collaborative writing in both academic and professional settings.
However, if you are reading this post, it is likely that you are already engaged in a certain amount of this kind of work, and that you and/or your organization already have tools in place to help manage the job.
So you?ve got the tools in place, how do you manage the human side of the equation? What about the sticky issue of clarifying roles or the ever-popular challenge of balancing the big picture with nit-picky details?
Here are 5 of our favorite tips for better collaborative writing:
1. Make sure you know how to use version control
At all costs, everyone should know how to get to the most recent agreed-upon draft, so that whenever a problem or disagreement occurs, there is a frame of reference to which the group can turn. Whether you?re doing the job using shared files on common server space or using Alfresco Team, at some point a human being is going to decide which changes to incorporate and which parts of the document are now buttoned up.
Here?s the kind of thing that can happen: a paragraph that had been previously cut is reintroduced, but now ? because the transition leading into that section has undergone subsequent revisions ? the paragraph doesn?t seem to fit. The transition will have to be rewritten to accommodate this. Documents are systems in that the parts are all connected. Chaos lurks in the shadows, waiting for its chance to strike.
Version control (including a dogged adherence to naming conventions) is a lot of what holds that chaos at bay. Does this characterization strike you as a little over-dramatic? Ask a project manager who has seen it happen.
2. Be clear about the purpose of each revision
Whatever the purpose, people should be laser-focused on it. Ask yourself: Is this iteration to clean up minor issues like style and tone tweaks or for larger things like structure and flow?
It?s infuriating when a revision that was supposed to be a substantive clarification comes back with nit-picky little style guide tweaks, ?that? vs. ?which? revisions, and so forth. That frustration can be eliminated by crystal clarity on the revision?s purpose. This is where the project manager or team lead says things like ?We?re checking the flow of information to make sure that every key term is either explained on first reference or can be understood from context and usage,? or ?I?m worried that there?s too much throat-clearing at the beginning and I want proposed cuts for the ?Background? section.?
3. Trust the Subject Matter Expert (most of the time)
Trust your SME on content, but be ready to push back when they add unnecessary layers of complexity and threaten to confuse the very people with whom you?re trying to communicate.
In Made to Stick, Chip and Dan Heath describe a communication challenge they call ?the curse of knowledge.? How can too much knowledge be a problem? Because it problematizes communication when one party cannot remember what it was like to not already have expertise.
Good communication is staged and sequenced. That?s why, to appeal to common experience, some math experts aren?t very good math teachers. If a fourth-grader is learning about square roots for the first time, it will only muddy the waters to say that 4 and -4 are both square roots of 16. It?s true, but it?s a level of complexity that will prevent learning.
Make sure your group understands the intended audience for your document.
4. Don?t keep fighting for a lost cause
However, when the group, or project lead, or other decision-making entity has decided something (e.g., ?No, we?re not going to use that example in section 2.?), the person who had a strong preference for a different approach needs to move on. Bringing these kinds of upstream issues into downstream discussion is a trust-killer, because your fellow team members thought that issue was settled. It?s also damaging to the emerging sense of shared accomplishment at having made it this far, because it implies that the agreed-upon parts of the work may still be revisited at any time.
5. Designate a final editor.
