Perhaps you’ll recognize this pattern: A committee of any size larger than 2 needs to consider a document, and can’t do so during a regularly scheduled meeting, and scheduling a meeting is hard to do anyways. Then comes the following Sentence of Doom: “I’ll circulate the document for comments via e-mail.”
The impulse is understandable: Everyone’s on e-mail. It’s a text-based medium, and so it’s almost natural for people to bang out a quick reply. Those things should drive up participation, and increase buy-in for the document’s contents. Hey–it’s like crowd-sourcing, almost!
Except it’s not. There are numerous problems:
- The document will fork, or even splinter. Competing versions start to circulate, and all of a sudden it’s hard to tell what’s under discussion.
- There’s a strong first-mover bias. Everyone’s on e-mail, it’s true, but not everyone is on e-mail on the same schedule. The discussion is framed, though, by the first people to reply. Fortunately, it’s not quite as bad as YouTube comments, but there’s something disquieting about seeing 10 e-mails in a thread you’re just coming around to.
- The fact that everyone’s on e-mail is a problem as well as a benefit: If something shows up in my inbox with an invitation for comments, I’ll probably comment on it–even if I haven’t been paying as much attention to the issue as I should.
A much more reasonable way to solicit feedback is to post the document to a wiki or to Google Docs and to share it with members of the committee. There are real advantages:
- There’s one document, which people can edit directly. Everyone can see what’s under discussion. Google Docs, and most wikis, preserve the previous versions, so it’s easy to revert back.
- It alleviates the first-mover problem, because people just focus on the one document, rather than the cascade of e-mails.
- Because you’re inviting people to participate in the process, rather than pushing the document out to everyone, it’s likely that only people who genuinely care will bother to click the link. That means your committee can create the best document possible, and then use that as the basis for building consensus or legitimacy.
As usual, the CommonCraft people explain this process very clearly:
Since Google Docs, and wikis such as PBWorks, use WYSIWYG interfaces much like Word or various e-mail clients, there’s not much to learn.
In 2010, let’s try to make group work a little more convenient!
- “Revision isn’t cleaning up after the party: it is the party“
- “Drafting and revising documents” on PBWorks
- “3 Ways to Edit Documents Collaboratively“
- Advanced collaborative editing: Google Wave
Image by flickr user bionicteaching / CC licensed