Electronic Cancers

[Marc Stiegler <marcs>]

I have been reading ACM's transactions on Office Information 
Systems slowly but surely for several months, since they have 
numerous articles on collaborative software. I recently ran into 
an article which has inspired another chapter for the Proponent's 
Manual, the document I foresee shipping with the Infofactory 
to tell a novice groupware installer how to interface the software 
to the group. I am sending my note for the chapter out to everyone 
because it might be relevant to AMIX's corporate product as well 
as the Xanadu InfoFactory, and because it is at least mildly 
amusing. Alas, it is not particularly surprising:
-----
Chapter XYZ: Electronic Cancers

In the ACM Transactions on Office Information Systems, October 
1988, Volume 6 Number 4, J.D. Eveland and T.K. Bikson tell a 
tale for our times in the article, "Work Group Structures and 
Computer Support: A Field Experiment." They had 2 40-person teams, 
drawn randomly from the same group of workers, tackle the same 
report-writing task. The only observable difference between the 
2 groups was that one group had electronic mail, whereas the 
other group had to rely on older, less modern tools. Each group 
had to write a report that would advise people on the verge of 
retirement on how to plan for their futures.

The good news is that the electronic team was very pleased with 
its results--there was a great deal of job satisfaction.

The bad news is the electronic team's product. The electronic 
team created a 70 page report, mostly in the form of 
tables. The manual-work group, by contrast, created a 15 page 
report, mostly in the form of anecdotes. 

According to Eveland and Bikson, both reports were good. However, 
let us be honest with each other. Which of these 
reports is more likely to be read by real retirees--the 15 pages 
or the 70 pages? And which is more often remembered--the point 
at the end of the anecdote, or the point in the middle of a dazzling 
array of columns of information? 

One can only conclude that the group without electronic support 
created a more useful and effective product, even though the 
electronic workers felt greater pride in their result!

Of course this was only one study, with just one outcome. But 
the way in which the electronic group failed is very suggestive. 
With the advent of electronic tools, it becomes much easier to 
create more material--and with the improved communication among 
team members, it becomes more difficult to delete material without 
a larger group consensus. So the report grows and grows. Furthermore, 
it grows in ways that are conveniently supported by electronic 
tools, such as tables and pie charts. It seems quite likely that 
the electronic support itself contributed to the failure of this 
40 man team to create a readable document.

How can you avoid these problems? There are two key components 
to preventing cancerous, tumorlike growth in your group writing 
tasks. 

Step one is to constrain the number of people working on the 
report--rather than having 40 people working on the study, put 
only 10 people on the task. Let the ten principal participants 
consult others as needed--but do not require them to consult 
others on a regular basis, and do not allow others to force more 
material upon them.

Step two is to correct the reward system in your group, so that 
people who REDUCE the size of a finished product are honored 
as much or MORE than the people who enxpand it. Take every opportunity 
praise teammates who find material to delete (particularly if 
they find ways of deleting material they themselves created). 
For large, critical projects, give awards  for concise phrasing. 
Make sure that everyone understands WHY shortness of presentation 
is praised above other factors. And appoint an editor, who has 
the explicit job of deleting material--and let the editor's judgement 
be final.

Even with these incentives, an electronic team will inevitably 
grow a large body of collateral material. Frequently, the collateral 
documentation is good, but just too extensive to be readable--you 
must remove it from center stage lest the stage grow to the size 
of a football field.

Hypertext, of course, supplies the natural place to put such 
related material. Run links to the collateral information, allowing 
the reader the choice of whether to read it or not. 

Indeed, when using Inclusion Lists, it makes perfect sense to 
compose all such related material together into a second document--a 
document that in paper formats would be called an Appendix. Going 
further, the separately composed Appendix can then be included 
by reference into the original report, and printed when desired.


--marcs