NASA Johnson Space Center
Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript
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.
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.
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].
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.
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?
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
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.
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?
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.
You were Director of Launch and Landing Operations at that time, is
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.
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.
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
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
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.
When did you see a change in that attitude? Was it after [Space Shuttle]
Challenger [STS 51-L accident] that you saw changes?
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
Do you believe it lessened the risk factor, or do you believe your
current process was just as good as the new process?
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.
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?
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
Why did you want that job?
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.
How important do you think that management style impacted the element
of trust between you and your team?
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.
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?
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.
You moved again to the Director of Shuttle processing, and transitioned
the ground operations to the spaceflight operations contractor.
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
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
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
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.
Do you feel like it was maybe the most challenging job you had while
you were here?
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.
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.
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.
Can you give us some examples of some of the areas that you were able
to help bring to light during that time period?
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
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 ’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.
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?
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
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.
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.
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.
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?
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.
One of the other aspects that changed during your time was the landing.
First missions were landed in California, and then now here.
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.
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
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.”
I was going to ask you what you thought was the hardest lesson you’ve
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
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.
Yes, humans, yes, men and women.
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
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.
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
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
Looking back over your experiences with the space agency and all of
your career, what are some of the brighter moments?
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
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.
Now you’re going to have an opportunity to do it one more time.
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.
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.
I hope I can do it, hope I can do it.
Are there any other thoughts that you can think of?
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.
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?
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
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
How will that impact the Constellation Program as you see it?
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.
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.
Okay. Enjoyed it. I look forward to your product.