Theme 1: Hard results, soft concerns
When the Program Manager was appointed as manager of the Epsilon program, his ambition was to develop an excellent vehicle and a process which valued and inspired people on the team. This section describes the challenge facing Epsilon: To achieve "hard" results (producing high-quality technical parts, sub-assemblies, and a complete vehicle efficiently) through an emphasis on concepts that many people termed "soft" (good communication, openness, honesty and trust.)Learning in the core team (Jan. 1992 - Sept. 1992)
The core "learning" team began with an awareness that they faced "real internal conflicts." The Epsilon program was unofficially expected to be a "Lexus-fighter at the price of an [American luxury car]," although as a front-wheel drive car with its planned variable costs, it would be difficult to compete with the Lexus.The core team members all felt a high level of frustration, and a sense of urgency, since the program was already late. They recognized the dilemma of being a pilot learning project; they could already see that their effort might mean "taking on" AutoCo's overarching culture. This culture included a strong reliance on hierarchy and functional authority -- an expectation that the boss is on top of technical details and makes decisions. On top of that, the core team members had difficulty communicating with each other. "I couldn't talk to [the Finance Manager] at first," the Program Manager noted, "in less than a high-decibel range."
At the beginning of 1992, the core team met every one or two months, working with a variety of communication and conceptualization techniques such as the ladder of inference, the left-hand column, role-playing, and system mapping (see systems archetypes and "ladder of inference" and "left-hand column" sidebars on these pages). Their ability to communicate improved, and they began to focus in on their most serious problems.
To give them a broader perspective, several members of the core team interviewed a dozen people from the rest of the Epsilon project, asking: What did people feel their greatest challenges and strengths to be? The team returned for a working session in March of 1992, ready to pick two or three problems and start fixing them immediately.
The lead MIT Researcher reported his impressions of the team: bright people, burdened with frustration and puzzlement but not resignation. The interpersonal dynamics typical in a product development environment were evident in this program.
| The comments of the researcher were typical of the ways managers from different functional areas talked about and reacted to one another in AutoCo. | Researcher: The participants had locked horns and couldn't get anywhere. [The Launch Manager] told me much later in the process that [the Program Manager] was ready to hang it up after a few months. But he saw enough value to keep him going. In one critical incident, early in the sessions, we used a ladder of inference and left-hand/right-hand column exercise to begin to look at the ways in which finance and program management couldn't communicate. |
|
Using tools to understand one another's positions allowed people from
different
functional backgrounds to work together more productively.
The Learning Organization work assumed that openness of communications, and the willingness to address assumptions, would lead to workplace efficiencies and effectiveness. How valid is this assumption? |
The exercises opened things up so that they could really look at their
assumptions.
Program management revealed how they assumed that the finance people "want to
hold us to [American automobile] costs." Essentially, program management
thought that finance didn't have a clue (and didn't care) about what it took
to build a car. "They just want to meet the numbers."
The finance people showed their assumptions about the program managers: "These program guys don't care about costs. They don't want to work to get to the kind of car that we said we were going to do. They won't control costs." |
| If people could see issues from one another's perspectives
would it allow them to work better together? A sound logical argument was necessary to convince the team to apply the tools in the service of improving their abilities to work together. |
I said, "Look, we're here to do something different from the way you continually do things." Instead of having a normal "let's-solve-it" style consulting project, I suggested that we "try to understand our own assessments of the problem. We are blind to the limitations of our assessments, and thus we can never see what is really happening. Yet we design solutions based on our own individual assessments." The core team members understood that argument, and went along with another round of experimentation. |
|
Tools from Total Quality Management were used. A learning tool is one which
people share with one another to work more effectively together. Learning tools
are spread freely to create shared insights, not used by one person to gain an
understanding which he or she uses to manipulate or change others.
See affinity diagram sidebar. The "KJ diagram" combines the intellectual-rational thought process with intuitive-emotional feeling data. It is generally used to process a group's own thoughts and observations; here, they used it to make sense of their interviews. | I had them break up into two groups (because there were so many of us) and each group did a "K.J." We used the technique to sort through the information gathered from inter-viewing Epsilon team members. "Listen to what you think people are trying to say," I said. "Get away from thinking only rationally about the comments. How do they feel to you?" We went through a "scrubbing" process [rewriting the statements to be clear], then grouped them intuitively. This is usually a very frustrating and bewildering process, especially for an engineering or action-oriented group, because everything is interconnected and diffuse. |
| The K.J. diagram incorporates multiple people and multiple perspectives and appeared to have brought to the surface an interrelated and interdependent set of problems. | Our theme question was, "What is the biggest weakness with our product development process?" And the overarching answer that emerged had to do with lack of trust and openness. This was unspoken before this point, and I think it wouldn't have been captured otherwise. |
| The researcher focused on problem articulation rather than problem solution (see Sidebar: Problem solutions, versus problem articulation). | Now they couldn't accuse me of "making them" pay attention to this
trust issue. They had seen firsthand, how it was at the core of their own
problems.
This incident made a lasting impression on [the Program Manager], and changed the dynamics of the relationship with Finance, which was very important. |
| Are these three key issues important on any product launch? Are they endemic to the product development process? Do they stem from AutoCo culture? Are they worth taking time to deal with? |
Program Manager: There were really only a few core issues. The rest of the
problems all generated from those.
|
The system map (Learning Team Meeting, August, 1992)
Now the "core learning team" engaged in a "systems mapping" process, to connect
the concerns of trust and openness that had surfaced in the K.J. diagram with
other symptoms in product development, such as the chronic critical problem of
late parts.
|
See the core team's view of "parts behind
schedule."
Focusing on one key problem -- in this case lateness of parts -- again showed the interrelatedness and interdependencies of all the problems facing the team. |
Program Manager: We weren't sure what to do next. We didn't know how to "change" fear or mistrust. So we started to look at a key problem: Why we were always late. No matter what we did, no matter how we approached the problem, parts were chronically behind schedule. We began to share our views about why. Over the course of a day, we built up a diagram of the system. |
| The K.J. and causal loop diagrams appear to have not only influenced how people thought about the problems, but also their perception of problem symptoms. | When one engineer changes parts, that part usually affects somebody else. The "A" engineers can't start part of their work until the "B" engineers solve their problem. Parts get late. This leads to pressure to get back on schedule, so we compress the supplier time. But then something else would become late, because we would be putting all our resources on the part that was late. When parts get so late that we can't recover, we revise the build schedule. Then people feel they have more time, so more parts get late. Worse still, the next time you have a build, people will assume you're just going to revise the schedule again, so they don't even try to meet the dates. |
|
How can a team effectively build a group understanding of a systemic issue,
so all members "own" that understanding?
This story of the finance manager's role was often repeated to illustrate how the system dynamics work is valuable to a cross-functional team. Finance people typically don't get involved in engineering change processes; here, that involvement helped build a deeper understanding of systemic issues. The researchers proposed that a shared image of the system would allow people to operate in a coordinated fashion. The hierarchical and autocratic management culture at AutoCo reinforced the engineering culture to limit discussions of problems until there were known solutions. |
We eventually got all this into a complex chart. We all understood the whole
system as it related to us, and we had all contributed to this map.
The map became critical. And the person who pointed out the key leverage point wasn't an engineer, a development manager, or a planning manager. It was the finance manager. She pointed out that just before the "reporting of lateness," there's usually a delay. The reason for the delay is: people are afraid to be criticized. There is a basic cultural commandment in engineering -- don't tell someone you have a problem unless you have the solution. You're supposed to solve it -- and then tell them. But during that delay, nobody knows about the problem, and nobody can react. That delay automatically compounds delays in other loops going on through the system. |
| The systems map was described by most people as enormously useful. When a group "sees the same picture, and comes to the same conclusion," is it the visual (like the system map) that helps them focus on issues systematically? Or is it the conceptual link? | Program Manager: We all saw the same picture, and we all came
to the same conclusion: This was a leverage point for us. We began to look
at how we could structure the project to ease that delay, and we concluded
that our real leverage was in improving the communication process,
improving honesty, and improving trust.
We had begun to build these in the core team, but they didn't exist between the functional groups in the rest of the team. But we knew that building trust was possible, because, after all, if we hadn't shared our views of the system honestly, we would never have gotten to this point. |
| Another factor accelerating the decision to promote open communication was the increasing complexity of automotive technology, particularly with fast-changing subsystems such as the electrical system. The better the team became at working together, the better it would deal with intricate components which cut across two or more functional roles. | Program Manager: Only a small [percentage] of the members of the team actually worked for me, where I could promote them and give them their performance reviews. Most of them worked for other functional organizations -- finance, assembly, body engineering, climate control, plastics. If I just pulled the team together the normal way I would get what we always get. People would protect the objectives of their organization. They would work on the product, but their organization would come first. My greatest leverage was to make them view the other members of the team as people with whom they had a personal relationship. If I could make them feel that they depended on each other, and that they wanted to help each other as people, that would counterbalance the material reward from their functional organization. |
| Was the statement that "we don't know how to make open communication work" a barrier which kept people from believing in the possibility of open communication? | We had been talking about open, honest communication around this company for as long as I've been here and I've been here 29 years now. We don't know how to do it. This was the first time I thought it might really work. |
The transition to openness
Converting to an atmosphere of honesty and trust was an ongoing process, with
many setbacks, continuing throughout the forty-two month program.
|
A premise of the learning organization is that the boss isn't the one with
the answers. Bosses are teachers and coaches who help others learn and apply
their learning.
What model of teachers are they using? Teachers of children? Or, teachers of adults? Manager's prerogative is typically that of being the decision-maker. Making those decisions was thought of as creating a codependency between manager and employee -- employees look to managers for decisions and managers expect they make the decisions. To the Program Manager and the Launch Manager, "empowerment" meant the recognition that engineers (and others on the team) needed to make decisions and feel responsible for those decisions. The launch manager saw the group's behavior as "dysfunctional." But how "functional" was it within the context of the larger AutoCo culture? |
Launch Manager: In one of our earliest design reviews in February, 1991, folks
were standing around saying, "What do you want us to do?"
I said, "Wait a second. You're the engineer. What do you think is the right thing to do for the customer and for the company? What is your recommendation?" They couldn't answer that question. I realized then that this team needed a lot of help. They were accustomed to putting all the alternatives together and the planning manager or Program Manager would decide. I knew I had the prerogative, based on my experience and knowledge, to tell people what should be done. But I told them I would reserve that prerogative for when I was willing to challenge them. I didn't want to make decisions that they should be making. I realized over a period of time, that AutoCo wanted to "empower" its teams, but on this team, people didn't feel empowered to do anything. That was our first realization that this was a dysfunctional group, probably very typical of most groups. |
| Involving people in making decisions implies that leaders make their reasoning process explicit or, as in this case, justify it as "reasonable." | Content leader: Every once in a while we bosses have to grit our teeth and swallow a decision that the team made, even if we personally think, "Well I'd rather not go on that path." If their thinking is reasonable enough, and they haven't missed any obvious issues, then my objection is just a matter of: "I would go the other way." |
|
The behaviors associated with letting people make their own decisions can
appear messy to outsiders -- not the calm where a boss calls the shots and
all the action occurs below the surface.
|
Launch Manager: A new project manager, after sitting on a very typical
discussion,
ran up to one of my team leaders and said, "My God, your program is a
disaster. You're not going to make it."
The team leader said, "No, this is the way we always talk. Everything that we know is thrown on the table. We thrash about, and issues sound a lot worse than they really are. This is our way of sharing what's going on." The project manager said, "You've got to be kidding me. If anybody had said anything remotely like that on [my previous program], he would've been killed. Problems would have to reach a level of disaster before people would ever talk candidly." |
| Engineer: Every day someone comes in and says, "That was a really stupid thing you said in that meeting the other day. We all talked about it and we think this..." I may say, "Yeah, you guys are right," or maybe I don't agree. But at least nobody has any problem coming in and saying, "I don't agree with what you said," or "Other people think this," or "You didn't think about that." And it helps. | |
| These comments are typical of the remarks made by engineers about trust and openness; they were gathered throughout the stages of the car project. | Engineer: When an engineer goes on vacation we cover for him. We all work as one, which I think would be pretty unusual in most other jobs. |
| Engineer: You don't hear dialog like, "People from body engineering are dragging their feet," or "Those hard noses from Assembly." We got that out of the way up front. Now we can get together and do the job. |
Creating the atmosphere of trust and cooperation
Based on interview data, the following factors appear to be important in
creating an atmosphere which leads to trust and cooperation. These factors
related to behaviors which the core team sought to practice throughout the
program. Each point is described and illustrated in a section which follows.
- A mandate that "bearing bad tidings" would be safe;
- Ongoing sharing of information and perspective;
- A culture of greater inclusiveness;
- Deliberate encouragement of informality and friendship;
- A mindset that "no one has all the answers."
- Leaders who modeled the desired behavior;
- The conversational tools of the learning lab;
- Collocation*.
A mandate that "bearing bad tidings" would be safe
The Epsilon leaders had to start by mandating that there would be no punishment
for candor, bringing in bad news, or raising uncomfortable questions.
|
How does a team effectively change its culture from one that expects
everyone to "have the answers" to one that encourages people to experiment
and raise issues before the answers are certain?
This comment was one of many illustrating how engineers came up with and contributed new ideas because they felt they would be heard. |
Content leader: If people know that they're not going to get punished
(for taking risks), they'll try harder. We had all kinds of ideas coming out
of the woodwork that people had been keeping in their hip pockets. The net
we use for umbrella storage was an idea of one of the engineers.
Engineers [on other projects] don't generate ideas like that; they wait for you to tell them what to do, so if it screws up they can say it wasn't their idea. |
|
Does admitting that as the boss you don't know the answers help?
If the boss doesn't know an answer, how would that evaluation affect the engineers? |
Team leader: [The Program Manager] always gave us a strong feeling that he wouldn't treat you like you were an idiot if you didn't know the answer. Or if you came to him for help, he would try to help. |
Ongoing sharing of information and perspective
Taking the time to share information from different aspects of the development process with a broad range of people appears to have created greater awareness of program issues as a whole. Efforts were made for people to become aware of everyone's role in light of the overall program goals.
| One of the questions the managers considered was whether taking the time to share information broadly could be made up by people working more effectively together? | Finance Manager: We had a better understanding of why each of us does what we do. This understanding was helpful in the long term, because it gave us a base of trust and understanding. I think it started to reduce people's sensitivities a little bit. You understand why something happened. If it wasn't necessarily what you liked to happen, at least you understood why. |
| Could managers sharing more openly result in others sharing their information more openly, countering a larger cultural tendency to hide problems? | Internal consultant: When a supplier has a good relationship with the engineers, the supplier will say things like [for example], "You didn't hear it from me, but something is going to be late and somebody's lying to you. Don't tell anyone I told you." |
A culture of greater inclusiveness
Including people, not just on the basis of who needs to know to do their job,
appears to have created an atmosphere where people were more aware of the whole
of what they were trying to achieve.
|
Team work was a much talked about concept at AutoCo. However, there were no
common standards or definitions of team work, and it was often managers promoting
their management style that led to contests over who had created effective teams.
|
Content leader: I think if you talk to any [Epsilon team member], they'll
say, "Oh yeah, we've got fantastic team work." Well, every program's got
team work.
On this program, [the Program Manager] provided a strong network for team work. He allowed it to happen easily. It's more than just collocation or expertise. For instance, take the EP prototype build; chassis engineering was given credit for having 100% of their parts there, and that was the first time something like that has been accomplished. And that says a lot about the strength of the engineering community as well as others who helped with that endeavor. It's like every day you're putting on your Epsilon suit and you're going in there and you're going to make a difference. [The Program Manager] made the program very, very inclusive. He was adamant about having suppliers in there for [internal prototype meetings]. The meetings up front were pretty boring but Epsilon seemed to achieve their success because of the meetings. |
Deliberate
encouragement of informality and friendship
Some attributed the quality of the Epsilon team process (at least through first
production prototype [1PP]) to collocation. Some attributed it to the people
who had been chosen for the team, and the quality of the engineers. Others
argued that the team appointment process was random; indeed, Epsilon probably
didn't get the "best" engineers, who would have gone to a higher-visibility
product like
Theta [1] or Sigma. No matter the cause, there was
an atmosphere of informality and friendliness which promoted good working
relationships among team members. Managers invested in and sought to actively
encourage the development of a climate which allowed people to work more
informally with one another.
|
Off site meetings where people were in residence were typically frowned
upon at AutoCo because of cost implications.
The time and effort the core team put into developing relationship and open communication was not valued by all team members. |
Engineer: There was a three-day off-site [Oct. 1991], where you basically had to walk away from your desk, designs and drawings. A lot of the team thought it was a waste of time; I think a lot of people walked away still not exactly sure what [the Launch Manager] and [the Program Manager] were trying to do. To me, the most critical thing that happened there was it really glued the team together. It was the first time everybody looked around and really realized they were all in this boat together, and it was powerful. |
|
How important is it to develop a focus on the personal as well as the
professional relationship?
|
Some of the dynamics and camaraderie and friendship came from living together at the hotel for three days, eating together, working together, and going and having a beer together. There's something about friendship outside of the work place that I think really helps build trust. If you met new people and had a beer with them or whatever, then two months later if you had a problem with an issue on the job you felt a little bit more comfortable approaching them. And I think it's human nature that if you get an opportunity to know a little bit more about a person's family and their interests outside of work, you trust them more than a total stranger. At the off-site we started talking about visions, and what the car was going to be, and everybody's roles and I think it created the bond. It was a reality check: This group of people was going to build this car and either make it a success or not. |
A mindset that "no one has all the answers"
The managers told people that they didn't know. They needed to learn too, and
they needed to create the conditions where their teams could learn. This
statement supporting "not knowing," ran counter to the expectations most
managers and engineers held -- of one another, their system, and themselves.
| How can business culture learn to acknowledge and accept mistakes in a constructive way? |
Vehicle development team leader: This was foreign to a certain degree; it
was uncomfortable that the boss was learning with us. He didn't have the
answers. We were going to do this together. As uncomfortable as it was
on one hand, it was exciting on the other, because all of a sudden we
felt like we were paving new ground. We weren't just being fed "the
right thing to do in a corporate environment today."
Some of the appeal may have to do with the word "failure." If you stumbled, it wasn't perceived by [the Program Manager] as a failure. Instead, the reaction was: "It was a good honest effort, I appreciate your energies, and what have we learned from this?" |
Behavioral versus technical: a zero-sum game?
As the Epsilon program developed, the core team placed strong emphasis on what
they called "process" issues --explicitly learning how to improve human
communication skills, decision making methods, and understanding of each
others' points of view. This emphasis on behavioral considerations--people and
process--was neither familiar nor well understood in AutoCo, which has a
heritage of strong technical and engineering achievement. In the larger company
culture, most people felt that time was scarce and thus needed to be invested,
as much as possible, in technology and engineering.
These thoughts about time were based on an implicit assumption that behavioral and technical skills were caught in a zero-sum game; one could only be improved at the expense of the other. In contrast, the Epsilon team leaders believed that a well-designed learning process would result in engineering and people skills reinforcing each other. Technological capabilities could be more easily applied, and have greater impact, as engineers' people skills improved and they developed the capacity to handle systemic and interrelated issues.
|
Does the AutoCo culture hold an assumption that developing process knowledge
and understanding among people detracts from engineering knowledge and
technical achievement?
The comments here were echoed by many people at AutoCo: "First handle the technical and then, if you have time left, you can work on the behavioral." Do "process people" sometimes assume that their work is denigrated by the larger culture, when in fact it is not?
Is there an assumption that resolving the tradeoff between technical and behavioral needs would extend a manager's work beyond the hours available in a day? |
Vice President: The first thing we have to do is make sure that people really
understand the engineering processes -- DVP&R, QOS, prototype process,
change control, the timing discipline, and so forth. If you asked me,
"Do I do that before I do any teamwork and team building?" -- the answer
would be an unequivocal yes. I think if you don't have a fundamentally
strong engineering framework, then no amount of team building or team
process will ever overcome that weak system. You'll fail. The team will
thrash about with all kinds of good intentions.
Now, the converse, I guess, is -- assuming you have a fundamentally solid engineering process -- that as you encounter difficulties or fall behind in one area, team building and the human side of teamwork come into play. A team can rally, help each other overcome difficulties and move on. As I understand organizational learning, it preaches an appreciation for the other person's point of view. If you, as a team person, understand that your action or non-action causes another person a problem, then you will try hard to make that not happen. That understanding comes from team building experiences. The team is a very large family that's working together. How you measure that understanding, I don't know. Program Manager's Boss: I could tell that the Vice President was really interested in getting this car program implemented. I think there were times when he was concerned that the team was spending too much time on the soft stuff and that could get in the way of hard results. I have been very supportive of this work, but at the same time continued to stress to [the Program Manager] that he had to get results. |
The dilemma of integrating process and engineering knowledge
Despite the team leaders' intentions to have process knowledge and engineering knowledge reinforce each other, the synthesis was imperfect in practice. In at least one case, there were complaints that the engineering knowledge was short-changed. This had to do with the team's change of structure -- bringing engineering and process authority together, assigned to one group of people -- without looking closely at the assumptions that these people would hold about one another.
| Not all engineers felt included. The fact that Launch and Program Managers were not engineers meant that they didn't jump into difficult engineering problems and participate in resolving them. Instead, they put them back on the team. As the comment shows, some engineers did not feel free to raise this problem. | Content leader: But when it came to dealing with some of the particularly difficult engineering issues, we were left out in left field, and we had no one to go to. I don't think it was [the Program Manager's] problem to get involved with these issues, because he doesn't know about engineering. But we should have been able to discuss the problem [that engineers felt unsupported.] I think after a while we recognized it and we avoided [discussing it]. |
Bringing the process leaders and the content leaders together on a team, it was thought, would allow them to recognize one another's blind spots and develop an appreciation for how the other side saw things. This, however, did not always happen.
|
The contrast between process knowledge and engineering knowledge was prominent
within the Epsilon team as well as in the larger organization. People seemed
to be experts at one or the other, but not both. Communication was not strong
between the two groups of experts and some issues may have been overlooked.
How can we design learning so that technical and process knowledge reinforce each other? Could members of both groups be empowered simultaneously? |
Content leader: There were some rough roads on this program. There used to be a
conventional breakdown of car program management. You'd have separate managers
for business planning, vehicle engineering, launch, and vehicle development.
On Epsilon, they tried to combine all those skills into one person. This was the first time they tried that management system and the way they implemented it didn't work very well. It worked in fits and starts. The real engineers all ended up reporting to the Chief Engineer, and the planning types ended up reporting to [the Launch Manager]. [The Launch Manager] is not an engineer by background. The planning people worked with the Design Center effectively, and knew how to talk about the features of the car, but they didn't have the background to say, "OK, now we need A and B completed by this time and we always have problems with B, so let's concentrate our efforts there." We found out after a three-month delay, for example, that some engineering issues affecting the audio system were not being elevated to the Chief Engineer's level of discussion. Some of the vehicle leaders didn't seem to know enough to bring up the right questions. They should have had much more deliberate communication between the groups from the beginning. |
[Back to the Abbreviated Table of Contents]