NASA Johnson Space Center
Oral History Project
Tacit Knowledge Capture Project
Edited Oral History Transcript
John P.
Shannon
Interviewed by Rebecca Wright
Houston, Texas – 16 April 2008
Wright: Today is April 16th, 2008. We're at the NASA Johnson Space
Center to speak with John Shannon, NASA's Space Shuttle Program Manager.
This 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 spending some time
with us this morning for this project. In February of 2008 you were
named to your current position. But, if you would this morning, start
with how you first came to work at NASA and then to the Space Shuttle
Program?
Shannon:
I started in December of 1987 as a fresh out. I had co-oped [cooperative
education] for a couple different local companies and Rockwell [International
Corporation] and Grumman [Aerospace Corporation]. I went into Mission
Operations Directorate, and was in MOD for the first 14 years. I was
in the Guidance, Navigation and Control Section there, and became
a flight director and did ascent and entry flight director [tasks].
So I came in right after [Space Shuttle] Challenger [STS 51-L accident].
It was probably the year before STS-26 flew. I was a little bit involved
with some of the work MOD did in the recovery. Then after [Space Shuttle]
Columbia [STS-107 accident], I was asked to leave the Flight Director
office and go be Frank [T.] Buzzard's deputy interfacing with the
Columbia Accident Investigation Board [CAIB]. Then Bill [William W.]
Parsons asked me to come over and do Flight Ops [Operations] for the
reconstituted [Space] Shuttle Program after Columbia. So major changes
of jobs after Shuttle accidents.
Wright:
Share with us some of the details about lessons that you've learned
dealing with the challenges of going to each of these roles and positions.
Shannon:
Not going in the time in Mission Operations Directorate—of course
that's a very specialized job in that when you're a flight director
or a flight controller, you have to have tremendous knowledge of the
systems that are being flown, the procedures of how each crew interacts
with each other and the flight control team. It's very mission-focused.
It's very different from a program type job, in that it is very insular
and you're just accomplishing the mission, and you do whatever it
takes.
Coming over to the program was very interesting, because it was in
a time of significant turmoil and we were not sure how we were going
to get back to Return to Flight. There were a lot of new procedures,
a lot of changes to the way things had been done for 20 years. It
was very challenging in that we just really didn't have a good idea
of how we were going to get there. I think the team that Bill Parsons
put together was able to work effectively with the Columbia Accident
Investigation Board. We weren't going to fix everything, but we were
going to fix enough things that it was going to justify bringing the
Shuttle back to flight. We accomplished that.
It was very difficult though, because the problems that caused Columbia
were very intractable problems. Because we lost the vehicle and we
lost really most of the evidence of what happened early on. Of course
it was recreated both from the recovered hardware but also from analysis
of flight data, it was recovered what had happened, but we had the
Columbia Accident Investigation Board that sat around for four to
six weeks without a real good answer on what had exactly happened.
So they turned to cultural issues.
They became very interested in some of the cultural aspects of the
Space Shuttle Program, which was hard for everybody around here because
our culture had been studied by FAA [Federal Aviation Administration]
and military organizations and all these high-performing organizations
that recognized we had a very good culture, and here the Columbia
Accident Investigation Board, because they were not quite as familiar
with us and they did not have an accident hardware problem to go work,
they worked on these cultural issues, and I think that that set us
off to go do some things that maybe were not as important as some
of the hardware fixes that we did. So it was very interesting.
Wright:
How did you take those experiences and actually gather any lessons
that you can apply to what you're doing now?
Shannon:
I think out of the Columbia accident, a number of things came through
that were very loud and clear. One was there was too much control
at the program manager level, and that you had one person for the
most part that was responsible for the budget, and of course nothing
happens unless there's a budget for it. They were also responsible
for the schedule and any technical changes that were made to the vehicle.
Most program managers were very adept at handling all three.
But it was very easy, if you had a budget concern, to not do technical
things that you might need to go do, or not take the time, expand
the schedule out, because you had some pressures from [NASA] Headquarters
[Washington, D.C.] or outside agencies or something else to meet a
specific schedule. So you had the opportunity to have a very biased
technical answer based on cost numbers, because you're trying to meet,
as a program manager, a certain cost number and schedule pressures
from the outside. So what the CAIB pointed out and what NASA very
strongly embraced was if you laid all of those into the same position,
that potentially you would have a condition where you would make a
poor technical decision based on meeting your cost numbers or meeting
your schedule.
Whether that was really the case in Columbia I don't think. I think
we had in Columbia a failure of imagination. We'd had this foam release,
but we never imagined that it could do what it actually did. Even
in flight when we saw it hit the wing, it was a failure of imagination
that it could cause the damage that it undoubtedly caused.
So what NASA set up was their governance model, which I like very
much. You really have three independent paths. As the Program Manager,
I'm responsible for the technical and the safety and the schedule,
just like I was before, but I have help. The safety organization was
enhanced greatly, and they have their own appeal route if they think
I'm doing something that is unsafe or is not appropriate, they can
appeal it up the path through Bryan [D.] O'Connor [Chief, Safety and
Mission Assurance] at Headquarters.
The same on the technical side. If the engineering team thinks I'm
making a mistake or doing something for the wrong reason or doing
something unsafe, they have that appeal route through—since
the engineering organizations are internal to the Centers—they
can go through the Center Director, then up to the Chief Engineer.
You can have things arbitrated. If the Program Manager doesn't agree
with the safety or engineers, it can be arbitrated all the way up
to the [NASA] Administrator level, which was all completely new.
That's happened once since Return to Flight. My goal of course is
not to let that happen, to work out at the lower levels the safety
needs and the technical needs. We've become a much more effective
organization in doing that. One of the places where that really became
clear was in the Mission Management Team work. I spent a lot of time
reworking how the Mission Management Team would do its business during
real-time execution of flights.
We brought a lot of safety guys and a lot of technical guys. We changed
the way we talk about things. We really listen to their opinions.
We require, whenever people come in with a presentation detailing
something technical, if it's been heard before, that [they] bring
forward the dissenting opinions that were out there. We hear those
dissenting opinions. So, while I'm not sure the CAIB had time or the
insight to be able to state exactly what our cultural problems were,
it made us internally look very hard at our culture, and we found
some areas where we could improve. I think we've been very effective
in improving that.
Wright:
You mentioned the governance aspect that has been implemented. Would
you consider that an improvement for the overall management processes?
Shannon:
Very much. Yes, I really do. Now other people will not, because they
consider it to be a pain to deal with. They'd like to be the program
manager that is all-powerful and can make the decisions and off you
go. That's not very healthy. It's good for me to know that I have
other folks that can challenge what I do, and it makes me make sure
I understand all the diverse opinions out there and try and come to
the best decision that I possibly can, and then be able to explain
it in a manner that if it is appealed up the path I will be able to
explain why I made the decision I made. I don't have a lot of ego,
so if I get turned around on something that's fine, as long as everybody
heard the discussion and they understand exactly why the decision
that was made was made. Again it's more healthy, because it takes
a little more time, but you get better decisions. I've seen that over
and over and over again.
The other thing it has really benefited is that it makes the safety
and the engineering team feel like they have a voice. Before they
did not feel like they had a voice. Now they know that by necessity,
because this may get appealed up, we have to listen to them and to
their opinion and take it into account. Now I would like to think
we would do that anyway, but you might not always. When you have the
governance model in place that's in place, it makes you do that. So
I see it as a huge advantage.
Wright:
Are there other examples of improvements for risk mitigation and management
processes that have come along since you've been working the last
20 years?
Shannon:
There are a lot of smaller ones. One that I think is still in development
that can be better, but I think we're much more on the right track,
is our overall risk management system. We now track our top risks
in the program. What I mean by that is we have each element go through
and talk about what their biggest risks are. It's not just technical
risk, it's also schedule risks and cost risks and mission success
risks, if you're going to meet the manifest or meet the customer's
needs or not.
We have a process called SRMA [Safety, Reliability, and Mission Assurance]
which ranks them. Then we take a look at our top risks, and we report
those up to Headquarters. It's very effective because once a month
I review that at my main board, and it keeps in front of everyone
what things we need to keep our eyes on, what kind of things we need
to continue to work.
Where I think it has some improvement areas is in tying that back
to the budget cycle, because I go into a budget discussion about where
are we going to spend our resources, and it has to tie back to where
your top risks are. Now informally we do that anyway. Say I want to
spend some money over here working on this, or doing this engineering
test, or in this wind tunnel, or whatever it is, because I know that's
a top risk. I might not have known it was a top risk before when I
wasn't reviewing them monthly, but I need to be able to tie it back
and show that here's where my safety score is on this particular item,
here is what I am doing now to the budget cycle, I am spending my
money to reduce my major risks in the program. Informally we do that.
We're trying to set up a formal process of doing that. When we do
that, that'll help me out a lot more.
Wright:
When we first sat down you mentioned that you have your experience
in the program area, but you have spent 20 years in the midst of the
day-to-day operations of flight controlling and flight directing.
I'd like to ask you some of the lessons that you've learned in regard
to improving, for instance, management performance. You've had such
key leadership positions.
Shannon:
It's changed a lot in 20 years and it's gone through cycles. But when
I came here, the Centers were very insular. It was all internal to
a Center. There was not nearly as much working across Centers. That's
the nice thing about programs, is I have a strong team not just at
Johnson but also at [NASA] Kennedy [Space Center, Florida], Marshall
[Space Flight Center, Huntsville, Alabama], and Stennis [Space Center,
Mississippi], and a team at MAF [Michoud Assembly Facility, New Orleans,
Louisiana], it’s primarily contractors, Huntington Beach. So,
if you're in the institution working for the Center, you may be a
little bit focused on Center. When you're in the program, you're focused
outwards.
It used to be very internal. You hear the fiefdoms and stovepipes
and the little catchwords that folks like to use. We've changed over
the last 15 years to a much more integrated team that's matrixed.
Matrix management came along, and people really doubted it for a while,
and horizontal organizational structures and integrated product teams
and all that stuff, that was all new in the early '90s. The things
that worked stayed. I don't hear TQM [Total Quality Management] much
anymore at all, though we all had to go off and take little training
classes, and there's been other things like that that have been out
there.
But the things that really worked, they stayed, and so what you have
now is you have just about every meeting you go to, certainly every
program meeting, it's a very matrixed meeting where I have agreements
to get support from Engineering, from Safety, from Space and Life
Sciences, from the Mission Operations Directorate, Flight Crew Operations.
I am not a direct supervisor of them, but they attend and support
the meetings. It's a lot different from the way it was 20 years ago
when I first came in. It's much more effective.
It's better because it keeps each of the individuals engaged. If they're
an engineer, they can go off and work Space Station Program, they
can work Shuttle Program, they can work Constellation Program maybe
in the same week, do different activities and report back. I was worried
at one time about performance measurements and how well we could provide
feedback if people were not performing well. All that takes is a little
bit of extra work communicating to their managers of the various organizations,
who is doing well and where there are some areas of improvement.
Now folks coming in the doors can see it like this is the way it always
has been and it works. It's been very beneficial from a manpower standpoint
that we don't have to keep everybody inside the Shuttle Program and
fence them off and not let them do anything else. It would be a huge
challenge right now if I did that, because people would be saying,
“What am I going to do in two years?” and walking out
the door on me. But as I do more work for Constellation and we're
constantly working with ISS [International Space Station], people
have a lot of different avenues that they can go into that they're
very familiar with. That'll help us all on our retention.
People have different styles [of management]. People are much more
sensitive now than they were 20 years ago. We get all the helpful
tips and harassing workplace and all those things out there. I think
back to a lot of the bosses I had or that I saw and they would never
have survived in the environment of today. Now you hope they would
have evolved and changed, and of course they learned it from the guys
that first came in the door. But it's a much gentler workplace than
it used to be.
It used to be you got called on the carpet and they used colorful
language. But it was also different, too, because it seems like people
back then could yell or discuss or whatever in different meetings,
but they'd get over it real quickly too. It was just the way it was.
But now it's not quite like that. I don't know if that's a cultural
phenomenon or not.
Wright:
Maybe history will tell us later. What about program efficiency, some
of the lessons that you've learned coming up in those leadership positions
that have helped you create a more efficient program?
Shannon:
Well, the matrix management is obviously the biggest thing by far.
When you talk about efficiency, there's a lot of different paths you
can go down. Cost-efficiency and coming to technical solutions or
meeting the manifest. There's a lot of different ways you could do
it. We're phasing over right now in the Shuttle Program where when
we did Return to Flight, money was almost no object, which is really
strange for a space program. Engineers get really used to that environment.
They really like it. But it was whatever it takes to get the Shuttle
back to flying, and there were no bad ideas, and everybody ran off
and did everything they could think of.
Now that we've flown nine times since Return to Flight, we're having
to back up because we do have cost controls. Some things didn't work
as well as you might have hoped that they would work, and you have
to back up. So we're going through a transition of leaning out the
program quite a bit, from the “spend whatever you need”
days of Return to Flight to, “Hey, let's pick the best processes,
the best things that we can do to maintain the safety. Let's get rid
of the other stuff that was not value-added that maybe took additional
workforce, that I could go use for Constellation now or I could go
use to speed my processes up.”
That's a change. As you change that culture, especially coming after
Columbia, you worry that people are going to think, “Oh, they're
backing off all the things they needed to do to make us safe to go
Return to Flight.” Of course we're not doing that at all. Matter
of fact, I think it makes you more safe if you're concentrating on
the things that really add value to the program, as opposed to things
that you were just doing because you didn't know what else you were
going to go do.
But backing out of anything is very difficult. We always said in the
Flight Director Office, once you put a flight rule in the book it's
in there forever, because then you have to justify pulling it out
and it's a rule, and rules are gospel to flight directors and flight
controllers. You can't ever pull anything out. Well, it's the same
way with the program. You have to be very careful that when you make
a change you understand the full impacts of that change. Cost, schedule,
processing time.
That's a difficult thing now as well, is some of the changes we made
like to the external tank, they were made as good ideas to reduce
debris, whether you needed to reduce the foam debris coming off the
tank or not in that specific area. If it was a change that would reduce
debris, it was automatically assumed to be good and was put out there.
When we found out that we're late on some tank deliveries, and when
you try to find out why are you late on tank deliveries—I went
out to the plant. One of the changes that was in an area that was
not a risk to us, had never shed foam before, but some folks in Marshall
engineering thought it was a good idea to go and rework it. They took
an hour-and-a-half process and changed it into a 55-day process. We
had another area that didn't really shed foam, they took it and it
delayed the tank by about a year because they were reworking how they
did it.
So the danger was when you were in an environment like Return to Flight,
where all answers are good answers, because we didn't know how we
were really going to get back to flight, making decisions that sound
good but you don't understand the full scope. You don't understand
how this is going to affect processing time. It doesn't do me any
good to have wonderful tanks that are delivered in 2011 when I'm not
allowed to go fly them anymore. That's where we were headed. We did
not understand cost impact, we did not understand schedule impact,
and we just looked at the technical side, so we got overbiased in
one area. It made us a very inefficient program, because it wasn't
value-added, and it was because we didn't understand the full scope.
So what did I learn out of that?
What I learned is you have to keep asking questions. That even if
it looks like a good idea, you have to understand the full scope of
any change you make before you change it. Drives people crazy. It's
obviously the right thing to do. Just make the decision and move on.
That's very rarely true. There are very rarely any free decisions.
You're going to hit budget, you're going to hit some other technical
piece of it, you're going to have some rework because you changed
the mold line in the vehicle and the aerodynamics change, so you got
to go recertify a bunch of stuff.
It might impact how the Orbiter was certified. Or it just might impact
how quickly you can get a tank out the door. So I'm going to have
a six-month time period where I can't go fly a Shuttle flight, because
I don't have any tanks coming to the Kennedy Space Center. It's all
because we made changes back in '04 that are just now, the engineering
is coming up there. And nobody asked in '04 when we were trying to
recover, “Well, how long will this make the get-the-tank-out-the-door
cycle?” There was no appreciation for that at all.
Because at that time nobody thought we would be out of tanks. Matter
of fact, we slowed down production on tanks at that time, because
we didn't have anywhere to store them. We filled up the VAB [Vehicle
Assembly Building]. We've flown all those. They're all gone. And I
have one tank in the program right now that's being mated up as we
speak. The next tank is not coming out the door for four more months.
So I've got an issue. I inherited all this stuff, so it's going to
be interesting to see where it comes out.
Wright:
That leads into the next topic of lessons learned about planning.
Shannon:
Yes, we're going through a significant planning cycle right now. It's
a change cycle, because the Shuttle Program and the manpower associated
with the Shuttle Program is going to be an integral part of flying
the next set of vehicles that we go fly. So we're trying to change
this organization that is very process-oriented, that has known how
to do their job for 30 years really, it's been about 30 years, into
a very lean organization that is very flexible, that can go do flight
tests on unmanned vehicles. Huge change in culture. It can help us
out because you take different risks, you make different technical
decisions based on flying a different type of vehicle and flying it
manned or unmanned.
How do you do that? Well, the other thing I've got is retention issues.
How do I get everybody to stay in the program until we fly our last
flight? Especially if they think after our last flight they're going
to get a pink slip. Those two go together, and it's all about planning,
it's all about how do I define what the organization is going to look
like, how do I define the individual transition plan for each person
that's out there and make sure that they know what their job is going
to be, if there is one in 2010, and what they'll be doing for Constellation,
and then engage them early, get them started early.
So it takes all the angst out of the process, they know where they're
going to go, they know what they're going to do. If they're not in
a critical job for the next program, we define, “Hey, we need
you to stay until this time, and then this is going to be your job
when you get out,” or we say, “Hey, we're not going to
have something for you, you need to go find something at this time,
if you can stay till this time we'll give you this much retention
and try to keep you around that way.” It's a huge amount of
work, because they're all very detailed personal plans for each person.
There's no other way to do it though. You have to go through, and
you have to make that decision. To do that you have to come up with
the basic organization you're going to need three years, four years
down the road, and then map from this organization to the next organization.
Talk about planning, it is a huge, huge task. We're right in the middle
of it right now.
Wright:
Underlining most of what work is done with the Shuttle is always that
aspect of risk. So there's the risk assessment, risk management, risk
mitigation. Can you give us some lessons and some best practices that
you've learned from dealing with all that element of risk? Especially
these last five or six years?
Shannon:
This will sound weird. I think we overmanage risk in the Shuttle Program,
which is probably a mouthful to say. We home in on certain areas,
and I always say we're fighting the last battle. We home in so much
on foam and impacts to the vehicles. We've flown nine flights since
Return to Flight. We've had no significant issues at all. Matter of
fact, it's been wonderful performance. But we can't let it go.
What I worry about is that we're so focused on the one area, and we
have so much being spent both intellectually and financially on an
area, that we pretty much have taken care of that we're missing something
else. The vehicle is incredibly complicated, no escape system, you’ve
got to get it right. So you try to keep the team focused on all the
areas out there. There's a great little commercial that's been out
there. I don't know if you've seen the two basketball teams, and you're
supposed to follow the white team passing the ball and count how many
times, and you do that. But in the middle of it a bear comes in and
starts moonwalking, and you never see it because you're counting how
many times this team passes. I showed it to my team last time we all
got together, and it's a great analogy. We're so focused on the one
task that we see in front of us, you totally miss this other thing
that comes out of nowhere and is obvious. And if you had an accident
you'd go back and you'd say, “How in the hell did you miss the
moonwalking bear?” It's right there, it's right in the middle
of the screen, but you're too busy over here looking at how many times
the white team is passing the ball back and forth. It's actually a
commercial to watch out for motorcyclists. You don't see what you're
not looking for.
It's a great analogy, and that's what I worry about on risk. I think
the SRMA system we set up that goes and identifies top risks, it makes
people think a little bit outside of what the primary focus has been
lately. As new problems crop up on a flight, we're very judicious
in making sure that we document those in SRMA and we talk about the
what-ifs so we don't have the failure of imagination.
But a lot of that is judgment stuff and where do you spend your money,
and again that goes right back to I need to be able to tie my risk
management system back to my budget cycle so I can spend the money
in the right spots.
Wright:
When you first got here, you mentioned it was right after Challenger,
and you were starting to learn and be part of the flight controller
system, and of course since then you've learned a lot on the job training,
and I'm sure had some formal training along the lines. Are there some
lessons or some specific types of training that you learned along
the way, or maybe something that was instilled in you by someone who
was here during that time, that you feel is something that you use
every day or you use as part of what you do to determine what your
style of management will be?
Shannon:
I think working in MOD you really learn to work the details and look
at it from a broad systems engineering standpoint. That was great
training. I had some incredible mentors there that provided just the
way you went about it. In MOD, they simulate two, three times a week.
For launches and entries, you do it more than that. So it's like a
test every day when you go to work. You go sit on console, and based
on your systems knowledge and your knowledge of the flight rules and
your knowledge of the conditions of the day, you have to make decisions.
Then you debrief. You talk about what decision you made, and how good
or bad it was, and were you listening, and did you communicate with
the right people that were out there.
That's wonderful training. As a matter of fact, to the Mission Management
Team, we brought the concept of debriefs to that team, which was very
uncomfortable for everybody when we first started out. Coming from
the flight control background, it did not bother me at all. I went
first since I was chairing the team, and I totally bared my soul and
said all the stupid things I'd done and that I would never do them
again, and here's how I got into it. And one by one the engineering
guys that had never done that before opened up, and they liked the
concept. So we've added debriefing, even on major meeting stuff, to
our repertoire of things that we go and do.
Knowing that, ops folks then are trained to take information in, even
if it's a limited dataset, and make a decision and move on. Engineering
folks are not trained that way. They're trained in a manner that is
very different, where you go collect all the data you can, all the
data, you spend the money, you take the time, you analyze that data,
you benchmark other areas, have the huge complete set, you talk about
it for a while, and then you come to a decision maybe at some point.
Very different culture. Ops guys get frustrated with engineering guys,
engineering guys get frustrated with ops guys.
We talk about diversity around here. Diversity is not gender, it's
not race, it's between ops guys and engineering guys, that's our biggest
cultural battles that we have. Of course [N.] Wayne [Hale] was an
ops guy. Parsons was an ops guy. I'm an ops guy. Drives the engineering
guys crazy. Steve [Stephen J.] Altemus even, the head of engineering,
is an ops guy. So what do you do? You have to adapt your style of
management to embrace the engineering guys. You can't say, “Okay
guys, here's the data, here's the obvious solution, boom, we're going
to go do it, see you later, meeting's over,” because we would
exercise the governance model quite a lot if we did that.
So what you do is you talk around the problem. You have huge patience.
You talk about all aspects. You make sure you gathered as much data
as you possibly can. You talk about different options. It's a much
more full process. The ops guys are pulling their hair out and lying
on the floor going crazy because they obviously see the answer. It's
not always the answer we end up with either. But it's very different.
The other one is engineering folks tend to need a little more time,
and so the way we do that is we have premeetings, we have many more
premeetings than I would normally think we ought to have. You can't
just bring it to one board and make a decision and go. We have a premeeting
where the engineering team gets to lay out all the things they think
about and all the stuff they're worried about. You have to pick the
managers for those meetings very adeptly, make sure the right person's
in there that will listen to them, that will hear all of it, that
will document dissenting opinions, that will work through all the
data. Then when you get to the big meeting, the engineering guys feel
like their concerns have been heard, you don't have to do the big
circle around the problem because they've already done that, and you
can more directly go to the heart of the problem and work it.
But it's a very different culture than the ops guys. That's a real
significant issue. I can disenfranchise a huge number of people if
I get into a meeting and make a decision in two or three minutes.
Then they dig in their heels, and it becomes very difficult to get
team consensus at that point. It's very, very difficult, because they
feel like, “Well, you're not listening to me and how hard it
is.”
I did have a little bit of formal training and went off to Harvard
Business School for three months, and anybody who's a senior manager,
if they have the opportunity to go do that, ought to go do that, because
you go through business cases, it's in the business school, do three
a day, two on Saturdays, you take a huge amount of time to prepare.
You learn so much. You talk about things you would never talk about
in the government, and with international partners. So I was probably
more influenced in management style just by doing that fellowship
than any other thing at NASA.
It completely changed the way I looked at how I treated organizations
and people and how you arrive at solutions to problems. I still call
those guys probably once a month. I'll call one of the old professors
there and talk to them about certain issues, and they're always extremely
helpful. So as senior managers get into their positions, if they can
have an opportunity to do something like that and then touch back
with those folks every now and then to talk about the issues of the
day. And they love it. If I call these guys they're so excited, because
they get to help the Space Shuttle Program, figure out what we're
going to do. A couple of them have gone down and seen launches. They're
so excited about it, and they give you good information. You can't
believe the vast amount of experience these folks have of course that
I don't have. I haven't been here that long. I haven't faced that
many outside-the-federal-government kind of problems. They have. So
finding those people on the outside that you can trust that are good
touchstones whenever you're facing a problem, it's hugely helpful.
It's extremely beneficial.
Wright:
Sounds like good solid training, which easily leads me into my next
question. How would you recommend to best train and equip the next
generation of space agency employees that will be working with you
for the next 20 years?
Shannon:
Well, we're going through a new time, and it's pretty exciting. Because
the focus is on design, development, test, and evaluation. The DDT&E
function. Now you're coming into a sustaining engineering role for
people that were here 25 years ago, they developed the vehicle, and
now you're just watching over it and sustaining it, maybe upgrading
it a little bit. This is a whole new rocket family that we're developing.
So the skills are going to be different, and you have to get a little
bit more away from the ops, which is more of the sustaining role,
and more to the engineering. We have to have two things. It's a huge
amount of discipline to work the details and make the appropriate
decisions, but also decisions have to be made, and the guys that are
coming in the door, they have to be extremely technically competent,
they have to understand the systems, they have to talk to other people,
get the lessons learned from other programs, talk to their counterparts
at Marshall, talk to their contractor counterparts, make sure they
fully understand the problem, and then make a decision and move forward.
That's something we haven't had to do for quite a while, so it's going
to be interesting to see how this plays out. Working the details,
making decisions and sticking with them, and realizing that if you
made a dumb decision you can come back in the next day and say, “That
was a dumb decision, I need to change that.” That's okay, and
there shouldn't be any punishment or any retribution for that kind
of stuff. But it's going to be an exciting time. We've got a lot of
work to do over the next several years.
They've talked about people losing jobs and it's ridiculous, because
our budget is actually going up, and budget is directly correlated
to jobs. When people talk about those jobs, it's the Shuttle jobs
going away, but they never tell the other side of the story of the
Constellation jobs that are coming forward, and the unallocated $1.2
billion worth of assets out there that are going to hire people. So
it's an interesting environment.
Wright:
It is, and you mentioned earlier about the diversity within the different
types and groups. How do you teach the lessons that you talked about,
or those processes to that many different kinds of people so you don't
lose these lessons learned?
Shannon:
That's a good question. I did not appreciate the split between ops
and engineering, and I don't think many people did, until maybe post-Columbia.
I think it really pushed that out into a forward position. How we
talk about that, how we engage the team on that, I don't know. I don't
know that we've actually thought about how to do that other than we
talk about it every time we get together. But that is our biggest
cultural issue in my opinion. It's not any of the other classical
things. It's the people that were brought up as operators and people
that were brought up as true engineers doing design work, how they
work together.
Wright:
What do you think was the hardest lesson that you had to learn in
the last 20 years?
Shannon:
Probably the best lesson I think is that you have to trust the people
that you're working with, and you have to let them know that you trust
them. But along with that goes when you say something, you have to
make sure they know they can trust you by following up and doing what
you said you would do. If you don't have that trust, then just the
whole process breaks down. I'll tell you right now in the program
there's some people that provide dates when they're going to have
different pieces of hardware available that I don't trust, because
I think they either pad their schedule to make themselves look better,
or they're afraid that they're going to be negatively graded so they
give you a fictitious schedule, and then later on after a grading
period they'll update it with something that is more realistic. That's
so difficult to manage.
It's been said a couple times, NASA's an all-volunteer organization.
We may look like the military but we're not. Since it's all-volunteer,
you have a lot of extremely smart people who for the most part could
probably go make more money outside. So you have an all-volunteer
organization who if they quit or were fired would go make more money
and be more financially successful anyway. That's a very difficult
group to manage. The one thing that keeps people here is the mission.
You don't get to do this anywhere else.
I think that's key to understanding that people want to be here. There
are other things they could do outside and be more financially successful,
but not get the job satisfaction. So you have to make sure also that
you're providing that job satisfaction to them. You're making sure
they have the opportunity to grow and learn and be a big part of the
mission. We spend a lot of time doing that as well, making sure that
people feel like they're appreciated for what they do. But again it
all goes back to the trust piece. You have to be able to trust the
team. As program manager, I am completely at the mercy of all the
guys that are turning the wrenches and doing the Michelangelo-like
sculptures on the foam to make sure that it doesn't liberate and that
they did their job appropriately. I can't go check all that stuff.
You need to go and trust them.
Wright:
Well, let me offer this question as a final one. What advice would
you share with someone joining the program?
Shannon:
The Shuttle Program, or just NASA in general?
Wright:
Maybe both. The Shuttle Program and NASA.
Shannon:
Well, the Shuttle Program, we are at a pretty stiff pace right now.
We're trying to finish up. We're trying to make sure we support Station
as best we can. I would strongly encourage, and I am encouraging my
senior leadership. We have probably the most difficult task we've
had in a long time right now, because we have to fly it out, we have
to fly it out safely. If we splash a Shuttle, the next program's in
huge jeopardy and NASA as a whole is in huge jeopardy. So we have
to pay attention. But I also firmly believe that in the Shuttle Program,
we have a unique set of skills on people that are able to design,
develop, assemble, flight test, launch, operate spacecraft.
That workforce really doesn't exist anywhere else. So the Shuttle
Program has to get involved in the next program so we don't have this
big gap between flight programs. We can pull them back on the schedule
to the left a little bit by engaging our workforce. So we want to
do both. We want to be extremely vigilant, do smart things, accomplish
a more significant manifest flightwise, we're going to fly more flights
in the next two years than we have in the last three, meanwhile we're
engaging the next program.
I was just out at Stennis Space Center for the first flight test review.
It's a year away for the next program. So we have to engage that workforce
into that as well. That solves my retention problems. Because everybody
that's here because they like to go fly rockets in space, they're
really excited about it. We're doing our favorite thing, flying the
Shuttle, but we're also doing the next program kind of work as well.
So you have to be very flexible, and you have to go outside your comfort
zone a little bit, because there's a lot of things that we do in the
Shuttle that are not going to be applicable to the next program. It's
a very well-defined program. The next program is not at all. We have
to help make it that way.
Coming into NASA, I almost wish I was coming in as a new hire right
now because the Station's almost complete, we've got all our partners
heavily engaged. The Japanese, part of their lab is up, more is going
to go up. The Automated Transfer Vehicle by the Europeans is up. The
Russians are still doing their thing. We're flying out the last part
of Shuttle. We've got HST [Hubble Space Telescope] coming along, our
last servicing mission to Hubble. So it's going to be an incredible
year next year as well.
But also you've got this great new program where we're going to go
back to the Moon and we've got that in our capability to do, and we
either do it or we don't, it's completely up to us. So it's an incredibly
exciting time. When I used to do tours as a flight director, I used
to tell all the congresspeople and staffers and senators and things
that would come, I'd say, “I love the Shuttle; I'd trade it
all in a heartbeat for an exploration program.” Voila, here
we go. So it's going to be an exciting time.
Wright:
We look forward to it and learning more about how you do what you
do during the next 20 years.
Shannon:
I'll still be here. So we'll do it in 20 years. That'll be good.
Wright:
Well, that's good news. Anything else you want to add?
Shannon:
I appreciate you doing this. This is valuable. It's good stuff.
Wright:
Well, thank you. We appreciate it.
[End
of interview]