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

Robert B. Sieck
Interviewed by Rebecca Wright
Kennedy Space Center, Florida – 22 July 2008

Wright: Today is July 22, 2008. We are talking with Bob Sieck, who’s served in a number of leadership positions in the Space Shuttle Program, here at the Kennedy Space Center in Florida. This interview is for the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright, assisted by Sandra Johnson. Thanks again for coming in to visit with us at the Center today. We’d like for you to begin by telling us how you first came to work with the Space Shuttle Program.

Sieck: I started on the Shuttle Program in ’71, ’72, somewhere in that timeframe, from the job I had, which was on Apollo spacecraft, the Command/Service Module. I was a test team project engineer. What that meant was I was involved in, for the particular mission that I was assigned to in the Apollo Program, heading up the NASA engineering test team that worked the spacecraft processing from the time it was delivered here to KSC [Kennedy Space Center] until it was tower clear out at the launch pad.

I transferred to the Shuttle Program, specifically the Shuttle Project Office here at KSC, because they wanted to get the benefit of those of us that had been involved in processing human spacecraft early in the design phase of the Space Shuttle, specifically the Orbiter, but the system as it were. So they formed a project office down here at KSC, and they got a number of us that had been involved in the various elements—processing of the pieces of the Apollo Program, the rocket, the ground facilities, and the spacecraft in my case together, so we could be in on the ground floor as it were of the Shuttle development. I don’t remember the specific year, ’71, ’72, but it was in that timeframe when they were going through the preliminary design review process for the Shuttle.

Wright: Tell us where that evolved. I know that you were also involved in the ALT [Approach and Landing Test] out at [NASA] Dryden [Flight Research Center, Edwards, California].

Sieck: Well, that evolved after the initial design phase and the production contractors got into the business of finishing the design and then building the hardware. We started on the facilities here at the Kennedy Space Center. I stayed with the Shuttle Project Office until they started the Approach and Landing Test Program out at Edwards Air Force Base [California], Palmdale [California], where they built the first non-spaceflight Orbiter, Enterprise. So they again got a group of us that were involved in the processing of human spaceflight hardware. They took us out there, the NASA team.

The Kennedy Space Center had the government responsibility for processing the Orbiter Enterprise for the Approach and Landing Test Program, just as if it were a spacecraft and a mission that would launch from KSC, and NASA-KSC had the responsibility for that. Well, out at Dryden, NASA-KSC had the responsibility for processing the Orbiter Enterprise from the completion of its manufacturing to the first flight and then all the subsequent flights that were part of the program.

So I went out there as the engineering manager for the NASA processing team for Orbiter Enterprise, which was good, because it allowed us—and we worked with the contractor, which was Rockwell [International Corporation] of course. They were the hands-on people, just like they were here in the Apollo Program for the spacecraft. So that was good from two standpoints. One, we were experienced. Again, the NASA team, which was not only engineering, but it was operations people, it was planning people, it was inspectors. The same type of team that would process spacecraft down here in Florida at the Cape [Canaveral] processed it with the contractor out there.

So we had experienced people doing the job, which was good, and it gave us the proverbial leg up as it were on understanding the nuances of a Space Shuttle Orbiter, so that when the first space-rated one, Columbia, would be delivered here at KSC, there was already a knowledge base in place from how to process the systems that were used on Orbiter Enterprise that would be the same as, of course, on the spacefaring version of an Orbiter.

Wright: What lessons or processes were you able to basically transfer or transition from what you had learned doing the Apollo spacecraft to what you were able to do for the Shuttle?

Sieck: As it usually turns out when you process spaceflight hardware, the flight hardware the first time through ends up training the team that processes the hardware. So you have the opportunity not only for the people skills, but you refine your procedures that at first glance when you’re putting them together sitting in a room, in an office, figure, “Well, this’ll work for checking out the latches or the computers or the flight control system.” And then when you start working your procedure against the vehicle, you say, “Oh well, I hadn’t thought about this, hadn’t thought about that, or this really works different than I had envisioned it.”

So you get to refine your procedures. You train the people, and you’re using the procedures. In checking out and processing a vehicle, there’s a lot of test equipment you have to hook up to it. In spite of the fact that the Orbiter was designed to be a self-checkout vehicle, it really didn’t end up that way. That’s another subject. So you end up making the necessary changes to your ground support equipment to be compatible with this flight hardware.

As a result of the Approach and Landing Test Program and processing Enterprise, we were able to fix a lot of things before we saw Columbia, the first space-rated vehicle, for the first time down here. So we were much better prepared to process it, and as a result there was less risk to the flight hardware when it was first delivered here, because we had already found out for, again, the systems that were similar in the Orbiter, we found out what the limits were for processing those systems on the ground. Everything from how long to leave something powered up to how hot you could let it get to how cold you have to get it to how many times you can operate this before you have to wait. That type of thing. We learned all that out in the desert processing Enterprise.

Also our system of planning and scheduling the work. A lot of the technical systems on the Orbiter are very complex. You may make your judgments before you know that much about the system, that, “Well, I can do this test in parallel with that test.” But then when you actually get to doing those tests for the first time, you find out that there’s conflicts. Either the technical capability of the Orbiter isn’t the same, or you require similar resources external to the Orbiter that can’t do this multitasking work at the same time. So the process of planning and scheduling, again, benefited from the Approach and Landing Test Program, which became very important down here as we dealt with trying to optimize our ability to process an Orbiter from landing to its next launch.

Wright: As the Shuttle was coming online, and before it came online you had a number of people, due to the gap between the Apollo Program and the Shuttle Program, leave or change jobs or move on. How did that impact your team that now you were training to work to prepare for the Shuttle? Did you have a whole new group of people, or did you have some that you had worked with in the Apollo days that were able to transition with you?

Sieck: I would say there was a mix. There were a lot of holdovers, government and contractor, from the Apollo. But relative to Apollo, Shuttle was an order of magnitude more complex, particularly the use of computer systems, the onboard system and the ground system. So even the veterans such as myself had to come up to speed on the use of computers in the work that we did. So the veterans in fact probably struggled with that more than the newcomers. In Mercury, Gemini, and Apollo, yes, there was a ground computer that talked to the vehicle, but the one computer that was in the spacecraft for instance had less computational power than a BlackBerry [PDA, handheld personal digital assistant device]. So yes, we used computers in the previous Programs, and as you know later on in the sixties and seventies computers became—they really came into their own. So us old-timers had to forget about switches and dials and this sort of thing and get used to things called software programs and sitting at a keyboard and typing in things. That was a major transition for us, relatively speaking, old-timers.

The newer people that were hired, whenever we built up down here to get ready for the space part of the Shuttle Program and having two and three and four Orbiters in flow at a time, the newer people were better prepared for the technology that the Shuttle brought with it than us old-timers. Sure, a lot of new people came on board. Those of us that had experience in Apollo and out on the Approach and Landing Test Program, probably in hindsight, moved into more of the key jobs whenever Columbia and the rest of the Shuttle hardware was delivered to the Cape in the late seventies, early eighties. Again, we were able to use the benefit of our knowledge to help train the new folks. But the first process for the first launch, STS-1, the Orbiter was here for so long. It required a lot of tile work.

I would say that Columbia, one of the major things it did, other than being the forerunner in the Program, was it trained the team. Trained the KSC team, trained a lot of people in the Program too, as we processed it and people found out, “Oh, well, this is the way this works,” or, “You can’t do this, but you can do this.” A lot of the requirements, a lot of the plans that were put in place before the hardware actually started processing got changed in that year to two years that Columbia was down here going through all the tile work and all the other systems development work, as well as being put together, because it was shipped here with some assembly required—a lot of assembly required.

Wright: You were Director of Launch and Landing Operations at that time, is that correct?

Sieck: Well, after the first [seven] flights I was. The first few flights I was in the control room. I was the Shuttle project engineer in the control room. Similar job to what I had in Apollo, but in charge of the integrated procedures for processing the vehicle—not just the Orbiter but the tank and the boosters—as well as during launch countdowns. So the requirements and all the integrated testing management was the responsibility of me and my office, and then after the first [seven] flights I became Director of Launch and Landing Operations, which had the Launch Director in that as well as all the operations and the planning people for NASA.

Wright: You had a relatively large team that was under your leadership. You mentioned about computers making a big difference. How did you communicate? You had so many requirements you said that were changing. The assembly needed to be done when you got here. Share with us how you set up or how you helped enhance a communication procedure that everyone knew what was going on, and that you had those assurances that things were being done correctly.

Sieck: Well, there’s two aspects of the management role down here in processing a vehicle like the Shuttle. One is the internal. Internal being the government contractor team at KSC that has the responsibility for developing the procedures, the software, the ground equipment, and executing those procedures with the processing of the flight hardware. It’s a government contractor team, thousands of people. You set up your organization—the classical way you do it is you have an engineering group, you have an operations group, and of course you have the safety and the quality, and you have the support organizations.

One of the benefits, again, of the Apollo Program is that people here understand the importance of teamwork and communication. So managing that government contractor team, many people were the same for NASA. Yes, sure, we brought some new people on. But the contractor people, for the most part, particularly for the Orbiter, were Rockwell, same people that processed the spacecraft before. The support organizations that take care of everything from all of those facilities that are out there, the cranes and the launch pad equipment, they were all experienced people.

So the importance of communication and running a safe and orderly process, put safety first, they understand that well. The major challenge was the external communications. The Program in the past, in Apollo Program, the Program office was very small from the viewpoint of the Kennedy Space Center. We had total control over the contractor, all the equipment, and all the processing, and all the scheduling, and for requirements that were implemented down here, pretty much control over those too. That was different in the Shuttle Program. Very large Program office, a lot of controls over what we did and how we did it. Not only from the government standpoint you had a large Program office, but each of the elements in the Shuttle, the Orbiter, the tank and the booster, they all had separate Program offices too, which we had to interface with.

The requirements in processing the vehicle, what you had to do, what you couldn’t do, the limitations that went with that, the requirements and the approval of requirements and the change of requirements, that system grew significantly from Apollo. Working with the contractors, who now had a NASA Program office that actually directed them that lived in another Center, increased the degree of difficulty for getting work done. It put much more demand on communication and cooperation. As a result, you worked your issues with those particular Program offices, project offices we’ll call them, but you often had to go to the Program office for help. Level two as it were. We had this structure: level one [NASA] Headquarters [Washington, DC], level two the Program, and then you had a whole lot of level threes.

So the external management, coordination, particularly for all the things that happened on the day-to-day basis, it put a real demand on our ability to communicate. Yes, we had a Program office here at KSC also, but their primary responsibility was—not to be demeaning—but it was the paperclip integration. It was the budget stuff. It was the top-level schedule stuff. It wasn’t the day-to-day, “This thing is broken or needs fixing. Can we use our own ingenuity and come up with a fix or modification? Is there a standard repair procedure that we can use for it? Who has to approve that procedure? The clock is ticking, it’s holding up work. Help!” We had a lot more of that that was not under our total purview to disposition it in the Shuttle Program than there was in the previous Program, a lot more.

How did that work? Well, in hindsight it could have been more efficient. Did we eventually get it done and get it done right? Well, I would say yes. But high degree of difficulty, high degree of difficulty. See, we had the pressure of we were trying to increase the flight rate—the Program did. We’re doing what we can to increase the flight rate, meet the advertising brochure, which was very optimistic early in the Program. I can understand you should have high expectations and goals, but as soon as we saw the Orbiter Columbia and its complexity, not that we gave up on it, but the advertising brochure of a two-week turnaround was—well, that’s fine. You use that to sell to people that this is a viable transportation system, okay, but time will tell what our real capability is for processing the vehicle. Although the pressure is on here at KSC because that’s all the hands-on work, there’s this other aspect of it that I mentioned, this external coordination, that you need decisions from people out there, some of which have never seen the hardware before, in order to process the hardware down here. That’s not within our control.

So yes, did that put a lot of demands on us? Did that cause frustrations? Well, yes, but we all still had the same objectives in mind. Get the vehicle processed in a safe and orderly fashion, and when you’re done, you look up the clock, and you say—or the calendar—that’s when we finished. But it’s done right.

Wright: When did you see a change in that attitude? Was it after [Space Shuttle] Challenger [STS 51-L accident] that you saw changes?

Sieck: Actually, I think the communication and coordination was better after Challenger. On the other hand, the requirements levied on us increased significantly. There were more checks and balances required, more oversight, there was less trust. There was more of the “prove it.” So the routine work and the routine problems you encountered required more concurrences before you could disposition them and move on. Day-to-day decisions, you had to get more people involved than we did before Challenger. So yes, the communication was better, but the workload increased. You had to do more work from one mission of the Shuttle to the next mission of the Shuttle. Where a previous procedure would have been install the wheels per the print, and sign off and stamp it off when it was complete, that procedure grew to a number of pages for measuring this, measuring that, check that, torque this, check the torque, untorque it and do it again, and that kind of thing after Challenger.

Wright: Do you believe it lessened the risk factor, or do you believe your current process was just as good as the new process?

Sieck: I think in a way it caused a problem, in that we had skilled people here that had been doing a lot of the jobs for a long time. So it took less emphasis on the technicians and the engineers exercising their judgment, which in the past had served well. When you put all those steps and other stamps in there it fuzzed up—I guess a better shorter answer to the question is it confused the responsibility for a lot of the work. When you have more people stamping off what a technician did, when you have more people signing a piece of paper, you fuzz up who is really responsible and accountable for the work. My favorite quote, which was on my office wall, was one from a Navy Admiral who said, “You have to have somebody responsible for every job. Unless you can point your finger at the person, a single person, who is responsible, then you as a manager or boss or leader don’t really have anyone responsible.” That was the downside of adding all these extra checks and balances and oversight.

The positive side was it precluded anything from going through the proverbial crack, and it educated a lot of people who heretofore had not been required to be there to see the job done or stamp off the job or really understand the requirement. It was a training session for them to understand this really is complex hardware. Of course it totally changed the culture from a “let’s see how fast we can get these things turned around and how much money we can save per flight” to a “let’s just do the job right, and when it’s done we’ll look up at the calendar or the clock and say that’s when we finished.” So that’s a long answer, really, to a short question.

Wright: But it’s a good one, so thank you for that. I know you were the Launch Director for the Return to Flight mission [STS-26] after Challenger. Did you feel like you were almost having to start over with the processing for Columbia?

Sieck: Well, they changed a couple things about the Launch Director job. One, they changed the job responsibility from what it had been previous to Challenger to after Challenger. Before Challenger, it was an “other duty as assigned.” The Launch Director also ran launch and landing operations. So you had a large organization with people to manage, plus contracts and this sort of thing, and administrative duties, and, “Oh, by the way, you’re also Launch Director, so you have these responsibilities.” Well, they overhauled it, and rightfully so, and isolated the responsibility of Launch Director from all these administrative tasks. The Launch Director became part of an overhauled after-Challenger Mission Management Team, senior management council. They wanted to make sure that the Launch Director was in communication with all the project managers and the management of the Program on a day-to-day basis, so that nobody felt that the Launch Director had an unlisted phone number and you couldn’t pick up the phone and talk to him or her any time of the day or night.

So they changed the responsibility quite a bit, and not only to include the management of the launch decision, launch countdown process, but also for KSC to make sure that this team out here had all the tools they needed to be successful in their work. That was just as important, if not more important, than the job of managing the launch count and the launch decision process, because the quality of the products that KSC delivers, which is a checked out vehicle, is directly proportional to the safety of the mission, and if the team doesn’t have the tools they need to do their job well, then that quality may suffer, and if that suffers then safety could be compromised.

So the other job of the Launch Director is stay very close to the pulse and the performance of this team. And if they need something, either from the contractor or NASA or both, then it’s the Launch Director’s responsibility to make sure that they get it. Whether it’s better tools, whether it’s better training, whether it’s better working conditions, whatever it may be. It was the Launch Director’s responsibility they got it. Because managers, as we found as part of looking at the aftermath of Challenger, you get bogged down in the day-to-day stuff—meetings, telecons, briefings, reviews of the budget of your organization or the contractor’s performance. It’s the analogy of you can’t see the forest for the trees. So they scoped the job such that you weren’t encumbered by all this other stuff, and make sure that that team out there has everything they need to be successful, as well as managing the launch count.

It was a great job. I looked forward to it. Admittedly I lobbied for that job after Challenger. Even though as organizations go, you would say well, it looks like a demotion from the hierarchy of the NASA management structure to say I want to do that. That’s my kind of job.

Wright: Why did you want that job?

Sieck: I wanted it because I felt that this was an opportunity for me personally to directly influence the safety of the Shuttle missions. I had grown up with the hardware and this team, and for the most part the same team was in place. I knew most of the people on a first name basis, and they knew me. I know that they wouldn’t hesitate to tell me that we need some help in this area. I enjoyed being out there where the work was being done. It was probably the journeyman engineer or operations mentality coming out in me. I enjoyed my years on the floor, even on second and third shift, talking to the technicians, the inspectors, the engineers in the control room. This was an opportunity for me to get back into that mode of operation as a manager.

Now it meant for long days and long nights, but I enjoyed them. I would come out on second shift and talk to the technicians. I’d come out on the third shift early in the morning to see how it’s going, because I had been there as a journeyman engineer on second and third shift. People will tell you—I never failed to learn something as a manager by going out on the floor and talking to a technician or inspector or an engineer. Always learned something. Again, in the new scope of the Launch Director job I could do that, and not for just the purpose of having a “how’s it going” discussion, but I could take some knowledge away from that discussion with me that might better help those people do what they did.

Wright: How important do you think that management style impacted the element of trust between you and your team?

Sieck: Oh, I think it had a significant effect on it, because they felt, “Hey, we can talk to this guy, and he may be able to do something about it in spite of the bureaucracies and the other stuff that we have to go through,” particularly the contractor people say, “Well, they don’t”—contractor technician says, “I’m a union guy, management won’t listen to me. But maybe Sieck will.” Yes, you’ll encounter those people that they’re wearing a chip up here and say, “Well, we’ll bend his ear, maybe we can get….” So you learn to filter out some of the stuff that’s just stuff. But people say, “Hey, we talked to him and look, he changed this, he made that happen. We got tired of slogging through this parking lot that’s full of mud to get to our job, takes us ten to fifteen minutes to clean up to go to work, and looky here, we talked to Sieck about it and a few months later we got the parking lot paved.” That’s just an example, but when things like that happen, you develop credibility.

When you get on the communications channels and launch count—and in my early years I did a lot of that as the test team project engineer in Apollo, and then the job I had as the Shuttle project engineer early in Shuttle to ferret through all of the, “Well, I’m having this problem, I’m having that problem, we want to do this, no, you can’t do that,” to say, “Okay, team, this looks like the right way to get through this quagmire and get back on track again, okay.”

That helped quite a bit in the Launch Director job, whenever the clock is counting down and people are getting tense and you’re having issues and that sort of thing, to be able to say, “Okay, let’s all settle down and get on the same page here,” because I had done that a number of times before. But it’s not a one-person show. Again, you develop the communication and the camaraderie with the members of the team, and I always felt confident in making the decision on the net in launch count because that team out there wouldn’t let me do anything dumb. It’s confidence. I have confidence in them, they have confidence in me as a team. So I never went back home after a launch, either when it launched or it scrubbed, saying, “We did the wrong thing today.” But that’s because of the team, not because of me.

Wright: What did you look for when you were moving team members into management levels that were going to be helping you do your job? What kind of attributes or qualities in an employee?

Sieck: People that had a passion for what they did, that to them it wasn’t just a job or just a move up the management chart so they could get a bigger office or get more power. They had to really want to do that job for the right reasons, that’s what I looked for. There’s a lot of people, fortunately most of the people here at KSC, that’s the way they approach their jobs and their work. It’s not just a job to them, they don’t come out here just to punch in and punch out. KSC through the years has developed the mentality in the team that, “Hey, you come out here to do the best you can because what you do is important.” And it indirectly and in some cases directly affects the safety of the mission and therefore the future of the Program, so that’s the way you have to look at your work. It’s important, and you could work in the middle of the night in a building that doesn’t have windows on it, but the results of your work are just as important as what somebody does on launch day out in the control room who may be pressing buttons with the cameras rolling. It’s just as important, and that’s the way you need to look at it, and for the most part that’s the way people out here always have looked at their job and still do today. It’s not just a job. You’re on a mission when you come out here. You’re important, and what you do is important. Management has always instilled that in the people, regardless of what your job is, and it’s still in place today. You ought to whistle when you go to work and whistle when you leave. If you can’t, you’re in the wrong job.

Wright: You moved again to the Director of Shuttle processing, and transitioned the ground operations to the spaceflight operations contractor.

Sieck: That was difficult. That was tough. What made it tough was—again, going back to the we took pride in what we did and we felt responsibility. And the message we were getting from NASA Headquarters was, “The kind of work that you’re doing, NASA in Shuttle processing, really doesn’t make a difference, because we’re going to change the modus operandi here to one of insight of what the contractor does.” The contractor is responsible for assuring that the hardware is processed in a safe and orderly manner. In the past that had been a shared responsibility between NASA and the contractor, and the Certificate of Flight Readiness that we signed off previously for the Shuttle Program as well as all other Programs prior to that essentially stated that. That’s what we did. So it was a joint responsibility between the government and the contractor. In specific jobs NASA signed off on the contractor did this, NASA did this, some of them we approved directly.

But now it was, “That’s okay, but we’re not going to do it that way anymore.” It’s all the contractor’s responsibility. And government, you’ll have insight into what they do, you can check their procedures, you can spot-check their this, you can do audits of that. There’s a few things that are specific government responsibilities still, and you’ll still have those responsibilities, like the management of the launch, the launch decision process, and the recovery of the vehicle, and a few other things that are inherent government-controlled. But other than that it’s the contractor’s responsibility. “Keep an eye on them, grade them, but back out of what you’ve been doing.”

So in a way it’s saying, “Well, what you did in the past really didn’t matter, because this is the way it’s going to be done in the future.” The term demeaning comes to mind. So that made it difficult to say, “Okay, guys and gals, we’re now going to do business a different way down here. You’re going to back out of this, and you’re no longer responsible for that, and you’re no longer responsible for this.” Where we had enjoyed a relationship with the government contractor team that was a joint like this, now it was more of a them and us. “I’m going to watch you. I’m not going to help you anymore. I’m just going to grade you.”

Now that’s one end of the spectrum. But some people, that’s the way they looked at it. We still felt a responsibility for delivering the highest quality product we could to the crew to fly, as well as the ground equipment that was used to do that. But it wasn’t the same. Of course the other message it sent was, “You NASA folks that are part of Shuttle processing down here at the Cape, you better go find yourself a different job now.” We were building up the [International] Space Station and that sort of thing, so there was a natural transition. But there was still government NASA people required as part of Shuttle processing. Well, as you might expect, the best and brightest that felt they wanted to continue their NASA career and move up to something that was more challenging fled our organization.

So as jobs and responsibilities go, that was the toughest job that I ever had. To manage that, try to keep the team together, try to meet the demands and the requirements of the Program with this huge distraction and morale factor going on. It wasn’t easy. In fact quite frankly that started my countdown clock to retirement. I knew that once we got through that transition, I would have had enough.

Wright: Do you feel like it was maybe the most challenging job you had while you were here?

Sieck: Oh yes, certainly. Yes, managing a launch count was a lot easier than managing the transition. And at the same time not only the downsizing—rightsizing was going on, as the administration called it, within the government contractor team. So we had layoffs, the contractor was having layoffs, and we were pulling out of the processing responsibility all at the same time. Very difficult, not only for me, but for the NASA team, as well as our contractor counterparts that we had established this teamwork relationship with.

As I explained it to NASA management, I said, “You got to understand that you’re incurring some risk here. The quality of the products that we certified ready to go fly were a combination of a government and contractor effort, and now you’re going to take a lot of the government component out of that. Will that degrade in the way of the quality? There’s nobody on this planet that’s smart enough to tell you or to measure it. But you have to accept the fact that you are accepting more risk. Maybe it’s insurance. You can call it insurance that we provided in it. But there will be more risk. You have to accept that with this transition that you have mandated.”

But we did it, we got it done. In hindsight I think NASA backed out probably too far, but we were able to maintain a safe orderly process in spite of the distractions and the morale things that were going on, and of course it helped Space Station at a time when they needed the experienced NASA help. Of course we weren’t allowed to hire any more people, so you had to find the resources from within to do the jobs that we had here at KSC, which is Shuttle processing as well as processing the Space Station, as well as getting on with some of the new development work at a time when NASA had the proverbial hiring freeze going on. So not just me, it was a challenge for the whole Center to manage this. But in hindsight, did it pretty well.

Wright: Well, as you mentioned, in 1999 you retired after thirty-five years of service, and you were appointed to the Aerospace Safety Advisory Panel [ASAP]. Tell us about that, and how you were able to use your experiences to still impact the work.

Sieck: Well, that was in two things. First of all it was self-serving for me, because I approached the Headquarters people about it, said, “Okay, I do want to retire, but I’d like to stay connected with the people and the business I enjoy working with.” Because cutting the umbilical, so to speak, after thirty-five years being the dedicated neurotic that I was for all this human spaceflight work—I didn’t want to just quit cold turkey so to speak, I’d get the DTs [delirium tremens, or “the shakes”]. “So I’d like to have something that’s not too demanding on my time, because I want to enjoy the priorities of retirement, the children, grandchildren, volunteer work and hobbies, but I’d like to stay connected.”

So Headquarters appointed me to the Aerospace Safety Advisory Panel. That was good. That kept me not only from my self-serving—but I was able to steer them in a lot of cases for areas that they ought to look at, because that’s where risk could be increasing or that’s where risk was inherent. And the safety panel may be able to help NASA in those areas, if in no other way other than highlighting them in our reports and our briefings to management and to Congress is that, “They need help there, they need attention there, that’s a slippery spot from a safety standpoint.” So I think I was able to help them there not only with my experience, but with the communication and the camaraderie that I had established with the KSC team they could tell me about things that you wouldn’t necessarily see in a briefing from management that was many levels above. “Hey, you, the ASAP, ought to be aware of this because—” type of thing. So that was good for both of those reasons.

Wright: Can you give us some examples of some of the areas that you were able to help bring to light during that time period?

Sieck: The erosion of the facilities and the support equipment down here at KSC. Again, after I retired the budget squeeze is still on, and people have a tendency in that period—and when you have plans to upgrade, maintaining equipment that’s old is one thing. Upgrading it, getting money to upgrade it, is more difficult. Of course the assumption is all the focus is on the flight hardware. KSC did its best to keep this aging infrastructure going, but what people lose sight of, particularly that are outside of KSC, is that you’re using hardware to process the Shuttle that was used in the Apollo Program. It’s forty years old. It’s time to make some major—if you want it to continue to serve the Program for another five to ten years safely, you need some money to do that. You can’t just keep putting Band-Aids on this stuff. Hardware, particularly stuff down here that’s exposed to the outdoors. It doesn’t mature with age, it just gets older. You need to revitalize it with some money.

So we were able, I know somewhere in that five-year period of time, to help KSC get the funding they needed to upgrade a lot of this aging stuff so that it could better serve the Program safely for whatever the life of the Program ended up being. There was of course a period of time there when, “Well, we’re going to have a new spaceship down here in another five years or so”—this is in [19]’99, 2000—“so we can just let this stuff deteriorate.” Well, no, you can’t.

I know that was one area where in our reporting to NASA, to the Program, as well as the people in Headquarters and the administration, where we were able to help them get the funding that they needed. That they really needed, not just because they wanted it, they needed it to upgrade this hardware. On the other hand did the safety panel keep Columbia [STS-107 accident] from happening? No. Nor did they keep Challenger from happening. You don’t have the in-depth insight as to a lot of the technical nuances that exist with the Shuttle that could keep those kind of events from happening.

But on the other hand, the safety panel can look at things like how much testing you’re doing, and where your resources are going for things like fleet leader testing on the Shuttle. And say the Shuttle, it’s like this infrastructure at KSC, it’s getting older with age, and you don’t want to use the next flight of the vehicle to be a fleet leader test of this system or this system or this system. So you, Program, need to invest more money in that so you can find out in a test lab what the life limit of this actuator or this component is, as opposed to finding out on the next flight of the Shuttle. In hindsight that was a factor in some of this.

So those were the kind of things that I felt the safety panel did help, and can still continue to help NASA with today as it goes. But I left the safety panel after five years, which is typically how long you would be on the panel, and was appointed to the Shuttle Return to Flight Task Group, the Stafford-Covey Commission. And again I felt there that we, those of us that were on there from KSC, General [Forrest S.] McCartney and I specifically, we were able to help steer some of the work that the Return to Flight Task Group did when they did that Return to Flight after the Columbia incident. That was a couple more years of my NASA part-time consulting work.

Shortly after Return to Flight, continuing on with my work with NASA, I was appointed to the Space Station Independent Safety Task Force headed up by Tommy [Thomas W.] Holloway. Of course that report was kicked off by a Congressional resolution to have an independent group determine what were the risks of the Space Station having to be abandoned while it was still being constructed. Where were the areas that should get the most attention to preclude that kind of event from happening, to leave the Space Station. I served on that till the report was put out, and that was about a year-long effort.

After that I was appointed to the Constellation Program Standing Review Board, specifically for the Ares [Launch Vehicle], but then as the chairman of that you also serve on the Program Review Board, which is still a work in progress. That of course again continues to keep me connected with the business, plus give them the benefit of the lessons learned through the years. And primarily the things that happened on my shift, I’ll call it, that we’re not proud of. NASA is not proud of, I’m not proud of, because I was part of the team. That’s the value added for having folks like me involved in the next great adventure.

Wright: I’d like to talk a minute about that, of the two Return to Flight efforts. You were in two different positions with those. Could you share some of those lessons that you learned from the first one you were able to apply to the second one, and then maybe the new ones that you learned the second time around?

Sieck: Well, I think the lesson learned in the first one has to go with development testing of the critical systems. You have to test enough to know what your environments, your boundaries are, the specifications. In hindsight for Challenger, the O-rings, there was two problems. One is the communication, and the management structure thing, that’s the second thing. But the technical contribution to the Challenger accident was there wasn’t enough testing done to fully understand the environments and develop the specifications for processing. In general terms processing hardware, specifically the joints on the Solid Rocket Motors. Had they done more testing early on, they would have found that these fourteen-foot-diameter segments need to be more circular before you mate them down at KSC. And again, more testing would have given us a tighter set of specifications so that particular segments where the flaw occurred never would have been mated because they wouldn’t have been in spec [specifications] for the team to put them together in the first place.

The other is the temperature environments, that if these are the specifications for the circularity as it were of these segments, then when you get ready to launch them here’s the temperature environments that you have to have in place before you can give a go. So in hindsight you look at it, everything was quote “in spec” when we mated the segments in the VAB [Vehicle Assembly Building] weeks before launch. Everything was in spec when we flew it. But in hindsight, those specs didn’t preclude us from flying hardware that was, in hindsight, flawed, and those specs were developed with the testing that was done years before that that developed the requirements that were levied on KSC, in this case, to go fly it.

So enough testing wasn’t done. What classically happens in a development program is the budgets are tight, and what gets sacrificed? Well, it’s the testing. The engineers are told, “Hey, this is all the money you can have for your development testing. Use it wisely, test the stuff that you think is the most important, and see what you get.” And it comes out all right, then that’s it, it’s good, that’s all you get. That’s what we got to be real careful of in the next program.

The other was the management and the communication in the aspect of the Challenger accident, which in hindsight was a disappointment. But that’s discipline and leadership, and you can fix that with people. But my takeaway from Challenger is just that. It’s the development testing and all of the models and everything else that engineers have to develop and use when they say, “This is the way to build the hardware,” and, “This is the way to process the hardware,” and, “These are the placards and the limitations and the requirements to place on those processes all the way from manufacturing to the launch decision.” You got to do that with testing.

The same applies to Columbia. Part of the Columbia problem, again, two. There’s the technical aspect of it, and there’s the management discipline aspect of it. The technical aspect of it, the engineers weren’t as smart as they thought they were or as smart as they needed to be to say that when stuff comes off the tank it’s not going to hurt the tile on the Orbiter. Because the math models didn’t say that if a piece that’s this big that comes off of this part, in time hits that part of the Orbiter—they didn’t have enough testing to be able to say that wouldn’t be a problem. They didn’t. In hindsight, their transport models weren’t complete enough. Their hazards and risks analysis weren’t detailed enough to say that could happen. So the assumption was that it couldn’t. Same kind of thing. The other again is the other part of it, it’s discipline, it’s management, it’s training on the decision process, same thing.

So what do you take to the next program for that? Don’t shortcut the testing and the analysis before you commit the design to the people to start building the hardware, or you say, “I’ve got a good set of requirements to impart either on the manufacturing process or the operations at KSC”—or in flight, for that matter. The testing is very important. Don’t cut it short, even though the budget squeeze is there.

Wright: You officially left NASA before the Shuttle became a carrier to the Station and helping the Station become where it is today. But you were here during the time that the Shuttle and the [Russian Space Station] Mir were interchanging crews and supplies. Tell us about the challenges, if you had any, during that time period of processing the Shuttle to go to dock with a different type of craft.

Sieck: Well, that was all in the payload accommodations, and the payload processing folks down here. To us it was just a different kit to put in the payload bay, and the only thing that was unique was having Russians on board, and of course again we didn’t have—our interaction with the crews is minimal. When we had testing that involves the payloads they would be down here, and when we’d have things like the countdown demonstration test and that sort of thing we’d see the Russians. But as far as processing the Orbiter was concerned, it was just a different kit. The real challenge was, from a Launch Director standpoint, those tight launch windows. You don’t have a lot of flexibility to go work a glitch if it occurs after you’ve gotten to the point where you’re down to just a few minutes of potential hold time to meet your window. So obviously the launch team did a lot of training and practicing on how to handle problems when you have those kind of constraints.

The other part of it of course, they weren’t the challenges—it was actually though a lot more exciting to be a spectator during the mission when they’re doing those EVAs [Extravehicular Activities] and docking with the Mir and that sort of thing. But we really didn’t have that much, from a processing team, didn’t do that much work with the Russians, although we found them to be a very interesting and very knowledgeable and passionate group of engineers. Same priorities we had. Safety was important to them also. They just had a different approach to what was required and what was nice to have.

The analogy I would use is a Russian engineer, if they’ve got a couple of operating lights in their home and they have a car and it runs, and they can afford the gas, life is good. An American, if we buy a brand-new car and the digital clock doesn’t work, we take it back to the dealer and say, “I don’t care how much time it takes, go fix that.” Priorities are a lot different. But when it came to safety and what it takes to operate systems and robust designs and designing things that’ll work there, they’re right there with the best of them, and they have a lot more experience on extended spaceflight than we did at that time. So if the cosmonauts said, “Here’s the kind of things that we look for when we go up there,” you listen to them, because they have a lot more experience, a lot more. But no more degree of difficulty in processing the Shuttle on those missions.

Wright: You had a number of night launches too, if I recall, during that time period. Did that change your processing or your procedures at all?

Sieck: No. No, it really didn’t. We got into our mode of—the astronauts about a week before get into their circadian rhythm of adjusting to a time of day to do their work. Unfortunately the NASA team, we weren’t able to do that. We get into the mode about two days before. So that was the major adjustment. But no, night launch, they’re spectacular, really, but I didn’t realize how spectacular they were until I retired and got to watch one from outside as opposed to in the control room. Then I realized. Really nice.

Wright: One of the other aspects that changed during your time was the landing. First missions were landed in California, and then now here.

Sieck: Yes, and California, processing the vehicle and getting it out of California, compared to the degree of difficulty down here, was a fairly significant workload for us. Particularly in the years when you’re trying to save money and reduce the amount of processing time. Obviously we preferred KSC landings. But the weather didn’t permit it. One of the things that finally happened—I know pilots prefer a runway that’s not surrounded by a moat, it’s like landing on an aircraft carrier, I realize that. But it was obvious in the early years that between the astronauts and the flight team, their preference was to land in California [Edwards]. If there was just one hint of a cloud forming somewhere down here at KSC that would violate the flight rules for landing, they would make the decision very quickly, “We’re going to California today.” It had to be an absolutely pristine, everything’s going to be perfect, weatherwise, for them to decide to land at KSC.

That mentality or approach persisted until probably the mid-nineties when people changed. Mission Management Team composition changed. Changes were made to the flight rules, the weather rules, and more confidence was developed in the ability to forecast the weather down here in Florida. But the degree of difficulty of processing a vehicle out of California and getting it back here is an order of magnitude more than it is handling an Orbiter that lands on the runway. More work, more opportunities for mistake, more opportunities for weather to impact the quality of the work that you do.

Out there in California the Orbiter is exposed all the time, and they get pretty ugly weather in California. Notwithstanding yes, the landing weather is a lot more predictable in the desert. But it takes you a week to get the Orbiter out of there, and all that time it’s outdoors with people crawling in and out of it, connecting things and disconnecting things from it. It increases the degree of difficulty as well as the cost and the expense significantly.

Wright: The other thing that I found interesting was that you were working on that safety task force with Tommy Holloway for the Station, although you really didn’t have a lot of hands-on experience here. So were you able to offer some objective views of what the topics were on that?

Sieck: I think that what I offered there is first of all the point—and I may have made it—about fleet leader testing. You got a lot of critical components up there that right now may work real well. Well, ten years from now will they be used up? What kind of testing are you going to do? What kind of components can fail up there that it’s going to put you in the scramble mode on the ground to help them? So have you figured out from those components? Have you done enough testing down here to predict when they will fail? Or what symptoms they might start exhibiting before they fail? Are you doing enough work on the ground to know that before it becomes an “oh my goodness” on orbit?

The other is understand those operations you do that put you at the most risk, put people at risk or put the hardware at risk. Of course with KSC, we assess and had for the Shuttle all the activities we do down here. There’s thousands of labor hours of work that go into processing the Shuttle. Some of it is designated as hazardous work, some of it is not. But we spend a lot of time analyzing those tasks, again, to make sure that the environment is as safe as you can make it for the people doing the task or the hardware, so you’re not going to damage the hardware, zap it.

Well, you need to do the same thing for the Space Station assembly and operations. Analyze everything you’re going to do in detail, even the stuff that you’re already doing. Make sure you know what the limitations are, make sure you know what the hazards are so that you’re protecting the people and the hardware as best you can. We learned a lot of times at KSC the hard way that tasks that we thought were routine, mundane, nonhazardous were, “Uh-oh, we hadn’t thought about this and look what happened.”

Wright: I was going to ask you what you thought was the hardest lesson you’ve ever learned.

Sieck: Well, I don’t know. There’s a lot of things in hindsight you wish you had done differently. I mentioned about the requirements won’t always protect you. So that gets into the—if you’re in a position of responsibility where you can raise your hand or even you can stop the show, and if your gut tells you you ought to do that, then you should do it. That’s part of the responsibility. That’s the kind of the thing I never learned in college, and never learned in Scouts before college. I didn’t learn it in the Air Force. But I think the first time I was really aware of it, Apollo 13. I’ll tell you my Apollo 13 story.

Apollo 13, I’m the test team engineer, NASA, for the spacecraft, the Command/Service Module. We ran the test down here where we load the oxygen in all the tanks and the boost, the launch vehicle, the rocket people load all of their cryogenics in their vehicle, and then you offload them. You detank them. So we did that test, and we couldn’t get the liquid oxygen, we couldn’t offload it off of one of the tanks in the spacecraft. So, “Uh-oh, there’s something wrong in that tank obviously, because we thought maybe it’s the ground support equipment at first, no, no, it’s in the tank.” So a big pow-wow. Took a couple days actually.

The management team came up with, “Well, there’s probably some damage in that tank, because it was dropped whenever it was installed out in California, and even though it passed all the other tests fine, there’s probably something wrong with the internal plumbing in it that’s keeping you guys at the Cape from being able to offload it. So what you need to do is power the thing up again, and we’ll just turn the heaters on in there, and it’ll boil off the liquid oxygen, and you’ll vent it through a different circuit. That ought to be fine, the flight hardware system ought to support just fine. So you go ahead and do that.”

So we did. So we go on station and turn on the heaters, and after a short period of time the console operator tells us, the test conductor and I, that you can’t monitor the temperature anymore. Temperature is upper limits. Temperature range is from room temperature down to minus whatever cryogenic temperature. He said, “Just be aware I can’t tell you how hot it is in the tank. I can tell you what the pressure is, pressure’s fine, but can’t tell you how hot it is.” So the test conductor and I and Rockwell counterpart said, “Hey, let’s stop the test, this doesn’t feel good, doesn’t feel good, let’s caucus a bit.” So we talked about it and said, “Well, let’s get some experts.” Well, it’s the middle of the night. It’s late at night. Said, “Well, let’s get the chief engineers involved. This just doesn’t feel good, about having these heaters on that are putting energy into this tank filled with liquid oxygen and we can’t tell how hot it is in the tank.”

So we got all these people involved on a telecon. Houston, the contractor, our bosses down here at KSC middle of the night. Everybody said, “Don’t worry about it, you guys out there, there’s a thermostat inside the tank that’ll keep it from getting too hot, just keep your eye on the pressure, make sure the pressure doesn’t go up and pop the relief valve or cause some other problems.” So we did that and we turned the heaters on, and in hindsight that thermostat, because of the voltage we were applying to the tank, which we were allowed to do per the requirements, kept the thermostat from working. So the tank got 1,000 degrees, melted all the insulation off the wires, and from that point on Apollo 13 was just waiting to happen. Any time they threw the switch and two wires contacted, which they could have done at any time, you would have had the spark in the tank.

Then we did that, and the next day management said, “Hey, nice job, good, you got all the approvals on this, you did good work.” Of course you know what happened after that. One of the times they turned it on going to the Moon, it blew up. It blew up because we melted all the insulation off the wires because we turned those heaters on for that period of time and had no idea how much power we were putting in the tank because our instrumentation didn’t tell us what the current was. So we didn’t really do our job and we didn’t feel good about it either. The guys said, “I don’t like this.” Said, “I agree with you, so let’s stop the test.” But the gut told you you shouldn’t be doing this, just—and turn it all over to people so they can work it in the cool of the day on first shift. They’ll have time to think. Don’t call them in the middle of the night with the pressure of saying, “Hey, we’re in the middle of this test, and we need a decision right now.” Don’t do that to your bosses. Don’t do it to yourself, don’t do it to your bosses. Work an issue like this in the cool of the day.

That’s what I learned from Apollo 13. That’s why when I got to that job that I really liked doing, more than once I said, “No, we’re not going to launch today. You guys are working this issue, you think you got a good idea to work around this problem, using your Yankee ingenuity went into your bag of tricks.” And said, “But I’m not sure you’d come up with the same decision if you were allowed to sleep on it for a day, so we’re going to scrub, go back, look at all the data, rest, come back, we’ll have a meeting tomorrow and see if you come up with the same conclusion.”

That’s what I learned from Apollo 13, learned to say no when everybody else wants to go. It’s hard to do, it’s hard to do.

Wright: You were here the first time the men went to the Moon and saw the sacrifices that were made there for Apollo 1, and now you are working with the NASA teams to send another group of humans, not just men, but humans to the Moon.

Sieck: Yes, humans, yes, men and women.

Wright: Lots of years of experience and lots of different spacecraft that you’ve worked on, lots of different types of processing. I know we’ve gone over some, but what would you define as some of the best practices overall that you hope are going to be instilled in the new Constellation Program to help bring NASA to its next era of space exploration?

Sieck: Well, practices would be—one is keep it simple, make the design as simple as you can. I already did the analogy with the computer and the BlackBerry. We got to the Moon with a human-rated vehicle that was designed to be flown by the astronauts, and because it was designed to be flown by the astronauts, Apollo in that case, there was a couple of missions where if it had all been automatic, we probably wouldn’t have landed on the Moon. We gave the crew the tools they needed to work around issues that didn’t go per the book, and by golly, we had a successful mission as a result of it, and it’s because we made it simple. Simple vehicle. You got a switch for that, one switch. Of course had good quality hardware too. So keep it simple is one best practice.

The other is beware or be careful about reuse, particularly of space vehicles, space-rated hardware. The rigors. Again we found out that regardless of how much testing we did in advance, we weren’t as smart as we thought we were. We found in the Shuttle Program that the fleet leader testing we did on the engines was very important, but there were some other systems we should have done extensive fleet leader testing on that we didn’t. So that brings up the subject of reuse. We had safe and successful Apollo missions because we had brand-new hardware to deal with every time, and it was real easy to process it and test it because it had to perform at its optimum, it had to be factory-fresh. When you get in the mode of “Well, this thing has flown ten times so it can be degraded some, it can be worn out some, it’s okay obviously because it’s flown.” Well, how many more times can you fly it before it’s going to break and you didn’t expect it to break? So if you’re going to reuse hardware, fine, but be careful. And if you’re going to use hardware for a long time, even if it’s not reusage, it’s like the Space Station, it’s going to sit up there, make sure you know what its limits are.

Of course the other is the people factor. Keep in touch with the people and where the rubber hits the road as much as you can, because they will tell you if you’re a manager and responsible for a process, and there’s people involved in the process, you need to know what they’re doing, what their issues are, and make sure you give them the tools they need to be successful. You can’t lose sight of the fact. The hardware is impressive. The facilities here are impressive. The flight hardware. But it’s all about the people. People that design it, the people that test it, the people that process it, the people that fly it, it’s still all about the people. They’re the most important part of any major Program.

Wright: Speaking of that, what would you recommend to best train this new group that’s coming in that’s going to lead us to the next era?

Sieck: Well, training them, they ought to go to school on the lessons learned from the past. It doesn’t mean you have to do it the way we did it in the past, but beware of what we did that worked and what we did that we’re not proud of, and use that as you go forward. That’s the best. You don’t have to be experienced. The other thing is you don’t have to be experienced to be good. We weren’t experienced when we went to the Moon the first time. We had a few older folks that knew a lot about the best practices, but nobody had been there before. The most experienced people in human spaceflight had come on during Mercury, and they were young then, they weren’t that much older when they were making decisions to send people to the Moon.

So you don’t have to be old, but take advantage of the lessons learned, and use every opportunity you can to get close to the hardware, the software, the procedures. Get out of your office, get out of the briefing rooms, get out of the meetings, get out there on the floor, get there with the procedures, get there with the hardware and the people that operate it, because that’s where the slippery spots are. They’re not up in the big office with the big desk with the doors always closed, worrying about budgets. That’s not it.

Wright: Looking back over your experiences with the space agency and all of your career, what are some of the brighter moments?

Sieck: Oh, bright moments, wow. A lot of them. Every successful landing and getting the crew out is a bright moment for sure. The first mission I was assigned to was Gemini 3, biomedical engineer. Got to meet the astronauts, got to tweak the sensors they were wearing for all their medical data, got to spend a lot time with them. In fact, did that for the whole Gemini Program, so I felt like the first time I went in the blockhouse with my procedures and my headset under my arm I was a real rocket scientist, wide-eyed kid, “Well, this is neat.” And I just talked to Gus [Virgil I.] Grissom and John [W.] Young right next door, patted them on the whatever, and they’re up there, and now I’m going to plug in my headset to the console, and I’m going to watch their electrocardiogram and this stuff and talk to them on the net in the spacecraft. That was a rush, really. I felt I’d finally made it.

Of course then the first launch, the first human launch. That’s when I found—I said, “Boy, I didn’t know that was that much of an emotional experience. This puts the—” I stopped. Their heart rate was running seventy, eighty, ninety beats a minute, mine is up here at 150, and I’m sitting here in this protected blockhouse, and they’re sitting on top of the rocket. Very emotional experience, first launch. First process, first launch.

The Apollo Program, the job I had then is the test team project engineer, I was in the control room, which was in this building. Launch pads are up there. So I got an eight-inch black-and-white TV set to watch men go to the Moon. The only one I got to watch from outside—because I was the backup engineer for Apollo 11 on the Command/Service Module—was Apollo 11, and I got to watch that from Titusville [Florida] with my family.

That was an emotional experience. That was really—that was a trip. I was going to drive down to the river. We only lived a few miles from it. With my wife and daughter in the stroller, and we couldn’t get halfway there because of the traffic and the cars. We finally got to the highway, the four-lane highway with a median in it, about fifteen minutes before the launch. I’ll never forget it. There was not a vehicle moving. All four lanes were filled with cars and trucks. People were sitting on the hood or on the top of the car, not even trying to go anywhere, didn’t want to. They were going to watch history.

There were pup tents in the median of the road. People were pulling up plugs of grass and putting them in ziplock bags as a souvenir because the vendors had sold all their T-shirts and memorabilia and that sort of thing. There wasn’t anything. I was thinking of the launch count procedure I had sitting out on my desk that was 5,000 pages. I could have worked the crowd. So I could have put one of my kids through college probably for what I could have sold those procedures for. But anyway, that one I remember. What a beautiful sight.

The first Shuttle launch from the control room was a real rush. Euphoria. High fives, hugs, handshakes, because we had been working on that for a long time. Once they finally got on orbit and they had the successful burn to circularize the orbit, we just erupted, even though we know it’s not over till the mission is over. But boy, I’ll tell you, that was memorable. As was the Return to Flight after Challenger. Those were highlights.

Apollo 1 was a low day. But Challenger was a shock, being in the control room when that happened. We all knew the risks of spaceflight, but we sure didn’t expect it that day, didn’t expect it. And like I say, every mission where the crew got out afterwards and everything went fine, particularly that everything went fine, which says the work we did here was done right. The things we were responsible for were done right. Was all good, all good, I don’t regret. There were some bad days, but it was a good career. I was in the right place at the right time, still feel privileged that I was part of this great adventure for as long as I was really.

Wright: Now you’re going to have an opportunity to do it one more time.

Sieck: Yes, and I hope it induces the same excitement for NASA when they get close as it did for us when we did it. I hope it does. Exciting is an understatement. I will always remember the night when I went outside with my wife, it was during the Apollo 17 mission. It was a night launch, so you could see the Moon up there, and we were standing there in the street looking up in the Moon, and I remember telling her, said, “Honey, while we’re standing here looking up at the Moon there’s two guys standing on the Moon looking up at us.” Think about that. Think about it. We helped put them there. Not just me, because these long days, hours, weeks, nights, the spouses are just as much part of the team as the rocket scientists that are out there doing the thing, really. Yes, great feeling.

Like I say, I hope that NASA can feel that again. Not just NASA but the whole community. That’s what made it so much fun. You’d tell people, “Oh yes, I’m working on Apollo Program, I check out the spacecraft.” Wow. People were proud of you. “Wow, you work on the Apollo Program, can I have your autograph? Have you got something I can”—that’s the way the country felt back then, proud, as it should be, should be. We were too.

Wright: Well, let’s hope that in the future we talk to you, and you’ll be able to say you saw that again standing outside, the Moon, and having someone look at that.

Sieck: I hope I can do it, hope I can do it.

Wright: Are there any other thoughts that you can think of?

Sieck: I think a lesson learned is NASA funds, this government agency, they’re always under budget crunch, save a buck every chance you get, so designing for operability—whether you reuse the spacecraft or not, but design it with cost in mind and operate it with cost in mind is a good feature. If you’re going to reuse the spacecraft, get the operators in, the people that are experienced in turning around or reusing hardware, get them in on the ground floor. Get them in early. We got in the Shuttle Program too late quite frankly, we did. When we got involved, those of us that had been involved in processing Apollo, they told us, “Hey, that’s a nice idea, Cape guys, but it would add weight to the vehicle right now, can’t afford that, it would impact the schedule, or it would cost us money.” Even though we got in at the preliminary design review phase, we were told already it’s too late. “Yes, it’s a great idea, and maybe someday we can do a modification to do that, but can’t afford it right now, can’t afford it, too bad.”

The other is it’s little things, like the Orbiter has a dozen different kinds of insulation in it, not on the outside, but on the inside, different for different lines, different boxes, different whatever. Well, in hindsight why couldn’t it have all been just one? Think of how much money that would have saved. Different repair specs, different procedures for different kinds of insulation, only need one. Simple stuff. That’s operability. Design it that way. Design it that way. I think that’ll save you money in the long run, and money, it’s a government-funded Program, and they’re going to be under the watchdog.

We’ll probably never be rich enough to do it like we did the first time when we had all that commitment, and they didn’t—as journeyman engineers we were told by our bosses, “Don’t worry about what it costs. We’re going to the Moon, we’re going to do it right. So if you need more resources, test equipment, whatever, training, just ask for it, you’ll get it.” Of course I remember then in the Shuttle Program as being the boss telling the engineers, “Be real frugal. Don’t spend any more than you have to. Do the best you can with this amount of money, because this is all you’re going to get.” You end up with different products, with those two different doctrines on how you can manage what you’re responsible for, regrettably.

If you have the ultimate commitment, the country gets rich again, I hope we do, then we’ll end up with a better product. Doesn’t mean we won’t get there. But you got to be more careful.

Wright: I know our time is out, but one of the things that you brought up, I would like to ask you your thoughts about it. Since we talked about STS-1 for just a second. The fact that you put John Young, that was the first mission that you—and yet you put him on a spacecraft that had been untested. What were your thoughts about that as you look toward the Constellation Program?

Sieck: I would have to say all of us that had been involved in unmanned vehicle Program before you put men on top, we were worried about that. All your eggs in the proverbial one basket. Because if you blow up an unmanned vehicle, okay, we realize it’s a test, and you have test failures, and we had always had test failures on every rocket we’d ever sent up before. So this is the most complex rocket ever built, and we’re not going to do an unmanned test. Those of us that had been involved, we couldn’t believe it. Said, “Well, they got a lot of confidence in this design,” and that sort of thing. But then yes, so did they in the previous ones, and look what happened. I’d have to say we were nervous, we were nervous. That’s why we were so euphoric whenever they got on orbit.

Now it’s got to come home. With all that tile that we’d had so much trouble with. So I’d say that worried us. Worried us. Even today, every Shuttle mission—look at the numbers. The probability that something can go wrong is pretty high. Very complex vehicle. In STS-1, it was not only very complex, but untested, which increased the risk significantly. On the other hand, the astronauts would tell you, like going to the Moon, your chances were one in five that you’d ever get back. But we were a more risk-acceptant society back then, and risk was more part of our culture. Today it’s not, regrettably.

Wright: How will that impact the Constellation Program as you see it?

Sieck: I think you’ll end up doing some things under the guise of saying, “This will reduce risk,” which in reality won’t reduce risk. In fact may even increase it. But because we’re so risk-averse, and we want every “I” dotted and “T” crossed, and because we don’t want to fail, we will do things that we probably wouldn’t have to do. There’ll be additional checks and balances. There’ll be additional oversight. Spend your money where it’ll do you the most good. The testing, that sort of thing, yes, that makes sense. But some of the other stuff wouldn’t make sense, and of course back in the Apollo Program if you wanted money for testing, fine, but the engineers were empowered to make those decisions. Now there’s a lot less empowerment because of the risk-aversity. Much more difficult.

We made a mistake back then. We made our mistakes. We were dusted off and told, “Nice try. Now what do you need to be successful? Do you need more training, more tools, more test equipment, more whatever?” Today you make a mistake, and regrettably you get all these boarding parties and investigation boards come in and tell you, “Well, you probably wouldn’t have made that mistake if you—so you need more this, this, this, this, this, this,” and a lot of that is not value added, it’s just reactionary, “Well, we have to make them do something, so make them do this.” We’ve lost sight of what Amelia Earhart said. Amelia Earhart’s quotable quote that I like was, “Determine first if the goal is worth the risk. If it is, stop worrying and go do it.” Sage advice.

Wright: I think we’ll just stop on that, because how best else can we end that? So thank you a lot for spending time with us this morning.

Sieck: Okay. Enjoyed it. I look forward to your product.

[End of interview]