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

Jerry W. Smelser
Interviewed by Rebecca Wright
Huntsville, Alabama – 15 May 2008

Wright: Today is May 15, 2008. We are in Huntsville, Alabama to speak with Jerry Smelser, who served as Project Manager for the Space Shuttle Main Engine and External Tank areas at the Marshall Space Flight Center, as well as a number of other leadership positions for NASA. 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. We thank you again for stopping by and visiting with us today for this project. If you would, we'd like to start with you telling us how you became involved with the Space Shuttle Program.

Smelser: My career with NASA and the Marshall Space Flight Center [Huntsville, Alabama] began in 1960. I was a charter member of Marshall Space Flight Center. In the early days, I worked in design on the Apollo Program, and then several years in manufacturing. One of my mentors was Bob [Robert] Lindstrom, and Bob became basically the Development Manager for the Space Shuttle Program. It was through my association with Lindstrom back in the manufacturing laboratory that I became involved as a member of the External Tank Development Program in 1975.

Wright: After that time period, your positions evolved, and your duties and level of responsibilities changed and grew more and more. Tell us about some of those positions and some of the challenges that you incurred during that time period.

Smelser: The Michoud Assembly [Facility, New Orleans, Louisiana] is a very large building, 43 acres under one roof, and had been used for the Apollo Program. The Chrysler Company sat in one bay, and the Boeing Company sat in another bay—winding down in terms of use of the building. We went into that building as an External Tank Project and basically began to lay out the flow of the hardware, and the design of the tooling, and the conceptualization of how the tools and the flow of the plant would accommodate the external tank. I was involved, working directly for [G.] Porter Bridwell. Jim [James B.] Odom was Project Manager in the design, the layout, and the flow of hardware through the plant in the early days. Eventually, I became manager of the structural work breakdown structure, WBS, for the external tank. Worked with the contractor in the design and development and structural testing for the external tank.

As the program moved from the early development phase and began to look toward test program and flight program, I eventually became Business Manager for the External Tank Project. After some time in that job, I moved into the Space Shuttle Main Engine Project. We were also in a plant renovation—upgrade of the plant equipment at the contractor facility in Canoga Park, California. So I spent the next few years in the Shuttle Program helping retool and re-machine the plant in Canoga Park to better accommodate the hardware requirements for the Space Shuttle Main Engine Project.

From there, I became Deputy Project Manager for the Space Shuttle Main Engine, and worked under Bill Taylor, who was Project Manager, and we ran the flight program for the Space Shuttle Main Engine. There was a development effort that was headed by Joe [Joseph A.] Lombardo. Those were two parallel projects for a while. Subsequently, after [Space Shuttle] Challenger [STS 51-L accident], when the two projects were combined, I became deputy to Joe Lombardo, and we had both the production and the development of the Space Shuttle Main Engine.

I was selected initially to become Project Manager to the External Tank Project, but when Joe retired, they asked me to become Project Manager on the Space Shuttle Main Engine. And I served in that role for several years in the early 90s. I left the Shuttle Program and became involved in the joint Air Force-NASA Program. Some people refer to it as NLS or ALS— Advanced Launch Systems, National Launch Systems. I was heading a group that was developing a new engine for that joint Air Force-NASA program. The program, after a few years, was under-supported and under-funded, and we never reached the point of making that hardware happen. We had contractors on board. We were doing a consortium that involved all three—Aerojet, Pratt & Whitney, and Rocketdyne—in a joint development program. Very innovative, we thought, in terms of how we were doing that. But the program never reached the point where it became a full flight development program.

Then I was asked to come back home to the Shuttle Program. When we agreed to become a partner with the Russians and we changed the location for Space Station and we needed more lift capability, I headed a group of people who redesigned the external tank to what's referred to as a super lightweight tank. We developed some extremely innovative weld techniques that involved a material that had never been used in a cryogenic application before. We also began to develop friction stir welding as a new process. The combination of new materials and new process gave us better properties. Both were very significant in helping us in terms of achieving the weight reduction objectives for the super lightweight tank. We delivered that development effort on cost—under cost, actually—and on a schedule that supported the needs of the program and met our weight objectives, so we were very, very pleased with the ability to bring that program online and make that happen for the Agency.

I left the Shuttle Program again, and went and did some other things for the Agency—I ran the test lab at Marshall Space Flight Center for a while and helped with looking at new launch vehicle concepts and some of that futuristic kind of planning that was going on throughout the Agency—and then came back on to the Shuttle Program as External Tank Manager again. From that position, I retired in 2004.

Wright: Your positions changed, and again, your roles and responsibilities changed. Can you share with us, during all those times, some memorable ones where the challenges that you encountered gave you some lessons learned that you were able to apply to the rest of your career?

Smelser: I think the Shuttle Program was extremely challenging from a vehicle standpoint because it was more than one body that was trying to fly together, whereas the Saturn Program was one body—cylindrical, with a column on top, an engine in the back—and we could pretty well predict the aerodynamics and controls that were required. On the Shuttle Program, you had an airplane that was attached to a cylinder, and they have different aerodynamic characteristics and don't necessarily try to fly in the same way. So I thought the aerodynamic challenge, the guidance and control challenges of a cluster of bodies that don't necessarily want to fly the same way, was extremely challenging. I'm not a flight mechanics person, but as an engineer, that was a very, very interesting challenge that the Agency took on and was very successful at.

One of the things that intrigued me as an individual is when Bob [Robert L.] Crippen and John [W.] Young flew the Shuttle off of the back of the [Boeing] 747 for the first time, because I was personally very concerned about the separation dynamics and the potential for recontact. From an excitement standpoint, the success of that was very exciting. I've seen some great successes. I'm old enough and go back to the Apollo Program, when I saw some of the [Dr. Wernher] von Braun team cry when the Saturn flew the first time. There's that kind of emotional attachment to programs, and I think some of us attached to the Shuttle Program, with that kind of an emotional attachment.

From a personal standpoint—seeing a plant go from an open space to see the hardware actually flow through a plant as large as the Michoud Assembly Plant and see what I call the world's largest lathe—they're really weld fixtures, but they're performing large diameter welds, like the final circumferential wells on tanks as large as the liquid hydrogen tank and the liquid oxygen tank—to see that transformation from open space to a flow of hardware and be able to know that at least at some level, I made a contribution. I remember when I looked at it on a drawing and thought about whether it should be this way or that way, and then you see it happen. I take great pride in seeing something physically happen that I at least had some level of involvement in, in conceptualizing or designing or influencing the design. That was a great reward, investment/reward kind of a career.

I've already mentioned the super lightweight tank. That team just was a phenomenal team, and we really had some tough challenges and unprecedented kinds of things that we made happen, so that was a very fulfilling venture for me. Space Shuttle Main Engine Program—that engine is so complex and so challenging in terms of the technology involved and the environments that are involved, and to be involved in incorporating some really significant safety features into that engine upgrade—alternate turbopump and different concepts in terms of the controls and so forth—to see them fly for the first time successfully, you just take great pride in being part of that. It's been a career that for a young engineer that comes off of a farm in north Alabama, and goes to college, and gets an opportunity to be a part of something as exciting as the Apollo Program and then the Skylab Program and then the Shuttle Program—it's just a career path that I think was unparalleled for that time frame for an engineer. I've been very fortunate in that regard.

Wright: I have a question for you about planning. You've worked in the areas in Apollo, and then you've worked in the areas preparing for Shuttle, and then after Shuttle was on production or in operation—tell us about some of the aspects of planning that you were able to apply across your whole career, and then if you had any aspects of planning that had to change because of how the operations changed.

Smelser: For complex programs—and the Space Shuttle or the Apollo are complex programs—one of the weaknesses, I believe, that often work their way into a program like this is insufficient emphasis on testing in the front end. In the Apollo Program, where we had unlimited budgetary resources and a fixed schedule, we really did emphasize testing—the testing of the engines and the cluster—and it was test, test, test. I think in the Shuttle Program—in retrospect—I think we did not do sufficient front end, in depth, aggressive testing. We had a good test program, but I just believe there were areas where we could have invested more in our test program earlier, and learned more about the hardware itself.

So I'm a very, very strong advocate of test, test, test. When I ran the engine program, I had a motto that I shared with the people: "Listen to the hardware, listen to the people, and listen to your gut." In order to listen to the hardware, you have to test it, and you have to test it in a way that demands that the hardware perform, maybe over perform, until you find out where the weak links are. So if I think the next generation should learn from us, it's don't cut corners on the test program, especially early in the program. Have an aggressive development program, have an aggressive test program, and listen to what the hardware's telling you.

Wright: You had so many people that you worked with, and then many that you were their manager. Talk to us about your management style and especially the aspects that you did to encourage or to instill good management performance with the people that you had trusted to get the job done.



Smelser: I know the people that work with me and for me would tell you that I'm a hands-on manager. I've spent many, many hours walking through the Michoud plant, interacting—and I can go back to the Apollo Program when I was in the manufacturing lab. I'd go out and talk to the welders and the assemblers and machinists, and show them a drawing and say, "Now, how would you make this come together?" So the first thing I do is I make sure I involve people at the lower levels in the process early. Don't give them a job and say, "They'll do the job." Make sure they're involved in the job early.

By nature, I'm not a people person. By nature, I'm an engineer type, and my wife will tell you engineers are weird. She had a cadre of engineer wives that all compared notes about us, and we're a weird breed. By nature, I'm not a people person. I'm an engineer. So a part of my involvement with people—I had to work with myself. But I do delegate well, I think, and trust people once they show that they're trustworthy. I tend to ask challenging questions, and I believe one of my skills is to know whether or not people are really leveling with me when they answer my question.

People that have worked around me and with me will tell you that one of my techniques is when people were using big words and fancy phrases, I would say, "Would you repeat that in farm boy language?" to get them to think in terms of a different level. Not impressive with words, but impressive with facts and information, rather than buzz phrases and shiny words. I tend to try to take complicated scenarios and simplify them in a communication setting where everybody feels comfortable with the phraseology that's being used and with the terminology that's being used.

I can be demanding, maybe harsh. But I try not to do that very often. I believe very strongly in rewarding people that do well. And, on occasion, you have to deal with people that don't do well, and that's not the easy part. That's the hard part of managing, actually. The easy part is rewarding people, except for the fact that the government bureaucracy sometimes limits what you'd like to be able to do. But certainly, I've found ways to do that.

I'm a great believer in setting objectives and goals and specific expectations and measuring against them. When I managed the contractor, at the beginning of the year, we always laid out in a book what our expectations were for that year. And monthly, as a minimum, we would go back with our contractor counterparts and review all of the objectives that should have been met to that point in time if we were going to meet the objectives for the year. If we started falling behind, we applied more focused attention. We do it biweekly, and if that's not working, we do it weekly. That way you have an understanding between the government management and the contractor management of what the expectation is going to be at a macro level, but then you also have it broken down so you know what you have to achieve as time progresses.

Months aren't very long when you're working on a long-range program. Pretty soon it'll be two months instead of one month, and you won't have met your objectives unless you measure yourself. That's very significant, also—I hold myself accountable for whatever project I'm responsible for, but I also hold other people responsible for subsets of that. But I understand that the accountability moves up the pyramid, and that at some level I'm responsible, and then at some level, my boss is responsible. So I'm accountable to him.

That's another part of managing—to make sure that not only you manage down, but you also are able to communicate up. You don't want to take so much of your boss's time that he thinks you're asking him to do your job, but on the other hand, you have to keep him informed so that he doesn't get a question from somewhere that he hasn't heard. Something that's going on, about to go wrong, or about to go right, and he hears it from someone else. There's a real thin line between communicating too much and not communicating enough, to make sure that your superiors are able to understand and support your position, and understand what progress is being made or what areas need some help from them.

Wright: That's true. You mentioned about learning to know who to trust, and that of course they had to trust you, too. What can you share with us, some techniques or methods that you use, to know that someone now can trust you as a manager, and that you'd be able to trust them to do the task that you wanted them to?

Smelser: The first thing, of course, is selecting people in your organization that you have some familiarity with in terms of background. You can't always do that because when you're building an organization, you like to build at least some cadre of the people that have not only expertise in what you're going to do, but also have a personal relationship that you know is going to work. Then you augment that with people that you bring from the outside or from other organizations within the government or within the contractor workforce.

The way that I attempted to do that is when you bring in new people—you think they have the skills, but they haven't proven it to you yet. They haven't worked in your system to make sure, and some people are very effective in one system and they just don't work in another system. You have to make sure that there's compatibility not just in ability, but personal compatibility. If you give people the feeling of responsibility and accountability, and you do that at a smaller piece level to begin with, and they produce, then it's time to expand their responsibility and accountability.

I've found that that's very successful, and frankly, I've been very fortunate in terms of the people that have worked with me because I've had some wonderful young engineers who are now mid-level engineers that are just doing great. Matter of fact, I'm doing a little work right now with a person who a few years ago worked for me, and at this point I'm assisting him. He's in a decision-making role, and I'm a consultant that offers him some advice when he needs it, but he's the guy that makes the decision now.

That kind of a relationship evolves over time, and I could identify probably a dozen people who have come through my organization—not just mine, of course, they were in different organizations as they moved up the line, and have advanced to levels beyond which I ever went. I could identify a Center Director that used to work for me, or a Program-level Manager that used to work for me. I consider that just absolutely tremendous, that somebody that I had some influence on years ago is now in power positions. Delegation, responsibility and accountability are the three things that I think are important in that regard.

Wright: You mentioned when you were in charge of the super lightweight tank project that it came in under budget. That must indicate that you have a concern about program efficiency. How best did you ensure that your programs were efficiently being carried through with those goals and objectives that you had?

Smelser: The way to make that happen—and we're not good at that within NASA—is to understand on the front end what the requirements are, have a negotiated and understood schedule and cost that both parties agree to—I'm talking about the person supplying the money and the person that's fulfilling the obligation or doing the job—don't change the cost and don't change the schedule and don't change the requirements. That's sort of in a dream world, I understand that. But that's the way to deliver a program on schedule and on cost—understand the requirements up front and don't change them.

There has to be flexibility. The thing that happens is as a program, like a Shuttle Program, evolves, we get smarter and requirements change, and both parties then have to make fair adjustments in the schedule and the cost associated with the changes that are inherent with a big program, as we get smarter. But there must be a continual emphasis on understanding requirements, meeting requirements, and maintaining—as I indicated earlier—maintaining on a small increment of time basis—some people call them inchstones to get to footstones, and footstones to get to yardstones, and yardstones to get to milestones.

I can't manage at the milestone level. I have to manage much lower than that, but I hopefully don't have to go down to the inchstone level, but somewhere in the middle level is where I have to understand what's going on, and I trust my sub-managers to manage at the inchstone level. All through the pyramid of organization, people must understand at all levels what the requirements are and what the expectation at each level is.

A manager at a project management level has to really listen effectively. I indicated earlier, listen to the people. You have to listen effectively to the people who work for you, as well as the people that you work for. You'll listen to the people that you worked for because they demand that. The people that work for you can't demand it, so you have to demand of yourself that you listen to them. Because they know what's going on lower down than you know what's going on. And if they are the right people in the right jobs, they're going to give you information that's very important as you go on, and you need to react to it effectively and promptly.

If they think they've got a problem, they have a problem. It may not be a real problem, but if they think they have a problem, it's a problem at that point in time, and you have to address it one way or the other. You have to either erase it in their mind as a problem, or you have to solve it and make it a non-problem. Or you have to go get help. If it's bigger than the two of you, you have to go get help.

Wright: I think I can positively say that almost every decision you made in your career had some level of risk to it, it just being a part of the nature of the business and doing the Space Program. Tell us about some of the lessons that you've learned or some of the practices that you instilled so that when decisions were made it was a good basis for risk assessment.



Smelser: I'd like to start my answer to that by telling you about an occasion in California when I was speaking to a high school group. One of the students said—we were talking about the engine, and I was telling them about the Shuttle Program as a whole, but specifically representing the engine projects at that time—he said, "Isn't that a risky business?" My answer was, "Do you drive an automobile?" Of course he said, “Yes.” I said, "Well, that's a risky business, too." The difference is, in my opinion, we get so familiar with driving an automobile that as a group, we really forget that there's significant risk until we get in trouble with it, and then we realize that we made a mistake. But a lot of times, we'll make a mistake because we don't treat it as though it were risk management. Driving a car demands a great deal of risk management.

The Shuttle Program—very complex. There are inherently very, very significant risks involved. Anytime you put people in a machine that complicated—be it an airplane, be it a Space Shuttle, be it an automobile—it has levels of very significant risk. Space Shuttle—more complex than an airplane, more complex than a car. People on top. It requires risk understanding, risk mitigation, continuous risk assessment, risk reduction.

The problems we have, in my opinion, within this Agency and probably any complex piece of machinery, is not managing the risk we don't understand. We manage the risk we understand. The problem is there are risks out there that we haven't yet done enough testing or had enough exposure in terms of opportunities. They're risks that we think are managed risks or non-catastrophic risks that really show up one day as a bad day. Inherently, I know that if you manage something this complex, there are going to be failures. What we want to do is make sure that the failures are failures that are not catastrophic. That's the intent. Then learn from each one of them in terms of how we apply the new knowledge not just to that particular item, whichever one it was that didn't perform to expectations, but apply that to similar hardware across the total program.

In order to manage risk, we have to understand what the risks are. That's the biggest challenge, in my judgment, is understanding what the risks are. We can do failure modes, and effects analysis, and critical items list assessments, and we do all the analytical things and engineering things that are practical to do, and there are still things we don't understand about the hardware. It's those things that I believe are more bothersome, and they're the ones that eventually cause us to have bad days. I mean, we've had some wonderful days, a lot of great days, and we've had some bad days. When we have a bad day, it's a really bad day. That's the thing about it.

Wright: Can you give us an example of a time that you know of that was a successful risk mitigation activity? Something that might have been going one way, and because of a process or involvement, that it became a good day?

Smelser: I'm not sure this quite fits the category, but it's certainly on the same subject. I alluded the alternate turbopump as a change in the Space Shuttle Main Engine. We went from a turbopump that had numerous welds, and numerous opportunities for leaks—although it was a great design at the time, it could be improved on. So we went to a new contractor, developed an alternate turbopump, and incorporated that—after an aggressive test program—into the fleet, and with that, in my judgment, came a substantial reduction in the risk associated with the engines that were flying each time. There's a place where there was a substantial investment made in an ongoing flight program with a development program that was introduced appropriately to bring the risk down associated with the engines.

This was something I was personally involved in: when we went from fusion welding to friction stir welding, we reduced the probability of having defects. We reduced the number of defects we know in the welds; we reduced the number of repairs that were in the welded hardware. In that case, what we did was reduce the probability of losing a piece of hardware in a proof-test. It should never have made its way to the flight program, but it could very well have caused the hardware to fail in the proof-test, and we'd have lost assets. Substantial loss—millions of dollars worth of assets. In that case, there's a process that we brought into the program that reduced the risk, at least from a programmatic standpoint and from a loss of hardware standpoint. Not necessarily from a loss of life standpoint.

We did numerous things when I was a part of the Launch Management Team—a lot of things in leading up to the week before the L minus actions that went on. A lot of things we looked at and assessed. Some people were looking at weather, we were looking at the hardware, we were looking at the instrumentation, we were looking at how the hardware was performing, looking back at the test program to see if there was anything that we saw in our ground test program in the engine test that we should be aware of before we flew.

All those things were incorporated in the thought process as we led up to, came up to, and signed off on the release of the hardware to fly. In flight, from an engine standpoint, we had certain instrumentation that told us the health of the engine in terms of temperatures and pressures and environments that were happening. There was one time where we actually shut down an engine on the way up the hill. But that was an instrumentation issue rather than a real failure—that's a case where an instrument told us that something was wrong, and we actually shut down an engine and still were able to achieve orbit.

There are a lot of things that have been done by different managers, and there've been days when I was in the position to have to say, "The engine's not ready to fly this week." Of course, the Orbiter had similar situations, where we’d get back data from an instrument that said there's something we don't understand, or the controller's not working right, and we're going to have to go in and do some double-checking—go back and check our sim model and see what's going on. There are numerous situations throughout the program where we've either called off a flight that day, or we've changed hardware over time, or changed procedures to incorporate the additional safety features into the system.

Wright: Given your years of experience, are there any improvements in planning or implementing risk mitigation that you would recommend that the Agency look at?



Smelser: I thought, as a system, our risk mitigation/risk management system was fairly effective. Not everybody agrees with me on that, by the way, I know that. I think it's the knowledge base that was the problem. I think when we applied the risk system, which I think was a good system, and when we fed into that sometimes information that wasn't precisely accurate or complete (it wasn't inaccurate from the standpoint of people not putting in their best knowledge). They put in their best knowledge, but sometimes our best knowledge just wasn't really quite good enough. I don't know how you design a system to do that.

I do think a more aggressive test program, which I've already emphasized, would help. I'm not saying it would eliminate all the problems because you're never going to eliminate all the problems. I understand from having been in this business for forty-three years plus that there are problems that you're never going to understand. You certainly attempt to. You want to and you try to, but there are going to be some things that we just don't understand, and the next program will have issues. Hopefully they'll be non-catastrophic issues, but they'll have issues that they won't understand until they actually happen. Then they look back and say, "Well, that was an opportunity to have advance our knowledge base."

That's why I keep emphasizing, and would emphasize with any new managers who are making decisions, to just test as much as you can and learn as much as you can on the ground. Let it fail. It's okay for hardware to fail on the ground because you learn something. As long as you make application from that failure. If you test an engine and it fails, you had a weak point that you needed to know. If you test a tank and you test it to failure, you find out where its weak part is. That doesn't mean test all of them that way, that just means to test enough to find out where the weak points are and see whether or not the weak points are acceptable for a flight program.

Wright: What about improvements or recommendations for improving management processes that can lead to those good decisions?



Smelser: That's an interesting question. Eventually, there has to be somebody that makes the final decision. That somebody, whomever that is, has to have a system that they're comfortable with. It must have a pyramid effect because you have to go down and get information. The great criticism—I think it was an unjust criticism—but the great criticism was that we didn't listen to people who were in the ranks. I honestly did not see that within the Agency I worked in for years. The managers I was around—I'm like the rest of them, I'm accused in a broad sense of not listening to the people. One of my theses was to listen to the people. But some way we don't convince the outside world that we're good listeners.

I really believe that the Ron [Ronald D.] Dittemores and the Tommy [Thomas W.] Holloways and the Arnie [Arnold D.] Aldridges and the Bob Lindstroms and the Jim Odoms and those people—I really believe they were good listeners. I believe that people that worked for them were good listeners. But maybe we weren't, and maybe we don't understand. Maybe it's back to that engineer syndrome or something, I don't know. From my perspective, I did not see that communication was ignored. But I know we've been accused of doing that. Let me finish that by saying if we were guilty of that, the next generation needs to make sure that they're not guilty of that. Make sure that they do listen down as well as up.

Wright: That leads into my next question. How would you train the next group of leaders for the Space Agency?

Smelser: At the leadership level, there needs to be a good combination of technical skills, managerial skills, “excite the people” skills. Wernher von Braun was absolutely a master as an engineer, as a visionary, as an entrepreneur, as a motivator, as a politician. It's hard to find the skill set of Wernher von Braun. There needs to be somebody at the top, with a combination skill set that's not strictly engineer but not strictly business guy, not strictly communicator. There needs to be a skill set, a good mix of those skill sets.

I thought people that I worked for—I thought Bob Lindstrom was very good. He wasn't deep technically in my opinion, but you couldn't snow him with a technical issue. He was deep enough to know when you weren't leveling with him. He was a good communicator, he was a good motivator, he was good representing the Center outside the Center. I thought he had a good skill set for that job. I think some people at JSC that I could name that had good skill sets for that.

Ron Dittemore had good skill sets for that. We need people of that skill mix to manage a program and be able to understand the programmatic implications when a test program is not giving the right results. Understand the political climate, at least to some degree. Understand the technical interactions of machines and equipment and hardware. It starts with having that kind of leadership. We need that.

I think the Agency is doing a good job with this now, but we need to get some good, young people with some experience. We really messed up as an Agency when we went through the valley in terms of between the Apollo Program and the Shuttle Program. We didn't bring people on, and we had people at the middle level, people right out of college, but we had a void in terms of middle management, lower management at the time of the early Shuttle Program—in my judgment. I think the Agency attracted some very, very good talent into the Agency now, but to make sure that we've got a good mix of skill sets across all levels is very important. To make sure that we don't have a valley in terms of mid-management or lower management. That's important.

Wright: How do you teach or how do you train these young people with those aspects that you feel like they need to have to become leaders?



Smelser: Excellent question. I believe there is absolutely no substitute for hands-on, get out in the shop, understand how the hardware works, run a test program for a while. I would absolutely insist—if I were at an upper, decision-maker level—I would absolutely insist that my managers have been around hardware—at least some of them—to understand how hardware works. Not just have been on the computer and looked at what the computer tells you it's going to do, but have actually been out there doing it.

I believe we're doing a better job of that. I think we are. At least, I'm being told we are. We're doing some in-house projects, we're doing some in-house testing. I was very disappointed as a middle manager when we lost our manufacturing capability at the Marshall Space Flight Center because I thought that was an outstanding tool for developing managers and engineers. It was disappointing to me when we lost that. I'm not talking about competing with contractors. I'm talking about doing the development work, but doing it hands-on. I think hands-on experience for young engineers is absolutely mandatory.

Wright: What advice do you give young people who want to have a career with the Space Agency?

Smelser: I'm not encouraged right now. I have a son who's a medical doctor, I have a son who's an engineer, and I advise them to go into telecommunications or medical science. It's not like it was when I came. When I came out of engineering school, the place to go was the Space Program. My personal opinion is that there are more exciting futures for an engineer for the next 20 years than the Space Program. Maybe I'm wrong. Hopefully I'm wrong. But if an engineer came to me and said, "Where's the place to work in the next 20 years?" I'd probably direct him to medical research or telecommunications. Hopefully I'm wrong, but that's the way I see the future. That's not negative about anybody at the Agency, I'm just talking about the political climate. Maybe energy engineering if it exists in the next 20 years.

Wright: You worked in so many different areas. What would you consider maybe the best lesson or the hardest lesson during that career that stayed with you?



Smelser: There are a lot of lessons that you learn over that long a period of time. I really can't identify one right now.

Wright: Before we close, I wanted you to have a chance to look at your notes. I know you brought some things.

Smelser: All I did was I took your questions and just put down some notes. I think we've covered most of that. Test before you fly, we talked about that. Listen to the hardware, we talked about that. Make an appropriate upfront investment, we've talked about that. Don't cut corners on design and development tests, we talked about that.

Wright: Is there anything else you can think of that you'd like to add about sound practices or lessons learned, or planning, management? Any other thoughts before we close out for the day?



Smelser: The only thing I'd say, and it's the same thing I've said, but I'll try to summarize it—make sure you understand the program up front in terms of requirements. Make sure there's adequate schedule for doing a good job of design, development, test. It may be impractical in today's environment, but if possible, lay out a reasonable schedule and don't change it, or change it as little as possible. Those are very important parameters for a successful program, in my opinion.

Wright: Those are good ones. So thank you. I appreciate it.

Smelser: Thank you.

[End of interview]