ALPHA DRAFTS AND TEAM WORK
/
In prior entries I’ve discussed the value of passive versus active strategies for getting data/information/knowledge into knowledge systems. The basic idea is that people have limited time and attention and are less likely to go to the effort to actively contribute material to a group repository or other kind of knowledge system. The more passively content can get into the system, the more likely it will. This is a continuum from completely passive (the system has a way of automatically capturing content) to completely active (the person specifically creates and contributes the content). For example, a team member gives a presentation and the related PowerPoint material is automatically loaded onto the team’s repository. The team member did nothing extra so this is completely passive. Alternatively, the team decides that there should be a library of presentations documenting past work and a team member goes back and specifically writes and uploads the material. This is completely active. In the middle would be a scenario where a customer service representative is electronically documenting a customer’s issue as part of the process of solving the problem. The content is created as part of the work itself, and the upload happens automatically. The issue of active versus passive contribution of content speaks to issues of motivation – contributors don’t have to be motivated for passive contributions, but they do for active.
The issues get more interesting when we talk about work in progress. Passive systems imply that automatic uploads are occurring. Collaboration tools such as ActiveNet, Colonos, Egnyte, and NextPage can be set to automatically sync users’ content with the system available to the larger audience. Automatic is great for getting around issues of motivation – the system is always motivated. However, it is a more sophisticated system that can distinguish between raw drafts and drafts ready for prime time. I’m not aware of any system that can do make this assessment automatically (please add to the comment section below if you do). This lack of “intelligence” on the part of content systems pushes some users to use only active systems where they can control when content is uploaded – meaning that their teammates have less access to the content they may need.
For example, a colleague recently declined to use Egnyte for our new project. He made the point that he didn’t want drafts automatically available to the rest of us. He felt uncomfortable with our accessing his unfinished work without his express approval and explanation. (You can set Egynte to only upload specific drafts, but we weren’t aware of this at the time.) My assumption is that he felt our having access to “alpha” drafts with the associated false starts, typos, etc. was not worth the cost. We are a new team and may not have built up the psychological safety (e.g., Edmondson, Bohmer, & Pisano ) required to create comfort with less than perfect work.
I believe team members need to have access to work in progress to keep on track with their own portion of the work – e.g., making sure similar terminology is being used. Being able to see a teammate’s work status also helps manage the process of the team’s work – e.g., knowing when a teammate is likely to need your own portion of the work. However, unless there is an understanding of where alpha drafts fit in the picture, conflict is likely to occur. We need to know the difference between alpha (very early stage, useful for very early stage review around terminology and process tracking – not ready for critique – think of this as early brainstorming where critique would shut down the innovative process), beta (still early stage, but openly welcome to review), late (set structure, review focused on clarification and error correction), and final drafts.
Adjustments to both social and technological practice are required to address this issue. First, teams need to come to a joint understanding around the definitions of the stages of work. I’ve provided my own definitions (alpha, beta, late, and final), but these may vary team by team or project by project). Content management systems also need to provide features for appropriately managing the various stages of work. At a minimum this means being able to note the content’s stage. A more refined system might have features specific to managing stages:
Formal feature sets are not required to put these ideas to work. Most content systems (even discussion tools with threads) have the ability to have general comments and these could be used to post the agreed upon descriptions and actions for different stages of content. Similarly, most systems have the ability to tag or label individual files and this could be used to note the specific stage and type of review requested.
While setting such labels are clearly “active,” once these have been noted, the system could be set to automatic upload and tracking. This may be an effective middle ground that provides teammates with access to current material in real time, but also allows the author to maintain control of the expectations around the work.
These same issues are on the table when we work with blogs and wikis. I think of these blog postings as beta drafts and look forward to comments for further development. Pointers to collaboration tools that are especially effective are appreciated, as are descriptions of how your team has managed the expectations around sharing early stage work.
The issues get more interesting when we talk about work in progress. Passive systems imply that automatic uploads are occurring. Collaboration tools such as ActiveNet, Colonos, Egnyte, and NextPage can be set to automatically sync users’ content with the system available to the larger audience. Automatic is great for getting around issues of motivation – the system is always motivated. However, it is a more sophisticated system that can distinguish between raw drafts and drafts ready for prime time. I’m not aware of any system that can do make this assessment automatically (please add to the comment section below if you do). This lack of “intelligence” on the part of content systems pushes some users to use only active systems where they can control when content is uploaded – meaning that their teammates have less access to the content they may need.
For example, a colleague recently declined to use Egnyte for our new project. He made the point that he didn’t want drafts automatically available to the rest of us. He felt uncomfortable with our accessing his unfinished work without his express approval and explanation. (You can set Egynte to only upload specific drafts, but we weren’t aware of this at the time.) My assumption is that he felt our having access to “alpha” drafts with the associated false starts, typos, etc. was not worth the cost. We are a new team and may not have built up the psychological safety (e.g., Edmondson, Bohmer, & Pisano ) required to create comfort with less than perfect work.
I believe team members need to have access to work in progress to keep on track with their own portion of the work – e.g., making sure similar terminology is being used. Being able to see a teammate’s work status also helps manage the process of the team’s work – e.g., knowing when a teammate is likely to need your own portion of the work. However, unless there is an understanding of where alpha drafts fit in the picture, conflict is likely to occur. We need to know the difference between alpha (very early stage, useful for very early stage review around terminology and process tracking – not ready for critique – think of this as early brainstorming where critique would shut down the innovative process), beta (still early stage, but openly welcome to review), late (set structure, review focused on clarification and error correction), and final drafts.
Adjustments to both social and technological practice are required to address this issue. First, teams need to come to a joint understanding around the definitions of the stages of work. I’ve provided my own definitions (alpha, beta, late, and final), but these may vary team by team or project by project). Content management systems also need to provide features for appropriately managing the various stages of work. At a minimum this means being able to note the content’s stage. A more refined system might have features specific to managing stages:
- Tickler’s regarding early stage work that isn’t progressing across a certainly absolute time line or isn’t staying in sync with other tasks on the project.
- Space for comments appropriate to the stage (and reminders about the differences between stages). This could include opportunities to comment on terminology or appropriate brainstorming for alpha stage, specific areas needing review in beta, requests for proofreading in late stage reviews.
Formal feature sets are not required to put these ideas to work. Most content systems (even discussion tools with threads) have the ability to have general comments and these could be used to post the agreed upon descriptions and actions for different stages of content. Similarly, most systems have the ability to tag or label individual files and this could be used to note the specific stage and type of review requested.
While setting such labels are clearly “active,” once these have been noted, the system could be set to automatic upload and tracking. This may be an effective middle ground that provides teammates with access to current material in real time, but also allows the author to maintain control of the expectations around the work.
These same issues are on the table when we work with blogs and wikis. I think of these blog postings as beta drafts and look forward to comments for further development. Pointers to collaboration tools that are especially effective are appreciated, as are descriptions of how your team has managed the expectations around sharing early stage work.
