NASA STS Recordation Oral History Project
Edited Oral History Transcript

Gerald A. Blackburn
Interviewed by Rebecca Wright
Downey, California – 24 August 2010

Wright: 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 Shuttle Program.

Blackburn: 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 archives.

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.

Wright: How much did that document change before it became solidified?

Blackburn: 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 astronauts.

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 testing.

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.

Wright: Can you show me the date on that document?

Blackburn: 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.

Wright: You were talking about dealing with different materials. You were part of establishing the product support laboratory here?

Blackburn: 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 redundancy.

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 evaluation.

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 support effort.

Wright: Who decided what came into your lab to be tested?

Blackburn: 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 process.

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.

Wright: About how many were there?

Blackburn: 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.

Wright: That’s the good news.

Blackburn: 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 as well.

Wright: Speaking of the tiles, there was a thermal protection system analysis system that you developed for the orbiter.

Blackburn: 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 this?

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.

Wright: After the Columbia returned, what was your conclusion on the work that you had done?

Blackburn: 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.

Wright: Must have been a very satisfying but exhausting time.

Blackburn: 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.

Wright: 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.

Blackburn: 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 under control.

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 they’re gone.

Wright: 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.

Blackburn: 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 of delivery.

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 utilized.

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.

Wright: 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?

Blackburn: 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 beasts.

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 way.

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.

Wright: 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?

Blackburn: 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 projects.

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.

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 office.

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 it.”

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.

Wright: When Columbia came back to Palmdale and started getting its modifications in the early ’80s were you involved with those issues as well?

Blackburn: 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 it go.”

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 went away.

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.

Wright: What type of impacts did the Challenger accident [STS 51-L, January 28, 1986] have on your area for materials and processing?

Blackburn: 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 was right.

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 different.

Wright: Before we close out today, I wanted to check with Jennifer and see what questions she had for you.

Ross-Nazzal: 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 between them?

Blackburn: 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 got better.

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 actual building.

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.

Ross-Nazzal: 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?

Blackburn: 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 at.

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 things.

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.

Ross-Nazzal: What do you think was your most significant accomplishment while working on the orbiter program?

Blackburn: 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.

Ross-Nazzal: 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?

Blackburn: 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 problem.

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.

Ross-Nazzal: What do you think was your biggest challenge while working on the orbiter program?

Blackburn: 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 like.”

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 memory.

Ross-Nazzal: 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.

Blackburn: 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 to it.

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.

Wright: Well, thank you.

[End of interview]