In the 1970s and 1980s, Digital Equipment Corporation was a successful, thriving computer manufacturer, second only to industry giant IBM. The company’s networking business, which was solving customer problems with leadership technologies such as Ethernet and DECnet™, was also very profitable. But by the late ’80s, the company had become complacent and unfocused, hiring and growing in all directions. In the Networks and Communications group (NaC), signs of trouble were already evident. Small competitors were beginning to carve out niches for themselves with products that were faster, cheaper, and quicker to market. As a result, we began experiencing problems in our ability to deliver products predictably and with the quality customers demanded.

Recognizing this challenge, we began to streamline our product definition, design, and development processes. Our group vice president, Bill Johnson, instituted a formal process to review key projects and programs. While solving project issues did result in improved quality and quicker time-to-market, the data gathered in this phase gave us an indication that we were facing much deeper issues. We began to see that our problems were linked to long-term dynamics such as changing customer demands and the increasing complexity of our business environment, which would require a different approach than we had used in the past.

This was the start of a long journey for our group. Our path took many turns as we met new challenges and discovered new resources along the way, uncovering deeper and deeper levels of obstacles to our business success. The process involved people with varied roles who were willing to work together to try new approaches, learn from their mistakes, and try again. Our story will hopefully offer some guidelines for others in the middle of a similar discovery process (see “The Journey: Going Deeper into Causes”).

A Systems Approach

The first phase of our journey was to address the immediate issues of customer satisfaction and quality. Customers were moving away from Digital proprietary computing environments, and were more often demanding multi-vendor “system solutions” — families of products that worked together to solve their business problems. As one key customer said, “We want to choose the best solutions regardless of who makes it. And we want everything to work together just as if it came from a single vendor.”

To meet this need, we began experimenting with a systems approach to product design and delivery, which meant paying as much attention to the relationship between products as to the products themselves. This approach caused us to focus in a more disciplined and structured manner on actual market and customer requirements, forcing us to surface our assumptions about trends in the marketplace, the industry, the technologies, the customer, and the competitive environments.

For example, we evolved a simple but powerful process called “Customer-Based Requirements Dialogue.” Rather than beginning with the question, “What product should we build?” we began by exploring our marketplace and customer environment assumptions. Only after we had acknowledged and explicitly surfaced our assumptions did we begin talking about the market requirements: the problems we were trying to solve and the opportunities we were addressing. Finally, we defined the specifications for the system and the features for each component product. We found this new process difficult because we were more used to prescribing solutions than describing the marketplace and customer environment in which the products would be used. Although these descriptions were about future states, which meant that most of them were educated guesses, this process proved to be more effective and efficient than our traditional methods.

Our systems approach also required us to work more actively across functional and hierarchical boundaries within the networks group, because it became increasingly clear that the answers we needed were located throughout the organization, not just at the top or in one area. We began to consciously open up our decision-making processes to include diagonal slices of the organization. We also made necessary job changes to meet the needs of our new approach, creating new roles such as systems technical leadership, systems business management, and systems project leadership. These changes addressed the need to manage the relationships between products, people, projects, and processes.

Focusing on the system also forced us to reevaluate our relationships with other companies. We acknowledged that if we were moving toward open solutions in response to the customer’s changing demands, then cross-company collaboration was required. An early result was that long-time competitor Apollo Computer (now Hewlett-Packard) became a new partner in the design and development of products.

From Systems Engineering to Systems Thinking

As we continued with our fledgling attempts at a “systems” approach to solving customer problems, we discovered two important books that helped bring clarity and structure to our efforts. The first was Peter Checkland’s Systems Thinking, Systems Practice, which clearly articulated our uphill struggle as we moved from “component thinking” to “systems thinking.”

Checkland writes, “Rene Descartes taught Western civilization that the thing to do with complexity was to break it up into component parts and tackle them separately…. Systems thinking, however, starts from noticing the unquestioned Cartesian assumption.., that a component part is the same when separated out as it is when part of a whole…. The Cartesian legacy provides us with an unnoticed frame-work — a set of intellectual pigeon-holes — into which we place the new knowledge we acquire. Systems thinking does not drop into its pigeon-hole, it changes the shape and structure of the whole framework of pigeon-holes. This questioning of previously unnoticed assumptions can be painful, and many people resist it energetically.”

With this new understanding, we renamed what we had been calling “Systems Engineering” and began calling it “Systems Thinking.” This new term reflected our recognition that we had to apply a systems thinking approach to all aspects of the way we did business, not just engineering. As a result, we developed a brief, 20-question guideline for people to use to begin applying systems thinking to any problem or situation they were facing. We also developed a systems thinking work-shop to meet requests for this type of work in other parts of the company. One such seminar was delivered regularly at a management development program, which reached hundreds of middle managers and technical leaders worldwide.

Then, in late 1990, we discovered Peter Senge’s The Fifth Discipline: The Art and Practice of the Learning Organization. This wonderful book made sense out of the experiences of the preceding three years, and gave us a clear set of constructs, language, and guidelines to bolster our efforts. Now we knew we were not in this alone — there was plenty of help and knowledge available that was based on a vast body of research and practice.

Servant Leadership and Decision Making

As we improved our ability to deliver at the product level, it became clearer that we needed to gain clarity at the larger “umbrella” level of shared vision. In order to do this, we needed to explore our individual “mental models”— our internal assumptions and beliefs about the way the world works — and come to some shared understanding of the larger issues we were facing. Therefore, in the early spring of 1991, we began looking for ways to surface, examine, and systematically break through our mental models of the marketplace and industry trends.

We began with a process called “FutureMapping,” a scenario planning methodology brought to us by North-east Consulting Resources Inc. of Boston. Through this process, we developed scenarios that described industry, competitive, and product trends from the present through 1997. Over the course of the next 15 months, we held one-day working sessions that engaged over 350 key people across the group in a modified version of this process. The key benefit was that we were forced to explicitly describe our industry, market, competitive, and customer “systems,” and to identify and monitor those five or six critical assumptions that represented “forks in the road”—decision points where we had to make tough choices.

As we did this work, it became clearer that the most difficult points for us in all of these new systems processes were the points of decision making. Working with teams that crossed functions, groups, hierarchies, and companies, it was often difficult to establish clear leadership roles and points of decision-making accountability. In addition, every manager, engineer, project leader, and technical leader had to balance the need for rapid execution and delivery against the desire to stay open to new information. It was all too easy to flip to one extreme or the other — to go for consensus and remain in dialogue forever, or to make quick decisions in an authoritarian manner. Our core challenge was (and still is) to manage this balance, and learn how to live productively within this dilemma.

To address the challenge of making decisions among diverse groups of people, we embarked upon some experiments with new leadership styles. With help from Robert Greenleaf’s book, Servant Leadership, we began moving toward developing “servant leaders”— or as Peter Senge puts it, leaders whose job is not so much to have the answer, but to instill confidence in those around them so that together they will come up with the answer at the time it is needed. We received some very positive feedback from this work — leaders told us they now found it easier to make decisions and that product development moved forward more quickly. But we also learned that the decisions were only as good as the information that was placed “on the table.”

Facing Undiscussables

It seemed that the next challenge we faced was how to bring more data to the table — including those issues that people did not feel comfortable raising. So, we embarked on a series of carefully designed and facilitated dialogues between senior management and several hundred engineers, technical writers, project leaders, and supervisors to discuss the obstacles we faced in quality and time-to-market. These meetings began to surface some of the difficult issues people found hard to raise because they felt “unsafe.” Harvard Professor Chris Argyris calls these unsurfaced issues the “undiscussables” that prevent real learning in organizations. Using the framework presented in his book Overcoming Organizational Defenses, we began to acknowledge the presence of “undiscussables,” but were left with the dilemma of how to raise and resolve them productively.

Change and Upheaval

At the same time that we were facing the challenge of how to deal effectively with “undiscussables,” a major change took place in the company as a whole. In October of 1992, Digital founder and CEO Ken Olsen was succeeded by Robert Palmer. This transition heralded two years of massive downsizing and almost continuous restructuring within the company. At that point, Digital as a whole was losing approximately $3 million per day, and had absorbed more than $3 billion in losses over the previous three years.

The immediate impact on NaC was that it merged with other networking entities under a new vice president, and continued to be reorganized and reshaped into many forms. As a result, people felt very insecure, morale plummeted, and attrition rose. It was simply not the time to begin the difficult and soul-searching work of connecting at the level of integrity, honesty, and respect espoused by Chris Argyris. Although we knew how important this work was for our long-term success, we just couldn’t begin it, given the constant instability and growing state of anxiety within the group. It was challenging enough just to continue to design, develop, and deliver products and systems. So what next? As with many of the breakthroughs we had in the past, the answer was close at hand.

Bringing in the “People”

Aspect In June of 1992, I presented at a conference on organizational learning, where 1 met Sandra Seagal and David Home. Their work, Human Dynamics™, offers a framework for understanding differences in the way we learn, communicate, relate, and develop as human beings. With support and funding from John Adams, now vice president and technical director of Networks Integration Software, I attended a five-day training course in Human Dynamics and became convinced that this was the missing piece that could move our work forward. Human Dynamics offered a systemic approach to the complexities and wonders of human functioning that was clear, logical, and structured, yet broad and flexible enough to encompass the infinite nuances that make us each unique human beings (for more on the Human Dynamics methodology, see “Human Dynamics: A Foundation for the Learning Organization,” May 1994).

Back in the Networks Group, we saw Human Dynamics as the technology that would enable us to rebuild the trust, safety, and empowerment we knew was desperately needed. Over the next two years, almost 500 people across the company received training in Human Dynamics. Much of this was accomplished under the auspices of the Engineering Excellence Program led by Corporate Consulting Engineer Peter Conklin. Human Dynamics was seen as a foundational technology that would enhance our ability to make the changes needed in our engineering processes. We also began to dovetail Human Dynamics with Human Systems Change, a technology from Options Consulting, Inc. (Reading, MA) that was helping us create a systemic language for the human/cultural side of change so that we could name and over-come perceived resistance.

As with the efforts of the preceding seven years, we have had some good results from our application of Human Dynamics. While it is difficult to measure them quantitatively, there are many anecdotal accounts of improved efficiency and effectiveness in interpersonal communication and team productivity. As with many new technologies, our challenge now is making this practice part of our everyday way of doing business.

Valuing the Relationships

Despite the difficulties in Digital as a whole over the seven years of this story, our portfolio of networking products has continued to be profitable. While we cannot prove a direct connection between our ongoing efforts and our continued profitability, it is clear that it was a contributing factor.

As a networking group, we have learned that relationships are equally important as products — after all, connectivity is the essence of our business. In fact, we are beginning to believe that a root cause of many of our business problems lies in the breakdown of personal relationships. Although our first inclination in business is to blame profitability problems on poorly executed strategy or a lack of management skills, we believe that the cause may well be the absence, avoidance, or breakdown of authentic connection and communication between human beings.

Peter Block puts it very well in his 1994 book Stewardship: “Money is a symptom, money is never the real issue…. An economic crisis for any organization means it is failing in its market-place. In some fundamental way it is unable to serve its customers. And if it is unable to serve its customers, it means it has failed to serve its own internal people.” We have learned that serving the most basic needs of our people — to connect, communicate, and grow in a supportive environment — does indeed produce a profitable business.

Our seven-year journey has brought us far in our ability to learn and work together in more effective ways. In some sense, we have worked “back to front.” If we were to start over again, we would without a doubt begin with the fundamental technology of Human Dynamics and proceed from there. We would then know that we were building on the most solid foundation there is—people who are aware of themselves as fully empowered human systems, learning and growing, and consciously nurturing themselves and each other in order to produce the results they most desire.

Chris Strutt holds the title of Consulting Engineer. Systems Thinking Methods, In the Network Integration Software Segment of Digital Equipment Corporation.

In a future Issue, Chris Strutt will discuss In more detail the application of Human Dynamics technology at Digital. Editorial support for this article was pro-vided by Kellie T. Wardman.