The Future Does Not Compute

Thoughts on a Group Support System

This is Chapter 10 of The Future Does Not Compute: Transcending the Machines in Our Midst, by Stephen L. Talbott. Copyright 1995 O'Reilly & Associates. All rights reserved. You may freely redistribute this chapter in its entirety for noncommercial purposes. For information about the author's online newsletter, NETFUTURE: Technology and Human Responsibility, see http://www.netfuture.org/.

Decision support systems have come a long way since the Sixties and Seventies. Time was when Nobel Prize laureate Herbert Simon could announce with a straight face: “There is every prospect that we will soon have the technological means, through [heuristic programming] techniques, to automate all management decisions.”/1/ From battlefield strategy to commercial product development, machines would increasingly take charge.

While I suspect there is more truth to Simon's prediction than most observers allow -- after all, only a person whose own thinking processes were already largely “automated” could have ventured such a statement -- history has contravened his expectation. Now, some thirty years later, neither the battlefield commander nor the CEO is in foreseeable danger of obsolescence.

We still hear about decision support systems, of course, but they mostly attempt to offer a relatively humble suite of logistical services to the human decision maker. The buzzwords flitting about the research publications tend toward the more modest end of the spectrum: electronic meeting systems, groupware, computer-mediated deliberation, and so on. What these denote can range from simple electronic extensions of the chalkboard and the paper memorandum to ambitious, if relatively crude, gestures in the direction of Simon's original vision.

Brainstorming, analyzing, and voting

I will look briefly at reports of one particular “group support system.” Developed by researchers at the University of Arizona,/2/ this system was designed to facilitate meetings. The meeting room contains a microcomputer for each of four to ten participants, and a large projection system for displaying either an individual's work or the combined results of group work.

The typical meeting under this system has three phases. Using Electronic Brainstorming software and typing at their separate terminals, all members of the group record their ideas regarding the questions posted on the meeting's agenda. Although these contributions are anonymous, everyone can see the complete and growing list of ideas. Next, a vaguely described Issue Analyzer helps the group “identify and consolidate key focus items resulting from idea generation.” Information from other sources can be imported during this phase. Finally, a Voting tool provides various methods for prioritizing the key items. Again, voting is anonymous, but the results are easily displayed for all to see.

The Arizona researchers report on the experimental use of this system at IBM. In one case a manager, frustrated in her attempt to identify certain problems in shop-floor control through conventional meetings, employed the group support system with apparent success. “At the end of the brainstorming session, the manager reflected that for the first time she was able to get meaningful answers” to her questions. Immediately following this, the group prioritized a list of “focus items,” held some face-to-face discussion, and voted. The result? A high degree of satisfaction among the participants, who felt they had successfully addressed the problems.

This system can clearly provide low-level, logistical support. Ideas, once entered into the computers, are part of a meeting record that can be recalled at any time. Complete “minutes” of the session are available immediately upon its conclusion. Votes can be taken and recorded in an instant. Not surprisingly, the Issue Analyzer, designed to help structure the actual problem analysis, came in for criticism as “clumsy.” It appears that this was where the face-to- face discussion proved most important.

Overall, the system produced large time savings “strongly correlated with the degree to which the group's task was stated clearly and concisely.” One participant cited “the preciseness of the process procedures” as an advantage. The researchers note in a later publication that “process structure helps focus the group on key issues and discourages irrelevant digressions and unproductive behaviors./3/

Paradoxically, the anonymity of the process won praise for “knocking down barriers” between people One user mentioned the “openness of the process and its lack of intimidation. This was because of the anonymity.” A second was impressed by “the way the personalities are taken out of the process so that the process becomes more rational.” And a third remarked how “the anonymity of the input allows participants to change positions on an issue without embarrassment.”

In a related experiment, a Hughes Aircraft manager offered a similar observation: “I noticed that if someone criticized an idea of mine, I didn't get emotional about it .... No one knows whose idea it is, so why be insulted?”

Are there no risks?

The general literature on group support systems yields a mixed and confusing set of conclusions, leading the Arizona researchers to emphasize the importance of context. For example, the size of a group, the complexity of its task, and the prevailing corporate culture will all help determine the effectiveness of electronically supported meetings. Also, electronic support does not always have to take the same form. The system described here can be combined with any degree of “traditional” group interaction; it can be adapted to asynchronous use and distributed throughout several offices; and presumably -- although the researchers do not mention this -- the anonymous feature could easily be turned on or off, according to a group's wishes.

The University of Arizona developers claim a number of benefits for their electronic meeting system. In their own words, it

• enables all participants to work simultaneously (human parallel processing);
• provides an equal opportunity for participation;
• discourages behavior that can negatively impact meeting productivity;
• enables larger group meetings which can effectively bring more information, knowledge, and skills to bear on the task;
• permits the group to choose from a spectrum of structured or unstructured techniques and methods to perform the task;
• offers access to external information; and
• supports the development of an organizational memory from meeting to meeting.

On the other hand, they identify no risks or liabilities, although in a general discussion of electronic meeting systems they mention in passing the potential for depersonalization by the electronic medium, together with the necessarily limited “view” offered at any one time by a video display screen. Having listed these as theoretical concerns, they do not go anywhere with them.

Another researcher describing this same work manages to come up with two potential disadvantages: most people cannot type as fast as they speak, so the meeting is slowed down unless there are approximately eight or more participants (in which case the advantages of parallelism more than compensate for slowness of typing); and the system is useless for “one-to-many” forms of communication, such as lectures./4/

There is something disconcerting about this peculiarly limited range of assessment -- a limitation, incidentally, that seems quite typical of efforts in this field. The adaptation of the group task to a kind of computable algorithm seems just a little too easy, and the world of possibilities outside the algorithm just a little too neglected. This neglect is only more disturbing when set beside the authors' claim that the technology “is fundamentally changing the nature of group work.”

It is not that it is wrong to assess one's tools and methods against criteria such as the external flow of information, the precision of procedures (as indicated by faithfulness to a step-by- step, procedural outline of the way things ought to proceed), and time-to-solution. It is just that if these considerations do not take place against a larger and more meaningful backdrop, they easily begin to oppress, a fact generally ignored within the engineering and research worlds giving birth to the new software tools.

This is not to say that supporting software is inherently threatening. Much depends on the awareness of the group using it. That is exactly why the restricted vision of the researchers and their test subjects is disturbing -- the cultivation of a wider awareness is exactly what does not seem to be going on.

The risks are not trivial. For one thing, the work group may begin to conceive and carry out its tasks mechanically, simply following the prescribed format for its own sake. Such prescription can cramp any human relationship -- particularly where creativity is desirable (and where isn't it?). Even to write things down at too early a stage -- so that the things written confront one as a kind of objective, already achieved “reality” -- can in some cases stifle any further, freewheeling, imaginative thinking.

My own experience of meetings suggests that critical insights often crystallize unexpectedly at the end of a long and meandering journey -- and they may even nullify everything that preceded them. And yet, the journey was essential to the insight. Any effort to make the later stages grow too systematically out of the earlier ones may discourage profound revisualization of a problem in favor of a pedestrian “solution.”

Group work does require structure as well as freedom. But when the structuring tools contain embedded intelligence, one needs to assess carefully just how intrusive and coercive their influence might be. For such intelligence is aggrandizing: it not only increases the range of capability and the adaptability of the tools, but for these very reasons it also invites users passively to abdicate some of their own responsibility for shaping group processes.

The development of human capital

The issues here pierce to the essence of the business undertaking. Is the corporation a human activity in the service of human needs, or not? It is remarkable how easily and subtly the human-centered view slips from our grasp. Indeed, just so far as the corporation is viewed as an enterprise designed to score a profit, rather than to serve worthwhile ends under the discipline of economic controls, to that extent the entire organization has already been cut loose from its human justification and reduced to something like a computational machine.

But suppose we answer, “Yes, the corporation is a human activity in the service of human needs.” What then? The first thing we realize is that the individual and group activities within the company are more than a means to some external end; they are themselves a primary justification for the company's existence. After all, prominent among human needs is the need to work, to create, to cooperate, to solve problems, to struggle against the solid resistance of the world. In this striving, the individual and the working community grow, and such growth is -- or ought to be -- a good part of the reason for binding these human efforts together in the first place.

In this context, every problem is a gift -- part of the company's inventory of “raw goods” -- and invites the production of new, human “capital.” This is far different from seeing a problem merely as something to be gotten rid of by the most efficient means possible.

All of which indicates that meetings we support electronically cannot be assessed solely in terms of productivity, time-to-solution, precision of procedures, and so on. A manager must balance many different concerns, in addition to getting the product out the door. Is each member of the group being stretched so as to gain new skills and exercise a more mature judgment? Does the distribution of tasks reckon appropriately with the different ages and experience levels of group members? Is there a way to call upon this or that contributor's intense personal interests? What do the frictions between Jane and John suggest about their future assignments? In what ways can the group internalize and make practical the larger organization's commitment to meeting human needs?

The potentials of age

Consider, for example, the effect of age upon a worker's role. A twenty-five-year-old will typically approach life far differently from a fifty-year-old. Youth is full of biological energies, invincibility, and an expansive, I-can-do-anything optimism. In later years, this refreshing, energetic, I-centered, immediate-task-oriented style shifts toward the more reflective and communal. Here's how Bernard Lievegoed puts it in The Developing Organization: “At 35 a man will ask in a certain situation: ‘How can I solve this problem?’ A man of 55, if he has weathered the crisis in the right way, will ask ... ‘Who is the most suitable person to solve this problem?’ or even ‘How can I delegate this task so that the person concerned can learn something from solving it?’”/5/

As Lievegoed points out, some will not make this transition successfully, but instead grow more rigid with age, hewing to petty rule, defending their own turf ever more jealously, and generally proving a headache to the larger organization. In this case, management must ask,

What mistakes have we made so that he has become like this? When he was between 40 and 50 did we not profit from the fact that his department ran on oiled wheels? Did we leave him there because we could not be bothered to make a change? Did we overlook the symptom that no promising young men emerged from his department ready to move on to higher levels?” (p. 153)

When a manager is prepared to ask such questions, and then, with the questions in mind, to facilitate the deeply organic interrelationships within a group -- all in service of the values and purposes governing the larger organization -- will the group support software help her or hinder her? I don't believe there is any direct answer. There is only a complex set of issues we haven't really begun to address yet.

Using software as a foil

Or, again: in any group committed to human ends, the issue of anonymity mentioned earlier would present itself as a problem and an opportunity. Here, in fact, one can imagine a judicious and constructive employment of computers. If I were a manager with access to the system described above, I would use it to the hilt in tackling a specific issue. Then I would hold a follow-up meeting in which the electronically supported session became a foil for assessing the group's current state and performance. Why did participation improve when anonymity was guaranteed? Am I -- or is someone else -- behaving in meetings so as to squelch the free exchange of ideas? What are the various strategies of intimidation at work in our group? How can we function more openly, without intimidation? -- for surely a group cannot be at its most productive if its members do not have the maturity to deal forthrightly with each other!

And so the distortions and constraints of an electronic support system, used as a kind of foil, can help to answer the question, “What distinguishes a human-centered organization from a mechanism?” But the prerequisite for this is, unfortunately, just what is missing in the current literature: an ability to step back and look for the distinctly human potential in social institutions. Nor is the failure here surprising. What should the programmer look for, if not what is programmable? And yet, if we were not thinking in mechanical terms, we would train our engineers to think first of everything about a task that cannot be programmed. Only when they had fully lived their way into the specifically human -- and therefore never fully capturable -- dimensions of the task would they consider what supporting role their software might play.

Approached in this spirit, software engineering would prove a discipline of continual revelation by clarifying the boundaries between man and machine.

References

1. Simon, 1965: 47.

2. Nunamaker, Vogel, Heminger, et al., 1989.

3. Nunamaker, Dennis, Valacich, et al., 1991: 41-61.

4. Aiken, 1993.

5. Lievegoed, 1973: 152.