NASA Johnson Space Center Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript

Arthur E. Goldman
Interviewed by Rebecca Wright
Stennis Space Center, Mississippi – 3 June 2008

Wright: Today is June 3, 2008. We are at the Stennis Space Center in Mississippi to speak with Deputy Center Director Arthur Eugene Goldman as part of the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright assisted by Jennifer Ross-Nazzal. Thanks again for taking time out of your schedule to meet with us. Tell us, if you would, how you first came to work with the Space Shuttle Program.

Goldman: I had been working in nuclear power construction for about 13 years. My third job in that row was in the north Alabama area, and a friend of mine that I had worked with, with Tennessee Valley Authority who had come to work with NASA a year earlier, called me asked if I would like to come to work with NASA. That was in 1990. That was something that I had always wanted to do. My background is civil/structural engineering, and so I didn't expect to ever have the opportunity to come to work with NASA. But at that time, with the two-aged hump at Marshall of the very young engineering/technical people they had and the ready-to-retire technical people they had, they were looking for middle-aged management with some supervisory experience, and I fit that criteria and they didn't have to pay to move me.

I came to work, and it just happens that I came to work in the Shuttle Program. I came into a group with a gentleman, Jim [James M.] Ellis, who had Systems Integration at Marshall [Marshall Space Flight Center, Huntsville, Alabama] for the Shuttle Program within the Shuttle Projects Office, so it's a little different than the Systems Integration Office that is at JSC now, as well as the one that's at Marshall. It was one of the offices which was in a period of transition, and they were actually downsizing from a more robust office they had had earlier. But it was a really good entry-level position for me to come into the Program and get experience dealing with all of the projects and project managers on a variety of programs which cut across all the elements.

Our role was to assure that we have consistent answer from Marshall on a variety of topics, or that we were integrating the activities of the projects for the specific tasks. That's where I started, and I worked in that role for nearly four years and then moved to the Space Shuttle Main Engine Program as a Manufacturing Engineer. Then I worked my way up through that hierarchy, winding up as Project Manager in 2003 of the Space Shuttle Main Engine. So I spent approximately 12 years in Space Shuttle Main Engine, in roles varying from a Manufacturing Engineer, Technical Assistant to the Project Manager, Business Manager, Deputy, and finally as the Project Manager.

Wright: These different roles that you had, each one had its own set of challenges and learning aspects. Could you share with us some details about some of the memorable ones and the lessons you learned along the way that you've carried through?

Goldman: Sure. Starting in the Systems Engineering and Integration role, one of the key items in that was communication. Within the Shuttle Program at large, and even at Marshall, there was inconsistency among the elements and how they handled a particular topic. Across the program, each element tended to work it in isolation, and the realization that resources were being wasted in doing it that way—or at least it was not the most efficient way to do things—and trying to drive such that we had a communal approach to topics, so that at least where elements were working things differently, we understood why they were working things differently. That was a big lesson for me, that communication is that important. Because with the elements operating the way they did, and very little cross communication, having a group which cut across those elements and assured that each element was talking to the other, at least we were gaining the information from each so that we could share experiences.

When President [George H. W.] Bush 41 issued the ozone-depleting chemical dictum requiring that the federal government would not be using ozone-depleting substances—and I believe the deadline was 1996 to stop using a lot of Freon, trichloroethane, a lot of elements that were used in the Shuttle Program for cleaning in particular—I was working at that time in the Space Shuttle Main Engine Program with Rocketdyne. They were a California contractor, so they were ahead of the game by fact of the state laws. But that was a particular activity within the Shuttle Program that cut across all the elements. Each element was handling their own environmental tasks differently.

Mr. [Bob] Swinghammer, [phonetic] who was Head of Engineering at Marshall, was assigned by Mr. [Daniel S.] Goldin and [Thomas] Jack Lee, who was Center Director at that time, to head the NASA Operational Environmental Team to try to coordinate activities across NASA in meeting these goals and meeting future environmental regulation. I was assigned from the Shuttle Office. At that time, I was still working in Systems but had just begun to work in Space Shuttle Main Engine, so I was stepping across two tasks. I was assigned to work on Mr. Swinghammer's team, so that assured not only did I work within our Shuttle projects at Marshall on those tasks but also had a lot of involvement across the multiple Centers within NASA.

Communication, identification of requirements, and the cross talk between elements on how requirements were being met was one of the real big examples of how integration was crucial in a program as broad as the Shuttle Program. Then Space Shuttle Main Engine, even operating within the environment, it was how we used data. The Space Shuttle Main Engine had a long heritage of using data, of being able to test engines as we do here at Stennis, and using all of that information as rationale, we were able to take the data, compare performance during the test to previous tests and to our database of history. That was a good example of how vital retaining information—keeping information such as you're doing here with Knowledge Capture. What were past practices? What were things that you've done in the past that have worked, and when something begins to change, what's causing the change? If you have that database, that historical database of information on how you have done things, it makes it so much easier to go back and isolate what has changed.

One amazing example of that within Space Shuttle Main Engine is for a test operation that we used where we would seal the inside of the nozzle for a vacuum leak check, and we would seal an area of the nozzle. There was a type of tape that they used—something as simple as tape—it was double-sided tape. They would line the nozzle tubes near the main combustion chamber and then insert a block, if you will, that would seal that area. I can't remember whether it was green tacky tape or red tacky tape, but there was one brand of tape that we had used for years. That tape got changed for some process—they could no longer get one brand of tape so they just went to another tape.

It turns out that the tape they went to had a slightly different chemical composition which actually eroded the nozzle tubes. Once the engine was hot fired, that started a chemical reaction where the residue from the tape corroded the nozzle tubes. We began to experience leakage in the nozzle tubes when these engines would come back from flight, and we didn’t know why. In the process of doing the investigation, we identified what's changed in the process, and we saw that we'd gone from one tape to a different tape. When they checked the chemical composition, we saw that it was different.

That subtle change, that ten-buck change that you make, reinforced to us that no change is subtle within a program like the Shuttle. It certainly wasn't within Space Shuttle Main Engine. That change got made without getting much of a review or questions asked because it was deemed so subtle that it couldn't have an impact on the process, yet it had a significant impact on the performance of our engine. So those little things in the Shuttle Program bite you, as we've seen over and over. There just are no subtle process changes. You have to be very astute to be able to discern which ones are important and which ones aren't, and since it's so difficult to see which ones are important, it's better when you can have a broad review of that so that the right questions are getting asked. That's important within a single element, and it's certainly across the spectrum of the Shuttle Program.

Wright: That's very interesting. Thanks for that. Part of what you do every day, and maybe the underlying part of what you do every day, has to do with risk. If you could share with us, first of all, some ways that you would improve risk assessment or risk mitigation, and then give us an example of where you saw a change that really made a difference in assessing or eliminating risk.

Goldman: Risk management has become such a hot topic, and we keep trying to assign a numerical value to it. There are all types of software packages. There's a lot of methodologies that are used. In my mind, I still do a comparative risk assessment, but that's not rigorous enough. There's variability in all the systems that are used, but they all depend on an assessment of the individuals that are involved and understand the risk, of being able to identify or prioritize one versus another, that this risk is more important than this risk. You can do that within an element or within a component level of an element fairly consistently.

But when you get across, again, a program as broad as the Shuttle Program, it's extremely hard to compare risks from one element to another element and then across multiple elements. The only thing that I would advise there is that we continue to try, that we try to make the process more and more consistent. We have a tendency to jump from one methodology to another, the flavor of the month, if you will. A new software package comes. I don't think it's as crucial that we use the latest software package as it is we identify a methodology which seems to work most of the time, and then make that become part of our culture on how we do business.

I think the Shuttle Program, since [Space Shuttle] Columbia [STS-107 accident], has tried to do that. Sometimes it fits, sometimes it doesn't. We have a tendency to try to force-fit things. I think we need to be able to say when this methodology just does not lend itself well to this particular area, and instead of trying to force it, just realize that it doesn't work well. And get broad knowledge across the program for all the practitioners. S&MA [Safety and Mission Asurance], but not only S&MA, the Systems Engineering community, the engineers and technical people within each of the communities in such that we're employing properly. We often make one group responsible for that across the organization. S&MA is a really good fit for risk management. I think they're probably the ones that are most adaptable to that. They're also the ones that have their eyes across the program.

One thing that I saw way back, and this was between the [Space Shuttle] Challenger [STS 51-L] accident—I was not with NASA when the Challenger accident occurred. But coming from the nuclear industry, we were regulated by the Nuclear Regulatory Commission, so they gave us requirements we had to meet. We at NASA set our own requirements, so we don't have an outside regulatory body that oversees to make sure everybody's doing things the same way. In nuclear construction, you do your best to do things the same way. The more consistent you can be with policies, regulations, and plant-to-plant—we had inner utility working groups that tried to see what the best practices from each plant were. Those were great lessons because the more consistently we could do things, when an auditor came in and he saw that our documentation was filled out the same way as another utility's, then it just made it easier to meet the requirements of an audit and to have traceability.

When I came to Shuttle in 1990—I've always been told that NASA's Quality Assurance Program was based on the nuclear, and I found out no—it might be loosely based on it, but not in total. There was this strong tendency to do things different, and I would talk to people in the S&MA community and say, "Why would you not have the same documentation forms element to element across the program?" FEMA [Federal Emergency Management Agency] seals and hazard reports was the particular example we were talking about, and the man literally told me, "Well, because Joe works this element and he likes to see it in this format, and Billy likes this format." I was fascinated by that mentality that said because one person reviewing this today likes it in this format, we leave things like that and why we don't try to become more structured. I think we're moving toward that within the Shuttle Program, but it's still very, very slow.

The System Integrity Assurance Program set up following the Challenger accident was one of the methodologies intended to make us more consistent, and it never worked because it was never funded. It required elements to change their documentation. Since they didn’t fund it, then Project Managers just said, "I’m not going to do it," and they didn't. I don't know that it would have kept Columbia from happening, but it was one of the things that made the Columbia investigation more difficult, because we still did not have consistent records and consistent methodologies across the Shuttle Program.

I think the more and more we move toward consistent means of documentation, consistently and rigorously applying these techniques while still being thorough. There's a tendency to follow an instruction so blindly that you miss steps—you, again, force fit it. You have to allow yourself to realize something works or it doesn't or it's all encompassing. But the more we move toward consistent processes and having broad understanding of those processes across the Agency, the more we can hone in on a risk management system that will be effective.

Wright: Thanks. On that same line of thinking, since you've been a manager of these large, specific areas that are so vital to this Program, talk to us about some lessons you've learned in regard to improving management performance.

Goldman: Again, communication. I've said for a long time that project management is breaking a project up into smaller parts, putting good people on them, letting them do their job, making sure that they're all talking to each other, but allowing them the ability to manage their part of it to your guidelines, and having some way of tying it all together. The Project Manager's job, to me, is tying it all together. Having the different forums where discussion and communication will occur is key to that. A program as broad as the Shuttle Program requires a lot of different working groups and committees. We've been criticized before for having so many working groups and committees, but I really feel that's where a lot of the work gets done. It's where the detailed analysis gets performed by small groups of experts in a particular area.

Then it comes up the hierarchy of forums, ultimately coming to the Program Requirements and Control Board where the Shuttle Program at large can review a particular item. Though it might not be in their area of expertise, they can ask the right questions of the process and what was used. I like the way we do things in the Shuttle Program, and I think making those more effective, mandating and assuring that communication occurs—I think that is the one biggest thing that we can do. We continue to try various technologies, but when you get it at its lowest form, it's making sure that people are talking, it's making sure that management is listening, and it's making sure that questions are getting asked.

One of the criticisms of the CAIB [Columbia Accident Investigation Board] was that at Flight Readiness Reviews and Mission Management Team meetings elements did not challenge each other. There was a certain amount of gentlemen's agreement that I sensed, that one element didn't criticize another element's work or rationale because the specific element was expert in that area. But that should not have precluded questions about the process having been asked. [N.] Wayne Hale [Jr.] and Bill [William W.] Parsons [Jr.] did a major job in the Return to Flight efforts to assure that elements did critique each other's work, and I think that's employed today in the Flight Readiness Review process. Any technology that you can use to get information out is valuable, but we get overloaded with information. Knowing that people are not going to read everything that gets put out there, that they're not going to have all the detail, I still feel it's extremely important that we maintain our hierarchy of meetings and forums. You can always streamline them, but we ought to be very careful when we start eliminating things.

[Dr.] Joe [Joseph F.] Shea said in the Apollo Program prior to the Apollo 1 fire that a Program Manager can never know all the details of a program, but it's their job to assure a system is in place such that nothing ever falls in a crack. I feel like that philosophy is still as sound today. It's an extremely difficult thing to do at a program level, but I think any time you stop asking questions, any time you stop being curious, any time you start streamlining the process, be very, very careful because you could possibly streamline it too much such that—not necessarily someone's voice is not heard—but such that questions don't get asked, that there becomes a tendency not to be curious about things. That can swing the other way, where you spend all your time answering endless questions that are nuanced, or you get into the differences of opinion in that, "I wouldn't do it that way." So it's a very fine line to walk, but I think the Shuttle Program does a good job. We can always get better at that, but I don't think there's technology that fixes that for us. I don't think there are risk management systems that preclude us being good managers and us being very thorough.

Wright: How do you build an element of trust between and among all those people that you were just talking about?

Goldman: Again, communication. Dr. [Michael D.] Griffin [NASA Administrator] said one time not long after he came—he was asked a question about what's the one lesson that you feel like NASA needs to learn to make their mission successful, and he said, "We can start with listening to each other. If we could just learn to listen." I say that in so many meetings where people don't listen. They don't listen to the question, they don't listen to the speaker, they're thinking about what they're going to say once this person shuts up. It's listening respectfully, agreeing that you can disagree but that you disagree professionally. This is a program, it's an agency of strong opinions. People are experts. People, in particular engineers, have this feeling that, "This is mine and I know enough about it, I'm right," that too often they refuse to listen to other people and they get very defensive.

Bill Parsons did an excellent job in Return to Flight, again with Wayne Hale's help, and they put together a team of people that were going to be in the room to critique each other, but Bill allowed people to talk and Bill allowed people to beat on each other until he felt like it was getting out of hand. Then he would stop it, turn things around. But he always made sure that recommendations came forward, and he made sure that people were voicing their opinions even though they were strong opinions sometimes. That group—it was a very tough group—but I felt like there was tremendous trust in that group. We disagreed strongly on things, sometimes what was important and what wasn't. But my sense was that that group did trust each other, and they were put together specifically to work with each other. He put people on that team that he knew irritated other people, but he did it to assure that opinions were going to get brought up, that unpopular thoughts were going to be brought up.

I hate that kind of thing because I'm the methodical, "Let's do this, let's all collaborate, let's all agree, let's build consensus," and when someone starts throwing out opinions that are off the wall or out of the box, I get very frustrated very quickly. But I also saw the value in that, and I heard Bill talking one night because we were discussing one of the more strident members of the group, and Bill said, "I put him on the team specifically for that. He ruffles feathers." Bill was the one that would have to put him back in the box, but he made sure that the voice was heard and that the opinion got out there, and that was very astute on Bill's part, to recognize people have different capabilities but you use those complementary skills to have a very effective team.

The Space Shuttle Main Engine Team and the Shuttle Team—when I left it and came to Stennis nearly two years ago, I felt like it was still operating on that principle. It had changed. Wayne Hale and his deputy, John [P.] Shannon and his other deputies still did the same things. The teamwork had become more. The rancor in the room had begun to dissipate because the issues were not as controversial. They were still complex. But a tone and a mode of operation with each other had evolved. It may be incumbent on occasion to disturb that pot, to make changes within the group just to assure that they're still thinking outside the box and that they're still challenging each other. That's a difficult thing to do, though, is to build enough trust in a team that can be critical of each other, but do it in a constructive manner and do it understanding that this criticism is for the good of the Program and not for the good of the individual.

Wright: Program efficiency's got to be a challenge when you've got so many different aspects of your project that you have to keep in line and balanced with each other. Can you share with us some ideas about what you do for program efficiency and/or how you would recommend to improve it in the programs?

Goldman: Those were things where, as Space Shuttle Main Engine Project Manager, I counted on the contractor and I counted on my civil servants team to scrutinize them and again, to ask questions. I trusted my contractor thoroughly because they were the ones that had to deliver the hardware and to guarantee the hardware. But in an era of constrained budgets, we had to spend a lot of time prioritizing that. The way I did it was with a team approach that said, "Here's the budget that we have. Here's the work that we have to do. How do we make this fit in the budget? How do we assure that our hardware operates flawlessly, because we can afford nothing different, but do it within the budget?"

I had the luxury on the Engine Program of being able to remove hardware from the program, which would be something I would carry back to the Program Manager and say, "We build reusable hardware and we have enough with our flight rates. Here are the cuts that I have to make." Most of mine were in removing hardware, saying, "I'm just not going to build these components, therefore I can save this much money." Other elements don't have that same luxury, so it's tougher on them. The fear I talked about earlier about streamlining processes, when you've been burned by just changing a tape type, you get real, real leery in making process changes.

Technology improves and you count on the contractor to use, in our case, improved manufacturing techniques and capabilities. We didn't change material a lot, but we would change material processing. We did a lot of testing to ensure that it wasn't going to change the final outcome. But being leery of small changes really requires a lot of attention to detail in that. So attention to detail, thorough reviews, multiple reviews. We used our contractor, we used our civil service at Marshall, I used the people that worked in the lab for us that were matrixed to us that were experts in materials and structural analysis, et cetera, to review, and I listened to their input. A lot of times people don't like to hear those because they give a view that's not something that you want to deal with, but I wanted to hear those questions put on the table. I wanted to hear process changes challenged.

That's a real broad and specific and general answer all at one time, but it's an extremely difficult thing to do, especially when you're in a program where process changes can literally kill you. The final product is so complex that it doesn't lend itself to some type of statistical analysis that says, "This will be okay." As I mentioned, I came from a structural world, so we can do beam analysis and we can say, "The loads on this beam are such and the deflection is going to be such." You can do that on individual parts, but then when you put all those parts together, very complex geometries and then flow of cryogenic materials and heat transfer, et cetera, into a system, you really can't predict what it's going to do.

In Engine we had the luxury of having a long history of engine performance, so our predictions were based not on analytical models, but they were based on “What's the engine done in the past? When we had these conditions and operated the engine at these conditions, what were the results we got? When we got something different than what we expected, we would go back and try to find out why. What did we miss?” That's just applying it to the engine. Imagine the difficulty in applying that across the Integrated Propulsion System, the Orbiter Project, and all the individual parts that go into the Shuttle Program. Due diligence and care, I suppose.

Wright: How important is planning with everything that you do?

Goldman: Extremely important. From what we do with the test stand, assuring that we've got all the materials ready to do a test. Here in the test world, at the test rate we're running now, which is fairly low, it's reasonably easy to do the planning that we have. If you go back to Main Engine again, doing the manufacturing, assuring that you get it completed, inspected, and into test, then out of test, and shipped to the Cape [Canaveral, Florida], installed in the Orbiter—all the things that can fall upon you, any of those steps along the way from just transporting the engine from Stennis down to the Cape—planning is critical.

Groups within my project had planning meetings, if not daily, weekly to see what's the status on where are we. We had manufacturing reviews to see, for all of the individual parts for the engine that we had in manufacture. “Where are they? How do they come together in the assembly of the pumps and the remaining components of the engine, and where are they? Are we going to meet the needs at the Cape for engine installation?” And this would be for four missions downstream that we were looking at, and we were just one element. The Shuttle Program had similar scheduling meetings where it met with representatives from each of the elements to see where are we on the critical path.

I was amused, not long after I came to Shuttle, and I heard that for their scheduling meetings they never had a critical path identified because nobody wanted to be on a critical path. Nobody wanted to get that scrutiny. I thought, "Critical path is just a tool to make sure that you're doing the right things and you're putting the emphasis on the right thing." But the mentality was, "I don't want my element on critical path, so we're not going to have a meeting where one is identified." In the Engine project—and I think most of them have changed since then—I always wanted to know what the critical path was. I listened to the contractor on how they were going to deal with that and we would ask questions, but I wanted to be aware if our hardware was going to make it to the Cape on time.

In Return to Flight, that was critical. We had some design changes for a small part of the high pressure oxidizer turbo pump and knife edge seal. We found out a very, very minor geometric change on a drawing was picked up and changed the dimensions slightly in the manufacturing process, and then the manufactured part didn't meet the criteria and it didn't meet the environment in the pump. It was a case where analytical techniques had evolved when the part was originally designed. If we had had the analytical techniques that we had 20 years later when I was managing the program when the part was initially designed, they would have seen that it was right on the edge of its capability to begin with.

The small geometric dimensional changes which showed up in this part then made the part unstable, and we had cracking in the parts. We had gone all the way through the development program, through a rigorous certification program, inspection of the hardware to double what we intended the life to be, and the part performed flawlessly. Yet, in the manufactured parts that were flying, we were getting small cracks and we had to go back and trace down why. We were able to do it finally, and then we redesigned the part. But then that put us with ten pumps. Now we had to limit flights to one green run and one flight on a pump that was designed to fly ten times without being rebuilt. So it was a tremendous expenditure of resources within the program. Plus it took hardware since we fly three engines every flight and we only had 16 pumps.

We had to make sure that we were doing the planning—while we were doing the redesign of the seal—to get new seals built and certified and into the configuration while we still did all the work around that we had to do with all of our pumps to make sure we could support each flight. Plus, post-Columbia, we had to have a backup Shuttle ready to fly and do a rescue mission if need be. Not only did I have to have three pumps for a flight, I had to have six pumps because I had to have the backup flight ready, so it just cascaded. We talked about planning earlier. That was one of the big areas where we had to plan. But the knife edge seal was a good example of planning, it was a good example of process change, it was a good example of evolution in analytical techniques and engineering principles—all of which come together, again, in one component of one project within the Shuttle Program.

Wright: Amazing. What do you think has been the hardest lesson that you've had to learn? Or the best?

Goldman: One of the tough, tough lessons was process control, how no change is a subtle change. Mr. [George D.] Hopson, who was Project Manager before me, had a saying, "It seemed like a good idea at the time." That became our credo, because things that we thought would be good changes turned out not to be. I was fortunate to work a long time in Engine, and they base so much of what they do on their past. People say, "Well, y'all don't change much." No. Because we find something that works and we try to stay with it, because subtle changes can bite you. It was the realization of how important process control was, down to the level of what type tape do you us, and that chemical residue can affect something. An engine, which can operate in environments from negative 423 degrees to 6,000 degrees, can be ruined by changing one type of tape. That was a huge realization, and it just reinforced that everything that we do, all the rigor that we apply, we have to be thorough in that.

The other was communication. One of the things that I've done most in my career is doing coordination. People take communication as being so simple they presume that everybody's going to do it. But when you have a lot of parts of a project that have to come together, ensuring that all those team members are aware of what has to happen and that they're going to do their part at the same time seems like it'd be very simple to do. It’s hard work. It's not complex work, but it is hard work. But it's finding the person that's going to do that to ensure that they all talk to each other. How do you do that? Do you do it individually, do you do it through a collection of telecoms, et cetera? So that process control and communication, and that unknown things bite you.

This goes all the way back to doing outage planning in nuclear plants, and it's just as important in planning manufacturing on the Shuttle program—you plan for the big things. You can pick them up, you can brainstorm and identify all the things that you think will happen, and then you can put contingencies in place for that. There will be something come along that you never expected, and you have to be ready to adjust to that and to deal with it, to identify it and deal with it. Then you incorporate that in your planning for the next event, but then there will some other little thing that comes along. So the more planning you can do, the more scenario planning that you can do, the more you can talk things out and depend on everyone's past experiences of what are things that have happened to them.

Ron [Ronald D.] Dittemore had begun to do this, Bill Parsons and Wayne Hale did this a lot following Columbia in Flight Readiness Reviews and in a variety of reviews. Dr. Griffin does it. Bill [William F.] Gerstenmaier as well. “Is there anybody in the room that something to say that hasn't been said? Do you think there's some subject that's been uncovered? Do you think there's some point that hasn't been made through the presentation?” Granted that's to get the people that are sitting on the sidelines that say, "Gee, I've got something to say but they haven't asked that specific question," or, "I don't know if I ought to say that." That's to draw them out and to give them the entry to say, "Yeah, I've got a problem that's said." But getting those people to speak up and making sure everybody's opinion is heard and balancing whether the opinion has value or not. Because that's very tough as well and you never want to send the message that “I don't value your opinion.”

One of the criticisms of the CAIB Report was that people didn't feel they had the ability to speak up. That just frustrated and frosted me. It is a tough, tough program to stand up and say, "I disagree." I never sensed that there was a management attitude in the Shuttle Program prior to Columbia that said, "I don't want to listen to you. You can't stand up." I feel like it's important. I feel like that was our job, then as well as now, to stand up. Yes, you need to be right. Yes, it's tough to be the one person that stands up and disagrees. But if you have a strong opinion and you truly feel like safety's being affected, it's your obligation. It's your job. That's what we pay you for day in, day out.

Is it a tough world? Yes, it is. But stand up and make your voice be heard. Once management is aware of it, then it's their responsibility to deal with it. But it's your job to get it out. The people that sit on the sidelines and say, "I had a thought, but I didn't say it because management would have beaten me down," I have absolutely no sympathy nor regard for those people. It's tough, but it's a tough program. But there's nothing like seeing it lift off the pad, and in my case here, in that we had nominal MECO [Main Engine Cutoff] and the engines had cut off and we were safely in orbit—that's just a tremendous experience, and the people that have gotten to work with this program—it's been the thrill of my life to work on this hardware.

Wright: When NASA's looking forward and to the future with a new program, what would you suggest and recommend how we best train and equip the next generation of Space Agency employees, and the leaders that will take your place in the new program?

Goldman: Having them do work at all levels of the program. Every experience we get—experiences that I had when I was doing construction while I was in school before I graduated, I employ some of the things that I learned then in the job that I do today. Coming to NASA, I was terrified because I said, "I'm glad I've got the gig. How long before they throw me out of here?" But what I found was that in Engineering Management, the details of a problem change. The technical aspects of a problem change. But the methodology that you use to resolve the problem is still the same, and the rigor that you apply and the questions that you ask is remarkably the same as the world that I came from, and that helped a whole lot.

That's what we've got to coach people on, this tendency to—some software package magically gives you the answer that you need, or that you don't be critical of the contractor's work, or that you trust the contractor to do that work. We do trust the contractors to do that work, but we've got to maintain our intellectual curiosity. We've still got to ask questions. We've got to do the study. We can't go into meetings and ask questions that are rudimentary and under the guise of having management say and ask your questions. That doesn't mean go in there and have them explain to you how something works. You should do that homework before you go to a meeting. You should know as much about it as you possibly can if you're going to be involved in it. But then ask questions about the process.

There's no job within the Shuttle Program—there won't be a job within the Constellation Program—which is not important. Respecting all the people in the Program. I often hear of Constellation and preceding programs say, "We're not going to do it like Shuttle did it." Well, there's a lot of value in the way Shuttle did it. We ought to look for ways to streamline what we do, but we ought to be extremely careful because the rigor that's built into the processes is what assures that we fly safely, and that's going to be no less important on Constellation. Where we can find better ways to do it and streamline, that's great. But you're going to need the same rigor in the documentation because you're going to have problems which have to be solved.

Find better ways of communicating, but at the end of the day realize it's still one person talking to another person. And assuring that people talk to each other, assuring that you draw people into the conversation, respecting different viewpoints and valuing different viewpoints. Not only diversity of culture, but diversity of thought. Look for different people on teams to assure that they're bringing something to the table. When you do that, also as a team member, not feeling like your way is the better way because you have a different way of doing things. Being willing to accept the status quo when the status quo is working pretty well. Being able to accept that something works.

Dr. Griffin talks about “Apollo on steroids” for the Constellation Program, and I heard him say one time, "It proves that the old guys knew what they were doing because it worked pretty well." It did. When something works, you ought to understand it before you try to change it, and if it needs to be changed then do that. But if it's pretty good, the old adage, "If it ain't broke, don't fix it," is a pretty good one to live by. It's real easy to fall into that hole and say, "We're never going to look for a different way." You can fly this hardware while you look for a better way to do it, but the same engineering skills, the same people skills, because it doesn’t matter how good an engineer you are. At the end of the day, you've got to get your idea across to another person and have them accept it. So communication skills, interrelationships, dealing with people as human beings, and effectively, is just as important and just as crucial as engineering skills or business skills or any other skills that we use in these programs.

Wright: That leads up to one of the final questions. It's about the advice that you'd give someone wanting to join the Space Program.

Goldman: Be committed. Be dedicated. If you can't get enthusiastic about this work, then you don't need to be here. I've heard a lot of different people say, "We don't come to work for NASA to get rich." I'm making more money than I'd expect to make anywhere else, and I'm happy about it, and I'm getting to do something that I love. I used to get teased by one of the gentleman that NASA makes history every time a Shuttle lifts off the pad. You didn't make history building nuclear plants, and they're right. There is a tremendous sense of excitement in what we do, and I am amazed by people when I ask them, "Did you happen to watch the Shuttle launch today?" "No, I had a meeting I had to go to," or something like that. This is what we do, and it's exciting to see it happen. That, to me, is the big thing, is just if you're enthusiastic and you want to be in this business, there's a place for you. If you can be excited about this work, you're going to want to do it right. You're going to want to be a part, you're going to want to contribute. If it's just a job to you, please stay away because we don't need you. Just come inspired.

I heard Roy Tharpe, who retired from KSC [Kennedy Space Center, Florida]—this was 15 years ago. I had been at work with NASA a little over a year and at that time Roy was my age now, and he was talking about giving a new employee orientation to kids at the Cape that had just come to work—some are interns, new hires—and someone fell asleep in one of his briefings and he said, "Please wake them up." So he asked them if they knew what that flag on the VAB [Vehicle Assembly Building] represented that they saw when they came into work each day, and they all looked at him and he said, "That flag represents a commitment that a young president made to put people on the Moon." He said, "That's what we do here," and he asked someone what time they got to work and they said 7:30, and he said, "Why weren't you here at 6:30? Why weren't you here eager to have a day?"

We talk about different generations, and we talk about not having importance on the job but being more concerned about self. I'm sure there's some of that. I've still got to believe, though, that there are people that get excited about what they do regardless of what they do. We like people being excited about NASA. It is tremendously exciting. When you see the astronauts, when you are fortunate enough to work with them like I do now—I have never met one of those people that I am not thrilled to meet and amazed at their dedication. Our part is making sure they fly safe. Seeing them do what they do gives me inspiration, and it all leads up to a capability that this country has that very few countries in the world have. It's a difficult thing to say one of your job requirements is to be excited, that's something you ought to bring with you to work each day, but to me that's the most valuable part. Again, if you're not excited, go somewhere else.

Wright: That's pretty good advice. I wanted to give you just a second, if you want to look at anything else on the question list or any other thoughts that you have to add about best practices or thoughts that you feel will be helpful? We covered a great deal.

Goldman: Yes. But most of what I said is talk to each other and listen to each other. I still feel like those are the main things. Bob [last name???] says here, and I agree with it, you can never communicate too much. And that's true. People think that you can, but it's so easy to hit a delete key. People say, "How do I streamline the e-mails that I get because I get a lot of trash e-mails?" Just hit the doggone delete key. It's easy. You put more effort into trying to filter something than you would to just hit the delete key. Best practices—it all boils down to things that we've already talked about. Realizing that there are no subtle changes in a program like this, that you document what you're doing, that you always strive to do better. But all of that's wrapped around communication. Value other people's opinion, professionally as well as personally.

I don't know if y'all have had a chance to talk with George Hopson. George is retired now, he's the former SSME [Space Shuttle Main Engine] Project Manager. He had my job before me and was a mentor of mine. But George's experience in the Space Program goes all the way back to the start. He's one of the men at Marshall who helped save the Skylab Program when they had that part that was stuck or broken as they started uphill. He still works with the NESC [NASA Engineering Safety Center] some and consults, and as a matter of fact, he does a propulsion course that he teaches to a lot of people himself. Lynn Worland [phonetic], who was Chief Engineer in Space Shuttle Main Engine. That was where I met them, but they had a broad career in propulsion.

Roy Tharpe, if y'all could get the opportunity to talk to him, I think he's still working with a contractor at KSC—incredible. One of the great things I enjoyed about coming to work with NASA was seeing these gentlemen at their age that were still as excited as they were about what they did, and I worked with some crusty old so-and-sos that I learned a lot from them but I had a tendency to avoid them as much as possible. But to meet somebody like Roy, who had had the career that he had had. He tore a tech sheet out of a briefing package when Apollo 11 launched and took it around and got signatures of Dr. [Kurt] Debus, Dr. [Wernher] von Braun, the principles of the Apollo Program, and then took it home and framed it. To see he's still—after having a tremendous career—was still as excited and still serving in a role as a mentor as he was to young people at that time and still does. I never see him that he doesn't have a smile on his face and he's just enjoying what he does.

Any of the older project managers—and I talk a lot about the ones from Marshall. Roy Estess had the job I have for eight years. He's just a NASA legend. He came to work at JSC as the Acting Center Director. He and Bob, the first time I saw the two of them see each other in a meeting, they hugged each other because they had such high regard for each other. He's outstanding from a Stennis perspective. He also had very, very broad base across the multiple Centers.

Bill Parsons and Wayne Hale—it'd be interesting to hear their perspectives. I heard Bill one time say, just before he left the Shuttle Program—because he's a former infantry captain in the Marine Corps—he said, "My management methodology is not letting people talk," and yet he was forced to let people talk in this role, and he did a good job. I always felt like Bill was the hammer. He'd let the conversation go until he felt like the same things were being said over and over and over again, and then that's when he'd say, "We've got to come to a decision." He wouldn’t make the decision, but he would force a decision and a recommendation to get made and get adopted by everyone around the table. Wayne did the same thing, but he did it in so much different manner with his low-key demeanor. Very, very sharp technically. Wayne could make the decision. Wayne was often integral in the decision by nudging people one way or the other. It was interesting to see them, with two distinctly different personalities, but how effectively they worked together.

Wayne and John Shannon, who you could say were cut out of the same piece of paper almost, yet have complementary skills as well as the same skills. I'm extremely excited to see John as the Shuttle Manager now. Their upbringing in Mission Operations Director—it's a unique set of skills. Bill Gerstenmaier goes back to JSC plus his experiences at Headquarters. He's one of the most talented individuals that I have ever seen or been around. I’m fascinated by him.

Wright: All right, well thank you very much. We learned a lot today.

[End of interview]