NASA Johnson Space Center
Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript
Interviewed by Rebecca Wright
Hampton, Virginia – 29 April 2008
Wright: Today is April 29, 2008. We are at Hampton, Virginia, to speak
with Ralph Roe, who is the Director of NASA's Engineering and Safety
Center located at the Langley Research Center. The interview is being
conducted for the JSC Tacit Knowledge Capture Project for the Space
Shuttle Program. Interviewer is Rebecca Wright, assisted by Sandra
Johnson. We thank you again for letting us come into your schedule.
We know how busy you are. We'd like to start today with you giving
us a brief summation of how you first started to work with the Space
Shuttle Program, and then how your duties evolved to where you are
I was hired fresh out of college with the Kennedy Space Center [Florida]
and worked as a Systems Engineer in the Shuttle Processing Directorate
at the Kennedy Space Center. Then I went up the ladder of management
in Shuttle Processing—Section Chief, Branch Chief, Division
Chief, until I got to be Engineering Director. Then I also served
as a Launch Director, and that was a span of 16 years at the Kennedy
Space Center. Then I moved to the Johnson Space Center and was Orbiter
Project Manager for four years before coming and starting the NESC
[NASA Engineering and Safety Center].
Tell us about the NESC, because from what I have read, so much of
what you're doing really ties into so much of what the project's trying
The NESC was established after the [Space Shuttle] Columbia [STS-107]
accident to provide programs like the [Space] Shuttle Program an independent
organization that could provide them a second technical perspective
on difficult issues. So we put a team together of experts from across
the [Space] Agency that can help on very difficult issues. Any program,
really, we work on any program. But we were started because of the
Shuttle accident. So we've engaged quite a bit with the Shuttle Program.
The different positions that you had as you were coming up through
the ranks of NASA were founded in the Shuttle Program. You basically
have spent your 25 years in the Shuttle Program. Each one of those
positions had a different line of responsibilities and duties. Can
you share with us the challenges that you met with each one of those,
and maybe some of the lessons that you learned from each of those?
Or some of the memorable ones that you brought up with you as you
I think the most memorable ones, obviously, were Space Shuttle Challenger
[STS 51-L accident] and Columbia. They had the most impact on me and
provided the most important lessons learned. I think both of them
had a common lesson learned in that we allowed—from my perspective,
anyhow—we allowed our success, our continued successful missions,
to keep us from clearly seeing and investigating critical problems.
The Challenger was O-ring blow-by, and in Columbia, it was debris
from the external tank. When you're in a large program like that,
and you're successful, and you're working very hard to go from mission
to mission, it was obvious in hindsight now that we failed to investigate
two critical problems that we should have. I think those, obviously,
had the most impact on me and the most memorable lessons learned.
In the future, we don't want to let our successes blind us from seeing
problems that we need to stop and investigate further.
Did you find yourself developing processes or procedures that will
help you look into those types of manners or questions as you go through?
Yes, the whole concept of the NESC, I think, is to ensure that if
a program is stuck in that mindset and isn't investigating something
critical, the NESC is there to ensure that somebody is. That's the
concept that we've really started with, so that's why I feel like
it's so important. If an engineer wants to request we come look at
something, we come look. Often, now, it's Program Managers requesting
us to come participate, which to us is a significant indication that
it’s being successful, in that Program Managers are asking us
to come look at something.
What are the criteria that you have, or standards?
Really, we're a limited resource, so we have to focus our attention
on the most critical issues from an Agency perspective. We have literally
been involved in most of the issues that the Administrator would be
concerned about, and that's kind of how we view it. If it's an issue
that the Administrator would be concerned about, then we need to be
involved and make sure that there's an independent perspective that's
I'd like to talk to you about lessons in regard to a number of areas
within management levels—especially since you mentioned you
were involved with Columbia and Challenger—the lessons that
you've learned based on risk assessment. What you're doing now is
a product of those things, but along the lines when you were coming
through, what are some of the other things that you've learned that
you would share? Before it gets to you, what are you asking people
to do to check for risk assessment or risk mitigation?
The safety philosophy that we've used in the Shuttle Program I believe
we inherited from the Apollo Program. It has three main tenets: strong
in-line checks and balances, which is the engineers checking each
other, healthy tension between our organizations, and the third tenet
is value-added independent assessment. I think it's critical to maintain
those checks and balances, that healthy tension, and to provide value-added
independent assessment. We get in trouble, I think, when one organization
doesn't fulfill its role to provide that check and balance. Or one
organization becomes too strong or another organization becomes too
I think the Program Manager can make his best or her best decisions
when the different perspectives are provided in a balanced manner
from different organizations. So maintaining those strong in-line
checks and balances, healthy tension, and value-added independent
assessment, to me is what's critical from a risk management standpoint.
If you have all of those in place and your organization is well-balanced
from that perspective, then the real risks will flow up to you, and
you'll hear all sides of that perspective.
You mentioned earlier that you have limited resources. So what are
some lessons that you have learned in regard to planning and program
I think this is very critical, also. To me, it's all about building
relationships and trust. So in a program as large as the Shuttle Program,
it's geographically diverse, it's important that the team gets together
periodically in a face-to-face environment. They get to know each
other, they get to trust each other, and they build strong relationships.
Because when the problem occurs down the road, if you haven't already
established those strong relationships and built trust with the person
you're going to have to work that problem with, you're going to have
a very difficult time. So I think it's critical, up-front, to spend
as much time as you can building the strong relationships you need
to be able to work through the difficult issues that are going to
come down the road. That, to me, is really critical. I think Tommy
[W.] Holloway and Ron [Ronald D.] Dittemore were great examples of
trying to build that team and those relationships, and I think that's
a really good best practice.
You have a unique situation on your team, because like you said, you
pulled experts from everywhere to do that. How do you pull that together
to have a good performance from this group of experts? As you mentioned,
to build that trust and those relationships, but if they're scattered
everywhere and you bring them into work, how do you get them to talk
to each other and communicate?
I really copied what Tommy and Ron had started in the Shuttle Program.
Both Tommy and Ron had a Space Shuttle Program Council, and under
Ron, we started a Chief Engineers Council. We would bring those teams
together periodically at a location, one of the centers, and discuss
issues and whatever the topics were for the day—but more importantly,
begin to create those relationships.
So I copied that same forum in the NESC, and on a quarterly basis,
since we have employees at all ten centers, we all get together at
one of the centers and discuss what we're working on, but more importantly,
build those relationships. It took much longer than I thought it would.
It was probably the better part of the first two years before we actually
had the kind of relationships we needed, because not only were we
the four Human Space Flight Centers, but the six other Centers, Research
Centers and Robotic Space Flight Centers. So very diverse experience
there—[people] that normally didn't work together are now working
together on our team, and it took a while to build those relationships
In fact, some of the first few issues that we worked, when we brought
that forum together and we voted on what the right solution was, we
voted right down [according to] our backgrounds, experience. Human
space flight voted in one direction, and robotic space flight voted
in another direction. It was obvious then that we still hadn’t
gotten there, but now, four or five years into it, we've done a pretty
good job of building the right relationships. I borrowed that from
what we learned in the Shuttle Program.
After Challenger, were there any types of, these same types of aspects
set up that you remember?
I was so further down on the chain I'm not sure I had the right perspective.
Although, after Challenger, it was probably one of the more significant
periods of learning for a young systems engineer, because we essentially
went back to the beginning and said, "Well, did we get this design
right?" And we went back to review every aspect of the design
at that time. So that was an initiative that I'm sure was started
at the top, I just only saw one end of it. But I'm sure [it was] very
Do you feel like that's really helped you where you are now, the fact
that you've gone through all of those?
Oh, absolutely. Understanding that it's about relationships and trust,
that's critical to success of the NESC or success of any program.
How would you teach these lessons or processes to the next group of
upcoming program managers or employees? How do you instill some of
the things that you feel are important for success?
I think it's participating in inter-center projects, projects that
get you out of your current role where you may have blinders on to
your center's perspective only. Going and spending time at another
center. I spent my first 16 years at the Kennedy Space Center and
didn't know anything else, and so when I went to the Johnson Space
Center, it was quite an education for me to see, from a different
perspective, the same Shuttle Program. Getting younger folks the opportunity—it
would have been nice, I think, earlier in my career to have been able
to be involved in other inter-center projects or go to another center
for some period of time. I think that's critical.
That's a good thing to know. What do you feel, of all the lessons
that you've learned, what's the hardest one that you’ve had
to learn? Or maybe I should say the one that you take with you no
matter where you go?
I think it's when I said Columbia and Challenger. If you’re
blinded by the successes that you have, you don't think critically
enough about issues. That will stay with me forever.
Can you teach those type of techniques in a class? And if so, did
you have any of those on the job?
Actually we've spent a lot of time benchmarking and reading literature,
when we created the NESC, on how to create an atmosphere where you
do think critically about issues. We think it's important that the
management provide the leadership to establish that atmosphere where
it's acceptable to raise issues, and where it's acceptable to think
critically aloud about issues—not just in e-mail or in your
own mind. Often we see where managers will have a meeting and discuss
an issue, and they say, "Well, okay, does anybody have a dissenting
opinion?" That's not how to attack it aggressively. We think
the management should lead the way by being the first to ask a critical
question or “what if,” a worst-case scenario.
Then by doing this in that forum where everybody sees it's okay for
the leader to ask, "What if it's worse than this?" or be
critical about a particular issue, then I think it becomes more acceptable
for everybody else to follow his example or her example. So that's
what we see as the most critical thing, is that the management has
to provide the leadership to create the environment that allows critical
thinking and raising of issues to be acceptable.
Can you give us an example how you've used that technique in the last
three or four years, or four or five years? An example of one of the
issues that you've addressed?
There have been a lot of issues that the NESC has provided a forum
or the infrastructure in which people can feel comfortable raising
an issue to a program, especially in a forum like the Flight Readiness
Review, which can be very formal and sometimes even daunting to a
young engineer, I would imagine so. Raising that issue through the
NESC, and then you essentially have the infrastructure of the NESC
backing you up, and it isn't a lone ranger saying, "Hey, wait!
We've got to stop, we've got to look at this!" I think that's,
in general speaking, that's where I think we've done the most good,
in that we have the resources to do testing and do analysis that can
back up somebody's engineering judgment that something's not right
with a particular problem.
That’s great. It seems to be a very neutral forum that they
can come to. Can they come with generalities, or are you looking for
specific determinations that they need to have investigated?
I think a lot of times it is just generalities, mainly because it's
difficult for one or two people to have the resources to get all the
data they need to really investigate a problem. Since we have our
own resources, we can investigate a problem, we can run a test, or
we can do analysis, and maybe one or two people couldn't do this.
I think that's really the difference.
It sounds very, very interesting. I know you did some preparation
work. I was going to give you a second, and I know we didn't specifically
talk about the very first question about the best practices or sound
practices. I know you alluded to some of them.
No, I think we covered them. The safety philosophy was I think the
sound processes that I wanted to talk about, and the best practices
is this building of relationships and trust. I think the other thing—we've
talked around it a little bit, but I think if I were to offer improvements
for planning and implementation of risk mitigation, it would be to
include outside experts on your teams investigating difficult issues.
Because as we talked [about] earlier, the experts within the program
may have been working the issue for years, and they can develop this
bias that we were talking about, about not clearly seeing the issues
from different perspectives, and so bringing in folks from the outside,
whether it's the NESC, or some other Center, or from industry, or
the Department of Defense, it doesn't really matter, providing they
have the right expertise, and they can often provide you a different
perspective on the problem that maybe your own program or project
experts just can't see because they've been working it too long.
I think that's the biggest improvement that we could make, if we make
that commonplace, that we always bring in folks from the outside to
help us. It's often [that] the program expert has this "can do"
attitude about—and "We can do it, we can solve this problem,"
and it often leads the Program Manager or Project Manager to try to
solve his problem with the resources that he has at hand. Not saying
that they're not good resources, but that if you open it up a little
bit and take advantage of the resources that the whole Agency has
on these critical issues, you'll often come to, I think, a better
solution. So, if we can make that common practice, I think we'll be
It certainly gives another perspective for you to make a determination
from. Would there be a process of your internal experts and your external
experts who are at different extremes? Would you have to determine
how best to move forward?
Yes, but I think that's exactly what a leader or a project manager
wants. He can make a better, more well-informed decision if he hears—whether
it's two or three or four different perspectives on the problem. Often
we'll hone in on one solution, and we get stuck on that one solution,
and we missed the problem altogether. So if you're a leader, to me,
you're better off if you can hear two or three different perspectives
on the problem, and then you can make a decision on which way to go
based on those perspectives. I think that results in better, more
well-informed decision making.
The way that your program is set up, are you in that position to be
the person that asks those questions and to bring those in? Or do
other people in the group of your experts take that lead in the discussions?
Sometimes it's me, sometimes we have leads for different tasks. We
have multiple people that do that.
And in your case here, are you making a decision or a recommendation
back to the program?
Hopefully what we're providing, and what our intent is, [is] to provide
them an engineering position based on test and analysis, so that it's
not just a judgment or somebody's opinion. It's that we went off and
did testing or we did analysis, and these were the results to back
up our position. In providing a different perspective, it's not just
our engineering opinion or judgment; we're supposed to be backed by
test and analysis.
Do you feel that the decision to create your Center will continue
on to help solve future issues?
I don't know. Because we were created actually before the CAIB [Columbia
Accident Investigation Board] report was written, it was the summer
of 2003, there was a lot of support to go do this. As we get further
and further away from the accident, I fear that there will be less
and less support because as always, funding is an issue, and the less
people remember what was happening at the accident, the less people
there are to ensure that organizations like this are properly funded.
So it’ll be a struggle as we get further and further away from
an accident, I believe.
Well maybe some of the lessons learned and the processes you've created
And I do think, because we do see now the programs, Constellation,
Shuttle [International Space] Station, much more willing to bring
in folks from the outside and to bring in folks from Robotic Space
Flight Centers. A great example was [when] the Shuttle Program was
dealing with an engine cutoff sensor anomaly—it's been two years
now. They actually requested one of our folks from [NASA] Goddard
[Space Flight Center, Greenbelt, Maryland] to lead the Tiger Team
to look into the anomaly. That would have been unheard of five, ten
years ago, that they would have brought somebody in from Goddard to
lead that. I think we're making headway from that standpoint, and
if we can make that happen, and if it was universal, you wouldn't
need the NESC. The goal would be to make everybody think that way,
and then you don't need the NESC.
How many issues have you addressed since you've been in formation?
In four years, it's a little over 250 issues. All different, all Mission
Directorates, so not just human space flight.
Are these any of the ones that you've seen or ones that you encountered
when you were sitting in the midst of the program?
Yes. So I recuse myself from those.
What advice would you share with somebody joining a similar program
or wanting to join NASA at this point?
I think it's what we've already talked about, how important it is
to build those relationships and trust. Often as engineers, we're
trained in the discipline and the physics of a problem, or math, or
engineering solutions, and knowing how to and knowing how important
it is to build trust and relationships is not what we get trained
in. You have to see some examples, like I mentioned Ron and Tommy,
of how important it is to go do that. If somebody's starting a new
program, I’d spend a whole lot of time, as much time on those
relationships as I do on the technical aspect of it.
You have any suggestions on how to teach that or how to train people
Well, I think you have to see it and participate in it to appreciate
A hands-on type of affair, isn’t it? What else would you recommend
to equip the next generation of Space Agency employees? What are those
attributes that people are looking for, that you can train to have
that trust and that relationship building?
A lot of times, I know what we see that really inhibits that is when
people become really defensive about their technical position. They're
not open to other people's suggestions or criticisms, and they get
way too defensive, and then they really, again, become blind to seeing
that there might be a different way of accomplishing it or a different
solution. So trying to be able to resist that temptation to be defensive
about your own particular technical position, and to be open about
somebody else's perspective, and to listen to other people's perspective—I
can't tell you how much I've learned in the last four years. After
working in the Agency for 25 years, I've probably learned more in
the last four because I'm working with such a diverse group with diverse
experience. So if I take the time to listen to them, I can do a whole
lot better than if I just stick to my own personal technical position
that I've developed only by working in human space flight. So you
really have to be able to open up your mind to other perspectives,
and it’s difficult sometimes.
That's a great point, thanks for bringing that up because I think
everybody gets comfortable.
Oh, absolutely. When I was at the Kennedy Space Center, it was a frame
of reference that was purely processing of the Shuttle. When I went
to the Johnson Space Center, I said, "Oh!" It was a totally
different perspective. Now I've been working with folks from Research
Centers and Robotic Space Flight Centers for the past four years,
and it's two and three different perspectives. There's something we
can learn from all of them, and if we can keep open to that, we'll
do much better.
Very good information. I think I've kind of worked through all those.
If you want to look through some other thoughts.
I think we hit everything.
I think one of the areas that we might have, that you might want to
talk about a little bit more, is that when we ask for an example of
a successful risk mitigation activity.
Yes, the STS-93 electrical short. The ascent of STS-93 we had an electrical
short in a circuit that affected the main engine controllers, and
following that, the program stood down, I believe it was about four
months, if I remember correctly. We inspected all the wiring, or a
majority of the wiring, on all the ships. To me, it took a lot of
courage on the Program Manager's part to say, "No, we're going
to stop. We're not going to fly until we investigate this anomaly."
It's hard to maybe remember, but there was a lot of pressure there,
before Columbia, to complete the Space Station. I think it takes a
strong leader to be able to recognize when we need to stop and truly
investigate a problem without flying. Often we get in this position
where, "Oh, we'll continue to fly while we'll investigate the
problem." Because from a schedule pressure standpoint, that seems
to be the easiest thing to go do. So it takes a lot of courage to
stop and truly investigate a problem while the fleet's on the ground.
One of the comments that you made through our visit today was about
a strong leader, and you mentioned that you worked with Tommy Holloway
and Ron Dittemore. Are there others?
Bill [William H.] Gerstenmaier and Bob [Robert B.] Sieck. Those are
folks that do represent strong leaders in my mind.
You mentioned some of the attributes that you find in leadership.
Were there other attributes with the gentlemen that you mentioned,
like openness and good communication? Were there other things that
they did that you admired, that you feel really helped the success
of the program? Maybe you could share with us how they deal with failures?
When things didn't work out the way they were supposed to, when they
had to start over again. What were some of the leadership things that
you felt that they did to help carry the program through?
I’m trying to think of good examples. I think the whole aspect
of building up the team, as opposed to sometimes you get a leader
who has a tendency to tear down the team when things don't go right.
But those gentlemen, Tommy and Ron, [and] Bill, they have a tendency
to build up the team and build up the morale. That's probably it.
That’s a good thought. Is there anything else that you can think
you'd like to add?
I think we covered most of it.
All right. I can give you a minute. I don't want to rush you.
I think we talked about a little bit, the creation of those councils
in the Shuttle Program. Earlier in the Shuttle Program, there was
certainly a lot of friction between the Centers, Marshall [Space Flight
Center, Huntsville, Alabama], Kennedy, and Johnson. The relationships,
I thought, were horrible in some cases. The creation of those councils
really went a long way to improve those relationships and got the
Centers working together much better. I thought that was critical,
too. I think that's it. I think we talked about all my key points.
All right. I thank you, and I wish you the best of luck in taking
care of those issues before they become problems.