Models and Theories in Human-Computer Interaction/Coordination and Social Loafing

In my workplace we do not use a WikiBook, but we do use SharePoint in a similar manner as a document and knowledge repository contributed to, and maintained by, the entire team. In many ways it can prove a highly valuable tool. About a year ago I transitioned positions to the data warehouse team I now work for. Being able to read the documentation my new team had saved in its SharePoint helped me to get up to speed far more quickly, and without needing to take productivity time from other team members, then I would have been able to otherwise. I believe it also helped that documentation made for you SharePoint is often done with the express intent of transferring knowledge efficiently. When you have a face to face interaction, unless one of the individuals in the interaction has a script or plan they are following, you often jump back and forth when discussing a topic which can make it harder to get an overall picture than following a well thought out document meant to instruct you.

However, I also ran into some coordination problems with using computer mediated communication in this manner. I ran into some synchronization problems with teammates when I trusted that their documentation on processes, and source code for solutions, were up to date when they actually hadn’t been updated in quite some time. This caused me to waste time building on top of obsolete solutions, and taking steps that no longer reflected the actual production processes. I highly doubt that those same mistakes would have been made if my knowledge transfer had been done face to face with other team members instead of through reading documentation. The lack of face to face interaction with another person can also lead to misunderstandings that are far less likely when you can receive body language and tonal cues instead of having to rely on flat text.

Social loafing can also be a problem when maintaining collaborative documentation. I am lucky to work with a highly skilled, highly motivated group of people who I know all support each other. One aspect of our work where the majority of the team, including myself, tend to be far less motivated is in documenting our work. All of us would rather be solving a new problem, or working on a project, than documenting a process we have already created. One member of our team ends up doing a far disproportionate amount of the documentation for the rest of our team, not because he enjoys it, but because he knows it is important and that the rest of us are likely to let it slip. This is not ideal for many reasons. For starters, it is clearly unfair to him, and could lead to friction with other team members. It also means that someone other than the primary architect of a process is the one having to document it, which can lead to errors in the documentation that the primary individual would be far less likely to make.