This document discusses improving team communication for engineering managers facing complex system integration challenges. It proposes modeling a system development team's work as a set of interconnected conversations. The model represents team resources and communication activity with a graphical format. Using this model encourages thorough consideration of conversation requirements and explicitly documenting successful interaction patterns. This is expected to lead to broader computer use for managing system development and provide valuable tools for managers to better organize and clarify teamwork until more advanced communication methods are adopted.
This document discusses improving team communication for engineering managers facing complex system integration challenges. It proposes modeling a system development team's work as a set of interconnected conversations. The model represents team resources and communication activity with a graphical format. Using this model encourages thorough consideration of conversation requirements and explicitly documenting successful interaction patterns. This is expected to lead to broader computer use for managing system development and provide valuable tools for managers to better organize and clarify teamwork until more advanced communication methods are adopted.
This document discusses improving team communication for engineering managers facing complex system integration challenges. It proposes modeling a system development team's work as a set of interconnected conversations. The model represents team resources and communication activity with a graphical format. Using this model encourages thorough consideration of conversation requirements and explicitly documenting successful interaction patterns. This is expected to lead to broader computer use for managing system development and provide valuable tools for managers to better organize and clarify teamwork until more advanced communication methods are adopted.
Elsevier Science Publishers B.V., Amsterdam - Printed in The Netho-lands
287 Rick Thomas Evenvie w Corporation, P. 0. Box 9204 15, Norcross, GA 30092 (U.S. A .) and Robert Drury Systems Management Consultant, Atlanta, GA (U.S.A.) ABSTRACT Engineering managers, faced with ever greater system integration challenges, must actively im- prove team communications. As a conceptual tool, the work activity of a system. development team may be described in terms of a group of cou- pled conversations. Based on this approach, a model is outlined which offers a graphic repre- sentation of team resources and a metaphor for interactive communication activity. Use of the model encourtzges complete consideration of the requirements for a given conversation and helps to explicitly document successful interaction patterns. Models with these features are ex- pected to lead to broader use of computer work- stations for managing system development. Until then., the concepts are valuable to managers to help to organize and clarify their teamwork. INTRODUCTION There is no doubt that skills with language are among the primary factors determining management success. To gain cooperation, managers communicate. A project can be seen as a series of conver- sations which result in reaching a goal. By no- ticing and sharing common conversatinn patterns as explicit entities, effective patterns are refined and reused, serving as an organiza- tional tool. Productivity improves because of *Paper presented at the First International Conference on Engineering Management, Washington, DC, September 22-24,1986. more certain and quicker conversations. Such extended uses of language will appear as tools begin to support richer structuring by communicators. Current management skill de- velopment can anticipate these tools. These skills in turn will influence the tools and the structures that they support. In this way, every team may be a test bed for future communica- tion m&hods. The purpose of this paper is threefold: to con- sider the potential of teamwork communica- tion tools; to illustrate the use of explicit models for communication in management; and to en- courage management effort in these areas. This work is not empirical. It offers a synthe- sis of current developments into a conceptual 0167-5419/88/$03.50 0 1988 Elsevier Science Publishers B.V. 288 design. The approach is intended to be prag- matic. The authors are managers who seek to realize the potential value of advanced com- munication methods. First, premises on management and human nature are presented. Then there is a review of some significant technical developments. In the context of engineering projects, requirements for team communication support tools are pre- sented using a graphical model for resources. Finally, implications for current action are sugg:;sted. MANAGEMENT AREA OF INTEREST As an illustration consider a group of mana- gers/engineers who are forming a team to han- dle a major project. Through clear personal agreements, they seek excellent team perform- ZYJC. Given a preliminary specification for a commercial elertronic product, the team is to build a new factory including structure, auto- mation equipment, and initial staffing and op- eration. Not only must the team consider many technical and market issues, but must also con- stantly refine ad hoc procedures for corre- spondence, accounting, calendars, documen- tation, contracts, and the like. This example is from a field referred to as systems management (Silverman, 1983, p. 1052). Systems management includes both de- velopment and operations aspects of a large technical system. It is characteristic of such teams to develop complex, one-of-a-kind prod- ucts. These products typically have diversity of physical structure, of formal contractual rela- tions, and of required operations knowledge. In the projects many parallel activities, there are many unforeseen contingencies to address. Generally, when there are complex require- ments, when the work product is not immedi- ately tangible, and when there are many people in dependent efforts, a project plan does little to insure success when Yaken to the bank, What are the limitations of a team that intui- tively concern a conservative banker or tech- nical manager when presented with a proposal? First, we are limited as communicators. Dif- ficulties include: (1) (2) (3) (4) Sustaining communications goals such as making complementary tradeoffs and reaching consensus. Keeping a complete, shared view of the current work design and possibly over- whelming options. Dealing with the mechanics of communi- cation such as the need to send messages when certain events occur, and the need for many people to participate in a meeting at the same time. Bearing the high development cost of com- munication procedures. We are also limited in acquiring and using system knowledge. (1) (2) (3) (4) When working with large systems, there is less breadth of experience in a career. There are only limited policies of recording experience. There is a disinclination to search for so- lutions. Experts are scarce and the system manager is very busy. Early choices in a design may become costly blind alleys when it is necessary to restruc- ture a system (Silverman, 1983, p. 1052). New management challenges demand new methods. Robert Goizueta of Coca-Cola put it this way: The acceleration in technology growth has accelerated everything else in our world, including the obsolescence of business experi- ence. . ..in all our plans we must also plan to quickly change our plans if necessary. (Goi- zueta, 1986) To achieve the called-for flexibility, tech- niques are needed which allow the team (and its partners ) to follow a coherent joint course of action. A VIEW OF WORK What one can imagine clearly, one can re& ize. Along the way, one learns to recognize fa- miliar situations and to know what is 289 significant. Frequently, one must take experi- mental paths, responding with confidence to surprises, while alert to meaningless events, At every turn there is the opportunity to im- prove skills and tools. This is the nature of craftsmanship: experience in following an un- hldi2~ path and unconsciously using (and spontaneously learning) guiding patterns or old friends. As a team member, one proceeds coopera- tively, with shared directions, in constructing quality results. Communication patterns de- velop, based on that richest of unconscious pat- terns, natural language ability. All of this goes on all the time, a sort of man- agement by going somewhere. The key quality that a person brings to work is awareness, a willingness to experience and act, which is di- rected towards work through communication. The focus here is on team communication tools which complement these aspects of hu- man nature, while taking them as given. A val- uable tool will enable a team to form conversational environments which will mu- tually reinforce the team members intuitions. This approach encourages us to treat as ele- mental units the conversations surrounding co- operative work effort and also to avoid untestable concepts such as mental informa- tion processing. (For a philosophical treat- ment of this issue, see Winograd and Flores, 1986, pp. 68-73) where the authors argue nothing exists except through language.) In this paper, organizational boundaries and functions are purposedly blurred in favor of a focus on conversations as elements. So while the level of interaction varies widely within the team, the action of every team member impacts to some extent the action of every other Like- wise, little consideration is given here to spe- cific administrative systems within which people might work. These are seen as accumu- lated results of conversations which serve to address the resource needs of the team. ORGANIZING VHROUGH COMMUNICATION The ways that managers have happened and chosen to organize have brought us to this junc- ture. Enterprise can be seen as structure accu- mulated through a series of past conversations plus the presently active conversations. To- gether these working conversations, when characterized, are our baseline for synthesizing new communication designs. Past conversa- tions may be characterized by observing struc- tural remnants and starting new conversations concerning the record. And current conversa- tions may be sampled with empirical tech- niques such as those of Mintzberg (1973). A first step is to describe the range of manage- ment work as a scheme of conversations, as il- lustrated with the following statements. System management work is seen conven- tionally as simultaneous planning, implement- ing, and monitoring processes, though the defining lines are usually quite blurred (Sayles and Chandler, 1971) . (1) Planning is a process of communicating about opportunity. A plan is a snapshot of a continuing discussion. ( 2) Team members implement components of a system. They direct their crafts according to conversations. They also communicate about cooperation and thereby structure the conver- sations about results. We usually think of this as action. ( 3) Monitoring, or measurement, is key to meeting the requirements of a complex project. Having a clear view of present situations and of inherent possibilities, managers direct their en- terprises better. This view is gained in large part through conversation. Organizational development, cast as com- munication, includes &ill building, team build- ing, and tool building. (1) In skill building, we learn how to do something by watching, doing, and through conversation. Through conversation, we also learn about sources of work-related experience, 290 personal management habits, and communi- cation skills. (2) In team building, we seek to develop co- operating units by promoting good personal re- lations and a common point of view. A ?ommcn language helps immensely. Coordinating the viewpoints of team members requires recurring conversations. These recurring conversations are the source of team structure. In this sense, the design of effective conversation patterns re- places organization charting and policy making. ( 3 ) Tool building includes the establishment of the infrastructure by which conversations are held. Conventional media ( meeting room, tele- phone, correspondence) offer a channel but no inherent aid for structuring. On the other hand, computers used as communication media pro- vide for structure. A computer program, such as a spread sheet or database, is most often seen as a way to represent some aspect of the work. A different view is that these programs are waystations for segments of conversations ar- ranged in patterns. To complete this view of organizational de- velopment, note that measurement of effective- ness at development efforts is critical in building successful teams just as measurement of work results is critical in building successful prod- ucts. By clearly observing the teams conver- sations with its public and itself, we find direction for our next steps. Using this approach, both system manage- ment work and organizational development work are cast as similar conversational pro- cesses. Conversation is used as a common con- ceptual thread through the processes of producing work and building team ;. This offers a more general design metaphor but more im- portantly allows us to think explicitly about conversations which operate on other conversations. NICAL DEVELOPMENTS Current developments in communications and computer technology are discussed here for two reasons: First, these technologies, used in products and in organizing, present growing opportunities for the system manager. Second, and more importantly for this paper, they illus- trate and support abstract designs useful in management work. Communication standards are established so that users with different equipment needs can coexist in a common framework. In order to de- velop this framework, an industry group typi- cally forms a standards development committee. This process is an ongoing agreement, to agree on a standard. Currently, the Manufacturing Automation Protocol (MAP) (Kaminski, 1986) and the Technical Office Protocol ( TOP) (Farowich, 1986) are good examples. In these cases, a model for communications standards practices, estab- lished by the International Standards Organi- zation (ISQ), was used. Several nnajor manufacturing companies adopted this model and initiated a long process of proposal an.d re- view to build consensus. The IS0 model is made up of several layers of services. The lower-level services are con- cerned wit*h physical connection, network ad- dresses, message routing, session management, and terminal compatibility. Each layer ldeals with specific technical issues and provides a service which makes its implementation trans- parent to other layers. At the higher levels, ap- plication layer services support user messages, electronic mail, file transfer, and database ac- cess. Building on this level, user groups can standardize messages about their local environ- ments. Figure 1 shows a summary of the IS0 layers plus two non-standard layers illustrated here by workstation applications. The Apple MacintoshTM and other desktop metaphor user interfaces present the user with a visual means to organize files. In some cases, basic operations are common to all application programs. These user interfaces serve as pro- prietary standards to implement a layer sup- porting communication of a capability in software form from a developer to the user. Fig. 1. Communication standards. On the desktop, there may be another layer of software specialized to support interpersonal communication concerning the work at hand. A recent development, software generically re- ferred to as coordinators (Winograd and Flo- res, 1986), permits coworkers to jointly track their commitments. These systems enforce a standard framework for a conversation so that action is more likely to result. By representing working conversations, they, in effect, repre- sent (or model) the work product. While these two software systems are not currently being developed as communication standards, they suggest that the standards Ipro- cess can continue to higher levels of communi- cation function. Programming language usually brings to mind a familiar procedural language. These lan- guages, now highly developed, use a sequence of instructions to manipulate data. Seeing limi- tations in this approach, computer scientists have developed programming methods which can more clearly represent real situations. One such method is known as object-oriented programming (Booth, 1986). Classes of ob- jects can be defined which represent physical or conceptual things. This includes abstract ob- jects such as a task in a project management program, and material objects such as a me- chanical component. The programming lan- 291 guage is used to describe internal states of objects, and message generation and receipt by the objects. Some programming systems also support on-screen visual objects. Useful properties of programming objects in- clude these: (1) There is no dichotomy between instruction and data; definitions of object classes in- which are trig- received by the (2) (3) (4) elude action instructions gered when messages are object. Objects can be combined objects. t.o produce new Sub-classes of objects can be created which provide more specific features while inher- iting the properties of the original, more general class. Objects can be viewed by either specifica- tion or implementation. This allows an ob- ject to be used on a trial basis before it is complete. Object-oriented programming is mecha- nism that captures a model of the real world (Booth, 1986, p. 220). The primary reason for presenting this technique here is to introduce modeling concepts and the possibility of intui- tive manipulation of computer-based artifacts. It is important to note that this is a computer language formalism that is not a valid model for human communication. Knowledge engineering, specifically the devel- opment of expert systems, offers to represent operations knowledge in a usable form. A typi- cal expert system contains numerous, unique representations of expert knowledge. These rules describe situations and resulting deci- sions. An expert system also includes a scheme for chaining rules together in order to reason from an existing situation to a desired outcome. (See Hayes-Roth (1984) for more depth.) An integral part of most expert systems are tools that the developer/expert can use to help manage the collection of rules. Maintaining consistency and accuracy can be difficult when many rules interact. It is natural to think 0.f managing this devel- 292 opment process with the help of rules about building expert systems. Rules may describe how other types of rules are used. Different types of rule-making knowledge may be distin- guished and the development process can be made more explicit. Neches (1985) argues that this step is essential if one is to be able to ex- plain and change an expert system. In other words, for an artificial expert to be trustworthy, it must be clear how it came to lay claim to expertise. Expert systems serve to facilitate a dialog of evolving understanding among a knowledge- able community ( Winograd and Flores, 1986, p. 76). These technical systems are tools for managing communication about expertise and are not equivalent to human experts. With this in mind, an analogy can be sug- gested between expert system deveivpment and team management. In each case, there is an in- cremental integration of new knowledge into an existing framework. For the expert, system, this framework is the collection of rules. For the team, the framework is the established patterns of communications. Richer metaphors can be used to describe communication practices (independent of computer technology) and can become part of our natural language. These technical devel- opments suggest several management policies: (1) (2) (3) Working language, a complex, open sys- tem, can serve more effectively when more clearly defined and taught. Actions, recorded in a usable form, can guide future action and allow continuing refinement of methods. An explicit process of development, re- corded in a usable form, can allow easier changes to and more trust in an organization. MANAGEMENT MODELING CONCEPTS Management science often presents a model of a management situation as part of a program of action for the practitioner. A primary limi- tation of such models is that they do not share a global framework and as a result are difficult to plug in to an organization. Two authors who address these issues are considered briefly. DeMarco (1982) provides a framework for modeling software projects. Integrated models serve to represent the specification (environ- ment ) , the design (product), and the develop- ment process (project). Since software development is done on computers it is rela- tively easy to maintain these explicit models. Such models offer the possibility of using pre- viously recorded experience as components of a new effort. In other management domains, good means for maintaining models are not so readily avail- able and it is correspondingly difficult to reuse experience. In general engineering projects, modeling re- fers primarily to representation of the product. Numerous representation conventions are es- sential in complex projects, but are limited in their ability to provide complete integrated views. Media used for modeling are diverse. (1) A common model medium is human memory and shared assumptions, with re- nowned failings. (Though a lot can be accom- plished using simple, persistent slogans. ) (2) Physical analogs, such as model bridges, serve well as long as the product is primarily physical. (3) More effective are visual forms such as drawings, and diagrams, as well as written spec- ifications, precedence networks, spreadsheets, data bases, and collected memoranda. (4) For successively more complex projects, the need is apparent for a framework in which models are refined. One can envision consider- ably more powerful schemes leading to a uni- fied work representation from which team members can select views as needed. (To some extent this is accomplished in CAD systems for designing microcircuit chips. ) In any field, it is the responsibility of a team to adopt an effective work modeling scheme to help team members share work. A few team members have the responsibility for selecting 293 the work models which support the team. The teams ability to represent work (and stay on target ) grows with the successful paticipation of these team members. The focus of this paper is not on models of the environment and product. Instead, models of the project communication and team capa- bilities are of interest. So to proceed with a con- ceptual design, a graphical model for team resources used in systems projects is presented. The goal is to define a token that serves as a general representation of a team. Consider the properties of the popular tokens called money. Money serves a purpose because of its equivalence to common goods and serv- ices. Homogeneous tokens are used as currency to simplify exchange. Money is easy to use be- cause we only have to count to use it. Books, seminars, software, and professional time can be thought of as an offering of expe- rience. In the?Fe cases the goods may be under- stood in terms of a token: liner notes, brochures, and resumes. Unfortunately, the re- liability of this understanding falters as the services become complex and costly. Value of these services is context dependent and is dis- covered only as they are used. In other words, market value for one-of-a-kind system prod- ucts is undefined. What is needed is for such experience to carry with it a self-description in the form of a famil- iar resource token. Then a busy user has a handle on the situation. If tokens can be de- signed which are more descriptive, yet still iso- morphic to some degree, tokened experience can be a currency of exchange. A specific model to address this need is based on the work of Low (1976). This work gives a rich, static scheme for viewing teams and man- agement activity. It is offered here as an illus- tration, rather than a design. Any model for this purpose is inherently incomplete until it stands the test of implementation. Figures 2 and 3 show outlines for models of team and team member. For each of the six cor- responding functional aspects, there is an anal- ogy between the team and team member . Fig. 2. Team model. capabilities. These six aspects for a team are: Market need analysis or search, Development, Preparation of production resources, Production, Evaluation including finance and mea- surement, and Linking of products to the customer. Associated with this model Low applies de- sign criteria in evaluating a resource. Two of these address the internal state of the resource: simplicity and completeness. Two others ad- Fig. 3. Team member model. 294 dress the interaction of the resource to the en- vironment: fit to requirement and clarity of purpose. Used as a framework for working con- versation, such models may aid in making judgements about these criteria. Low also presents valuable perspectives on the relation between structure and process and on the role of limits in directing an enterprise. Finally, the hexagon and cube geometry sug- gests graphic representations of resources and their relations. If elaborated, such graphical ob- jects may offer a physically manipulated struc- ture which represents the capabilities of teams and their conversations. REQUIREMENTS FOR A TEAM MANAGEMENT MODEL The ultimate goal of management design is simple, clear conceptualizations which enable broadly improved joint action. With this in mind, the remainder of the paper offers the ba- sis of a framework for enhanced team communication. A representation or modeling scheme for a team is an agreement on a standard description that aids in communicating about human re- sources. The hexagon-shaped tokens may serve as a general outline for such a standard. With this in mind, several perspectives are consid- ered: (1) the view of a team in representing its capability, (2) the view of a team forming in- ternal relations, and ( 3 ) the view of an individ- ual developing workskills. The model must provide a complete, yet sim- ple, description of a team. To be complete, it must allow a team to describe all of the major functional aspects of its work. It must be simple enough so that by seeing its mode! a team can be easily recognized. This allows models to serve as a token of exchange. Similarly, a model must provide a way to rep- resent a team member. A model of a team mem- ber is a way for him to represent his capability. The person works by establishing contact with others by way of this representation. It is not a mechanical substitute for that person. In a sense, the model serves as a resume, not only in matching a person to a job role, but also in day to day offering of service within a team. Externally, the representation for a team should look like the representation for a team member as suggested by Figs. 2 and 3. In other words, the team resume and personal resume can be read with the same familiarity. If job re- quirements are then represented using the same model, a manager can direct a team by match- ing modeled expertise to modeled need. From the outside, a model of a team nlusi provide a way to represent, in a structured way, the services offered. Since we are concerned with professional work activity, another way to say this is that the model must present communi- cation patterns that the team will engage in. When implemented this model may define for- mal channels for actual communication to/ from the team. As a team forms, it is necessary to model the make up of the team from individual team members. The model must represent specific relations while supporting the standard exter- nal interface. Given this tool, team members can construct relations by defining patterns of communication. The resulting structure may then serve as a channel for communication within the team. By creating a description of a team and its commtinication patterns, effective conversation is guided, in a way similar to cre- ating and using forms or spreadsheet tem- plates. Team members can use this facility to manage their conversations and agreements. As a by-product they can capture effective pat- terns in useful form. A model must also provide a way for the team member to organize and view his capabilities. A model should prompt a team member to con- sider important aspects of the job role. And it should guide the measurement of current effec- tiveness. Finally, as a working environment, the model becomes a channel through which con- versations are conducted. AS descriptive tokens, these models are to 295 serve as building blocks in the use of productive resources. The team manager is a model builder, combining resource tokens to form teams and thereby produce systems. The modeling pro- cess, though, is not like writing computer pro- grams. Instead it can be a communication process in which a manager operates as if he were exchanging tokens, collecting a set which represents a capability to accomplish the task at hand. To make a functional modeling scheme, while maintaining the simplicity of the money ana- log, several further requirements are needed. The modeling process should apply, not only to a teams own development, but also to an- other, independent team being commissioned. Since much of the function of system products is team communication, the product and the team building the product can be mod.eled with the same methods. In other words, we are in- terested in a team that produces teams: both refinements of itself and new systems teams. Much of the communication of a systems team consists of messages about resource ca- pability. If, conceptually, all work-related con- versation seeks to match capability to need at some level, conceptually, a resource model can be extended to serve as an outline for most mes- sages. Messages to/from models of team mem- bers are tokens which represent capability and specific action. If this is accomplished, then each communi- cation act can be both a message and an act of modeling. Each message, in the form of a rec- ognizable token, is a commitment in an action conversation. As a model for future messages, it may be part of the establishment of a pattern in an action network. And as a description of part of a system, cumulatively, these messages form a model of the product, created by communicating. The relation between a resource model and a message should be direct and clear. A resource model represents the potential to address a pur- pose and grow to meet it. Messages are in- stances of this capability. Furthermore, the messages are components in the construction of a developing resource which serve to extend the framework of cooperation. Successive stages of growth are reached by conversing about re- sources and enabling these resources to func- tion well. The value of viewing teams, individuals, messages, and system components with a com- mon model lies in simplifying and integrating working conversations. All of these things are similar in that they are ideas or words of importance to system managers. In any orga- nization a special jargon develops as a short- hand for issues in the work at hand. Resource models, as suggested by the tokens, can be part of such a specialized language. The benefit of using these words is in their participation in the structure of a cooperative effort. A token may have meaning in a specialized context. At the same time it has standard handles that can relate it to those who might not need to under- stand its full capability. WORKSTATIONS TO SUPPORT MODELING TO support such concepts of management modeling, adaptive teamwork communication tools will be developed. These workstations will be more than document handling systems. They will be used more like the telephone for diverse, short messages which can be compiled and reused. Graphic software will support the type of models described above. First, a workstation might present a working environment in t.he shape of the resource model. This working environment would prompt the user to apply a well-rounded set of considera- tions to a problem at hand. At the same time, it could provide a framework for organizing de- tailed capabilities pertaining to the job. By using a recurring physical layout for work situations, the design of a working environ- ment can invoke the power of human visual memory and hand/eye coordination. Similar to current desktop operating systems which pro- 296 0 Person Workatation Screen Fig. 4. Communications modeling. vide pictures of nested file folders, the multi- level model for resources can enhance access to needed resources. Capability, in the form of models, is associated with an artificial place which is recalled by a person pointing to tokens in familiar contexts. A workstation serves as an interface between a person and a resource model that he is re- sponsible for maintaining. One can think of it as a project scope for viewing a team and its communication patterns. Software tools will provide a facility for maintaining these graph- ical representations of teams. Figure 4 illus- trates this. And, of course, the workstation must allow the team member to formulate and direct mes- sages within the network that the team has established. The workstation must also support conven- tional application software for representing physical and numerical aspects of the work. For example, CAD software allows representation of mechanical designs, or accounting software provides a financial summary of a large volume of activity. The sources and uses of the infor- mation in these programs would be managed using the communications environment. This resulting artificial working environ- ment will address these major requirements: (1) (2) It supports a view of resources, and allows resource modeling. (3) It merges the major modes of human ac- tion, conversation and eye/motor coordi- nation, for mutual support. It suggests significant job aspects to the user and promotes common measures of performance, 1 (4) It permits the use of job-specific software tools. (51 It encourages combined effort. (6) It supports participation in conversations. If realized, such systems will provide a basic apparatus supporting self-sustaining, creative growth of a team. A team will gain a broader vie-m of -work, greater interconnectivity, and better guidance toward its goals. GENERAL IMPLICATIONS These ideas are useful in todays operation. Consideration should be given to these action items: (1) (2) (3) (4) (5) (6) Create simple metaphors and instill them through consistent language and images. Teach advanced communication and mod- eling skills to all team members. Enroll each team member to comment on and record methods. Use clerical support to explicitly record project action and to measure the teams success. Design projects with internal knowledge products in mind. Encourage an on-going level of effort on these forms of organizational remember- ing and teaching. This discipline can enrich our communica- tion environments, progressively offering ex- perience for the use of new tools. A team can operate as if advanced workstations were available to all team members now. Changes of this nature will have both routin- izing and liberating aspects for the individual. Working through workstations tends to be im- personal. Furthermore, spending long periods of time in the grips of a powerful symbol system draws one out of touch with basic humanness. But rather than a big brother that dictates language rules, new tools present an opportu- nity for all to participate in the extension of language. Advent of such systems will allow a team to build its own communication environ- ment. The result will be greater clarity, respon- siveness, and satisfaction in our working lives. This conceptual work suggests much further study. This might include: (1) (2) (31 (4) Developing examples to test the usefulness of various resource tokens. Developing a formal model for resources. Conducting mathematical studies, e.g., is there an effectiveness multiplier effect in the use of integrated communication environments? Investigating possible interim standards as a way of bootstrapping. Evolution is a process of adaptation on suc- cessive levels. At this point in human develop- ment, what could be more adaptive than making language more useful? Language as we know it is a preliminary framework for dynamic, image- based action structures. Through awareness of 297 human abilities, and by design of human corn-- munication, teams can become much more ca- pable. AS this is done, people will ask larger questions, and find paths to greater integration. REFERENCE Booth, G., 1986. Object oriented programming. IEEE Trans. Software Eng., SE-12 (February): 211-221. DeMarco, T., 1982. Controlling Software Projects: Man- agement, Measurement, Estimation. Yourdon Press, New York, NY. Farowich, S., 1986. Communicating in the technical office. IEEE Spectrum, 23 (4) (April) ; 63-67. Goizueta, R., 1986. Quoted in The Atlanta Constitution, May 8. Hayes-Roth, F., 1984. The knowledge-based expert system: a tutorial. IEEE Comput., 17(9) (September): 11-28. Kaminski, M., 1986. Protocols for communicating in the factory. IEEE Spectrum, 23 (4) (April) : 56-62. Low, A., 1976. Zen and Creative Management. Anchor Press, Garden City, NY. Mintzberg, H., 1973. The Nature of Managerial Work. Harper and Row, New York, NY. Neches, R., Swartout, W.R. and Moore, J.D., 1985. En- hanced maintenance and explanation of expert systems through explicit models of their development. IEEE Trans. Software Eng., SE-11 (November): 1337-1351. Sayles, L.R. and Chandler, M.K., 1571. Managing Large Syctens: Organizations for the Future. Harper and Row, New York, NY. Silverman, B., 1983. Analogy in systems management: a theoretical inquiry. IEEE Trans. Syst., Man, Cybern., SMC-13(6) (November): 1049-1075. Winograd, T. and Flores, F., 1986. Computers and Cogni- tion. A New Foundation for Design. Ablex Publishing Corp., Norwood, NJ.