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

Steve M. Poulos
Interviewed by Rebecca Wright
Houston, Texas – 17 June 2008

Wright: Today is June 17, 2008. We are at the NASA Johnson Space Center to speak with Steve Poulos, NASA's Deputy Director for Engineering. 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. Thanks again for taking time out of your busy schedule and sitting down with us with this project. We'd like for you to start by telling us how you first came to work with the Space Shuttle Program.

Poulos: I hired into the space business in 1984, and I was working for Rockwell International. At the time, I was engaged in cargo engineering and integration, and spent a few years doing that. Then eventually, I hired into NASA full time as a civil servant, and then spent most of my early career in engineering in Crew and Thermal Systems, doing flight experiments and EVA— Extravehicular Activity hardware development.

But in 2003, I was Division Chief of Crew and Thermal Systems at the time, and the day of the accident for [Space Shuttle] Columbia [STS-107], it was probably about a week after that that Frank [J.] Benz, who was the Director of Engineering at the time, had asked me to come up and help him as part of the NASA investigation side of the accident effort. What ultimately happened, after a period of a few weeks, was Randy [Brock R.] Stone and Jim [James W.] Kennedy—Randy Stone was Deputy Center Director here at Johnson, Jim Kennedy at the time was Deputy Director at KSC—and Frank Benz became a triad for the NASA Accident Investigation Team. We referred to it as NAIT, N-A-I-T. Since I was already working with Frank, I essentially became the Deputy to that group.

So for six months—it wasn't really even that long—but up through July 1, I was engaged with everyone in terms of the investigation. Late June, Bill [William W.] Parsons called me and asked if I would be interested in working in the Shuttle Program and taking on the Orbiter Project Office responsibilities. And he gave me about an hour to make a decision. I immediately called my wife and all that kind of thing, but yeah, that day I accepted the position, and July 1 I started in 2003 full time as the Orbiter Project Manager.

Wright: Share with us how those duties changed over time. You talked about where you got there, because you walked into—as you mentioned, during that investigation—into that position. Tell us about these last years and how those duties evolved.

Poulos: You bet. Actually, I feel very fortunate in the sense that coming immediately after the accident, I had the opportunity to spend four or five months as part of the investigative team. The team here, local at JSC, was focused on the Orbiter System because that's what we have a responsibility here. So the day I was assigned responsibility for the Orbiter, I had a pretty good understanding of the issues that needed to be worked, and that really gave me a leg up. If they had just called me without me having any real involvement with the investigation or anything, and said, "Take over the job," it would have been a much more difficult effort to get mentally engaged and really understand what it was that the CAIB [Columbia Accident Investigation Board], the Accident Board, was looking for with a number of their recommendations.

One of the comments that I did want to make today and I feel pretty strongly about, and I think maybe many others would echo this: we as an Agency, I believe, made a mistake when we came out forcefully—and I don't want to take away anything from Mr. [Sean] O'Keefe [former NASA Administrator]—but the terminology of “accept, comply, and embrace” the CAIB recommendations established a mindset for all of us that we were going to do whatever it took to meet the letter of each of the recommendations, letter of the law. In retrospect, what we could have done, maybe should have done, is taken a step back in the totality of the recommendations and made a conscious choice about how we were going to go off and implement the various recommendations. And which ones we were going to actively work and which we thought were good inputs but we didn't feel like we needed to go do any work in those areas. So I characterize that as a major lesson learned. When you have independent boards and panels for any type of mishap, the recommendations that come out should not be considered cast in stone. They really ought to be considered in the light of day with the appropriate programmatic management criteria that we apply to anything: cost, technical schedule, risk elements for the overall effort.

So anyway, that's maybe an aside, but the other part of my job in Orbiter was we had to develop the Orbiter Boom Sensor System [OBSS] to be able to inspect the Thermal Protection System [TPS]. We had to come up with a means to repair the Thermal Protection System. There were a few other ancillary things that we ended up doing, like establishing a digital camera in the underside of the Orbiter when the external tank separated so we could photograph and then ultimately downlink the imagery. For me personally, most of my career has been project development, flight hardware development, so it was a really great opportunity for me to continue in the flight hardware development arena. At the same time, though, the Orbiter was a very old vehicle, is an old vehicle. It's not that it's unsafe, it just has its quirks. And there are things that break or have problems literally every day, which was, as I've told many people, the beauty and the curse of my job. Every day it was something different, but every day it was a new challenge.

Now, the critical development items for us became the Boom Sensor System and the Thermal Protection System repair hardware, and that became the pacing items separate from the External Tank Project, which certainly I can't speak to. It was outside of my area of responsibility. The other thing that we hurt ourselves on was we were always three months away from launch. I remember telling Bill Parsons one day that—and I think he eventually remembered it because he parroted it back to me at one point—if you're going to build something like this, that's as complex as this Boom Sensor System, it's going to take 21 to 24 months. There's no way to shortchange it. It's just that's what it takes to go build something like this.

But while Mr. [Ronald D.] Dittemore [former Space Shuttle Program manager] was still here, before he left, we had targeted a September launch, and the accident was in February, so whatever that was, six, seven months. Then we were in December, and then I think we went to March or April, and September after that. As much as I would try and almost plead with our senior management, "Please give us a little more flexibility here because we just can't make that schedule," we kept moving incremental dates. Now to be honest, whether there was a political undertone to any of that or not, I had no insight. It wasn't one of those things that if we had said up front that we're going to be stood down for two years and that could have ultimately affected the program, who knows? I don't know. We live and work in a political environment, so it was certainly something I'm sure that the folks at [NASA] Headquarters [Washington, D.C.] had to keep in mind. But it did make it difficult for those of us who were off trying to actually build the hardware and implement it.

The projects themselves—I could not have been more proud of the team that came together to build systems that actually in many respects exceeded our expectations. Almost every one of them that we developed exceeded our expectations. I'm going to just use the Boom Sensor System as an example, and then you can steer me in your next direction. The system complexity was not so much a technical complex system, it was the fact that it had hardware coming from the Canadian Space Agency and Sandia National Labs [Laboratories], as well as the Boeing Company, United Space Alliance, JSC Engineering at the time. All of those organizations were each doing certain tasks, and just the fundamental integration of all those disparate groups of people with their various responsibilities became a very difficult challenge.

But the part that made it—maybe easy is the wrong word—but made it all come together was the common goal. We were all working toward a very straightforward, well-understood Return to Flight with a system that will enable us to inspect the Thermal Protection System. We actually did it in 21 months. To be honest, I didn't think we could do it in 21 months; I thought it was going to be closer to 28, but the team really pulled it off.

The other thing that we had to do—which in a perfect world from building systems you would never do—the sensors themselves, one came from Neptech which is a Canadian company, and the other came from Sandia National Labs. They were, for all intents and purposes, off-the-shelf hardware. It already existed, the technology had already flown on the Shuttle. So they had a certain capability in terms of the level of detection that they could see on our reinforced carbon-carbon [RCC] in terms of the size of damage. It literally took us about 14 to 16 months into that 21-month cycle before we came up with the criteria of what we had to be able to detect. In a perfect world, it would have been nice to know from day one, “What size of damage do we need to be able to see?” It varied actually by panel to panel, but as I say, we didn't have that until much later. But in retrospect, we were using systems that already existed, so we kept the team moving along.

I used to get—I'll use the word “beat up” a little —from the Independent Review Boards, in particular the Stafford-Covey [Task] Group—about moving out on the development of the system without having the requirement. Really, my comments at the end really said, "We had the systems, we were going to go certify the system in terms of being able to fly in space, and it will be able to detect whatever it can detect." Then my hope always was that once we had the requirement, that the sensors would be able to detect what they needed to. Interestingly enough, it ended up being very close. There is 100 square inches out of 20-something thousand square inches of reinforced carbon-carbon where we don't absolutely meet the criteria, but it's pretty good. It's close enough at the end of the day.

So anyway, that was one of those decisions that we had to make, and I really took heat for it personally, not only external but internal, because a lot of folks weren't comfortable moving out without having those baseline requirements. But we were all moving forward. We wanted to obviously continue with the space program and the Shuttle Program and complete the [International Space] Station.

Wright: Let's talk about the example that you gave just a little bit more, because it sounds what you did is that you changed a process that people were very comfortable with in order to meet a schedule. Tell us a little bit more about what you learned from that, other than the fact that it made people feel a little uncomfortable. Maybe some of the techniques that you used to calm those fears as well as moving forward that ended up being proof that the decision was the right one.

Poulos: One could always argue whether the decision was right or wrong. And to be honest, I don't know that I ever allayed everybody's concerns through the entire development process. But I have a personal philosophy in terms of taking on a challenge or a new hardware development project, and that is never say no from the beginning, because you're never intelligent enough just off the top of your head. I like to use the phrase, "Get on the train." Let's get on the train, put some engineering assessments, engineering analysis behind what we're being asked to do, and prudent minds will eventually show whether the path we're on is a good one or not. So that was my message to everybody personally. And I think I basically had to say straight-out flat to everybody, "I know we are not following our process. Yes, I would love to have the requirements, but we don't." Basically again, almost pleading with everybody, "Bear with me. Let's go build the system, and we'll test the system to the greatest extent possible," knowing that eventually we would get the requirements and we would know how big of a gap that we had.

Eventually, people recognized the strategy. And I would characterize it as a strategy. It wasn't until we got near the end, and it was probably two months before flight, literally, the Return to Flight, where we completed the testing to show the capability of the sensors and contrasted it against the requirements. Then we figured out how much overlap or lack thereof that we had, and then 100 square inches poked out. But at that point it was such a small area.

We also, something I didn’t mention, we did implement a novel system, the Wing Leading Edge Impact Detection System, which is a set of accelerometers that are bonded to the structural spar members in the wings of the Orbiter. If something impacts the panels, the reinforced carbon-carbon, it'll cause the accelerometers to excite, and we'll be able to see that, because we were able to download the data from on orbit to the ground. So I felt like if there really was a significant impact of concern, we would see that in those sensors, and it would help us to the extent that if we really thought we had a problem in that small area, we could always send an EVA crew member out to put eyes on. Actually, we built an EVA digital camera. All these things are being done in parallel. As I say, as a hardware guy, it was really fun. But a digital camera that we were able to download the images into a laptop and then download those to the ground as well.

So all those things played together, and I think when everybody saw the fact that there were multiple levels or multiple opportunities to evaluate the risk, including the ground assets that the Kennedy Space Center [Florida] had. Plus we had the ability to evaluate the tank when we got on orbit with the External Tank imagery, and then the Boom Sensor system, the Wing Leading Edge system, the RPM, R-bar Pitch Maneuver when the station folks take the photos—when you overlay all of that information on top of each other, the opportunity for something to fall through the crack and not be found is really a small, small number.

So that was the way I characterized it for everybody. Ed [Edward J.] Mango and I shared the opportunity to manage the Office together. Ed was my Deputy. We tried to come up with this Swiss cheese looking thing one day where all the holes had to just perfectly line up over about six different things where you would have a problem, and it's just a small likelihood.

Wright: How important is planning when you're trying to do all these major projects parallel that come out at the same time?

Poulos: Fundamental. We utilized for about two years a forum every Friday, about four hours. We called it a Return to Flight working group. I would characterize my job at the time was really broken into two parts. There was all the development work, getting the vehicle ready for Return to Flight. Then there was the day-to-day sustaining engineering because we were still processing the vehicles at the Cape [Canaveral, Florida], things were still having their standard issues. So what I'm really going to probably spend most of my time talking about is the development work.

Having the Friday Return to Flight working groups, we brought in representatives from all the stakeholder organizations. We had Flight Crew, MOD [Mission Operations Directorate], S&MA [Safety and Mission Assurance], the engineering base and the contractor base, all of us would get together. And the project managers who worked in my office—they all did, all of them did—would come in with some subset of their team, and they would talk through where they were in terms of cost, technical, schedule, and risk. As a collective team, we would review all that to see how each of the different projects were coming together. Actually, I made it mandatory that all the projects had to sit there or have a rep to sit through all the discussions, because as you say, it was imperative that this all came together at the same time. Because all this hardware had to fly on Return to Flight. Occasionally we would have to beef up resources on one project because they were falling behind, so occasionally we had to take some resources off a project that might have been a little ahead of schedule to help other projects. That really was the forum that enabled us to do the cross-work for planning and making sure everything came together at the same time.

Wright: When you were in that forum and as you were discussing areas—I'm sure not everything always fell right into place. There must have been times where you had contradicting ideas and opinions. Can you share with us on how you mitigated those issues that came up?

Poulos: Probably the most challenging issue was relative to the thermal protection system, the repair concepts. This was something at the very beginning most people thought couldn't be done. There are probably people today that'll tell you it still can't be done, but I would very strongly argue the other side of the equation. I think the team has come up with four distinct capabilities—two for the tile system and two for the RCC system—that if we ever had to effect a repair, it would work.

What we did early on though—and this is probably one of the areas I didn't think through as well as I maybe should have—we had five different NASA Centers involved, each off brainstorming different ideas. At one point, we were probably funding twenty different concepts. Low-level funding, but you added it all up, it was pretty significant dollars. I would say probably eight to ten months into this, I realized that we were not converging. We would get into the Return to Flight working group meetings on Fridays and we'd talk about this, and everybody had their favorite concept or idea. "That would work. That wouldn't work."

So eventually, what we had to do as a strategy on how to move forward was we set up a two-day, all day meeting. All the folks that were involved came to JSC. We met in [room] 966 down the hall here and went through each and every concept. Its plusses, minuses, likelihood of success, schedule risk, cost estimates, everything that a project manager would want to see. But really, our key focus was on the technical feasibility. Could we actually come up with something that would work? When we concluded that two days, I caucused with everybody. I was prepared to go down to, I think at the time, four different concepts. But there were some folks who wanted to keep a couple others in play, so we ended up leaving there and dropped from twenty to about six.

The challenging part, where we really debated the most, was on the tile repair and the material that some people affectionately referred to as “the goo.” Its real terminology is the STA [Shuttle Tile Ablator]-54. There were very passionate arguments on both sides of the equation that the material would not work in space vacuum. So we went round and round on that probably for a year, if not more. We had done testing to the best of our ability here on the ground in our various chambers, KC-135 [reduced gravity aircraft] flights, 0-G [zero gravity] simulation, and I personally felt very confident that the system would work. The material would work. But there were some experts out there—and I'll put experts in quotes—ceramic scientists and others that felt that the material would just bubble out and wouldn't come out in a nice bead-type fashion like caulk-gun caulking that's used at home.

So that really was probably the most difficult project effort we had, certainly on the Orbiter side. Many debates, many arguments at the PRCBs [Program Requirements Control Board] about whether we should even be flying the material because so many people thought it was useless. It was the only time in my five-year tenure that—to coin the phrase—where I threw my badge on the table. I said to Bill Parsons, "This hardware, if required, will give the crew a chance to come home." To not fly it and leave it on the ground, to me, was unconscionable. To Bill's credit, he eventually said, "We're going to fly it."

The crew took exception. The crew office was the ones who really did not want to fly it, but what happened—and this is a lesson learned for future project folks—is I screwed that project up from the very beginning in terms of how I defined the requirement of how much material was going to be required to fly. We kind of played around with it for a month or two or three, and everybody kept asking, "How much material do we really need to plan for?" I didn't think it through, and this is the one I really kick myself in the butt over. I made an arbitrary decision and said, "Just look at our flight history. The longest length of damage that we've had coupled with the widest damage." So it was like twelve inches by eight inches. Then I said, "Take it all the way to the bare structure, and whatever that volume is, that's how much material we should plan to fly."

That was the wrong decision because what I ended up doing was driving a system that carried 600 cubic centimeters of material that was this huge cylinder that attached to the back of the crew member. So from a crew member utilization perspective, I could see very quickly why they hated it, and I don't blame them for hating it. But in the back of my mind, I was always working mentally through the fact that if they had to use it, they'll get over the fact that it's a pain in the butt to use it.

What we should have done—what I should have done—was done a more statistical analysis. Because we've had thousands of impacts on the belly of the Orbiter over the years, and we could have come very quickly to an appropriate three, four, five sigma value for the damage volume that we needed to protect for, and it would have been significantly less than where we ended up. So today, we fly something called the T-RAD [Tile Repair Ablator Dispenser], which is a child to the original Cure-in-Place Ablator [Applicator], CIPAA, the big canister, and it only has 100 cubic inches of material. But if you followed the flight experiment that occurred a couple of flights ago, it proved its merit, and it actually did work. I did restrain myself. I didn't send any e-mails out to say, "I told you so," but it was fun to watch it come together. I really felt good for the team because they really worked hard.

So getting back to your question on the challenges side of the equation and how to work through that. That was the one that really sticks out the most because it had such strong, passionate feelings on different—not only people, but we eventually got to where we were almost by organizations, were split. Crew office was totally against it. Engineering was totally behind it. MOD hated it because of the difficulty. S&MA loved it because it provided a contingency capability. If we didn't have it at all, it probably would have made some of our lives a little easier. But it goes back actually to the CAIB recommendation again, "You will have a repair capability." Really, the only way to prove a repair capability at the end of the day is to demonstrate it on orbit and then actually fly it home, which we were never going to do. But at least going on orbit and demonstrating it was something that was good for the ones we did test.

Wright: I noticed one of the words that you use quite frequently since you've been talking with us is the word “team.” If you could share with us how important it is to put together a good team, and what are the elements of a good team, and how you build those?

Poulos: In my going away party, which was just a few months ago now, most of the people who came up and said some kind words referred to the fact that the day I showed up, I focused on the team. Its roots come from my father, who gave me two small pieces of advice when I left home, which was Pennsylvania, before I moved to Texas, 1982. The two simple pieces of advice was one, "Always say we, never say I." Two is, "Always write it down." So the "we" part has stuck with me forever, and I just extrapolate it to be team because I don't do anything on my own. Certainly not at work. It really ended up perpetuating throughout the entire team, and we had 2,500 people in totality who were working on the Orbiter, whether it be civil service, local, other Centers, contractors, local weather centers. It was a pretty large team. In fact, at one point the budget we had it on in one year was a little over $900 million. So it was a pretty large effort.

For me, and the reason I so much focus on teamwork, is when people are having problems and folks recognize that they are part of a team, then it's almost automatic that somebody who has the knowledge or the wherewithal to help will just jump in and do it, rather than feel like they have to go ask their management or that. So it was, “We're all in this together.” We're going to succeed together or we're going to fail together. If you have the ability to help somebody—I don't know if I said that or not, I probably did—you have an obligation to help so that we can meet our objectives, meet our goals.

Wright: As leader of that team, how do you help instill and nurture an element of trust between the members, and especially between the management and the employees, where they feel they can bring up subjects and topics?

Poulos: That was a really good question. Because trust—first and foremost, there was the contractor base who worked under an award fee contract. They didn't know how to take me when I first came on board. I was a new commodity. Most of the folks didn't know who I was. What I think they quickly figured out was is I walk the talk, and that in order for us to collectively be successful, whatever award fee score they were getting was a reflection on ourselves, myself and my civil servant team. So when they saw that if they were having trouble we would jump in to help, they started conversely doing the same thing.

Similarly with the other Centers, and this was one of the more rewarding things for me as well. At one point we had, helping the Orbiter team, all but three Centers: Dryden [Flight Research Center, Edwards, California], JPL [Jet Propulsion Laboratory, Pasadena, California], and Headquarters. I don't really ever say Headquarters gives us any help—I'm just kidding. They do quite a bit. But we had all the Centers that were doing some form of help, tasks, et cetera for Orbiter. Invariably, once they were engaged and they started seeing and hearing some of the problems that we were having, they would start to offer help. It was almost self-feeding, self-perpetuating.

As far as folks that work directly for me, part of making sure that the trust existed was expectations and accountability, and then the roles of responsibility and authority and so forth. I tried to keep the expectations simple and easy to understand, did not micromanage, but they knew there were periodic checkpoints where they had a responsibility to come in and share where they were at. What I've seen over the years is a number of folks or organizations that are fearful of bringing forward their problems because it almost seems like maybe they're failing in their job, and they're perhaps unwilling to air dirty laundry or ask for help. My tact is really 180 degrees out. I actually rewarded the folks, usually in public forums, when they brought forward their failures, their test failures, the anomalies they were dealing with, or when they were asking for help because they needed it. That type of thing caught on after awhile as well, so people knew that they could come into a working group meeting or one of our Control Boards and say they were having trouble, and they weren't going to get beat up over it.

Actually, I do want to give credit to Bill [William H.] Gerstenmaier, our Associate Administrator for Space Ops [Operations]. I worked in Station for a little while and had the opportunity to work with Gerst, both when he was in the Shuttle Program and Space Station. He had the mindset, or still has it today—it's very simple. If there's a problem, don't attack the individual that's bringing you the bad news or whatever news it is. Okay, we have an issue. It's on the table now. Let's figure out how we're going to solve it. When I saw how he did business, I started to try and emulate that to the best of my ability, and it really does make a difference because people are willing to just put it out there, whatever's going on, and it's amazing how ideas start flowing, people start bringing in help. Then my favorite block on the project management schedule, "And a miracle happens," and it all comes together.

Wright: What would you think has been the hardest lesson that you've learned through your time with NASA? Or maybe the best lesson you've learned?

Poulos: Best lesson? Best lesson is too easy—it's the people. The difficult one is I’m not perhaps as politically savvy as maybe I should be or could be. And politics is beyond Washington. There's the political element, just one organization to another, almost one group to another, and I never really spent a lot of time thinking about that because my blinders were on and I was off collectively with the team trying to work to our objectives. But those subtle things, like just periodically tagging up with other stakeholders and making sure that they understood the rationale for decisions and what drove doing things a certain way, goes a long way. That's probably something that I've tried to start doing a lot more of maybe in the last year. So that was really a key lesson that I picked up and maybe learned it the hard way, in the sense that probably could have gotten more help outside of the Orbiter team had I been a little more out there, as opposed to being so focused down on it.

Wright: You brought with you your dad's advice about, "It's not me, it's we," and then also, "Write it down." We've talked about the we and me, but share with us about writing things down.

Poulos: Well, decisions. I have worked with folks who are reluctant to put things in e-mails, and I realized, and I've always realized, especially when e-mail came into bear, it made my life a little easier instead of having to carry around my notebook all the time. This actually gets back to the trust part. When folks would send me information and were looking for guidance or direction, "Which way do you want to go,?" I always felt like responding to all if it was a multi-person e-mail with my recommended go-forward plan provided tangible traceability. So there was no fuzz that yes, I agreed with the path we were taking. Therefore, whether it's a contractor team or my own folks or whomever, they knew that I was going to stand behind that response and back them up.

I don't want to say I read every email, every word, because that would be a lie. But I open every e-mail that I ever get. Some of them I don't read because it's not something that I really need to read in detail, but those that I do, I do read in detail. I always personally try to at least send back a quick little note, something as simple as, "Copy," "Concur," "I understand." Just to let folks know I got their message and that they know I'm paying attention.

Wright: I guess that lends itself to a question that we can discuss some, which is about communication efforts. What do you do as a manager to make sure that the communication flows up and down to get to your teams?

Poulos: My new boss, Steve [Steven J.] Altemus, and I have been talking about this. I've been back in Engineering now for three months, so he and I were just talking the other day and I said, "You know, I don't feel like I personally get one third of the information that I used to get as the Orbiter Project Manager. " And it was frustrating me a little. I didn't know what to do about it yet, so it's something we need to work on. But we had a morning telecon every day at 8:15, and then three times a week at 7:00 am we would tag up with the contractor team, again over telecon because the team was distributed around the country: Florida, California, local here in Houston, multiple places. There were probably 30 lines up, and I don't know how many people were listening, could have been hundreds.

But I would make it a point to convey every day whatever information I'd gotten over the last 24 hours. If I talked to the Program Manager and he gave me a little insight on something, or whomever might have conveyed some information, everything that I knew I just kind of put it out there. Communicate, communicate, communicate. Then we would go around and we'd have a standard agenda the folks would call on and they'd share latest issues, concerns, successes, whatever the case may have been. It really to me was a great opportunity to get synched up. It's almost a daily checkpoint. Of course, then we used it also as, if there was something that just happened over the last 24 hours, then we would decide at that tag up, "Well, we'd better have a separate meeting on this. " So we would decide we were going to tag up at noon and then go through what the issue is and what our options are.

The other thing that I tried to do was we would have short Program Management tag ups twice a week, Mondays and Thursdays. Someone was tasked with taking minutes from that meeting, which was very good. So I would distribute those minutes to everybody, distribute it to everybody in my office, and to the senior managers for the contractor, and the organizational leads, engineering, S&MA, and so forth. And I told them that I'm looking to you to distribute this information down through your organizations as well. So that gave folks an opportunity to see what was happening at overall program level, beyond just the Orbiter project.

Then we would have off-sites as management team. There were about 60 of us, so we'd get together once a quarter, and we would go typically to a vendor site. I remember going to Corning, New York [Corning, Inc.] Went to Ames [Research Center, Moffett Field, California], White Sands [Test Facility, New Mexico], and a few other places. Boeing, up in Seattle. It gives a chance to get away for a few days. It also gave us the opportunity to talk about critical things associated with the whole group that we needed to do better on. That was a good chance for all of us to work together and come up with good strategies, and we would typically tour the facilities that we went to. Folks from the Shuttle Program usually were kind of excited to have us come up here. In fact, when I went up to Corning, New York, I didn't realize how big of a deal it was until they brought their nightly news crew out and they did an interview with me. And the next morning I saw myself on TV, which is always kind of funny.

So just various methods of trying to ensure that communication was happening. I’m not one to hold back anything, really, unless it's personnel or personal in nature. But other than that, it's free information. I mean, I tell people what our latest budget status is. You know, “We're overrunning here, underrunning X amount.” Just if people know, they can be part of the solution. Did I get at the essence?

Wright: Yes, very much so. Thank you. Speaking of budgets, program efficiency's got to be a bit of a challenge when you had so much happening at one time, and as you mentioned a while ago, that you have something different, something challenging every day that would come up. Share with us your techniques of being able to provide an efficient program in budget constraints.

Poulos: There was a six-month period where I was in heaven as a project manager because budget was no question, which is how I got collectively out of hand with all these repair options that were being looked at and a number of different things. Then about six months into it, somebody pulled in the reins and said, "All right, now you guys have got to be real project managers." I said, "Well, we knew that day was coming." But it really takes a discipline, I think, of working through and understanding your content. What the expectation is, whether you're at a project level or a program level. What is the expectations that are lubbing on you? Doing a good bottoms-up assessment of the work content and the cost, really go into that content—people, materials, et cetera. Rolling it up and recognizing that there is a need for some level of contingency for the “I-forgots” or the things that just happen, unfortunately. Then going forward and defending that request.

Now, at the program level they're in a much different scenario because their budget is mandated by Congress. At the project level, we had the ability to do exactly what I just said. From the bottoms-up review, and assessing all of our sub-projects, rolling it up, and putting a little contingency there, and then working forward. What I think actually enabled us to be successful was the fact that because we had so many projects that were being accomplished, and the program was not holding me accountable to each project discretely. So in other words, I didn't have a separate charge code for the Orbiter Boom Sensor System **or the repair hardware.

Although it was tracked by the budget analyst, the program manager didn’t hold me accountable to that. He held me accountable to the bottom line. So if one of the projects was underrunning—and there was always one or two that actually did underrun—the opportunity to shift funding to the ones that were having trouble was there. And we took advantage of that quite a bit because some of the projects just had more complexity and some additional challenges. The Boom Sensor System, that TPS hardware were the—not the problem children, but they were the difficult projects. The other ones, a little more straightforward design development and typically ended up underrunning, so that helped. But you did have to track it.

If there's one thing I can offer advice to a project manager, is if you think your job is 75% technical and 25% the rest, you don't understand your job. In a perfect world, it's probably 25% people, 25% cost, technical, schedule to get to the 100%, tracking them all almost equally. Unlike a first-line supervisor, whose job should be more on the order of about 75% people and then 25% technical in terms of mentorship and bringing the troops along. So that was something that I had to remind myself at least once a month, that, "Okay, Steve, you're getting too much time in technical meetings and not spending enough time looking at how the troops are doing. Are they getting the care and feeding that they need? Oh yeah, where are we on our budget right now?" I was very fortunate and had the very outstanding Assistant Manager for the office that just did a phenomenal job managing the budget. So if you really want to do things right, follow management rule number one, which is surround yourself with good people. I had that opportunity. The people that I got to work with were all top-notch. Very little direction required, and always exceeded my expectations.

Wright: How would you recommend to best train and equip the next group of Agency leaders that are coming up? What are your thoughts on that?

Poulos: I am currently involved with a program that Mike [Michael L.] Coats has established, Program Project Management Development, and we're the first class. There's about 25 of us, I think. At first, I thought—because the course content started with leadership, and then it had project management, contract management, we're going to do resources next. We have a couple left to go. Resources and then systems engineering. Then we went up to Washington [D.C.] as a group and did a Congressional Operations Training Effort for four days, which was actually one of the most enjoyable courses I've ever taken because they clearly explain why nothing ever happens in Washington, and it's designed that way, for that tension to exist.

But I've spent 25 years doing project engineering or project management, and I thought, "Why do I need any of this? I could probably teach a lot of it." But after being in it now for a little over a year and a half, the real benefit at the end of the day is getting to know the other folks and their backgrounds, because we have folks from other Centers, folks from other organizations here on site. But then re-reminding myself of things that I've forgotten over the years. Because it's very easy to get comfortable with a particular style of doing something, perhaps because it's worked in the past so you perpetuate it. But reminding yourself that there's other ways to do it, especially when times get tough, whether the budget's getting cut or you're losing some of your best folks, and how do you deal with those scenarios? We're getting good insights through this training, so I really applaud Mike Coats for wanting to establish this forum, this training module or set of modules, because I think it really will be helpful to those of us that have the opportunity to take it.

Wright: What advice would you offer someone who's thinking about coming to work at NASA, and/or someone working at NASA and wanting to move up into the program?

Poulos: The best advice I would give is don't be afraid to move around to different organizations. When I first hired into NASA in 1989, after five years working for Rockwell, I thought my pinnacle job was going to be Division Chief of Crew and Thermal Systems, because that's where I supported the organization as a contractor. I hired in there as a civil servant in '89. About eight years later, I was asked to move to the EVA Project Office. Didn't really want to go, but I decided—and I was pretty much working EVA stuff anyway so it wasn't too big of a leap. Then I was asked to go work in Space Station for a while, and I did go back to what I thought was my dream job, Chief of Crew and Thermal Systems. Then I was asked to go work Orbiter. Then I was asked to come back here and work as Deputy Director.

I know Lucy [V.] Kranz [JSC Associate Director, Management] in particular will usually point me out as an example of somebody who's moved around quite a bit here in the Center. I've been on various teams, Center-level teams, Agency-type teams, to be able to know not only a lot of people around the Center but around the Agency. Just knowing how the Center works, knowing the other organizations—half the time just knowing who to call and who to talk to to get a task done is a tremendous help. If you grow up in one organization and never move, your whole world seems like maybe 150 people, when in reality we have 3,600 civil servants or something like that and 15,000 contractors. I probably even am fortunate enough to cross paths with 2,000 of the civil servants and I don't know how many thousands of the contractors, just by moving around.

Wright: That's great. Before we get to the end today, I wanted to go back and think a few minutes and see if there were any other thoughts you had, especially in any kind of recommendations for new management processes. I know you've already given some, and I wanted to make sure that you had covered pretty much those ones that you wanted. Are any of those other basic best practices, sound principles, that you carry with you every day to do your job?

Poulos: I'd say having a process is critical. Understanding the process is more critical. We have, in the engineering directorate, a work instruction how to design and develop hardware, and I forget how many pages it is. But you give it to a young engineer and you say, "Go build me a widget, and use this document as your guideline or how to go do it." They'll diligently read it and not have a clue what they're reading, so they're missing that. They know there's a process, but they don't understand it. Then, when do they actually start to understand it? After they've done two or three projects. And then they finally start, "Oh yeah, okay, now I get it. Now I know what they really wanted me to do." The other part of the understanding is if you know the process and you understand it, then you know how you can deviate from it and still make sure that everything is safe and we're not going to set ourselves up for a major failure.

Safety, number one objective. Crew and ground safety. There's no fuzz on that. But the knowledge to be able to deviate from it—to be honest with you, I have never had a schedule and a budget that I ever felt comfortable with. And I don't think that I personally ever will. So you have to be prepared to be, for lack of a better word, creative. But the creativity can be a double-edged sword because you can miss some very critical elements that either a) will create a safety problem or b) cause a failure of the system or the hardware. So that's where, after doing it a couple hundred times now for me, that helps a lot. Hopefully that's something I can pass on to some folks within the organization.

In fact, that's one of the initiatives I want to take on as well. It's very similar to what you're talking about, but in more of a face-to-face type fashion than what I'm going to call a project leadership forum. Bringing in the project engineers and project managers and talk about challenges that I've had or that they're having, and what steps I might have taken or that they're taking to solve their problems. Because a lot of folks engaged probably are having the same issues and might welcome some insights into what some folks have done to solve some of the problems that they're dealing with. Sounds very similar to what you all are trying to capture as well.

Wright: That sounds very interesting. It's a good way—an exchange of information and teaching at the same time. Were there any other thoughts that you have or any other aspects you want to offer today?

Poulos: Let's see, I want to make sure I remember the three—my predecessor, Ralph [R.] Roe, who I admire greatly. Of course, Ralph left under difficult circumstances and moved to Langley, but in our five-minute hand over when I sat down with him, he gave me three pieces of advice. I've got them all. The first was, "Whenever you're making a decision, always make sure that you have the Flight Crew, MOD, and Safety engaged, and that they're all on board with the decision." Two was, "You're always going to have thruster problems on the Orbiter." And three was, "This is the best job you're ever going to have."

In closing, I would say by far, the Orbiter Project job was the best job I ever had. It may have been stressful as all heck, 14 hour days for two years, but I wouldn't have given it up for anything. I loved it, I loved it. Although being out of it now for a few months, I realize that it was a pretty stressful job.

Wright: Well, what you did say? Something different, something challenging every day.

Poulos: Exactly.

Wright: It's good now that you have a moment to reflect. Thank you for your time today.

Poulos: Absolutely. My pleasure.

[End of interview]