NASA STS Recordation
Oral History Project
Edited Oral History Transcript
Gerald A. Blackburn
Interviewed by Rebecca Wright
Downey, California – 24 August 2010
Today is August 24th, 2010. This interview is being conducted with
Jerry Blackburn in Downey, California as part of the NASA STS Recordation
Oral History Project. Interviewer is Rebecca Wright, with Jennifer
Ross-Nazzal. We also have someone sitting in with us today videotaping
for the Center [Aerospace Legacy Foundation], Bob [Robert] Sechrist.
Thank you again, Bob, for being with us today. Mr. Blackburn, you
were in the aerospace industry for over 40 years, many of those with
the Space Shuttle Program. Tell us about the first involvement that
you had and some of the major aspects you were involved in with the
I began back in 1962 working for North American Aviation [Inc.] out
in El Segundo [California]. I transferred over in ’64 to the
Downey site here on the Apollo Program. Much of my background had
already been invested in Apollo. We had quite a learning curve in
terms of developing manned space technology with that program.
After the Apollo Program started winding down and we were completing
the ASTP, the Apollo-Soyuz [Test Project], we were beginning to put
our proposal together for the Space Shuttle Program and the orbiter
follow-on. There was a lot of anticipation about winning that contract.
We had had some serious layoffs here at the division, so it was a
very stressful time but we were confident that we were going to be
successful in getting the orbiter contract.
That proved to be true, we got the orbiter contract in the early ’70s.
The whole temperament of the facility changed because now we were
on a new program, an even bigger program than we had with Apollo,
and a more challenging one. The technology challenges that we faced
with the orbiter were very different from what we experienced on Apollo.
But there were similarities, and we tried to leverage a lot of the
technical information, knowledge that we had acquired.
For example, one of the areas was age life of materials. I was working
in the materials processing department for engineering at the time.
As our designers would select materials for the components and the
build of the orbiter, we had to make sure that they were going to
meet the end item specification requirements for 100 missions or 10
years, which seemed a little naive from today’s perspective.
But we were aggressive, and we said let’s go back and look at
materials that we had selected for design on Apollo. Even though that
was a nonreusable vehicle, the specifications and the criteria for
design would not change that much, so we began to look at what we
called the age life data and see how much of that would translate
into design elements on the orbiter, and much of it did.
We did have some new materials that we were starting to look at, for
example the thermal protection system was brand-new. They did not
want to use an ablative system as we had on Apollo, so we had to look
at this new LRSI [Low-Temperature Reusable Surface Insulation]/ HRSI
[High-Temperature Reusable Surface Insulation] type material. There
were several nonmetallic materials, like adhesive systems, that were
going to become unique. We had begun to look at and we had used on
the Apollo Program several RTV [room-temperature vulcanized] silicone
type materials. We were going to be using them on the orbiter as well,
or at least we wanted to.
The challenge was these vehicles were not going to just fly once.
They had to be serviced; they had to have this long service life.
All of this suggested that we were going to have a lot of testing
to do. At those times we didn’t have a lot of the technology
we have today, so there was a lot of materials evaluation and testing,
a lot of lab work. Which was good for us because that was our job.
When I think back in terms of the orbiter program, a lot of those
early days of getting the contract was involved in trying to understand
with our NASA customer out of Houston [JSC] what the end item requirements
were and then developing answers to that in terms of the technology
and the changes that we were going to have to implement in the designs
and fabrication. One of the key documents that we referred to as our
“bible” in the labs was called the Materials Control and
Verification Plan. I have a copy of it here, this is out of my old
It was a very thorough document. What it did was establish, based
upon NASA’s end item specification requirements, how we were
going to implement that and what we were going to do. It covered the
gamut of just about everything that you could think of in terms of
material control. By definition control and verification says, under
contract, “Materials we use in this orbiter will be controlled.”
That means they will be selected as appropriate, they will function
as designed, and we will verify that.
Then when all this was over, we had to certify that when we deliver
an orbiter, yes indeed that orbiter is in full compliance with all
these requirements. We’ve got over 100 pages of elements here.
Everything from static age life, flammability requirements, outgassing
requirements, mechanical properties requirements—all of those
had to be established, understood, and then translated from the requirements
to the drawing to the actual production of the hardware.
How much did that document change before it became solidified?
The actual document, before it was approved by the NASA Center, went
through probably about a year of discussion and interpretation and
negotiation. Once it was published and released—this came back
to haunt some of my contemporaries at NASA in Houston. There was a
paragraph in the beginning that said this Verification and Control
Plan would be implemented and used on the program as a “guideline.”
That little word hung on us and NASA for many years, because for example
one of the critical areas in here was the flammability requirements
for nonmetallics. Later in the program after we had started designing
and were quite a ways down the design path, NASA decided that they
wanted to increase the cabin pressure. They wanted to do an oxygen
prebreathe, which would eliminate orbital prebreathe time for the
Well, what that all translated into was raising the oxygen concentration
from 14.7 psi [pounds per square inch] to 30 psi. That increase in
oxygen dramatically changed the flammability characteristics of a
lot of the nonmetallic materials. Flammability requirements were originally
based on the 14.7 criteria, and now you’re changing that to
30 percent oxygen concentration. You’ve changed the design requirement,
so this guideline has to change along with that.
That resulted in a lot of discussion and negotiation. The first result
was go test some key materials to see what the risk level is for increased
flammability of materials in the crew module. A panel of I think about
30 materials were selected and we sent them to White Sands [Test Facility,
New Mexico] for testing at the NASA facilities there. It turned out
that about 40 percent, or almost half of them, failed flammability
We had a rating system. If a material passed flammability it was A-rated
and it was used in the design anywhere. If it failed it was given
an X rating. Almost half of them did go to an X failure mode, they
burned very dramatically. With that sampling, there were several hundred
of the materials that we hadn’t even looked at yet and the question
was what are we going to do. We were far enough along in the design
process that a lot of it would be very difficult to change. In some
cases you couldn’t change them out.
This resulted in a program for about three years that I recall, where
every material that was in the crew module was procured, sampled,
test specimens made and sent to NASA White Sands. We rerated all the
materials based on that. If they were in critical use applications,
then we would have to go back and reconsider either a redesign [or]
an MCR [Master Change Record] action to the contract. Hopefully there
wasn’t too many, but there were some.
The whole exercise came down to would Rockwell recertify the crew
module for 30 percent cabin environment for flammability. That fell
on my office to do that certification. My decision was that there
was insufficient data and support for that certification. I presented
that to NASA and said that as a contractor we were not willing to
take that risk, we could not take that risk. So it would be up to
NASA to decide whether or not they were going to fly under those conditions.
That’s the way it was left, NASA assumed that risk. Almost on
a case-by-case basis they then controlled those materials and those
flights and signed off.
The single most important material that was debated and discussed
was Velcro. Velcro in the crew module was a real problem. The crew
loved Velcro. They had to have it everywhere; understandable. But
the problem was that Velcro in a 30 percent oxygen environment burned
like a fuse. If you continued to put Velcro everywhere you had a very
high flammability risk. So the recommendation was some stopgap measures.
Velcro could only be installed in short lengths. There had to be a
gap between them. The reason being if you did get an ignition there
would be no propagation, so you wouldn’t have a fuse effect.
We tried to limit it to so many square inches per surface and that
sort of thing. That was the way the risk was mitigated, under mutual
agreement between us and the ES5 [Materials Technology Branch] office
out of Houston.
Can you show me the date on that document?
Yes. That was in June of ’79. There have been a couple of minor
edits to it. My counterpart Mike [Milton W.] Steinthal kept badgering
me for years, “I want to revise that.” I said, “Send
me an MCR and we’ll go do it, but it’s going to take a
lot of money, going to take a lot of time, and we’re very mature
in the program. My recommendation is it’s not warranted. We’re
operating within the guidelines as we had established them. Let’s
leave it alone.” The MCR never came across my desk, so we were
never given contract authority to go revise it.
You were talking about dealing with different materials. You were
part of establishing the product support laboratory here?
Yes. There’s a little background history on that. During the
Apollo Program, as with many of the programs at that time, organizations
tended towards redundancy. For example, I was in the quality department
on the Apollo Program, in what was called the quality assurance laboratories.
Well, the engineering department had what they called the engineering
development laboratories. So in one company you have two laboratories
doing many of the same things. The question was why do we have this
The reason the redundancy was there was because the engineering department
couldn’t get the quality department to do tests that they wanted
to do and vice versa. Everybody went and did their own thing when
they weren’t getting the results that they wanted. We had some
significant management changes in the organization, which then led
to consolidation. Can’t continue to fund these two sources.
There was a reorganization to merge the quality assurance lab with
the engineering development lab. We came together and became one laboratory.
At that time one of the other things that was going on was we were
anticipating ramp up for the orbiter program. I said, “We need
to make sure that at the shop floor level the response from the laboratory
is more direct and more timely. So we’re going to create a product
support laboratory. Instead of over in a building someplace over here,
we’re going to put you right into the building where the production
goes on.” Our lab was literally above the shop floor. We could
go to the window, look out and see what was going on.
Consequently, some of the activities that we were involved in were
things like materials testing. The shop would be using an adhesive
that had a shelf life on it where they needed to check and make sure
it was still good. They could take it right to the lab, have it tested
on the spot. Quick response in terms of laboratory type testing and
The other significant task that we had was MR support, material rework.
Crews working down on the shop floor are building something, and it’s
wrong or they make a mistake—supposed to have three holes and
I put four holes or whatever—they’d write an MR. That
MR would then clear through our office. We would send an engineer
or technician down to the floor, take a look at what they did, and
give them a rework on it. The rework is don’t do anything, scrap
it, do something, whatever. Again quick response, direct, shorten
that cycle time in the whole process.
The third activity that the product support lab was heavily involved
in—there were a lot of times when we did our job right, when
everybody was working correctly. They didn’t need us. It’s
like policemen who don’t have crime, that’s wonderful.
When we had time on our hands we would get involved in failure analysis.
There would be many times when there would be a system failure in
a qual [qualification] test at a vendor and they’d call us up
and say, “Can you send an engineer out to support?”
This involvement with the failure analysis, with the MR action on
the floor and the laboratory testing made us extremely valuable in
terms of the design centers as well, because as we would find something
that wasn’t working—especially if there was a material
rework on a part and it was because of the process and there was something
wrong with the specification—then we would go back to the engineering
design office and have that all corrected. So an interagency function.
We had about 15 people working in the product support lab. About half
of them were technicians working in the lab facilities, and the other
half were engineers like myself who were handling the engineering
Who decided what came into your lab to be tested?
We had multiple customers. The primary customer was the shop floor,
and it would be an inspector. The inspector says this is wrong, this
needs to be fixed, there’s a problem. That was the principal
driver that brought that work in. Then there were project office people,
there were other departments. We frequently got involved in what we
called tiger teams. They were groups that were formed instantaneously
because of an emergency. The one example I can describe was the body
flap, I believe it was on [Space Shuttle] Columbia [OV-102].
Columbia was up at Palmdale [California]. It was in final fabrication.
The body flap had just been installed on the back of the orbiter.
As typical of these problems, it was second or third shift. They were
doing a hydraulic system installation and a pressure check in the
aft compartment. The resulting failure analysis said a QD failed,
quick disconnect. The result was the system under pressure, hydraulic
hose whipping around—it’s like a garden hose you turn
on with nobody holding the end of it—spraying hydraulic fluid
all over the inside of the aft fuselage. It collected down in the
bilge area of the aft, then a lot of that ran down and it dripped
onto the body flap that had just been installed for a systems fit
check with tiles on it.
The first phone call of course goes to upper management and then the
trickle-down. A tiger team in the middle of the night was formed and
called, “You, you, you and you, get up to Palmdale, assess the
damage, figure out what’s going on, what are we going to do.”
That little exercise cost us about three weeks of schedule. We had
to remove the body flap. The curious part of that story was that we
did not have replacement tiles to put back onto the vehicle. So the
question was what are we going to do with these HRSI tiles that are
soaked with hydraulic fluid. This was before we did the high tile
We looked around and said we got to get that oil out of there. At
the time, one of my other functions was working with contamination
control, so I was a principal engineer in solving that problem. I
said there’s one factor that we do know, that the hydraulic
fluid is sensitive to heat. If you get the temperature high enough
we can bake it out. The other factor was that it had a very low residue
point, because we had changed the hydraulic fluid type because of
that feature. HRSI tiles are impervious to heat, that’s what
they’re designed for.
So the recommendation was to go bake and drive the oil out of these
tiles, and we need to do it right away. How are we going to do that?
We’re going to get some propane-fired barbecue grills and put
them out on the back and we’re going to barbecue the tiles.
And that’s exactly what we did. It was a wonderful picture.
I wish I’d taken a picture of these technicians with the desert
sunrise and these barbecue grills flipping tiles to burn the oil out
of them and get them clean.
About how many were there?
It was about 30 or 40 tiles. I think on the body flap was a little
over 200 tiles on the whole array. It was a corner of the section,
so it wasn’t all of them.
That’s the good news.
That was the good news. And it worked, it worked very effectively.
It was a very effective fix and a very cost-effective fix. Timely
Speaking of the tiles, there was a thermal protection system analysis
system that you developed for the orbiter.
That was another tiger team, a bigger tiger team and a bigger problem.
We were getting ready to ship Columbia. Columbia was shipped in March
of ’79. It was in Palmdale, and we had a visit from one of the
NASA Johnson [Space] Center [Houston, Texas] people who came down
and they were inspecting the tile installations. At that time we had
quite a few of the tiles installed. I think that configuration was
a little over 31,000 tiles that had to be installed. They were on
a ground stand underneath the belly of the vehicle. Of course you’re
not supposed to touch the tiles, because the oil from your hand interferes
with the surface condition of the tile—not without gloves anyway.
But our NASA customer is our NASA customer, and this gentleman decided
he wanted to touch one of these tiles. He reached up and as he did,
he touched one of the tiles. Unfortunately the tile came off in his
hand. That was a real problem. It triggered another tiger team, a
whole year of activity. The synthesis of what that analysis was there’d
been a mistake in terms of calculating, and thinking that the adhesive
bond of the tile to the structure was a nonstructural bond. And that
is not true, it is a structural bond. The decision had been made early
on if it was a nonstructural bond it didn’t need to be tested.
So all these tiles had been installed and nobody’s tested it.
Here we sit with 31,000 tiles, about 80 to 90 percent of the vehicle
tiled, going to be shipped in a month or two. We don’t have
any confidence in the integrity of those bonds. A tiger team was called
at the product support lab. My boss at the time, Jorge [H.] Diaz,
brought us in and very somberly he says, “We are in big trouble,
we’ve got to fix this. We’re going to figure out what
the problem is and fix it.”
The first approach was to figure out how big the problem is. Since
we don’t know whether the integrity of the bonds are there,
we’re going to have to develop a test method to figure out how
to test these tiles. The challenge is you got to test them in place.
How do you go to basically a vehicle with eggs bonded to it, and test
all of them without breaking the rest of the eggs? Day and night we
worked for about three weeks coming up with a test. The test we came
up with we called the spider puller.
This device we called the “spider” because it was a pad
that was the shape of the OML [outer mold line] of the tile. It had
a very light RTV seal around it, so it could go onto the surface like
a suction cup and apply just enough pressure. We pull a vacuum on
it, then we would react it against these four legs that came out,
which then very gently lay on the surface of other tiles. The idea
was it was a pull test. It’s like taking a suction cup and pushing
it and then pulling on it. Then from that we were able to measure
the stress load on the bonded surface.
The magic number was six psi. If it would meet a six psi pull, then
the bond strength was acceptable and we would approve it. The first
thing we did was we proved the test. We showed that yes, the test
worked, it did tell us what we wanted to know. We could discriminately
determine whether that tile was good or not and then you’d move
on to the next tile. One down, 29,999 to go. How are we going to do
The first thing we’re going to do is replicate the test kits,
the very complicated test instrumentation had to be built. To start
off with we built 30 of these test kits. We built them in one week,
which in retrospect was one of the most interesting projects I had
because we literally had a blank check to go buy equipment, put this
together and make it happen. The bad news was we were working 24 hours
a day to get it done. We got 30 kits built, [then] we had to train
teams to go do the testing.
Beyond all of this, we have an orbiter sitting in Palmdale that’s
supposed to be at [NASA] Kennedy [Space Center, Florida]. What are
we going to do? We’re going to ship it, we ship on order. It
flew down there, and that meant that now all of this testing would
have to be done at Kennedy Space Center. The first thing we did was
send a team down, almost 150 people, that had to commandeer the OPF
[Orbiter Processing Facility] and take it over as a testing facility
for all these tiles. At one time we had close to 400, 500 people from
California that were on travel status. We would go down for three
weeks, come back for a week, go down for three weeks. We were on rotation.
We had to test all the tiles that were on the orbiter and prove that
they were acceptable, and if they weren’t then they had to be
removed and replaced.
Most of them were okay, turned out that the actual bonding process
was pretty good so we didn’t have to replace that many of them.
My special involvement in that exercise was working with Jorge Diaz.
He was the team leader from Rockwell’s standpoint. He let me
take on the task of what we called “the impossible 100.”
By configuration there were 100 tiles that were impossible to test.
Even with our best test method there was no way that these tiles were
ever going to be tested in place.
My job with my team was to show by analysis why they would not be
at risk. In most cases it wasn’t too difficult because either
the tile was trapped—it was a tile that was behind another tile,
so it would still be contained and it would not fall off—or
because of the nature of the process data that we had, we could show
that there were process test coupons and based on that we could sell
it. It was an engineering paperwork analysis. That was my particular
function over the course of several months down there, to convince
everybody that it was not a threat, that these 100 were okay. And
that was fun.
After the Columbia returned, what was your conclusion on the work
that you had done?
I think everybody had done a fine job. Looking back at it, typically
we tend to overdesign our products, especially where it’s man-rated.
That was a lesson learned from Apollo, and it was just as true in
my opinion on the orbiter program. I think that overdesign tendency
in choice of materials and construction served us very well in giving
us that extra safety margin and success. The big question had always
been, “Gee, with all these tiles on there, when we light the
fuse and send the first one up, how many tiles are going to be in
the bucket and fall off?” That was the big threat and question.
We were all pleasantly surprised that they all stuck. And not only
did they stick, but they continued in service.
I’d be very fascinated to find out what the replacement [rate]
has been. I imagine it’s been fairly low because it turned out
that most of the replacement was only based on physical damage. The
bigger damage was people bumping into it or moving a ground stand
into it or something like that. Somewhere in the files here is a copy
of the first STS-1 report that looked at the tiles specifically. We
sent another team that went out there and did a very thorough examination
of all the thermal tiles when they came back.
Must have been a very satisfying but exhausting time.
Yes it was. A lot of lessons learned. For a period of almost a year
and a half we had teams going down there of engineers and technicians.
These were very intense periods, stressful times. They were working
long hours under pressure, the customer was looking over our shoulder
every step of the way. We were trying to meet schedules, get things
done. Most of these people were removed from their families, they’re
down there for weeks on end.
When we started bringing crews and teams back, one of the biggest
problems was you’ve been working in this intense high level
environment and you come back and we sit you at a desk, they have
you reading specs [specifications] and documents. That drop had some
serious impacts on us in terms of staff. You get a high out of that,
“I want to do more of that.” A lot of people actually
transferred to stay in that environment down there. Other people changed
jobs. Some people just couldn’t take it coming back to this,
just wasn’t the kind of thing they were comfortable with anymore.
It’s very interesting how one tiger team issue can turn into
issues that you have to deal with when you break that tiger team up.
Tiger teams are unique in that they’re very intense, but the
result is it’s a make-or-break situation. People perform at
their best or at their worst. A wonderful example I remember reading
recently was on the 9/11 [September 11, 2001 terrorist attacks]. They
had an uncontrolled tiger team. The agencies were just in everybody’s
way trying to figure out what to do, and it was one gentleman from
public works in New York who stepped up to the plate and got it all
Most tiger teams are the same way. Everybody’s got an expertise,
but one person steps out and will take the lead. A good tiger team
lets that person lead and, when they’re finished, move back
and another one step in, which is the perfect model for what a good
efficient team should be. But tiger teams last for a minute and then
Talk to us about the life certifications for the orbiter, how you
were able to certify that they could fly for 10 years or 100 missions.
The original contract requirements were NASA wanted an orbiter that
was capable of either 100 missions or 10 years. The anticipation is
that we’re going to fly 100 missions in 10 years. Obviously
that, as I said before, was pretty naive. But when our control plan
was written and when we looked at selecting the materials for age
life, it was based on the fact that it says for a minimum of 10 years
or 100 missions.
That qualification says that I’ve built you an orbiter, and
every material on that I am certifying is going to last for 10 years
or 100 missions. I didn’t say whichever comes first, but it’s
understood by virtue of our analysis and our decisions here that it’s
a ten-year minimum. This material is not going to dissolve at nine
months—that’s something that’s going to be there
for ten years.
The thing you have to remember about the build cycle, we had a lot
of things going on. The actual build cycle for orbiters was from about
1972 to about 1992. Long lead items were purchased as early as 1972.
That was of course on the Enterprise [OV-101] vehicle. When you buy
materials, the age dating is from the date that the material is formed.
So if I started construction on hardware and elements in 1972, ten
years is going to be 1982. I didn’t deliver the vehicle until
1979 so material in some cases were already five years or older. They
had half of their life according to the certification by that time
As we came up to ten years Mr. Steinthal calls my office and he says,
“All right, Jerry. Here we are, we’re coming up on ten
years. Is my warranty up?” I said, “Well, Mike, I don’t
think so. We need to talk about this but no, your warranty isn’t
up. We said 10 years or 100 missions. You haven’t flown 100
missions yet. You haven’t even flown one mission on some of
them. You’re okay.” It’s like buying a brand-new
Cadillac or Lincoln [luxury car] and putting it in the garage and
never driving it. Then 15 years later you come back in, is that a
new car? Technically it’s a new car. On the other hand, is it
going to function the same way as if it had been new? No. Because
the orbiters are designed to be flown, they’re designed to be
I said, “I will do an analysis and I will give you a recertification.
I will recertify to NASA that the life of the orbiter materials will
be extended for another ten years. So I’ll give you a 20-year
life out of the orbiter.” The agreement was okay that’s
fine, we’re good on this. Little did I realize that we’d
look at a 30-year certification on it, or that when we lost [Space
Shuttle] Columbia [STS-107 accident, February 1, 2003]—I had
several phone calls, the first one of which I did not really care
for. It was from the LA Times [newspaper] and one of the reporters
there was trying to build a story around the orbiter fleet being obsolete
and the materials all going to hell in a handbasket. I said, “No,
I’m sorry. I was intimately involved with the program and I
can guarantee that there are no materials issues with age life. This
is a very sound design, the vehicles are very solid. There are no
age life issues at this time.” And wouldn’t be for many
many more years.
However, I did get a phone call from [The] Boeing [Company]. I had
already retired by then, and they asked me to come back. They said,
“We’d like you to work with a team that has been asked
to recertify the orbiter for 30 years and in some cases up to a 40-year
life on materials. Will you come in and help?” So I went back
and worked with a team and we looked at all the materials again, taking
it from our last certification and extending out in some cases to
40 years. A lot of those materials are nonissues. The metallics—aluminum
isn’t going to age significantly over those periods of time.
It was mostly the nonmetallic issues. The biggest threat was some
of the adhesive areas.
We ended up doing a certification based on analysis, and testing in
some cases. I suggested to Boeing, “I would like to take an
engineering team back to the Smithsonian [Institution National Air
and Space Museum, Washington, DC] to do an evaluation on the Enterprise,”
because the Enterprise is actually the oldest vehicle in the fleet,
and it represents a lot of the actual flight materials from the regular
operational orbiters. We have a living specimen sitting there in a
wonderful site. I talked to Valerie Neal [curator] and we worked an
arrangement where we would help their curators at the same time, who
were preparing it for the [Steven F. Udvar-] Hazy [Center]. We spent
a couple weeks back there going through the vehicle and inspecting
all the materials, especially concentrating on those nonmetallic materials
and adhesives that were questionable.
The results of my report to Boeing was that not only did I have confidence
in the 40-year certification on most of those materials, I would almost
go indefinite. I would be willing to certify that the orbiter Enterprise,
if it needed to be, could be retrofitted as an orbital flight vehicle,
because the vehicle was in that good a condition. That’s after
sitting out on the apron in [Washington] Dulles [International Airport]
for several years in the snow and weather. It’s in remarkable
condition. It goes back to the design rigor that we put into material
selection and design and build.
That’s where we closed the book and said it’s good for
40 years, the vehicles are not going to fall apart. I felt pretty
good about that, we did a wonderful job. My only hope had been—when
I finished my contract with Boeing I said, “I really think that
you’ve got a wealth of data and information here that needs
to be not only preserved, but it needs to be integrated back into
your programs for the future. Knowing what we know about these materials
from an age life issue, that criteria should be used in design for
future programs. You need to figure out how to go do that.”
That’s where I left it with them.
Did you find yourself in an interesting position on that contracting
consulting basis? Did you feel like you had more of an opportunity
to be more direct on your findings than maybe you did when you were
in charge of the lab?
Well, it’s definitely in a different space. I’m going
back to a facility I had been working at and I’d been an employee
at. But now I’m not there as an employee, I’m there as
a contractor. That’s an odd feeling. A lot of the people I’m
working with are the same people I worked with when I’d been
there, so we’re picking up conversations that we had had before.
But you’re right. I’m now there for advice and counsel,
not direction and decision, and I could be a little more firm. I could
twist a few more arms, I could make things happen. When I wrote the
final report [to Boeing] I said, “Please make sure that you
share copies of this report with the curators of the Smithsonian and
with the NASA Centers as well.” I don’t think that report
was ever released outside of Boeing, for whatever reason.
One of the reasons I did accept the contract in the first place—I
said, “I want to make sure that I have an opportunity to interface
with some of the younger engineers, because I think I have some things
I can share that would be helpful for them in their learning process
and their growth.” I found that the management and the leadership
was very different, a lot younger and much more reserved than we were
when we were managers. Leadership and people on the Apollo Program
versus leadership on the Shuttle orbiter program versus what I’ve
seen at the end in the new program, they are very three different
I would like to say it’s evolutionary, but I can’t because
it’s not going in the right direction. I’m afraid it’s
been mitigated in some ways, diluted. I’ve got my own theories
as to why that is. I think that when we were working Apollo, Apollo
was the first example because there was no books. We wrote the books
on aerospace technology, manned space technology. Orbiter was the
same thing. It was more complex, it was more convoluted, involved—it
was different in another way.
The difference is that then—aggressive is the wrong word. There
was a much stronger acceptance of the need for decision and tied in
direction in terms of what your job was. You are the customer as NASA,
and we are the contractor. You are paying us to make these decisions
and help you meet your requirements, so we’re going to do that.
A lot of our conversations during the orbiter program were just that
The best example—Mike had flown in from Houston, and we were
in the office. We were having a very elevated, heated discussion on
a technical topic. Mike can be that way, and I can be that way. My
secretary came in after he left and she says, “Are you going
to get fired?”
I said, “I don’t think so.”
She said, “But you were almost at blows.”
I said, “No, we were aggressively discussing issues.”
That’s the way that was at that time, and I think it was an
important factor in terms of the successes that we had in the program.
You mentioned earlier that there were some times where you weren’t
as busy. Could you tell us how your support lab changed or how it
was impacted once you moved out of development production into operations
phase of the Shuttles?
When I came back from the TPS [thermal protection system] issues down
in Florida—this is one of the other spin-offs from tiger teams.
You do a good job, you might get promoted, and that’s exactly
what happened. They put me in charge of an engineering group called
Materials Control and Specifications. I had about 30 people working
for me. Principally we were all the technical spec [specification]
writers for the program, but we also had a couple of other special
Because of my experience with the 100 tiles, I inherited a project
that this group had called single barrier failure analysis, SBF. The
SBF were 80 components that were on the Shuttle orbiter that were
critical components. That meant if they failed we’d lose the
orbiter, Crit 1 as we called it. The problem with these 80 components
was that they were very complex. Control valves, things like that.
They had to be thoroughly analyzed in terms of the single weak link
in the design. I had a couple of engineers that had been working on
the project for two years, and I was left to bring it to closure with
NASA had requested us to provide confirmation and analysis of risk
mitigation for these components based on this single barrier failure,
which meant there was one material or one element in the design that
if it failed the whole component failed. In most cases these were
subcontracted components. We had to go work with the designers and
subcontractors. We had our engineers look at it, and then worked with
the NASA office to come out with the understanding and rationale as
to why these were not a risk to the program, or how they were being
controlled and managed. I ended up going down in the mid ’80s
to Houston to finally sell off all these to the program, to the ES5
The other aspect of this group that I inherited was a computer system
called MATCO, the Materials Analysis Tracking and Control System.
It started from the Apollo Program. The Apollo Program was another
unique program in that we didn’t have the technology we have
today. The best we had working for us were mainframe computers with
a lot of keypunch cards. We had a program called COMAT, Controlled
Materials, for Apollo. It was the early attempts at mechanizing information
on materials. So when the orbiter program came around, we invested
our own money into moving this to the next technology level.
We had a computer program that actually tracked every material that
was on the orbiter and where it was and showed how it was verifiably
okay. I had about five or six encoders. Every drawing that was created
from orbiter came through our office, went to one of my encoders and
one of my design checkers. First thing they looked at, “Did
the engineer select the right material, or is it the wrong material?”
We had to approve whether or not that was correct.
If it was a subcontracted product, valve or component or wing, same
question. “Were the design drawings and the materials selected
and used proper and meet contract requirements?” All of this
funneled in through a group of people that were doing the analysis.
Then we had worksheets that we prepared, and they were given to computer
encoders that would input this into the mainframe.
The reports that would come out identified every single material by
designation, and then it rated it based upon the requirements of use
for that material. This is for a metallic material, CRES 302, a stainless
steel rated at 125,000 psi. It’s bar and rod stock to an AMS
[aeronautical material] spec. We had the operating temperature it
was going to see in the vehicle, we had a corrosion rating for it,
we had a stress corrosion rating for it. We had a gaseous oxygen rating,
liquid oxygen, nitrogen tetroxide, hydrazine. This whole family of
requirements would have to be analyzed and checked off. In this case,
because stainless steel is such a good corrosion-inhibiting material,
it has an A rating.
This MATCO system served two purposes. Number one, it was a way for
us to track and make sure that we were using the right materials in
the right application. Secondly, it was a way of verifying. So when
you come to me as the customer and say, “Prove to me that you
did use the right materials,” I can show you how we used the
right materials. This computer program and data, which was the core
data on the engineering selection of materials, could then be tracked
back against the configuration drawings of the vehicle. I could go
into this computer system and say, “This material CRES 302 Condition
B bar wire, I want to have a report that gives me every part number
on the Shuttle orbiter that uses that material.” I want to know
where it is, and I could do that.
This became very critical because later on, once we delivered the
orbiters to NASA, one of the things that was going to come up was
a flight readiness certification. A flight readiness certification
says all right, I got my orbiter, I’m ready to send it up, prove
to me that everything on that orbiter meets those requirements. We
would have a report run and we would send that to NASA and say this
is the verification. There was a formal sheet that we would sign off
on that says this proves that this vehicle is ready to go.
What becomes real important here for this computer system is that
people don’t understand that not every orbiter is the same.
Not only is not every orbiter the same, but each orbiter unto itself
varies from mission to mission, and day to day. Part of the significance
of this was that we could match our engineering data to a snapshot
in configuration time. Theoretically I could go back in this and tell
you what the material selection was and condition for an orbiter on
such and such a date. That’s how significant this was. Very
intensive in terms of computer programming.
Remember again, this is before the world of computers of today. When
I went back on the certification for life extension, the consulting
contract, the office that is now handling this for Boeing called me
up one day. There was a review team that was coming in from [NASA]
Headquarters [Washington, DC], and they were looking at program cost
associated with this system.
There were two questions that they had. Number one was the computer
code for this program is very expensive, because it’s mainframe.
It’s old world, a lot of cost associated with that. So the question
was, “Do we need this anymore, can we get rid of it?”
I said, “Well, if you’re asking me, the answer is not
only should you not get rid of it, but you have made a very big mistake
in not taking this and migrating it to the new technology and getting
this to the point where you can run it on your laptop or access it
over the Internet.” That’s mistake number one. You should
have transitioned it. Before I left my group that was one of the things
that I left for management to consider.
The other thing is that in this system you have invested millions
of dollars in information that is priceless. At one time when I was
running this program our new business office approached me and they
said we had a contact from Japan. Hitachi [Ltd.] wanted to buy this
program for their space program. I asked the guy, “What’d
you tell them?”
He says, “I told them no, we’re not interested in selling
I said, “Really. Do you realize what you have here?”
He says, “Ah, it’s just another computer program.”
I said, “What you have here is the basis and foundation of engineering
analysis of material selection for manned space hardware. It doesn’t
exist anywhere else.” That’s where I left it. “I
hope you’re successful, but I’m going to keep these copies
for myself just out of curiosity.”
This is what we call the directory. The directory is just a list of
the ratings of materials that have been looked at for the orbiter
program. One of your questions was how many materials were used on
the orbiter. I used to ask that question every day. My staff—I
said, “I want to know how many materials are on these vehicles.”
Of course you can’t answer it because it depends on time configuration
vehicle. What I finally started using for my briefings and whatnot—roughly
an orbiter contains about 800 different metallic materials. That’s
everything from the structure down to components and springs.
We have a little under 3,000 nonmetallic materials. It’s everything
from TPS to lacing thread. There’s a lot of materials there,
that’s a lot of work. That was a great group. I really enjoyed
working with that group for the years that I did. Of course by that
time I’d moved out of the technical side into the management
side so I was spending more of my time on people issues and program
issues than I was on the technical stuff, which was the fun stuff
when I was younger.
When Columbia came back to Palmdale and started getting its modifications
in the early ’80s were you involved with those issues as well?
A little bit. Columbia was our first love. Enterprise was the first
vehicle that we put all our energy into, and [STA-/OV-] 099 [Challenger]
was the [Structural] Test Article. But Columbia was the first real
ops [operations] vehicle. There was a lot of labor of love that was
in that vehicle.
It took longer to build Columbia than it did any of the other vehicles.
If you look at the cycle, it’s about seven years that we had
been working on Columbia from first lead item on through. The other
vehicles, most of them were like three to four years for a build cycle.
We spent more time with Columbia, we had more invested in it. A lot
of the lessons learned were on Columbia, which later translated into
the rest of the fleet.
In terms of the actual mods [modifications], my involvement in most
of those was through the product support lab. We would get phone calls,
“We’re making some changes, we’re doing this mod
installation.” Or through the office, it was the drawings. We
were looking at the EO [engineering order] changes and the mod changes,
talking to people about making material changes where they made sense.
One of the big issues that came up was if there was a new material.
NASA would come in periodically and we’d do these program reviews
in terms of getting ready for delivery. They would send a team in
from the appropriate Centers. Then basically it was a grilling of
the engineers and the designers in terms of, “All right, let’s
talk about what you’re doing to the vehicle and what makes sense.”
From our side it’s changes that we wanted to make that we thought
were important. Of course NASA is coming back and saying, “We
haven’t got any money, we can’t do that.” Or don’t
want to for whatever reason.
We would have this review for about a week. The NASA system Centers
would write up what they called RIDs, Review Item [Disposition]. It
was an item that they found in the records that they felt needed to
be addressed. The measure of your success as a designer or design
group was how many RIDs you got. If you got a lot of RIDs you’re
in trouble. Nobody ever got zero RIDs, because everybody who came
down had to prove why they were there.
On this particular vehicle—I think it was Discovery [OV-103]—there
was a young engineer from Houston, brand-new kid. I felt sorry for
him because he wasn’t getting much mentoring. He was left to
himself, and he felt that he had to prove himself. He started doing
a review, and he wrote this RID and turned it in to my office. I read
it and I called him in. I said, “I don’t think you want
to turn this in, I think you need to go take it back to one of your
senior members and rethink this one.”
“Well, no way, I’m here as the customer.”
I said, “All right, if you’re going to let it go, let
He had reviewed the drawings for the orbiter that we were getting
ready to ship, and his decision was that we could no longer use single
panel circuit boards. We needed to switch to multilayer circuit boards.
That was new technology, but on this design we had single layer because
that was the design at the time. In most cases all of the components
had already been qual cert [quality certified] and built with single
layer boards. His RID was to change our design and remove and replace
all circuit boards in the orbiter and replace with multilayer boards.
I said, “This is career-limiting, young man. You put this out
there, besides being a laughing stock, you’re going to have
some problems.” He refused. So we went down for the review.
This kid gets up there and he starts his pitch. Aaron Cohen was there
at the time. Aaron is sitting back, listening to this kid. He [Cohen]
turns over to somebody next to him and he says something—Aaron
didn’t even respond. The guy next to him said, “And this
is your own idea, young man?” Something to that effect.
He said, “Yes sir.”
He says, “Pull that RID and I want to talk to you.” It
Those were the kinds of things that we were constantly working at
that time. If you’re going to make a mod change it has to be
significant, and you have to think about it in terms of its retroactive
impact and its future impact. In many cases if we did make a change,
even like the few that we made with the control plan, we only made
them for future designs and applications. That became critical in
the program. In retrospect, counsel I would give to the program today
is a lot of those were serious and good decisions, and hopefully they
got captured and they’re being factored back in so that as a
lesson learned you don’t go back and make the same mistake again.
What type of impacts did the Challenger accident [STS 51-L, January
28, 1986] have on your area for materials and processing?
The obvious ones, from an emotional standpoint, were just devastating.
It was unbelievable that we would have that kind of a catastrophic
failure. But there was a part of everybody I think that said statistically
your luck is going to run out. Statistically no matter how much you
did put into the program for success, the complexity of the program
is such that it’s going to be there. Columbia [accident] proved
that statistic again with the same result.
Now with all that being said, most of us, I think what we did was
we came back and said, “Oh my God, what have we done wrong.”
There was this immediate self-introspection, “We’ve done
something wrong, we’ve got to go find out what it is.”
That’s the first reaction that I saw, at least on my staff.
Everybody renewed their efforts. They wanted to be part of the fix
too. Little did they know that they would, with the return to flight
program that went on.
The return to flight management’s reaction to Challenger was
every single requirement and thing that we have done is suspect. “You
will go back and review everything you did.” We literally did
until [STS-]26 [return to flight]. That’s all we did was go
back and take a look and check and double-check and make sure everything
The curious thing about the Challenger accident from my standpoint—one
of the engineers on my staff, the day after the accident, came into
my office and dropped a briefing on my table. He says, “Take
a look at this.” I started thumbing through it. It was a briefing
that he had pitched the October before to one of the review boards
about the cold temperature seal effects on the solid rocket boosters.
Describing exactly the failure that we had. I looked at it and I said,
“Thank you, appreciate that. I’ll pass it on, but I’m
sure there are other people that have been looking at this and understand
what its impact is.”
It was an awakening for everybody that we’re in a very risky
business. There’s nothing given that says this is going to be
perfect every time. I’m convinced that it did renew the vitality
of the group and its rigor in terms of performance. It’s just
like any of these kinds of accidents. The safest period in time is
after the accident because everybody’s on target by then.
By that time we had already delivered Discovery and we’d delivered
Atlantis [OV-104]. A lot of it had been passed down to the Cape [Canaveral,
Florida], so we were going to rely on the Kennedy ops. About that
same time I think was when we were getting into the LSOC [Launch Support
Operations Contract] operation transfer. They were consolidating,
so there was a lot of issues and tension there because there was a
bidding war going on in that contract.
We felt that this was not the time to change hands on hardware, but
that wasn’t shared. There were transition issues, but I think
one of the things it did was it began the process of removing the
focus from California as a design center to the ops center down at
Kennedy and the world down there. The spin-off from Challenger was
the contract go-ahead for Endeavour [OV-105]. That renewed our vigor
in terms of we got another orbiter to build. In my opinion, I think
that Endeavour and Atlantis and Discovery are all much better vehicles
than either Challenger or Columbia were. It’s not to take anything
away from Challenger and Columbia. They were all just as sound, but
Before we close out today, I wanted to check with Jennifer and see
what questions she had for you.
I did have a couple. You noted that there is a difference between
all the orbiters in the fleet. Can you give some examples of the differences
Probably the most significant difference in the orbiters was Challenger,
because Challenger wasn’t supposed to be an orbiter. It was
a test article built just for structural testing. Enterprise was the
one that was supposed to be the ops vehicle. The only difference between
Enterprise as an operational flight vehicle and the other vehicles
was we had a configuration requirement which we called the sealed
structure. That meant when you brought a bulkhead up to a surface
and installed it, there would be a wet seal that was put in between
there to keep it from fluids and gases. Enterprise didn’t have
that. That was one of the factors and conditions I think for the decision
to use it as a flight vehicle, because it’s not a sealed vehicle.
Challenger, what it had going for it was it had proved all the structural
loads. If anything you had what you call burn-in. So you had the flip
there. Those were the two vehicles with the major differences in terms
of the rest of the fleet. Discovery, Atlantis, Endeavour were all
pretty much the same in terms of configuration. The minor differences
are the later installations of the drogue chutes [parachutes] that
were put in. One of them had the extended duration configuration,
designed for longer missions. Then there was the other one where we
did the mod with the airlock.
Structurally and materials-wise, minor differences between all the
vehicles in the fleet. You had the installation of what they called
the MEDS [Multifunction Electronic Display System], glass cockpits
and that sort of thing. I think for the average person looking at
it, an orbiter is an orbiter is an orbiter—they all look the
same. But it’s like a race car driver, he knows the difference
between the cars and the way they handle. Of course as the constructors
of the vehicles, we know that we didn’t have this tooling back
then, we didn’t have this capability back then. It progressively
I’m building the build timeline of the vehicles. When you take
a look at that compared to the operations timeline, the entire build
cycle was concentrated in a very short period of time. The build cycle
of Challenger has a chronology of ten years. That’s because
a lot of it was spent as a Structural Test Article as opposed to just
But when I go back and I look at this from my career standpoint, from
1979 to 1986 is this intense period of building and constructing spacecraft.
That’s when the heart of this program was active and going on
from our standpoint. In 1986 there were four orbiters down at Kennedy.
We were really looking at the end of the program at that time, because
we didn’t have clear direction. We had spares, but we didn’t
have clear direction for [OV-]105 yet. Of course then [the loss of]
Challenger changed everything.
You talked quite a bit about materials. But I was curious about the
other aspect of processing. Would you tell us a little bit about your
activities involved with that? Were you looking at subcontractors,
work at KSC in operations?
I made up a list of things I’ve worked on through the program
and activities. Any one of these could probably be a whole story unto
itself. One of the first things when I came on to the programs for
manned spaceflight was contamination control. It was a technology
that we developed through the space program. I became a resident expert
in it, myself and one other engineer were the only two contamination
control experts at the time at the company. Developing that technology
was critical, and it still is today of course. Part of that was failure
analysis and microchemical analysis. I got involved heavily into that
portion of it.
The other process was orbiter DD250s. DD250 was the pink slip, we
used to call it the pink slip of the orbiter. When we got ready for
an orbiter to go to the customer—the very first one was Enterprise.
When we DD250’ed Columbia, we had a three-day session up at
Palmdale. All of our design center people flew up to Palmdale. I went
up for the materials side. NASA flew in from Houston, they had Kennedy
reps [representatives] there as well. We spent two days literally
going through and kicking the tires and peeking and poking.
It was the customer sign-off and acceptance of the vehicle. The DD250
was, “You asked me to build you an orbiter, I built you an orbiter.
Here it is and we’re going to deliver it.” Of course there
was, “Well, you got to fix this, I want that taken care of”—we
had a tick list of things. The DD250—and I was involved in four
of those DD250 trips—was always an exciting time because it
was a completion. We finished it. You wanted an orbiter, you got an
orbiter, here it is. Each time it got a little better. The first one,
nobody’s sure about what’s going on. We had a lot of tick
list items to go through. But by the time we got down to Atlantis
we pretty much knew what we were doing. We knew what we were looking
The orbiter flight certifications, before each orbiter flight we had
to certify, as I mentioned, that the materials and everything met
requirements. One of the issues was how do you do that. I don’t
want to do this every single time, so we began to develop what we
called exception reports. I would take a snapshot of the configuration
of an orbiter, Columbia for example, as I delivered it. That would
be baseline. Then Houston and Kennedy would either manifest changes
or they would identify things that happened.
All of that flowed through my office. Our people then would go through
it, and we’d run that against our configuration and show the
differences. “There were 350 drawings that were changed for
this flight, and these were the changes that were made. They were
run against the system and they were all okay.” And if there
was an exception we’d have to sign off on each one. We had to
do that for every single flight mission.
Up until I left I had a staff of about five people that were handling
that. When I came back after Columbia, I was curious, and I went over
to the office. I said, “How are you guys doing that now by the
way, since you’re not using this system as much as you used
to.” They said, “Oh, it’s this guy over here. He
signs off on everything.” Oh my God. I’m glad he’s
a very smart man.
Solder Waiver Board, my office handled solder waivers. Frequently
there would be hardware that required electronic solder fabrication
processes, and they didn’t always meet requirements. So I had
a member of my staff, an electrical engineer, that sat on the Solder
Waiver Board. NASA quality and engineering would look at every waiver
and change. It’s supposed to have certain requirements. If they
didn’t meet them, we’re not going to change it. We’re
going to go with it the way it is, we’re going to waive the
requirement in this application, approve it. That was another action
we had to do.
Another major exercise we got into—I think it was about 1990,
’91. We had been given the go-ahead for the orbiter 105, and
we had delivered the other four orbiters and of course we had lost
Challenger already. NASA had written a specification called the OVEI,
Orbiter [Vehicle] End Item. That specification, which happened to
take up three volumes, was literally our contract for the orbiter.
The head of NASA Johnson contacted the president of the division and
said, “You know what, you’re getting ready to build and
deliver this last orbiter. I think it’s time we went back and
looked at the end item spec and revised it to look like what we built.”
So there was an exercise that literally took every paragraph and said,
“Take this original end item specification requirement, go look
at it as it pertains to the hardware we delivered. Is it still true,
or did we do something different? And if we did something different,
put together the documentation trail that shows why you changed it
and why it’s better.” That was an exercise that cost me
about three of my staff at least a year and a half, going through
all of the materials pieces. Part of it was material verification
plan, going back through and saying, “Did we do everything exactly
the way it was originally contracted?” I love that word guideline,
because as a guideline, yes we did.
The item I’d like to close with was in 1990 I was approached
by the division president for a special project. It meant leaving
the orbiter program in a way, but they wanted me to participate in
a special divisionwide team to look at implementation of MRP II, Manufacturing
Resource Planning. The company was anticipating I think getting into
the orbiter production business, because MRP is a mass production
type of computerized program.
They said, “What we want to do is see if we can design and build
the factory of the future.” A paperless factory of the future,
with new technology. The next two years I spent working this project,
looking at implementing a product called MACPAC as an MRP II system
into our plant here. We spent a lot of money and a lot of time, we
learned a lot about automated production. The conclusion we came to
is it does not make sense on a program like orbiters when you’re
not building more than three or four. The complexity of an MRP system,
even though you’ve got the computer tools to work for you, it
doesn’t work without volume.
The good spin-off that came from that, that did impact the orbiter
program—one of the first sessions we had, we had all of the
functions of the company sitting around the table and we started talking
about what we did. The design engineering group raises their hand
and says, “We design the product, we select all the materials,
and we create all the parts that go into the product.” Then
the manufacturing people step up and they say, “We build the
product, and we take all the engineering drawings and put the manufacturing
part numbers on them”—that are different from the engineering
part numbers and have different processes. Then quality gets their
turn, “We do it different.” Turned out there were five
different numbering systems for materials and parts, which is a real
problem in terms of potential issues. Communication, a bunch of other
So I went back to my staff and said, “Look, I need your help
on this. We need to solve this problem if we’re going to have
a total system that everybody can work to.” They designed what
we called an RMI system, a Raw Material Identifier. It’s one
number that’s semisignificant that everybody uses. If you’re
the design engineer and you’re going to create or call a material
out on your drawing, you’re going to use the RMI. You’re
not going to use the vendor’s number, you’re not going
to use quality’s number, you’re not going to invent your
own number. You’re going to use this RMI. If you’re quality
you’re going to do the same thing. If you’re materiel
and you’re buying the material, you’re doing the same
thing. That RMI system, which we’re still using today, significantly
reduced, in my opinion, communication issues with raw materials. That’s
the real threat. In many of these designs you get the wrong material
in the wrong application. That’s where you’re going to
have a failure and a problem.
What do you think was your most significant accomplishment while working
on the orbiter program?
I’ve had people ask me what I remember most about my 40-year
career, and I’ll answer that one in a minute. But back to your
question, there’s no two ways about it: my most significant
accomplishment for me personally is friends, people. It’s being
involved and participating in this program. That to me is an accomplishment
if nothing else, the ability to say that through my efforts and what
I did participating, I made a difference somewhere. Even now people
going through these old records, every once in a while somebody’ll
pick a document up and say, “I know that guy.” That’s
my name, I did that. That’s a warm fuzzy and a feeling that
you just can’t take away.
I like to think that my contribution was leadership, if nothing else.
When I did my MBA [Master of Business Administration] work in management,
people and working with people was one of the key things that I liked
focusing on. During the course of my tenure there I had about five
or six secretaries. One of my bosses used to come around and he said,
“What’s the matter, why can’t you keep a secretary?”
I said, “Because you guys keep stealing them from me.”
With a lot of my staff, people tended to move on and be promoted from
my group, which I really liked to see happen. The other thing was
I was known as having more women engineers than any other department
or group in the company. There was always some comments about that,
and there’s an old phrase that somebody shared with me that
I happen to believe in. “Sometimes the best man for the job
is a woman.” Just so happened that I had a lot of good ones
that came by, they met the criteria and did the job.
What is the one memory that I have of all my 40 years? It was the
day I was coming out of the plant on the Apollo Program. [I had] been
working late, and I’m standing out there at the gate and I see
the Moon over the plant. It just so happened it was a time when we
had a crew up there. I thought, “Wow, here we are down here
putting in all this sweat and labor, and there they are up there making
history." Felt that connection. That was cool.
That brings to mind another question. There were a lot more women
working on Shuttle than there were on Apollo. Can you share with us
some of how things changed when more women started becoming engineers
and working on Shuttle?
The good old boy network from the early aerospace aircraft days transitioned
into Apollo. They were the right people for the job, they knew how
to do things. Most of them didn’t have degrees either. They
were what we call bootstrappers, bootstrap engineers. They were still
very staid in their attitudes and their culture. Women were still
perceived as the encoders, the secretaries, administrative assistants,
the “go fer” type personnel.
As we got through Apollo and we started getting into the orbiter program,
I think that younger leadership coming in didn’t necessarily
share that belief that the place for a woman was in the kitchen or
home. Speaking for myself, it was a case of we had a job to do—I
needed an engineer. That engineer does not really have a sex, a color,
a creed or anything. They’re an engineer, they have certain
skills and things that they bring to the table. So when I would do
my job interviews it was always based on that. When I’d do the
paper screening, I seldom looked at the name. I would read what do
you have. Later, when we got into the orbiter program, there were
more women that were showing up in the interview process and the paper
screening process. I was seeing more of that, there was an interest
on the part of women.
From resident staff I had two middle-aged women on my staff. They
were computer encoders. One in particular, she was a wonderful person.
She was still part of that group of women that were intimidated by
the system. When we’d do the performance interviews it was,
“What do you want to do? Are you doing what you want to do,
do you want to do something else?” Well, it so happened that
one of her skills that she did on her own was art. She was a wonderful
artist so I said, “You really like doing the art. Have you thought
about technical illustration?”
She said, “Oh, I don’t know if I could do that.”
I said, “Well let’s try it.” So I put her in charge
of all our technical illustrations in our specs. She just blossomed,
it was great. That laid the background for her to move on.
From an engineering standpoint, I hired a young woman as a mechanical
engineer from Michigan State [University, East Lansing]. I needed
a field rep for a couple of companies back east that were doing actuators
for the orbiter. I had a guy that had been handling it, and this was
going to be a challenge because this was out of Albany, New York.
She was going to have to interface with a very serious good old boy
network and handle the job. Just a brilliant young woman in terms
of the technology.
I escorted her on the first trip. When we were there these guys would
sit across the table and talk to me about the reviews. Finally I said,
“Don’t talk to me, she’s the one that’s going
to sign your paperwork. If you don’t convince her it ain’t
going to get signed.” When we were out to dinner that evening
this one guy came over to me and he says, “You’re not
seriously going to put her in charge of this project, are you?”
I said, “Why?”
He says, “Oh, you know why.”
I said, “No, I have no idea what you’re talking about,
but you better get real smart real fast, because if she doesn’t
sign that paperwork you’re not shipping any hardware.”
Next day he changed his temperament a little bit, but this was the
Quite honestly, as late as—2004 when I was back after Columbia,
consulting, I ran into a couple of folks and the glass ceiling is
still there, it hasn’t gone away. It’s changed. The good
news is that there are more women that are comfortable in the role
of working on teams with men. They’re more confident I think
in terms of stepping up.
The significance, in my opinion, is women do not need to compete with
men in the technical world. If they go into it as a competition, that’s
where the problem is going to be because it serves the purpose of
the good old boy network. Women have to come at it as who they are.
Women are different, they have very unique skill sets. They have a
different attitude and perspective of communication. That needs to
be honored on both sides of the table.
Where I still see the problem is still—I hate to say it—in
the elementary schools. Girls are still girls and they’re channeled
into activities and places. “We need an artist, get one of the
girls to do that.” Why? What do we need? We need somebody with
talent, with a skill that can do this job and wants to tackle it.
There needs to be more effort down I think in the early grades. We’re
trying to do it with STEM [Science, Technology, Engineering and Mathematics]
education, getting them to recognize that science is not a man’s
world. I’d like to think it’s changing. I think it’s
still a long road to go, but it is changing.
By the way, the young woman that I hired that I sent to Albany—about
ten years ago I was over at corporate offices at Boeing. I ran into
her coming out of the corporate office and I said, “Are you
still working for the company?” No, she was working for a sales
company. She’d taken to the sales all right, but she hadn’t
got across that gap of personal identity. She was still trying to
compete. That was one of the reasons I think she was successful while
she was there. Anyway, that’s my philosophy on women in engineering.
I really wish that there were more of them, maybe there will be.
What do you think was your biggest challenge while working on the
The biggest challenge was the everyday surprises. Mike at NASA had
been in for a trip. We had a component that had some corrosion on
it, and we were working the problem. I said, “You know, Mike,
I spent a lot of time in school studying the engineering technologies
and so forth, and corrosion was one of the things we studied. Since
I’ve been working on the Apollo and the Shuttle program, I have
yet to see a single corrosion result that looks like anything in the
textbooks. It’s just never there.” Every problem was so
unique and so different. It’s getting people to understand that
your observation skills are very critical in terms of what you’re
doing on a day-to-day basis, don’t take anything for granted.
There’s a story I’ll share with that. We had a thrust
structure element from the aft fuselage. Titanium forging, critical
piece of hardware, expensive piece of hardware. Two-year lead time,
it’s a massive drop forging. It’s delivered into Downey
and it’s on the shop floor. I’m in product support lab
and I get a phone call, “Come on down to the floor. One of your
engineers just scrapped this thrust structure.” Three million
dollar thrust structure, he scrapped it. I get down to the floor and
say show me the paperwork. I call up the young engineer. I say, “This
is your disposition on this.”
He says, “Yes, that’s it.”
I said, “What’s the problem with it?”
He says, “It’s intergranular stress corrosion in the fillet.”
I said, “Where? Show me.” So he goes over and he pulls
the plastic back of the webbed section in there. There’s this
dotted line. He says, “See that, that’s stress corrosion.”
I say, “How do you know it’s stress corrosion?”
He says, “I saw it in the book once, that’s what it looks
I said, “Hand me your pencil.” I take his pencil away
from him, erase the stress corrosion. “Where’s the stress
corrosion now? If you take a look on the opposite side over here,
what do you see?” There was a little lead wedge. It’s
a marking from an X-ray radiography and it’s pointing to where
they mark pencil marks for some indications that they weren’t
sure what it is. Not stress corrosion, and not a scrap. Just a young
kid, needed the mentoring.
What is our problem today? Our problem today is Joe here’s got
years of experience, he’s been in the program forever. One day
Joe walks into the office and says, “I’m retiring.”
Normally what you should do is pick Joe’s brain, get him a mentee
and work that process, the longer the better. But what happens is,
“Hey, a month is up already?” Yes, Joe is gone. “Get
me some resumes.” You hire a new kid right out of the starting
blocks, no experience. The knowledge capture, the mentoring is the
most significant critical problem we have today. If we do not train
these young people coming in before the fact, just throw them into
the breach, you’re going to have a problem.
I had this experience. One of my senior engineers—we had contamination
in one of the fluid systems. He’s a senior engineer, and he
knew what to go do. He had to go to the engineering department where
the drawings for that system were kept. They track the entire buildup
of that system and that history. He comes back a couple minutes later
and he says the guy that had worked there had retired, and he was
gone. They hired a brand-new engineer.
This brand-new engineer came in and was told this was their workstation,
and proceeded to empty all the file cabinets of all the paper that
belonged to the other engineer. Threw them all away, because this
was now their workstation. So we have no records of the original drawings
and the markups and the buildup of the system. Just bad, bad communication.
Fortunately for him this guy was brilliant. He recreated it in his
Did you want to review your notes and see if there’s anything
we haven’t touched on? I think that we’ve pretty much
covered all the questions.
We’ve touched upon everything. I think that the questions like
the biggest challenges and the most significant contributions, those
are really important questions. The lessons learned I’d love
to spend a lot more time on, because lessons learned are what we’re
trying to capture now. Every one of these documents back here is a
history and a lesson learned to somebody. It’s a lot of paper
to other people, but when you consider one of those reports probably
cost NASA $200,000 or $300,000 or more, and now it’s relegated
to a stack of papers that probably nobody’s going to look at—there
needs to be this capture and this retrieval process. We can isolate
the stuff, but the next question is how do the young engineers that
are working the problems today know that this is here and get access
When I went back over to Boeing, one afternoon a guy called me into
the office. He had an old report. The report was a waiver condition
for material usage, signed by me. He says, “We just came across
this, and this is being used as justification to buy some thousands
of dollars’ worth of hardware. Why did you do this?”
So we talked a little bit, I start expounding on this document. I
turn around, and in the hallway there’s about three or four
guys, and a couple more leaning over the partition. They’re
all just eavesdropping on the conversation. When I’m done, they
started asking questions about this, that and the other thing. When
I finished I go over to the manager for the group I was working for.
I said, “You need to think about ways of getting more of us
old-timers into dialogue opportunities with your staff, because that’s
going to have some significant payback to you in the long run.”
As a matter of fact, we are talking about doing some of that. Just
last summer we did a panel of retirees up at the Griffith Observatory
[Los Angeles, California] on Apollo. A spin-off from that was this
past summer for the Apollo 13. One of the local universities asked
us if we could send a couple of guys out. Stan [M. Barauskas] went
out and participated with the young engineers in the engineering department.
They were just enamored of the opportunity to talk to a real live
engineer from the Shuttle and Apollo Program.
Stan and I are working right now to put together more of these panel
opportunities and create with our retiree list a “shopping list”
that we can pass around. These oral histories will help do that, as
we learn more who knows what about what. One of the things I’m
hoping to do besides the timeline is create an orbiter matrix that
says here’s the orbiter, here’s the wing, here’s
this system, and here’s the name of five people that you can
call that were intimately involved with that hardware. Hopefully we
have about ten years before that list disappears. That’s the
other threat that we’re facing. That’s all, this was fun.
Well, thank you.