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

Michael U. Rudolphi
Interviewed by Rebecca Wright
Huntsville, Alabana – 15 May 2008

Wright: Today is May 15th, 2008. We are in Huntsville, Alabama to speak with Michael Rudolphi, who has served in a number of NASA leadership and management positions. This interview is being conducted for the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright, assisted by Jennifer Ross-Nazzal. Thanks again for allowing us into the building and finding time to talk with us for this project. Tell us how you first got involved with the Space Shuttle Program.

Rudolphi: I was working with the Tennessee Valley Authority in 1985 or '86 timeframe. We were working some outages on nuclear plants. As a side note to that, the characteristic of working an outage is very much the same as getting ready for a launch on the Shuttle. Trying to get a power plant from a cold position up to hot and running and generating power is a lot like the same kind of checks and balances that we have on getting a launch ready. That's just a little bit of a side note there. I was working an outage and I was working pretty hard. I was driving back through Huntsville, Alabama on my way back home. I saw where NASA had a job fair.

Believe it or not, I thought, "I'm about wore out, I'm going to go see what NASA might have. I've heard a lot about this NASA, and I'm going to go see what they got." I pulled into the job fair just on a lark and went in and talked to a few of the recruiters. One of the recruiters said they were getting ready to build this ASRM [Advanced Solid Rocket Motor] project over at Yellow Creek in Mississippi and they might be able to use a construction kind of guy like [me]. Gave me a name to call. So I called up. I called the person over here at the Marshall Spaceflight Center. Went right over there that very afternoon and had an interview. Then by the next Monday morning I had a job working for NASA. It happened so fast I couldn't believe it.

I started working then on the construction of the Yellow Creek project, which was a replacement for the solid rocket motor that we presently fly, RSRM [Reusable Solid Rocket Motor] that was the ASRM. It was meant to be a replacement for that. We were going to build a brand-new state-of-the-art factory over in the little village of Iuka, Mississippi on an old TVA [Tennessee Valley Authority] construction site.

I was the construction manager for that project and did that from 1988 through the time that the funding was withdrawn on that project in 1992. Coming out of that, I was actually in the Facilities Office but had made friends and contacts in the Project Office. So I was asked to stay on and moved into the [Space] Shuttle Project Office. I continued to work at Yellow Creek for just a little while as Resident Manager there, and then was offered a job to come back to Marshall and work on the Solid Rocket Booster [SRB] Project. It was in the early part of I believe it might have been '95. I took the job as the Chief Engineer for the Solid Rocket Booster Project. That was my real introduction and my real beginning to work on the Space Shuttle Program. STS-68 was my first launch. Began working the Booster Project at that time.

Two or three years later the Booster Project Manager retired. That happened to be Jim [James W.] Kennedy, by the way. He left the project, and I was selected as the Project Manager on the Solid Rocket Booster Project, and did that until Christmas of 2000. I was asked to take on the job on the Reusable Solid Rocket Motor Project, and I was a Project Manager on that for three years. In that timeframe we probably went through 25 launches. Then in [November 2002] Bill [William W.] Parsons asked me to come to Stennis [Stennis Space Center, Mississippi] and be his Deputy Center Director at Stennis. Then we all know what happened on February 1st of 2003 [Space Shuttle Columbia STS-107 accident]. I was the Deputy Center Director at Stennis, and I was asked by the [NASA] Administrator to be one of the three managers that ran the recovery effort. I spent three months out there in Lufkin, Texas leading the recovery effort, and after that, went back.

Bill Parsons had been selected as the Shuttle Program Manager. So I went back to Stennis and was the Interim Director at Stennis Space Center until the end of that year, 2003, at which time I was asked to come back to Marshall and lead the propulsion work for Return to Flight, a very challenging time for all of us. I did that for a couple or three years and was the propulsion manager on all the propulsive elements for the Marshall Spaceflight Center and got us through that. I stayed on through Return to Flight and then was moved over to the Director of Engineering at the Marshall Spaceflight Center—where it again was heavily involved in the Space Shuttle activities and participating in launches and that kind of thing—until I retired in the spring of 2007.

Now I'm back working on the Space Shuttle Program from a contractor's perspective. I've been around the Shuttle Program, the [International Space] Station Program, and the [Shuttle-] Mir [Phase 1 of the International Space Station] Program. I've been around all three of those programs over their history. Saw the Mir Program come and go as a matter of fact. Really one of the most exciting things that we went through was the joint Mir-US program. Real exciting during those times. Did a lot for our relationship with the Russians.

Wright: You've explained or shared with us those many positions that you had. Each one had its own challenges and level of responsibilities. Share with us the details about some of the most memorable ones and the lessons you were able to learn during that time period.

Rudolphi: I think when I go back to the Solid Rocket Booster Project, the most memorable impacting experience I had there—that was the time we introduced the United Space Alliance [USA] SFOC [Space Flight Operations] Contract to Shuttle. That was a dream that the Administrator had or somebody had along the way about trying to turn the operations of the Shuttle over to a single contractor. Being in the SRB Project, we were the first propulsion unit to go through that transition.

The contractor at that time was United Space Boosters [Inc.], USBI we call them. Transitioning that project from USBI to USA was a very, very meticulous, take a lot of energy—you can imagine the distractions of one company taking over another company and trying to continue to fly. I think during that timeframe we were flying. One of those years was one of our years in which we flew eight flights a year. It was really a busy time. Doing our level best to keep people focused on the work during that transition was really challenging.

It was very interesting, but at the same time was very challenging—trying to figure out our new roles and responsibilities, working through that. I can remember specifically talking to my group of NASA folks that ran the ARF [Automatic Reentry Flight], trying to convince those folks that this was really a pretty good idea, that we needed to get out of some of the things that we were doing and turn it over to the contractor. And the emotions got high from time to time. I wouldn't say we'd come close to fisticuffs, but we came pretty close to people storming out of the office. "This is not anything I agree with and I'm not going to do it," and, "I don't see any value in it." But after a little chat and a little talk and a little time working on it, we could get them to come back in, and we finally made that work. I think it turned into a pretty successful endeavor.

We launched a lot of boosters in that transition period, and since then, that have worked flawlessly. I will tell you that there were things going on at the program level that were exciting at the same time. That probably wasn't near as impactful to our projects as some of the things down in the project. I mentioned the Mir work that we were doing, and I remember clearly when we launched Hubble [Space Telescope], and I remember very clearly whenever we had a mission—maybe you can help me remember the name of the mission. I think it was '92 I want to say where we flew. We had some problems on orbit, and we came back home, and we turned right around. It seems to me like it was 60 days later we relaunched that mission.

That was some really exciting times. I can very vividly recall Tommy [Thomas W.] Holloway at one of the morning stand-ups acknowledging that we had to curtail the mission. It was like a 14-day mission that was cut down to I want to say—we ended up cutting it to four days. I don't remember the details on that. But Tommy announced at the stand-up that we were going to try to just take that payload right out and turn that mission around and fly it again. We all thought, "Well, we'll see." We put our running shoes on, and we pulled that off. Really one of the most remarkable feats I think that we had in that timeframe was turning that mission around. Showed how people could really turn to and do that job.

One of the most interesting programmatic accomplishments that I was involved with in RSRM was the planning and the execution of what we called Engineering Test Motor 3. We had convinced the program—and it came from its very infancy—we had done so much work on the solid rocket motor keeping it within really, really close tolerances and close bounds of operational performance that we'd never ever stopped for a minute and thought about, “What kind of margins do we really have in the hardware?”

At that time it was Ron [Ronald D.] Dittemore—we convinced him to let us have our underrun for that year and build a five-segment test motor. Well, guess what we're flying on Ares I? I think one of the real fundamental reasons that the five-segment motor survived and is flying on Ares I today is because we had that demonstrated capability. We fired that motor in October after the Columbia. Beyond a shadow of a doubt there were skeptics coming out of the walls about whether we ought to do that. “We could not tolerate another hiccup.” I kept reassuring the folks that we'd done our work and the test motor was going to be all right, and on October 13th of 2003 we fired that motor, and it was very successful. It's still talked about today.

Obviously the Columbia accident and the recovery. The Columbia accident haunts most of us that were involved in the Shuttle Program at that time. I was at the FRR [Flight Readiness Review] for STS-112, which flew right before the 107. We had the foam release, chunks of foam coming off, as a topic at the FRR. I think many times during those two or three days of those FRRs, if I would have just stood up—like many other people could have—and asked one little simple question about, "Do we have test data to prove that comment?" we would not be here. We would not have experienced what we went through.

That lesson has really stuck with me. The environment at a Flight Readiness Review is one of—there are a lot of real, real smart people sitting around the room, and the image is that "Gosh, I sure as heck don't want to be the one to ask the stupid question." Because you want to make sure that your questions are well thought out, thoughtful, and are very intelligent questions. I have learned through that process that sometimes when someone has the courage to ask the stupid question or the less than elegant question, people start thinking and they wake up and they start paying attention and they get involved in what's going on.

If I would have had the courage to stand up and just ask one little fundamental question, we wouldn't have been where we were today. The sad part about that is that the folks in the program at that time—Ron Dittemore was the Program Manager, and Jim [James D.] Halsell [Jr.] was the Integration Manager at the Cape [Canaveral, Florida]. There were some real, real intelligent Project Managers around. George Hobson was in that group, [V.] Keith Henson was in the motor [RSRM], and Ralph [R.] Roe was in the Orbiter, Lambert [Austin] was the Integration Manager, Bill [William F.] Readdy was sitting at the head of the table. There was a lot of people who were very concerned and conscientious. But because we failed to ask that one simple little question, we let ourselves be led through that, and out of that has come a lot of things. We've learned a lot about it, but I think the thing that we learned the most is: don't be afraid to ask that stupid question.

Then as the Propulsion Manager, I think the lessons of Columbia driving us and guiding us through Return to Flight had a lot of positive aspects to it. It had a lot of negative aspects to it—the negative aspects being that we had just committed to so much stuff that probably wasn't relevant to safe Return to Flight that we agreed to do, and it brought a lot of work. The things that we committed to for safe Return to Flight—I think we executed those very, very, very well. There were still a lot of things out there that are in the CAIB [Columbia Accident Investigation Board] report that probably weren't really necessary for safe Return to Flight. But we still worked those. Some of them are still hanging out there—work we need to do today that, “We probably ought not to go out and do that.”

Return to Flight was challenging to all of us. I think we had our closing ceremony on the recovery on May 1st, 2003. The CAIB report came out in September. About a month after that we'd written our responses to that. We were off trying to make repairs to the tank. The community at New Orleans [Louisiana] at MAF [Michoud Assembly Facility] trying to get all those repairs made really did a stellar job—tearing apart what we needed to tear apart, and then rebuild it to get ready to Return to Flight.

Probably the lowest day that I had on Return to Flight was an hour after STS-114 lifted off we found out we'd lost another piece of foam. The morale of the troops was about as low as I've ever seen it at that time. But we put a corrective action team together and went out and decided we didn't need that piece of foam anymore. We put the team together to take that off. Since that time we've been getting our stride back and we've getting a little better every day. It continues to improve, and we're just clicking right along right now. It was an emotional roller coaster getting us through Return to Flight. Return to Flight wasn't really over with 114. It really didn't end until we got the next launch off. We've still got some things on Return to Flight, like the safe haven that we still got to hold on to until we get some of the designs made.

You got a question on here: successful risk mitigation. One of the things we did back in the Ron Dittemore era—at the tail end of the Tommy Holloway and beginning of Ron Dittemore era—he developed this thing called the Shuttle Council. That was a time where all the Project Managers for both the contractor and for NASA would go off for a day or so and examine what we were doing; examining in a forum where we could be critical of ourselves, looking at what we were doing and deciding if that was the proper direction that we needed to go. One of the outfalls of that was, I think, our flight readiness process got better in terms of the crispness of the detail that we brought to the flight readiness reviews.

We did two other things I think that were really significant. We set up a Chief Engineers Council where the chief engineers for all the projects got together on a regular basis and you could get together and just talk technical details. That has brought a lot of shared knowledge and a lot of problem-solving ideas across the different projects, and it's been very helpful to the program and helpful to each individual project. We also came out of that with what I would say is a pretty consistent method for making upgrades to what we wanted to upgrade, either in terms of Shuttle or the infrastructure around Shuttle. We built a process, and Jim Halsell was the first organizer and leader of that effort. That really brought some really needed and well-focused upgrades to the Shuttle and to the infrastructure.

I was the Project Manager for RSRM at that time, and we got many inspection methodologies and things that were aggravating processes for workers to do. Ergonomically made it a much much better place for work and for the health of our workforce. We also dealt with several Shuttle upgrades at that time. Replacing some bad actors in the environment: we started working on trichloroethylene replacements. We started working on asbestos replacements in the motor. We upgraded several of the systems in the solid rocket booster in terms of electronics and the fuel system for the APUs [Auxiliary Power Units]. There was more than that on the Orbiter, but I just can't think of anything right now. There was a lot of good came out of that. Good ideas came out of that. With us just getting together and talking about things.

Wright: What other improvements in planning for risk mitigation or thoughts on risk management would you think about implementing now, especially since you've had a chance to step away from the other side and you're on the contractor side? What other thoughts or suggestions would you put in to instill new management processes or risk mitigation processes?

Rudolphi: Having experienced several of the leadership positions in the program and in the Center, I think if I were king for a day or if I was going to talk to somebody about risk mitigation and management activities, I would offer that: after a leader spends about two years in that pressure cooker, be it one of the Project Manager jobs or the Deputy Program Manager or the Program Manager jobs, give them a break. Get them out of that. Make it clear ahead of time that you're going to do that: “You're going to work this for a couple of years. Then we're going to go put you someplace else. Then we might put you back in again.”

We've got a real bad image about how we treat our leadership. If a person gets burned out or a leader is in one of these positions and the pressure is starting to show a little bit or starting to work on them a little bit, it seems like our action is we just move them off, and the stuff that they've learned in those years and the ideas that they've come up with—that goes with them. We lose that. I think it ought to be a standard diet for a person in one of those positions to be in it for a couple years, go do something else for another year or so, and then very comfortably come back in and do it again. Because there is a lot of stuff to be learned by reflecting on where you've been, what you've been doing, how you've been doing it. Go off and do something else and let those ideas influence what you do and go back.

I think today I'd be a much better Project Manager, much better leader, and would enjoy doing that. It seems like we have this, “You got to keep moving on, you got to keep moving up, you got to keep moving on, or you have failed.” I think it ought to be the other way around. It ought to be a nonfailure action to go, “You've worked in the program, now go work in the Center a little while, then come back. Move around a little bit, see different perspectives.” It is important—regardless of how you do it—it is important to have leaders in the program offices that have seen how an institution works and vice versa.

So many times we get leaders in the programs that grew up in the programs and have not got the appreciation of what the institution can do and should do for the program. By the same token, we've got people that grew up with the institution that think that we live for the institution, whereas we live for the program, we live and exist for the programs. If we're in the institution, we have to find a way for people to see themselves supporting projects and programs. At the same time, the programs have to have the support of and recognize the value of the institutions. We've not done good at that at NASA in the last 15 years. We've broken that into two silos, and we coexist out of necessity, as opposed to being partners in what we're trying to accomplish.

Wright: Speaking of partners, now that you've had a little bit of experience working as a contractor, as a Vice President with ATK [Aerospace Company], tell us what you see as a different way of looking at things, being so much a part of a federal institution for a while, and how that would affect best practices and sound practices.

Rudolphi: I'd start that off by saying moving from the government role to a contractor role has not diminished our interest in and care for the programs—for Shuttle, Station, whatever else. Those are still dear. I think that our contractor community has that same care and interest in the success of those programs. I think the difference where we can partner and be maybe a little bit better in partnerships is that I have found that a contractor organization often looks at things maybe from a bit of a different perspective than the government civil servants do. That's neither right nor wrong, but their perspective generally implies that there's got to be a return on the investment. In doing so, the lifecycle cost has got to be considered.

When I was with the government and I was a civil servant, I think sometimes I was more interested in finding the quick, “this is the best thing to do because this might be the safest thing to do or this might be the most expedient thing to do,” as opposed to sit back and say, "Well, it might be the safest thing to do, but there might be other things that can generally raise the safety of the program, as opposed to doing this one big thing, which may or may not raise the overall safety of the program." I think the contractor perspective on that is: be thorough in that analysis, and look at all the other things and make sure you're spending the money on the right things, as opposed to just spending money on some of your stovepipes.

Wright: What are the best practices or sound practices that benefited you as you went through all the different positions that you had, and in working on special projects as you did with Columbia? What did you fall back on?

Rudolphi: I believe that the work gets done by people who are treated properly. I think sometimes in leadership positions we get the idea, the approach or the mentality that we know everything. Quite frankly, we know very little. We got to rely on the people who have got their hands on the hardware, their feet on the ground, to tell us what needs to be taken care of. I've always prided myself on trying to have an ear to listen to that. I always try to find time to get out and to walk around every day trying to learn something—what's going on on the floor, what's going on in people's minds.

Spend some time walking around listening to folks, not trying to tell them anything but just listening to what they do. I think that's a very valuable tool. You learn what's going on, and I think just by being in the presence of the folks that are doing the work is a way of a) relating to them and b) they get a chance to recognize that management doesn't have all the answers and that their help is needed. It'd be tough to be working on the tools all the time and wonder if what you were doing was really important. I think that's the first thing: get out and walk around, get out and talk to the people.

The Columbia recovery was one of those that really paid back in dividends to get out and talk to those firefighters working on the ground and see what's on their mind and see how they do their job. Because how they do their job often reflected in what we needed to get our job done, to make our planning and to think ahead about where we go next and what we do next.

I believe that one of the most successful leadership skills that I have seen people use, and I've used it myself, is: don't be afraid to ask. If you don't know what the acronym means, ask somebody what the acronym means. If you don't know what they're talking about, say, “Wait a minute. Help me relate this to my toaster or to my car or something so I can get a feel for what you're talking about.” Whenever you would see a pitch, either in the FRR or someplace else, about "Is it safe to fly?" if you couldn't say it in a sentence: "It's safe to fly because I've tested it, I have analysis to support this,"—if you cannot say it in one sentence then we really don't have good rationale. I've heard, "Try to explain it to your grandmother." I really think you need to have rationale that's simple enough for a fourth or fifth grader to understand. If they can understand it, then you've got good rationale. So many times it has been very helpful in meetings to remind: "Hey look, let's try to get this simple." If you can't make it simple, then you probably don't understand it.

Wright: A lot of what you did before you even came here had a lot to do with planning your facilities and then all these projects that you've talked about. Give us some thoughts about major factors in successful planning and some of the lessons that you learned, maybe not from your mistakes, but maybe from others that were associated with planning.

Rudolphi: I'm pretty sure I've made about every mistake that can be made. Hopefully we've learned a little bit from that. There's a couple things that come to mind when you start thinking about a project or thinking about where you're going. I'll use this example: if you and your spouse are going to build a new house, and you go out to your favorite Chinese restaurant for dinner, and you're going to talk about it. You turn the napkin over and you draw a bunch of boxes: “We're going to have a living room, a dining room, a kitchen, and we're going to have the washer and the dryer over here, and we're going to have a basement.” Whenever you're done with that planning, you have spent 90 percent of your money.

It's the same way with a major project. If you decided you're going to have a rocket that's got a front end and a back end and a payload in between and you're going to do some fundamental things, you've spent 90 percent of the money. If you want to save money on a project, you've got to go back to the very fundamental design, fundamental beginnings. So many times we want to have the whole project and we want to save the money by using a different supplier of the bathroom fixtures or going out and buy the APU from a different source or buy the insulation material from a different—it's too late. It's too late. Oftentimes we go into projects early on, and we'll take a $100 million project that we've set down on our napkin and we rationally came up with, and we'll bring it in for $60 million. Well, it just doesn't work. You can't do that.

So the message is: when you start into a project, make sure that you've got your requirements right, your fundamental—I don't mean the second-, third-order requirements—make sure you got the very fundamental requirements down. If those are sacred, then put the resources to do that. I always practice having 30 or 40 percent reserve. I know the Program Managers always thought that was too much. But quite frankly, the amount of reserve you hold is very important, and 30-45 percent reserve is really what you need to have when you go into one of these “mystery programs” that we oftentimes go into. Or you'll run out of money before it's all over, and then you'll have to go adjust your fundamental mission requirements.

The second part of that is that if you make changes along the way, they may change the estimated cost, but the inefficiency that you went through in that is very costly, too. So give yourself some reserve up front. ETM-3 [Engineering Test Model] is an example where we did that. We laid out our plan step by step by step, put our funding in place, held our reserve, and executed it without having to replan, which saved us a ton of inefficient loss of dollars. The replanning effort is what kills you whenever it comes to the loss of resources available to do the project; everybody's got to stop, everybody's got to start over. It becomes very inefficient.

Going into planning a project, again, is one of those things that we have to have a little bit more knowledge about what we're going to do than sometimes we think we do. Getting the right people involved in the planning is important, people that know what it's going to take to put the parts together, know what it's going to take to manufacture the parts. Don't have to have a long dissertation on it, and they don't have to spend a lot of time on it. But they need to influence the duration of the project as well as the cost of the project. So again, it goes back to that fundamental thing: get some people around that understand it so you can make the estimate right the first time, because all that redoing is very inefficient.

I think about planning for the recovery effort. That was some real-time planning done there. I've often wondered why the Columbia recovery was successful and the New Orleans thing [Hurricane Katrina, August 2005] was not successful. I've wondered about that a lot, and I've thought about that a lot, and I've concluded there's one reason that the Columbia recovery planning and execution was successful and the New Orleans thing wasn't. The technical understanding of what we had to do at Columbia was very, very clear. We had a clear vision of what we wanted to do. It's sad for New Orleans, but I don't think that was the same story. I think we had the right resources and the right technical people leading that effort. Knew exactly what to do, knew exactly how to go do it. That's the difference. Took the time to get the people around the problem that went off and did it.

Wright: Speaking of people, how do you apply your lessons into providing good leadership and helping your managers perform at their best and how to build those teams? What are those types of practices and ideas that you have to build those?

Rudolphi: Whenever I think about what I want people to do, the first thing I do is put myself in the position of having my leader explain something to me about what they want me to do. What are they looking for? What do they need to know? Why are we doing this and what are those fundamental overarching needs out of all this? Try and have those discussions without getting too complicated. I think we at NASA have always been blessed with people that want to do what we want to have done. We work with a very high caliber of individuals. I think that what they want to understand is that the job needs to be done, and explain it to them in simple terms so they can go do it. Then get out of their way so they can do it.

I often use the term when I'm working with my folks, “The best thing I can do now is to stay out of the way.” Let people do what they're really trained to do and what they are capable of doing. The supervisors and leaders we have all got there because they're capable of doing something, and I think the best thing we can do sometimes is to trust them to do what they can do. Offer the opportunity for them to come tell you if they got a problem, and then ask them some questions about how it's coming. Just simple questions. Let them know that you're interested in what they're doing. Let your team know that when you ask for a briefing, the briefing is not being put together for me to stump you. The briefing is because “I don't understand, and I trust you know what you're doing, but I'd like to understand this a little better just so I can talk intelligently about it.”

So many times I felt like in my life I've had to put a briefing together and go talk to somebody, and it was because they were suspicious of what I was doing. Whenever people put briefings together under that kind of rationale, they'll tell you what you want to hear, and you'll be fooled in the long run. I think we have to keep the information on such a level that it's here to help people understand. And I think if you can explain it to me, you can probably explain it to that third grader. I've always tried to keep it as, “We're together in this problem, we're together on this project, and I'll not do your job, but I do want to understand your job. I want to understand it so I can do my job better if I understand what you're having trouble with.” Because then I know what to do; I know how to help. So many times it's not that way. So many times it's “Well, I don't exactly trust what your team out there is doing, so I'm going to dig on it a little bit.”

Wright: How do you pass on or how do you build that trust between teams? You've mentioned that managers have got to trust their employees, and then employees need to trust their manager. How do you work on that or how do you build that?

Rudolphi: We have a saying around, whenever I was on a project: "We need traditions." I think we need to repeat certain things. We need to celebrate certain things. We need to have traditions that people can count on. For example, for many years we had a tradition that the day before the launch, the propulsion team would go out and walk the vehicle down, just go out and look at it. And the team would get together, and we'd go out there, and as a group we’d gaggle around and we’d ask, "What does that over there do?" and "What does this do?" And the responsible person that knew something about that would spend a little bit of time talking about that. From my own experience, when someone asks me a question and I can effectively explain what something does, I've really built a real strong relationship with that person. He's asked me a question, and I have given him or her a description or a response, and all at once now we now understand something on a common level. It goes a long way in building trust in a team and character in a team.

Trust is probably the hardest part of building effective teams. It's a bit like your Thanksgiving dinner and your Christmas dinner; you take the kids to the beach, and we do it every year. People get to where they see those things as places where we have a chance to be a little bit vulnerable, a little bit open, and it doesn't hurt. If I say something or do something that is not impeccable, that group understands that. They can tolerate that and they can help me through that. If we don't have trust, we never really get down to where we can have a real effective conversation. Because if I'm not trustworthy to you and you're not trustworthy to me, then we stay on a superficial level.

We need to encourage traditions. They can be as simple as take the team out to lunch on Thursdays, or we go out together and look at the hardware on such-and-such a time, or we go walk around. But there's a time in there where you and your team have a chance for a bit of an intimate relationship where no one's in charge and we're just enjoying each other. Those have been very effective; we got the data to prove it. We use the training session that's called the 180-degree feedback or 360-degree feedback. We know that works. It's been very effective in my cases, for example, to move staff meetings around. If you have a staff of five people, then one out of every five meetings is in your office. Then we rotate it around where we get a chance to see people in their own environment with their own people doing things, as opposed to just seeing them all in a conference room that's very sterile and you don't get a chance to have that close moment.

Wright: What are some other thoughts upon how best to train and equip the next generation of Space Agency leaders?

Rudolphi: There's a certain amount of that thing that I talked about a little bit ago about having a time for a close moment, a vulnerable moment. I think one of the key methods for us training our new round of leadership folk is to take time to mentor young folks. We have programs. We have programs at all the Centers that allow an up-and-coming individual in their formative years to spend time working on the staff or working as a close assistant to the leaders. We probably don't do that enough. We probably think that once they've done it, they don't need to do it again.

It's one of those things that—if we want that kind of behavior—we got to take time for those people to see the benefit of that kind of behavior. They got to see us in action. They got to know that the leadership team is not a group of witches around a brew pot chanting magic. They're really just working problems the same way that these people work problems. And the techniques and the approaches that people use to get people to speak up and get people to talk and bring out the information and bring out the data—we really need to share those experiences with more people. Give them a chance to see that in action, get them to see the benefit of it, get them to see us screw up so they don't repeat those mistakes.

I have had the opportunity to mentor. I've been a mentor for the last five or six years that I was with NASA and had a different one every year. It was a very productive exercise for the folks that we had, because they did get a chance to see us in action. They did get a chance to see us, recognize that we're not just peeling off these answers and all these solutions—they take a lot of work, and takes people's input to make them work. They've seen us screw up and they've seen us do some good things, and all the while we're doing that, they're forming an image of what we are about.

Believe it or not, they take that image with them back, and they share that with the people that they've worked around. They do a world of good developing the relationship between the rank-and-file and leadership. They help a lot there. I took a couple of them with me down to Columbia on and off, and the experience and the maturity that they gained in that process—they've all done well and are doing well. Every one of the folks that I've ever mentored is doing well. Not because I mentored them, but because they see the benefit of what we're doing and they're willing to take on the challenge and do the job. And they all do very well.

Wright: What would you tell someone just now starting to look at or wanting to come into the space program? What advice would you give them?

Rudolphi: They can do it. The first message that so many of our young people need to hear is: they can do it. It's doable. It's hard, but if they've withstood the barrages of a college education, they can do it, and they can make a difference. I've been in the space program for 20-some years, and there's been people in it longer than I have, but I've never had a bad day at work. Even the days that were bad days, I have always enjoyed the work that I do. The work is enjoyable. Nowhere else in the world is the caliber of people on the general scale as high quality as the ones that are in this program. And, by the way, you can make a pretty good living and feed your family at the same time.

Wright: As we start to close down this morning, you spoke a lot about lessons and advice and practices and things that you've learned. What do you think is the hardest lesson that you've learned in your career? Or maybe the best lesson?

Rudolphi: I think the hardest lesson that I've learned, that's probably had the most influence on me, is that I could have saved seven people's lives. I'm not the only one. But I could have done that. I wasn't around for Challenger [STS 51-L accident]. I came to work the day of Return to Flight. I wasn't around for Challenger, but I followed the story a lot. I was there for Columbia. I could have solved that problem. I could have asked a question that would have stopped and made us think, and I think because of not wanting to be seen as asking the stupid question—and paid a little bit more attention to what we were doing, I believe there's absolutely no reason in the world why those seven people needed to perish at all.

That's a lesson that is clear to me that we need to get into our new rocket. We need to keep our rocket simple. We need to reduce the number of failure opportunities to the absolute minimum. Do it now. Do it at the front end of the program. Don't expect that, "Well, we'll accept that for now, then we'll fix it later." Never happens. Never happens that way. That was a hard lesson, but I think I'm hopeful that we'll bring a lot of those lessons into the new rocket and keep us from making some of those stupid mistakes.

Wright: Are there any other thoughts or any other notes that you'd like to share with us?

Rudolphi: One of the very fundamental things that I think is important that we continue to do: we have got to keep teaching our people to be curious. Curiosity and courage are the two things that we've got to demonstrate and we've got to teach. Courage comes in the form of: don't be afraid to ask that dumb question. Curiosity is: if it really doesn't make sense to you, it's probably not making sense to a lot of people. So don't be afraid. Put your curiosity to work and then put your courage to work.

Wright: All right. Thank you so much.

[End of interview]