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

Michael D. Leinbach
Interviewed by Rebecca Wright
Kennedy Space Center, Florida – 10 June 2008

Wright: Today is June 10, 2008. We’re at the Kennedy Space Center [KSC] in Florida to talk with Michael D. Leinbach, Shuttle Launch Director, as part of the JSC Tacit Knowledge Capture Project for the Space Shuttle Program. Interviewer is Rebecca Wright assisted by Jennifer Ross-Nazzal. Thanks again for letting us come in your office and visit with you this morning.

Leinbach: Glad to do it.

Wright: I’d like to start by you giving us a brief background on how you came to be a part of the Space Shuttle Program.

Leinbach: I’ve always been interested in space and space travel, since I was just a kid. I remember Alan [B.] Shepard’s [Jr.] first flight. So after my master’s degree in Virginia [University of Virginia, Charlottesville] I was working with Babcock & Wilcox [Company] nuclear power plant design office. I was doing well, I was moving up and enjoying that, but I always wanted to work for NASA. So I sent in an application—this was back in spring of ’84. I went to different Centers, I got some calls from Glenn [Research Center, Cleveland, Ohio, formerly Lewis Research Center] and Langley [Langley Research Center, Hampton, Virginia] and here at KSC, and ended up coming down here in the fall of ’84 as the Launch Pad Structural Engineer for NASA Design Engineering. Of course, back then Pad B was not even online yet, we just had one launch pad for the Shuttle Program. But that’s how I got to KSC and how I got into the Shuttle Program.

Had several assignments out on the launch pads that got me introduced to the NASA Test Directors. I was the Lead Designer for the slide-wire system upgrade after the Challenger [STS-51L] accident. So I met the NASA Test Directors through that project, and that’s how I got out here into the operations world. That’s how I went from NASA Design Engineering to operations. That was in early ’88, and did various assignments in the NASA Test Directors Office, and I started launching the Shuttle as a Shuttle Test Director in the summer of ’89—so pretty quick. I was assigned to all the Department of Defense missions. After the Challenger accident, we still had quite a few DoD missions on the books to fly. There were two of us launching the Shuttle from the Test Directors’ position, and the other guy, Al [Albert D.] Sofge—he got the NASA missions, the non-classified missions. So I started launching them from that perspective, and I moved up through the ranks, and I became the chief of that office. That was from ’88 to ’98.

From ’98 to the year 2000, I was the Deputy Director of the Space Station Program here at KSC, and we did testing on the components here on the ground. It was called the Multi-Element Integration Test, where we tested the components on the ground before we flew them to shake out problems on the ground, and that was actually a very successful test. We found some significant problems that would have really impacted the [International Space] Station on orbit. So that was two years as a Deputy Director there in the Space Station Hardware Integration Office, and then I came back to the Shuttle Program in May of 2000 as the Assistant Launch Director, and then in the summer of 2000 I became the Shuttle Launch Director, and I’ve been the Launch Director for eight years now.

Wright: Through these phases of your career with NASA, you certainly have worked in a number of different areas, between the design and the testing and the launch and the ISS [International Space Station]. Let’s go back through some of those and talk about some of the challenges that you encountered. Even just the challenge of walking into the NASA culture compared to being in the nuclear program. And maybe as you go through, tell us about the challenges that you encountered from the different areas that you worked through. And some of those lessons learned, could be the lessons that you learned of moving through the testing area. The years that you were Test Director, some of the lessons that you learned possibly in planning, some of the major ones that even that you use now, that you carried through.

Leinbach: The biggest one through my whole career has been communications. And you find when we pick up problems or we have an incident or an accident—not necessarily a catastrophic accident, but just an incident here at KSC—you find that probably 80 to 90 percent of it was based on poor communication. It could be oral communication, it could be written communication. Lots of times, it’s a communications issue rather than a hardware failure. Sometimes it’s a true hardware failure, and that’s the way it is, but a lot of times it’s communications. It doesn’t have to be an accident—it could just be a loss of a shift in work and delayed some other test based on poor communication.

That’s the one thing that we as managers need to make sure we do is communicate our goals and expectations and get that communicated through the entire workforce, and if there are any questions, answer their questions. Open up. Be communicative, big time, with the workforce. That’s down to the workforce and that’s up to our managers, up to my bosses. Communications is key to a successful program.

I saw it when I was a Design Engineer. I was working on the slide-wire system, and I didn’t invite all the stakeholders to the design reviews. And therefore, we came out with a design that was perfectly satisfactory, but it was not optimal because we didn’t have all the stakeholders in the meetings. I was taking a lead—and this is not an excuse, this is just the way it was—I was taking a lead from the more senior guys in Design Engineering about who to invite, but it was not the total list, and we would have had a better design had we had full participation in those meetings. That happens in Shuttle Program, it happens in every program, I’m sure. Communications is key.

Wright: Are there any suggestions on how best, for instance in the planning phase, to identify and to know who all needs to be involved in those types of decisions?

Leinbach: It’s tough if you’re new to a program. You really have to rely on people who have been around a while. I know a lot of people through my 24 years, of course. So now, I have an idea of who to invite and who to communicate with, on any issue. But when you’re new to a program, you can’t know that. You don’t know it yet. You have to rely on your managers to tell you who to communicate with. If your managers don’t tell you right, you’re going to go down the same road I went down with the slide-wire system. You’re going to not fully communicate. There’s no recipe for it, there’s no equation to know who to communicate with.

Wright: Are there elements of teamwork that, as you build your team, you like to instill in your employees that help nurture and foster communication?

Leinbach: Probably the biggest thing I use is what I call “the people’s Launch Director.” There have been Launch Directors in the past that have been not unapproachable, but less approachable than me. I get out, walk around, talk to people. I try to make it an easy thing to communicate with me, and for me to communicate with them, by breaking down what used to be a barrier. It used to be this, “Oh, you’re the Launch Director? Oh my God.” But that’s not me. I’m Mike. When I go out and talk to folks, it’s, “Hey, Mike, what’s going on?” It’s not anything else.

So breaking down any kind of professional barriers that may exist because of a position someone has is very important to me. I’ve tried to do that. That’s the one thing I’ve tried to bring to this job since I’ve had it, is to, as I say, be the people’s Launch Director. We can debate whether I’ve been successful or not, but that’s what I’ve tried to do. The guy that was in [my office] prior to you, I didn’t know he was coming up. He came in about ten minutes before our interview started, and he had some things he wanted to talk about, about his career. He came in, shut the door and said, “Mike, you got ten minutes?” “Sure, come on in.” That’s a great example, it just happened. It was a great example of people that are comfortable coming in and talking to me. That’s what I’ve tried to do, open up some.

Wright: How do you mentor these folks that you are responsible for overall as their supervisor? How do you help build the current folks that are in place to become productive and efficient managers that are going to work well in the program?

Leinbach: True delegation is extremely important. Not paper delegation. You have to give people work to do. And what I like to do is give people assignments, let them go off and make a few mistakes along the way, and learn from their mistakes, which is very, very important. I’ve seen all too often in my career where you’ll get a manger who says, “Oh, I’m a good delegator.” But then they just ride herd over the people and correct them at every step along through the process, whatever the project is, they correct them every time. Well that’s not mentoring, that’s not delegation. That’s a Big Brother, it’s the hammer on the people. I would much rather see somebody make a mistake and correct that mistake and learn from it than me step in before the mistake is made. Now, of course, if they’re about to make a critical mistake, that’s entirely different. But if they’re about to make a “boo-boo” as opposed to a mistake, let them go. They’re going to learn a hell of a lot more from that than me stepping in before they make that mistake and correcting them.

Then with that is, “Hey, if you ever want to come in and talk about it, come on. Door’s always open.” I’ll check in with everyone every now and then. I’ll walk around and just see how they’re doing, if they have any questions. Just kind of walk around with a cup of coffee, shoot the breeze a little bit. Maybe at first, if it’s a new person, they’ll not open up with me. But if I go by a couple, three times with a cup of coffee, then they’ll say, “Hey, yeah, Mike, I have been meaning to talk to you about this.” So it’s an openness. True delegation. It’s care and concern for the people. Wanting them to succeed and advance in their careers.

Wright: Do you feel like this helps build an element of trust between management and employees?

Leinbach: Oh, absolutely. Absolutely. One of the things I try to do as a NASA guy is get out and talk to the contractors about where I think things are heading. We’re about to go into a major transition and turmoil. I’ve been going around, talking to the workforce about the way I see it going. That’s not to say that’s the way it’s going to be, but I’d much rather go out and talk to the workforce and give them what’s perceived as bad news than have them receive no news at all. It’s coming from a NASA guy, talking to the contractors. That can rub a few managers on the contractor side a little raw, and it has. But what it also did—it got them to go out and talk to their own people. They didn’t need the NASA Launch Director to go talk to their folks.

But that opens up people, and the trust that it instills from that, ensues from that. Again, that’s getting out and talking and communicating, and I get straight questions in those sessions that they may or may not ask their boss, but they ask the NASA guy because I have no direct supervisor responsibility or anything like that. So I get some pretty neat questions that way. Again, it’s all about opening up and talking to folks.

Wright: Doing that takes time, and your job does have a number of responsibilities and duties, and underlying everything you do has that element of risk. Tell us how you manage to get everything done and also know that the issues of risk are being taken care of. Maybe if you could give us some examples of types of processes or meetings that you put in place to make sure that those levels of the risk mitigation are there.

Leinbach: In risk mitigation, you’re talking technical risk mitigation?

Wright: It can be anything. I know risk covers a whole blanket of issues.

Leinbach: Yes, it does. Well, I schedule these meetings. I was just talking about it with the workforce. Those are scheduled meetings where I’ll go their site and get 50, 75, 100 people in a room, or maybe 20, whatever it turned out to be. So those types of meetings are scheduled. But you’d be surprised. It doesn’t take long to pick up a cup of coffee and walk down the hall and talk to an Orbiter Test Conductor or a NASA Test Director. Five, ten minutes, and that can mean a lot.

Risk mitigation—that just covers so much. We do a lot of status meetings, but that’s not risk mitigation. Provide an example of a successful risk mitigation activity that impacted the Shuttle Program—well, there are lots of them. Lots of technical ones. Tons. Hundreds. Thousands of technical ones where we’ve reduced risk. In my 24 years, most of which—well, it’s all essentially been in the Shuttle Program, the biggest one I see is the creation of the Mission Management Team after the Challenger accident. Before the Challenger accident, the MMT did not formally exist. It existed in part, and we had some senior managers here on launch day. But as a result of the Challenger accident, the Mission Management Team was created and formalized. The Launch Director back then, Gene [James A.] Thomas—a good friend of mine—writes about it in his book, and he talked to me about it. He did not know, the Launch Director did not know about the O-ring problem the night before launch. Think of that. Didn’t know. There were managers talking about it in some room somewhere, but Gene did not know. So here comes launch day, and the rest is history.

The good thing that came out of that, if there could be any good—one of the things is the creation of the Mission Management Team, where we get everybody together and we talk about any issue that may be in any part of the Program. “Is it an O-ring issue, is it a diode issue, is it a ground support issue?” Typically what we end up talking about are things that are outside documented requirements. We have these things called Launch Commit Criteria. We have OMRS, those are the Operations and Maintenance Requirement Specifications. And those are documented, formal requirements that we have to meet in order to launch the Shuttle. Well, as you can imagine, there’s a ton of other stuff that can’t get documented, doesn’t get documented, never seen before.

Those are the types of things that we talk about on the Mission Management Team, along with the documented requirements. If we start to violate a documented requirement, then the Mission Management Team kicks in. But their biggest responsibility is to bring out in the open, to all elements of the Program, other stuff that we ought to be talking about. Because if you talk about the documented stuff and you talk about the undocumented stuff, theoretically you’ve covered it all and you should be good to go. They can be a thorn in my side, frankly. As the Launch Director, I’m responsible for the Launch Team getting to T-0. The Mission Management Team is a Program function making sure we’ve met requirements and these other undocumented requirements. Every now and then, they can start getting into my business, and so they can be at thorn in my side. But that’s, in my mind, the best thing that’s happened to the Program that I’ve seen.

Wright: That’s good because that’s a really good example for that. I’m going to talk to you for a second about the time that you spent working being responsible for the ISS Component Processing, because you had multi-customers—contractors, international partners. Could you share with us some of the ways that you did business with all these different types of customers that you had to pull together to get these components tested and ready to go?

Leinbach: When I went over to be the Deputy Director, in spring of ’88, this Multi-Element Integration Test [MEIT] was in its infancy. It was in its creation. I got over there, and I had a whole lot of responsibilities, and to understand what MEIT was all about was part of it. So we went through the first round of MEIT, and again, the purpose was to test the components on the ground before we flew them to shake out any problems that you’re obviously going to find before you fly.

So we were testing the interface between the U.S. Lab [Destiny], and a computer that emulated the Russian piece, and Node 1. So we had the Lab physically on the ground here, Node 1 was on orbit, and the Russian piece was on orbit already. But we had computers to simulate all that. We found some problems that we needed to fix on the Lab before we flew the Lab, so it was very, very successful. But that first round of MEIT, MEIT-I, was a disaster because everybody involved came in and they all wanted to be in charge. They all wanted to be on the test team. I spent many a third shift just watching because I wanted to really see what happened. I’d go over on first shift and second shift, but I also came out on third shift just to watch. I wasn’t in charge of MEIT yet, but I wanted to see what was going on.

The test team that they had set up for MEIT-I was a disaster. It was huge and cumbersome and people would vote about whether we should pick up this thing called an IPR, an Interim Problem Report. That’s not the way you do business. If you have a problem, you pick up an IPR, and you go resolve that problem. You don’t vote. “No, I think it is.” “I think it’s not.” We had the international reps there. Canada [Canadian Space Agency] was coming online soon with the first robotic arm. They had hardware already here at the Kennedy Space Center. We were about to test MEIT Phase II.

Phase I was a disaster, and so my boss, Tip [John J.] Talone [Jr.], said, “Leinbach, go make MEIT-II work.” There was a team of three of us that really led MEIT-II, and it was John Strait [phonetic] and Scott Chandler and myself. We put together a test team very similar to the Shuttle Test Team because that was what I was familiar with and I knew worked, and I knew that the test team they had for MEIT-I was not working well. It wasn’t unsafe the way they were doing it; it was just very, very cumbersome and expensive.

So we pulled together a test team on Phase II, and one of the biggest things we did—aside from just structuring it after the Shuttle Launch Team—was to insist that the engineers at Johnson, Kennedy, Marshall [Marshall Space Flight Center, Huntsville, Alabama], and Canada all got together face to face and talked about how we were going to run this test. “What are the requirements for testing the arm?” Back then e-mail was not what it is today, and we did a lot of telecons. I watched that, and people were confused, and they just weren’t communicating accurately. You say one thing, I interpret it differently.

There’s no better communication than face-to-face. So I carved out part of the budget for travel, and it turned out to be a significant part because we were bringing in people from three Centers and from the West Coast and Canada. At first, I said, “Well, let’s bring everybody here and talk about it.” Then I said, “No, you know what would be better? Why don’t we go to their site?” So we took teams of people to Houston to talk to Houston engineers. We took a team up to Canada to talk to those engineers up there. Just that fact of us coming to them I think helped. As opposed to saying, “You come down and talk to us.” We’ll come up there. We’ll talk to you. The response was just outstanding.

And the result was we had very, very clear requirements. We had a lean test team. We tested those components, found some significant problems, and MEIT-II was a huge success to the extent that one of the components—if we had flown it, we would have had to bring it back down to fix. Think of that, what that would have cost, as opposed to my little old travel budget to make sure people were talking.

There it is again. Communication. Face to face communication is key. So that’s how we pulled off MEIT-II, and then that turned into III and IV and V, and we’ve essentially, since those days, tested all components on the ground before we fly them. Early on in the Station Program, all the components were going to be “ship and shoot,” where they were going to build the Canada arm for instance. Build it, test it up in Canada, ship it down to the Kennedy Space Center, load it in the Orbiter, and fly it, with no test on the ground at all. Because it theoretically saved money. Well, we knew that was not the right way to go. So that’s Multi-Element Integration Test in a nutshell.

Wright: As it continued, were there a lot of changes in the planning aspect, or did some of the initial areas that you set in place to build this process remain?

Leinbach: Yes, they remained because the success of II versus I was just night and day. It wasn’t just me. It was John Strait and Scott Chandler and everybody that supported the whole test. I mean, there were dozens and dozens of people that contributed to the test, we were just the point people. But those processes we put in place, the teams still travel to the remote site to get requirements, the test team is still structured the same way. Once we got the course correction done, it stayed in place.

Wright: Do you have to change any of your basic communication philosophies dealing with international partners, since they have different types of communication efforts?

Leinbach: You just have to be sensitive to idiosyncrasies that we have. You just have to be very, very sensitive to ours, and to be sensitive to what theirs are, because some questions can come across as arrogant to us that for them are typically natural questions. So pre-briefing the folks on what to expect from an international partner. I took a team down to French Guiana to talk to Arianespace [European Space Agency’s launch site in Kourou] on how they launch rockets down there. Not as part of MEIT, but here lately. We got together before the trip and said, “Okay, and this is how the French communicate, and we can expect them to communicate this way.” So when I did, and on the surface you could say, “Boy, that was kind of a rough question or a curt answer.” Well, to us, yes, but to them, no. It’s the way they work. Knowing idiosyncrasies beforehand obviously is key, and we did that. You’re always surprised. But as long as you know going in what you can expect, I think you’re better off.

Wright: In a different phase of your life with the Shuttle Program, you were tasked to lead the initial debris recovery effort after Columbia [STS-107 accident], in Texas/Louisiana. And I know talking with you on that project, a very rough assignment, and a totally different one from preparing a Shuttle for launch. Now you were bringing it home. Share with us about those aspects and how you put some of the lessons that you’ve learned through your previous years, and how you were able to move that effort from picking up the pieces to the reconstruction effort here where you can move it on even into a legacy, where you wanted to send it to the academia world to have it studied.

Leinbach: That was just a tough time for NASA and the country. The way I got involved in the initial debris recovery—one of my assignments as the Launch Director is to be the Chairman of the Rapid Response Team, and that’s a team that deploys here from KSC to wherever we need to go. This time, of course, it was Texas. So I was the Chairman of the Rapid Response Team, and therefore it was my responsibility to get the first team from Kennedy together, a multi-disciplined team from Kennedy in logistics and engineering and safety—you name it. And we had a few reps from each organization get on that first plane to go out to Texas—out to Shreveport [Barksdale Air Force Base, Louisiana], as a matter of fact. So that’s how I got there.

Once we were there, we had to start setting up something brand new. We had no idea what happened, where the pieces were. We knew the astronauts were gone. We didn’t know where they were physically, but we knew they were gone. So when we first got out there, I met with the Base Commander, and he was very courteous to us and gave us a whole building to go work in. The second group of people I met out there was the NTSB, the National Transportation Safety Board, and of course they do this for a living, aircraft accidents and other accident investigations. They were very helpful. Very, very glad to have them with us.

So we set up processes, and, here again, communicated with people openly and honestly about what was going on. I remember the day like it was yesterday when I had to tell the team that next morning that we found the crew the day before, the astronauts. Everybody wondered, “Where are they? When are we going to get them?” Well, it was very early on. It was a very difficult thing to do to say we found them. But the team needed to know that. So I got everybody together and just said, “Okay folks, this is the way it is.” I wasn’t this matter-of-fact about it—it was a very, very emotional thing.

We built those processes and the recovery of the pieces and then the shipment back here to Kennedy. I was only out there 12 days. There were a lot of people that were deployed for months. The last bit of debris was shipped back on May the ninth, and the accident happened on February the first. So for many months there were people out there. I was only out there 12 days, and I was asked to come back and do the reconstruction in the hangar. Another new set of processes had to be developed. Team meetings every morning talking about where we should go, and I had the NTSB here, too. They were extremely helpful here.

One thing I remember is as the debris was coming back from Texas, every day when there was a shipment coming back, we took a break. Everyone in the hangar was invited to take a break and go greet the truck. Not everybody did. But it was this type of thing where, “Here comes more. Let’s go out and welcome this piece of Columbia home.” So everybody was invited. Some people did it, some people didn’t, for their own reasons. I always did. The ones that didn’t, I suspect they stayed in the hangar and just reflected for a moment. So we’d get everybody together and see the trucks roll in. I had different presentations to the team from Public Affairs. I remember one morning, I went out in the hangar and called a timeout for about an hour and showed a video of the crew, and better days. Everybody was crying. But again, just working with the people. Very, very important. Some of the best friends I have now are from that time.

Wright: I think it reflects and reaffirms your opening statement, which was communication is such a vital ingredient to a successful program. No matter what, if it’s something that’s moving forward, like your international partners working on how to get all those components tested, or if it’s keeping your team together through a time that’s not easy.

Leinbach: I think I told you this before. The whole mood of the Agency was different in the Columbia accident recovery and the Challenger accident recovery. I was a youngster back in the post-Challenger days, but I remember seeing Challenger launch and blow up. But the Agency’s mood after Challenger was, “Let’s put that behind us. Let’s just forget that happened. Let’s go bury the debris.” Literally. It’s in a silo over here on the Air Force side. The mood of the Agency with Columbia was entirely different. It’s, “Let’s talk to people about what happened.” Ron [Ronald D.] Dittemore, Program Manager, in the first few days after Columbia you saw him on TV. He was just outstanding in his communication. We didn’t know what happened, but he was up there talking about as best we knew, what was going on, what happened.

The whole mood of the Agency was different. That in part led to the program of lending debris out to universities and institutions to study what happens during hypersonic reentry. That program’s been, I would say, mildly to moderately successful. I had hoped for more. I had hoped to lend out a lot of debris to a lot of universities and get a lot of good studies done. Well, we lent some to some and got some. So it’s partly successful. The offer’s still there. We still get a request every now and then. But that didn’t and would not have happened after Challenger. It was the mood. I was in the right place at the right time, as far as that aspect goes, because I had that desire to learn from this accident—me personally, and the Agency did as well. So we were just teamed at the right time together, the Agency and me. When I say “me,” it was a lot of people that wanted to pull this program together, lending the debris out.

Wright: But you were in the position to keep it moving.

Leinbach: Yes. I did the presentations to the guys in D.C. about the value in this, and once they approved it, then we were off and running.

Wright: Afterwards, and keeping your team together and moving back into launch days after Columbia—tell us about that, and again, the communication efforts or maybe anything different that you did to keep people in focus and looking toward the future.

Leinbach: We do a lot of training on the Launch Team. For the first year or so after the accident, we didn’t train at all. Everybody was busy doing the recovery or the reconstruction or the paper trails, et cetera. About a year or so after the accident— we were a year and a half away from Discovery launching after Columbia—I started doing the Launch Team training again. We needed to do it. We needed to get our skills back, our sharpness back. So we trained a lot. We trained a lot in the control rooms and individually out at the work sites. We got everybody trained back up and felt really good about Return to Flight. As a Launch Team, we didn’t do anything special for the Return to Flight launch other than individually reflect on it, but there were no Launch Team celebrations or anything. There were a lot of celebrations with Return to Flight. But as far as the Launch Team goes, no. We were doing our business.

Wright: Back to business?

Leinbach: Back to business, yes.

Wright: I’m sure that felt good, just being able to say that.

Leinbach: It felt real good.

Wright: Well, talking about training, and looking back on your 24 years for a moment, to look forward to the next years, what would you suggest on how best to train and equip the next group of Agency leaders? What are they going to need to know?

Leinbach: There’s some technical aspects we need to do better. We need to get away from paper processing and paper test procedures, and we need to go electronic. That’s going to happen in the next program. The Shuttle Program being as old as it is, there have been a lot of processes that have developed over the years that have made their way into the Program that have never gone away. It’s a very large program, we have a lot of requirements that have become requirements over the years that I still question whether we need to do them or not. I would tell the Program Managers of the future—you start very lean. You start with the requirements to launch that rocket, and be very careful about taking on added requirements.

One of the examples I always use is we had a problem with the flex hoses in the aft of fthe Orbiter, and one of the theories was that it was a fatigue problem. Slight bending over many, many cycles or years could cause these problems. One of the theories was the rollout of the Shuttle from the VAB [Vehicle Assembly Building] out to Launch Pad could in part be contributing to that problem. So we instrumented the Orbiter and the mobile launcher and the crawler-transporter for a rollout, and it was going to be a one-time thing. We did that once, and then the second rollout, said, “We’ve got some good data, let’s do it again.” “Okay, we’ll do it again, but this is it, right?” “Yup, two times is all we need.”

You know the end of the story, I don’t even have to say it. We instrument the rollout every time. We’ve gotten the data. We don’t need any more data. We’re not getting any new data. But we continue to collect the data. It’s a small thing, but it takes technicians time to hook it up, it takes analysts time to decipher the data. But we’re not getting any new data, we’re just getting more data. That’s a little example of a requirement creep that has gotten into the Shuttle Program that we need to do away with and not allow in the next program. We won’t be able to afford it.

Another major one is the Launch Team itself. We have what I refer to as parallel Launch Teams in our prime control room, which is right down there, and then our backup control room. On launch day, my team in the prime room are charged with dispositioning problems and making sure we’ve met all of our Launch Commit Criteria and then give a go for launch. After Challenger, the Launch Director back then and the Chief Engineer decided to poll Fire Room Two, the support room, giving a go for launch. That has remained today. I ask Charlie [Charles A.] Abner, Chief Engineer, if he’s go for launch. The only way he can answer that question is to be involved in all problems just as much as we are here Fire Room Four.

So we pick up a problem, the prime team works it, and the backup team works it. As opposed to the prime team working it and asking for support. That’s a parallel Launch Team; it duplicates the Launch Team. It’s cumbersome, it’s unnecessary. It’s not unsafe, it’s just cumbersome, and it could cost us a launch attempt because if they’re working the same problem we’re working, there are shared resources and there’s time constraints, and we could miss a launch window because they haven’t dispositioned the same problem we just did. So for the next program, the next Launch Team is designed the way it should be. That was the assignment I had last year or so. It’s back to basics. The support room is the support room, and the prime team will ask them for technical support if they so choose. That was a huge addition to the Shuttle Program that has remained to today.

So I would tell the managers again of the next program, just be careful. Careful. You design the system and you test it based on the design, and don’t let extraneous or unnecessary tests creep in. Processes are going to tend to creep in. We just have to be awfully, awfully careful not to allow it to happen. We’re all engineers. We all want data. You can never get too much data. But I would tell you all the data we have in the Shuttle Program, we don’t need it all to make a go/no-go call. It’s good to have, but we don’t need it all.

Wright: A while ago, you mentioned something about budget, carving a little piece out of your budget to be able to travel to these other Centers. Budgets always tend to be a burden, but of course it also gives you permission to do things. Do you have any suggestions for lessons shared on how best to run a very successful program but yet be able to be efficient in your program cost, especially when someone’s asking you where you can cut?

Leinbach: We have the opportunity in this next program to set it up right. Learn from the exceedences in the Shuttle Program. The little piece of it I have is starting out on the right track. Budget’s going to constrain the next program, and if the senior managers in the next program don’t lay down the law now about—only allow true requirements and true processes into the system. Once it starts expanding beyond those required to safely launch it, it’s going to turn into another Shuttle. It’s going to turn into a more expensive program to operate. We have a unique opportunity right now. Set it up right and don’t let it grow.

I’ll give you another example. The people down in French Guiana for Arianespace, they have down there in French Guiana everything they need to launch that rocket. They don’t call back to Paris for support. They’ve got it all down there. If they pick up a problem they cannot solve, they scrub, and then they might ask people back in Paris for help. They have everything they need down there. It’s really ESA’s [European Space Agency] launch site in French Guiana—the operators down there do not allow design changes to come in to the system unless it can be proven that they are true safety enhancements.

That is not the case here. We modify the Orbiter every time. Before every mission, we modify the Orbiter to some extent. Sometimes significant modifications, sometimes minor modifications. We change the Orbiter every time. ESA does not change the Ariane rocket at all unless it’s a true safety enhancement. That’s another lesson the managers of the next program have to adopt. That once we have a machine that flies and flies safely, fly it over and over and over. Don’t change it every time. We’re engineers. We love to change things. We really do. But to be a successful program and a fiscally responsible program, you don’t have to change, nor should you change just for the sake of change. Don’t change. The Russians don’t change the Proton or the Soyuz—they don’t change them unless they have to. You don’t see airplanes change after each flight. The Shuttle changes after each flight, and it’s got to stop.

Wright: You started out by talking about communication being such an essential element. Are there other thoughts of best practices or sound principles that you implement along with the communication to make sure things work as well as they can?

Leinbach: Large teams and meetings—not always the best. I’ve been in meetings where there are 50 people in the room, and maybe—pick a number, six, eight, ten, twelve contribute and make decisions. We have a lot of processes in the Shuttle Program that require, by our own doing, multiple signatures to sign off on a piece of paper that it’s good to go. Meetings are very cumbersome, they can be very large. I would tell the next Program Manager, “Keep the meetings lean, have the people there responsible and give them the authority and responsibility to make decisions, and if you see people coming to your meetings over and over that don’t contribute, then they don't need to be there.” It’s very difficult to say, “Okay, Joe, you haven’t contributed in three meetings, so don’t come back.” It’s very difficult. But that’s the kind of discipline the next program’s going to need. So larger isn’t always better.

One of the lessons we’ve learned in the Shuttle Program is to give more responsibility and authority to the technician on the floor. It’s essentially a Level One Certified Technician. And that man or woman is able to sign off on a piece of paper that he did that task, he did it well, and he’s the only one that has to sign off on it. There are a lot of tasks you can’t do that with, but there are some tasks that you don’t need a quality inspector to sign off, you don’t need an engineer to sign off, you don’t need a NASA guy to sign off. If the technician says, “I did that right,” copy, he did it right. That came into our Program I want to say about eight years or so ago. That’s been very successful. That is a good change. A change towards leanness, a change towards more efficiency. That’s been good. But there’ve been a lot of other examples where the processes have gotten large and more people involved. The Mission Management Team, after Challenger, was 14 members. And it’s up to 27 members today. Their roles and responsibilities have not changed, but they have almost double the number of people on the MMT now. Does that make it better, worse? I don’t know. It’s just a fact. It’s bigger.

Wright: Do you have any advice for anyone that wants to become a part of the Space Agency in the next years?

Leinbach: Oh man, this is a great time. It’s going to be sad to see the Shuttle end, but this is a great time. I mean, we’re setting in place now what will be America’s space transportation system for decades to come. It’s an extremely good time to come on now. And you see that, you see some hiring now. There for a while in the Shuttle Program, we were pretty stagnant, and didn’t hire kids out of college much. That’s starting to change, you’re starting to see fresh faces out there, and that’s good. You go to meetings where there’ll be a bunch of old-timers like me, but then there’ll be some newbies in the audience too, and that’s good to see. This is a great time, it is a great time to come on out here. Honestly, you’re going to be working for the next program for years and years and years to come.

Wright: Are there some other things that you’d like to offer, or some other thoughts that we haven’t gone over?

Leinbach: Yes, don’t get stuck in a rut in one organization your entire career. Getting different experiences, either around a Space Center or between Space Centers, is extremely valuable. I’ve done it only here at KSC. I’ve never been to another Center. But I was Design Engineering, then Shuttle Ops, and then Space Station, and then back to Shuttle Ops. I would not trade those two years in the Space Station Program for anything. I wish I had more diverse background. So what I would tell folks, especially the new people—go pick an area you like, go work in it for a while. Go pick an area that challenges you, you may not think you want to go work in, but go work in it. See what the budget people do for a living if you’re an engineer. If you’re a budget person, come out here and see what engineers and technicians do. Go around. Learn the different aspects of a Program. Because if you get pigeonholed, you’re going to be very, very good at what you do, but you're not going to see the big picture. To be a manager in a big program, you’ve got to see the big picture. So for career advancement and personal fulfillment, move around. But if you get the opportunity to move around, move around. You can always come back. That’s the advice I would give people.

Wright: Would that be also some advice you’d give the Agency—to open up those channels for that flexibility?

Leinbach: Yes. Yes, in fact, the [NASA] Administrator before Mr. [Michael] Griffin, Sean O’Keefe, he had that vision. He had it in spades. In fact, there was a program or a policy back then that if you wanted to rise to the Senior Executive Service within NASA, you had to go spend a year at some other Center. At some other Center, not just some other job at your home Center—you had to move. So that was forcing that onto the workforce as opposed to instilling it as a good thing to do. People saw the value, but they hated the idea—some of them, not all of them—some of them hated the idea of moving to another Center for a year. We had them here at KSC. A guy worked back here for a year. He’d go home every month for a weekend or two, five days. But that was forcing that culture onto the workforce as opposed to having them see the value in it and choosing to do it. So I would not put a policy in place to force it, but I would have people who have done it go out and talk to people about the value, the true value, of moving around some. Because it is absolutely the truth.

Wright: Is there a lesson or a piece of advice that was given to you by someone after you came here that you have found to be very valued as you’ve gone through?

Leinbach: Yes, it’s kind of a cliché, but it’s true—the people that don’t make mistakes are the people that are not doing anything. I’ve made some glorious mistakes, but I learned from every one of them. Early on I got that advice. It might not even have been here, it might have been at my previous employment. But that’s absolutely true. Don’t be afraid to go out and get something done, and if you stumble along the way, fine. Just correct. Learn from it.

Wright: Is there anything else you can think you want to add, or any other final thoughts?

Leinbach: I wrote down just three people to talk to. Bob [Robert B.] Sieck. Horace [L.] Lamberth—Horace was an outstanding engineer. He was NASA’s Chief Engineer early on, when I hired in here, and then he went over to the contractor, so he’s going to be able to talk to you from both the NASA side and the contractor side about engineering. How to lead engineering organizations. He’s retired now, but you can find him. He comes out for launch, and he’s still very active in the Program. He’d be a good guy to talk to. Then the other one, Gene [James A.] Thomas. Gene was the Launch Director for the Challenger, and was Launch Director for four or five missions before the Challenger accident. But he’d be able to talk to you about the early days of the Shuttle Program that I can’t because I wasn’t, obviously, here. Bob Sieck would also, Horace would also, and Gene would. He’d give you, from his perspective, lessons learned and processes that came into the Shuttle Program that were good and bad that I just can’t give you because I wasn’t around.

Wright: That’ll be great. Thank you.

[End of interview]