Source

Grudin (1994), “Groupware and social dynamics: eight challenges for developers”, LIT-757, read in NOTE-835: Table 1 (p. 97), the section “A Disparity: Work vs. Benefit” (pp. 96–97), the sections on intuition (pp. 100–101) and on email (pp. 102–103), and the closing list (p. 104).

What was actually shown

The claim, in Grudin’s words. “Groupware applications often require additional work from individuals who do not perceive a direct benefit from the use of the application” (Table 1, challenge 1). “Most groupware requires some people to do additional work to enter or process information required or produced by the application” (p. 96).

The cases.

  • Automatic meeting scheduling helps the convener and needs everyone’s on-line calendar. Calendars were found to be kept by managers, not by individual contributors, so “this groupware feature is rarely used”.
  • Voice annotation is easier for the speaker and harder for the listener.
  • Project management helps the manager and needs others to enter what they do not otherwise keep on-line. A naval system built over ten years was replaced partly for that reason.
  • Decision makers favour applications that benefit managers and underestimate “the unwelcome extra work that an application will require of other users, resulting in neglect or resistance” (p. 101).

The success case. In email “the primary beneficiary typically does a little more work” (p. 103): the sender, who wants the message read, types it.

What could have come out otherwise. The success cases could have included applications that asked work of non-beneficiaries and were used anyway. Grudin reports one, a voice-messaging system that succeeded only after management removed the alternative, and treats it as a case of forced critical mass, not as a counterexample.

What this does not say

  • Not a measurement. No study here relates the size of the disparity to the rate of use. The cases are chosen to illustrate, some come from the author’s experience, and there is no base rate of failures.
  • Not sufficient for success. Grudin says “even a net benefit with equal costs and benefits for all users will not guarantee groupware success” (pp. 96–97), because of critical mass and freeloading, and lists six further challenges. Removing the disparity removes one cause of failure, not all of them.
  • Not about time. The disparity is between roles at one time: convener and invitee, manager and subordinate. It is not, as the design-rationale literature often puts it, between an author now and a reader later.
  • Not about mandated systems. Where an organization makes the extra work someone’s job, the problem is “much less likely” (p. 96).

Connections

  • CLAIM-179 rests on this account. It holds that an agent filer removes the disparity because filer and beneficiary coincide, which is the email condition. This account supplies that premise from a read source, in place of the unread 1988 paper (LIT-759). It does not supply the conclusion that removing the disparity prevents abandonment.
  • QUESTION-037. An argument record kept across sessions is a groupware application in Grudin’s sense when the owner and an agent share it. The account predicts that the owner’s review, the work that benefits the record rather than the reviewer, is where neglect will appear.
  • CLAIM-176. Grudin’s advice to add group features to an application already in use (p. 100) agrees with capture inside work already being done. It says nothing about when to capture.

Note of 2026-10-30: what holds it back

No study in the record measures, member by member, the extra work asked and the benefit received across groupware applications, with mandate and critical mass held apart. Grudin’s evidence is cases chosen to illustrate, with no base rate of failures (NOTE-835).