|
 |
|||||||
|
The "Peace Corps" Model of OD: A Values-Based Model for Building Collaborative Work Environments in Engineering Organizations by Randi S. Brenowitz, M.B.A. and Tracy C. Gibbons, Ph.D. This article appeared in Vision/Action, the Journal of the Bay Area OD Network, Fall 1997. Introduction It's easy to talk about values and ethics in our work when we feel encouraged to bring our values to the client. What happens, however, when the client system is built on a value base different from the OD consultant's? We are not talking about being afraid to leave your laptop in someone's office, or of unethical behavior, but rather of the work-related value system of most Silicon Valley engineers. Frequently this segment of the population engages in win-lose thinking, sees communication as expressing weakness, values isolation and individual achievement, avoids conflict, and de-values social norms without understanding (or even identifying) the consequences of that behavior. Many of our colleagues find that doing OD work with engineers can often be extremely frustrating. However, we have evolved a model that has allowed us to intervene successfully in engineering organizations. The model is derived from our many years of working with engineering and manufacturing organizations in high-technology companies. This experience has enabled us to evaluate the similarities and differences among these organization types. We have observed and contributed to fundamental shifts in the meaning of the term "team," how teams are perceived and utilized, and how best to develop teams and collaborative work environments with engineers. When
a client system is built on a set of norms and values that differ
from ours in this way, OD models and experience has taught us
to: Underlying Principles To
be successful, the model must be used in an appropriate context,
which involves four elements. These elements, which we discuss
below, reflect our values of: I. We comprehend and accept the fundamental differences between engineering work and manufacturing/process work. By definition, manufacturing and process workers have respect for the concept of process. Because of the obvious interdependencies of the components of a process, and the relative ease of cross-training and work-sharing, process workers have been using teams for a number of years. To them, the team concept is simply part of their regular work environment. In engineering organizations, however, we have found that frequently the concept of team is associated with a loss of creative freedom and individual uniqueness. In an organization where the charter is to imagine and invent, even the possibility of losing the freedom to innovate is traumatic. (Practitioners know that teams increase in innovation and creativity--but that's looking at it from our value system.) Design engineering work is not a matter of continuous improvement, but rather of creation and innovation, leading to technological and conceptual paradigm shifts. This type of work does not easily lend itself to cross-training or pay-for-knowledge reward systems that are typical within team-based process organizations. The length of feedback loops in engineering organizations is much longer than those in manufacturing organizations. On an engineering project, it may take years before one knows if the customer or the marketplace thinks positively about the product. This is in contrast to "quality control" or "internal inspection" in manufacturing organizations, where feedback may be received in a matter of hours or days. Traditionally, engineers were trained to be independent workers. They are often frustrated that today's technology and market demands impose structural constraints on their work environments. They generally prefer being measured on individual uniqueness and heroics, not on collaboration and team behavior. II. Working with intact teams (to the extent possible) will increase the effectiveness of the model. This shows our interest in helping them with "real-world" situations rather than abstract classroom exercises or perfectly constructed cases. It encourages them to believe that our work is relevant to their situation. Once we have a few early adopters, working with the intact team helps create peer expectations and support for the new behavior. III. We engage team members in the process. We do not come in to an organization with a complete plan for how everything will be. We come, instead, with a working plan and a desire for the rest to evolve. Engaging the team members in this evolution increases buy-in and allows us to make the necessary modifications to our plans. IV. We integrate team development with the core business. Through this methodology, teams become the way the core work is done rather than management's "flavor of the month" or something to be done only when management is looking. We learn about the core business and their current concerns--not to be sympathetic or popular, but to know enough to be genuinely helpful. Yes, sometimes this requires learning about things we didn't intend (or desire) to learn about. This is part of our cost (and benefit) of offering a higher quality product. The Model In
our effort to articulate what enables us to be successful working
with this population, we created what we now call the "Peace
Corps Model of OD." This model bridges the contrast between
the value set of the client system and the OD practitioner by: Peace Corps workers live with the indigenous population learning the local language, customs, and culture. We have had to become experts in the language and culture of intuitive, analytical personality types. We "live" with intact, cross-functional, and cross-organizational teams by attending their meetings according to their time schedules. We also participate in quasi-work events, such as birthday lunches and team celebrations, and we learn about supposedly non-work issues such as people's hobbies, passions, and pet peeves. This enhances our credibility as we encourage new forms of behavior. Peace Corps workers are asked to respect the accomplishments of the natives and to bring only those tools that can be useful to the population. OD consultants working with engineers must recognize the difficulty of what today's corporations are asking of their engineering organizations. It is easy for those of us working in and around Silicon Valley to become complacent about computer technology. A healthy respect (perhaps even admiration) for the work being done by these engineers is necessary if we are to work with them in a collaborative way. Just as no Peace Corps worker would bring a fax machine to a village that lacked electricity, as consultants we must resist the temptation to bring a client the newest state-of-the-art OD intervention simply because we are eager to use this new tool. The appropriate foundation work must be done before any new technique is introduced, always respecting the organization's current practices. Each intervention must be modified to meet the specific needs of that particular group. Off-the-shelf solutions are suspect in a community of inventive technologists. It is imperative that Peace Corps workers maintain their own core values. Although we suggest constant modification of our processes and our behavior, we recognize the importance of maintaining the integrity of the intervention. We must always "walk the talk," remembering that we are dealing with a population trained to find flaws in systems. Engineers are often willing to work with us to fix the bugs in our process, but if they find an integrity problem, they will define the whole intervention as fraudulent. Peace Corps workers must acknowledge how difficult change is and continuously support and coach the natives while reinforcing the new behavior. When OD consultants work with engineering organizations, we must do our work in such a way, however, that the population does not feel patronized. We must remember that we are on their turf. If we pay enough attention to this factor in the model, we may even learn something new about change from our clients. We contrast the Peace Corps model with that of historical Missionaries and Crusaders, who scorned local beliefs, felt superior to the natives, abrasively replaced local customs, and pursued their own agenda (to conquer or convert). The subtle but important distinctions between Peace Corps workers and Missionaries and Crusaders are easily noticed by engineers. While retaining a healthy amount of cynicism, they are willing to work with and respect the ideas of the Peace Corps--but they are, justifiably, ever-vigilant against Missionaries and Crusaders. The Danger The danger in using the Peace Corps Model of OD is the risk of "going native" or colluding with the client. It is possible to become so involved in the local values and customs that you no longer bring a new perspective. Although we strive for understanding and valuing the engineering culture, we cannot start making excuses for anti-social behavior nor should we collude with dysfunctional parts of the culture. You may be in danger of "going native" if you find yourself: *
believing that starting or ending meetings late is not a problem
|
||||||||
|
||||||||
