NASA Johnson Space Center Oral History Project
Commercial Crew & Cargo Program Office
Edited Oral History Transcript

David Giger
Interviewed by Rebecca Hackler
Hawthorne, California – 15 January 2013

[The opinions given in this transcript are the opinions of the person interviewed and do not necessarily reflect the official opinions of SpaceX.]

Hackler: Today is January 15, 2013. This oral history interview is being conducted with David Giger at the Headquarters of the Space Exploration Technologies Corp., or SpaceX, in Hawthorne, California for the Commercial Crew & Cargo Program Office History Project. Interviewer is Rebecca Hackler, assisted by Rebecca Wright.

Thank you again for your time today. We’d like to begin by asking you about your background before you joined SpaceX, and what led you to become involved with this commercial spaceflight venture. What are your job responsibilities, and how have they evolved, particularly relating to commercial cargo?

Giger: Thanks, Rebecca, for having me here and interviewing me. It’s been a really exciting time here at SpaceX over the last six years that the COTS [Commercial Orbital Transportation Services] program’s been going on, and I was fortunate enough to be there from the beginning. I started at SpaceX back at the beginning of 2005. I didn’t know anything about the COTS program, and I think a lot of people didn’t really at the time.

SpaceX was less than a hundred person company, working on a small rocket called Falcon 1. When I hired in, my background was really just in school. I did undergrad [undergraduate] in aerospace engineering, and I did a Master’s degree in mechanical engineering at [University of California] Berkeley. Some of the other early recruits at SpaceX had come from the [San Francisco] Bay Area [California] where Elon [Musk, SpaceX founder and CEO (Chief Executive Officer)] had been, and I was just fortunate. Right place at the right time, and knew some of the other recent grads, and was able to get started right out of grad school.

When I came in, I hired in actually as two different positions, Mission Manager for the first flight of Falcon 1, working directly with Gwynne [E.] Shotwell at the time as the Vice President of Business Development. Then the second half was supposed to be in propulsion, since my background was combustion, working with Tom Mueller. Just like any job at SpaceX, one job takes a lot of time, so I quickly found out that wasn’t going to work so well.

We agreed that I’d focus on the first flight of Falcon 1, and do the payload integration and mission integration for that, which was super exciting, going out to Kwaj [Kwajalein, Marshall Islands]. That took me through to 2005, and we launched the beginning of 2006. Around that time, we started hearing things from Gwynne and others about NASA wanting to take this new approach with commercial space exploration, with Mike [Michael D.] Griffin [NASA Administrator] at the time and others involved with this.

We got an RFP [Request for Proposal], and we didn’t really have anyone working on Dragon in a lot of detail. We had some conceptual ideas of what we thought Dragon might be, and it’d always been a goal of Elon’s to make a similar type of human-faring spacecraft. We put together a real small task team, and fortunately I was tasked by Tom Mueller in the propulsion side, “Hey, help me put this propulsion proposal together.” It was really exciting. A lot of it was listening to Tom and his vast wealth of experience that he has with different engines.

Also researching and looking at prior human spaceflight programs, because we knew this COTS endeavor—initially it was for cargo, but we kind of knew that the end goal was crew. Which I think was really key, because we always kept that in mind throughout the whole development, even though when we got turned on it was really only for cargo. Elon and, I think, NASA really helped us stay focused on, “Hey, we want this spacecraft to be capable of carrying humans into space eventually.” I think that is a huge benefit, especially now going forward, that we had that in mind from the beginning from the design goals.

Once we submitted the proposal, we were fortunate enough to be one of the ones selected. I think we were maybe 200 or 250 people in 2006. I remember it was a big, big celebration at SpaceX. Everyone was excited, Elon was ecstatic. It was probably the biggest contract we had ever landed by far, the Space Act Agreement. Everyone got really, really excited. It really gave us a direction of, “Here are the milestones that we want to meet in the Space Act Agreement,” and then we laid out a plan, “Obviously we still have Falcon 1 going on.”

We started building up a team, and it was really small at the beginning. It was maybe half a dozen people meeting with Elon every couple of days. Elon was really involved with the architecture at the beginning. Throughout the whole thing, but really provided that vision. Then working closely with a few key people at NASA—I think over the six years, what I realized is it needs to grow. You can’t just dive in with a giant team, I think, at the beginning. It makes it kind of tough to do if you’re trying to start something brand new and you have a giant team you’re trying to organize.

I think it was really helpful that we started small. Both on SpaceX’s side, and on NASA’s side, so that we could really communicate quickly and efficiently, and bounce ideas off each other, and really keep it agile. Then inevitably, and as it should be if you’re trying to build a spacecraft, you need more than five people. It grew with time, which I think was important, and it grew to the maturity level that was needed to do eventually certification and verification of meeting safety requirements for the [International] Space Station.

We definitely grew. Towards the end, right before the C1 and C2 launches [COTS milestone and demonstration missions], we had a large portion of the company, which at that time was maybe close to 1,000 people, working on Dragon, which was exciting. A big number of people on the NASA side as well, with their counterparts, and daily phone calls, and a lot of them here in person. Which I thought was really a key, too, for witnessing tests and being able to say, “Okay, yes. You guys did that. I agree,” and sign off right at that same time. That’s kind of the broad overview of COTS.

Hackler: That’s really exciting to be able to work on it right out of school, and get started with something right away.

Giger: Yes. I was really really fortunate to be there, and dove right in. The way my position evolved—I was in propulsion, after I was a mission manager for a year, and my job was basically developing this new engine, the Draco engine that went on Dragon. SpaceX had never developed a hypergolic, bipropellant engine. Fortunately my mentors—Dean Ono, my direct boss, and Tom Mueller—had a lot of experience in that. It was really me working with them. Building it up and testing it, in El Segundo [California] at the time. Then going down to [McGregor] Texas, and hot fire testing it, and qualifying this new engine. That quickly expanded into the rest of the system, because there was there were really not that many people to work on it.

I researched a lot of different propulsion systems, and changed the architecture multiple times. Then we decided, “Hey, we’re going to build our own propellant tanks, too.” We took on that endeavor, and then worked closely with a vendor on a lot of valve components. Then integrating the whole system, and built up the team from there. Then I moved into sort of a technical manager position for propulsion, probably back in 2008, and had a small team of a couple other young engineers. One guy took over the engine for me, and we had a tank guy, and we had a guy working on the components, and we just had a small, really good team working on everything together.

Then, in 2009, because I had worked on the whole system, and had really been there from the beginning, I had some conversations with Gwynne about, “Hey, there’s a lot of these interdisciplinary problems coming up between structures department and avionics and how they work together, and how does this affect the other system?” SpaceX does systems engineering in a little different way. We don’t have a whole segregated department, which I think was really key to the success of this program, that every engineer kind of has that systems engineering responsibility. You do kind of need a belly button for who can help moderate between some of these technical decisions.

I was fortunate enough to become the lead engineer for Dragon in the middle of 2009, and I helped steer our way through a lot of these integration headaches, which are kind of inevitable, I think, with any spacecraft development. Initially, you try to get them all on paper, and you do trade studies, but people are kind of focused on, “I’m going to build this valve, or I’m going to build this avionics box.” But at the end of the day, everything needs to work with each other as an integrated system. It was really exciting.

I spent since 2009 through today working on these integrated problems, where I get to interact with all the different departments, and it’s something new every day. It might be a radio frequency interference issue that we need to work through, or a mass and center of gravity issue for the whole vehicle and we need to move boxes around. It’s something really new every day, and that’s what keeps it exciting. It keeps me on my toes, allows me to learn a lot of new things.

That’s what I’ve been doing on COTS, and I did that through the C1 launch and the C2 mission as the lead engineer, which was awesome. Now I’m continuing to do that for crew, which we were fortunate enough to get going last year as well.

Hackler: One thing I’m curious about—you said that at the time of the COTS Announcement you had some ideas for the Dragon capsule, but they weren’t very fully developed. In your view, do you see that COTS Announcement as the impetus to really get started on working on that vehicle?

Giger: Definitely, yes. Elon definitely had a vision, I think from the time he started SpaceX, that he wants to make humans a multi-planetary species and travel throughout the solar system. He had this vision of this Dragon spacecraft, but it was really a very low level of effort until we got the COTS program. Then it was like, “Okay, we have a schedule, we have milestones, we have funding,” which was obviously key as well at the time, being such a small company. That really gave us focus.

I think because it was designed at that time to go to the Space Station and do docking, and having to meet requirements, it definitely changed the design somewhat from what we might have envisioned from purely a SpaceX standpoint. But I think it was still great that it gave us that clear direction of, “Here are the requirements, this is what you need to go meet, this is your mission.” Definitely it allowed us to get focused.

Hackler: It sounds like it was a very intense effort to get that proposal put together. How much time did it take you to do that? Did you have any other role in the proposal process, or was it mostly putting that aspect of it together?

Giger: I was the little fish at the time, so I was really just focused on propulsion. I do remember it was the biggest proposal we had worked on at the time, but it was still lean. Now that I’ve participated in other proposals, and seen the magnitude of documentation that needs to be generated—looking back, it was definitely short and to the point, which is really important and follows the character of the whole COTS program. It was, “Cut out any of the fluff with the contract stuff and the proposal, and really cut to the chase of this is what we want to deliver. This is how we’re going to meet your RFQ [Request for Quote] requirements, and this is what we envision.”

It was really straight and to the point. I’ve gone back and I’ve read it a few times, scavenging ideas for other proposals, and it was a pretty good proposal. I think the whole thing ended up only being maybe about 50 pages or so, but there were lot of iterations, just even conceptual designs. We threw in some CAD [Computer-Aided Design] images, and we had some designers working on the overall architecture of Dragon sitting on top of Falcon 9. Falcon 9 was actually pretty new at the time as well. We originally had a Falcon 5 rocket [with five Merlin engines], and then we realized that for all the different missions we were looking at it made sense to upgrade it to a Falcon 9 [with nine Merlin engines].

I mostly worked on the propulsion system, did a lot of iterations on the schematics, helped with thruster layouts and orientations and number of thrusters, that kind of thing. It was pretty furious across the company, for the small team that was actually working on it, of really trying to put our best foot forward, because we really wanted to win COTS. We thought we had a good architecture and good working environment at SpaceX to really get it done.

Hackler: Did you have any role in meeting with the NASA representatives during the due diligence sessions at all, or any of the negotiations with the Space Act Agreement?

Giger: No, not for the original COTS proposal. Since then I have been, for the new commercial crew stuff, but not originally for COTS.

Hackler: You started working with the Falcon 1 rocket, which had multiple failures before it was able to successfully launch. Can you talk about how you overcame those technical problems, and were able to continue with the COTS agreement?

Giger: Yes, looking back it’s definitely a different perspective than living it real time. I think any engineer that we’ve hired—we hired a lot of young, bright people from the best schools—coming in and working on a program, and really seeing firsthand a launch failure or different anomalies come up is hard. Because you’ve been through school, or had other experiences where you study hard and work hard and want to get an A and want to do the best in class, then you’re like, “Wow, that didn’t quite go as planned.” It was really enlightening, and a learning experience.

Elon and Gwynne, and the whole company—I never got the feeling, never once in a second that there was despair, or that we were going to give up or anything. It was, “We’re going to keep pressing as hard as we can, we’re going to learn from it, and we’re going to get it right.” I think that was really key. I think if there had been any sort of doubt it would have made it really hard for people to continue to push as hard as they did, and might have gotten flustered. It was really, “We’re going to learn from it, we’re going to get down to root cause, and we’re going to work through any issues that come up.”

It was definitely challenging, and it was a lot of long hours, and it was sitting on the edge of your seat a lot of times for that next launch. But I think we really grew up a lot as a company over those few years, and that was the first time we worked as a team. A few people had worked with each other in the past, but it was the first time we had ever built a rocket, and we were learning a lot of things along the way.

We weren’t afraid to have issues. These were all demonstration flights, and we knew them. Some of them had payloads, but they were all with the understanding that these are demonstrations. That’s why we called them demonstration flights. Even working with DARPA [Defense Advanced Research Projects Agency], like we did on the first flight, they fully knew that this was a brand new technology, brand new rocket. We were just going to give it a shot. Try to do it low cost, try to do it in a different way.

I think that was the key part of it, that the expectations were obviously for success, but I think we’re a little bit different. We weren’t just going to sit there and analyze something for years and years and years and years to the nth degree. We were saying, “Hey, we’re going to get as far ahead as we can, as quickly as we can, and then we’re going to find out what’s not working by actually going and testing it.” We did it a little bit differently, but SpaceX was built on “test, test, test, test, test.” We test as we fly. We always say that every day here, “Test as you fly.”

That’s what we learned from Falcon 1, that basically any difference between how you fly the vehicle and how you test it on the ground is where you’re going to have problems. That’s probably the biggest lesson we learned. What we do now is we really try on the spacecraft, and on the launch vehicle side, to test it as close to identical to how you would do it on the launch day as possible.

We do these full, integrated stage tests down in Texas, where we have the full rocket with the same hold-down features, the same hookups to the rocket, the same electrical interfaces, the same flight software, the same ground software. Everything as close as possible to the real thing. We run a full, basically simulated mission, and fire the engines, and run it through the paces. I think that’s why we have been, fortunately, successful since those initial failures. We’ve had a pretty good track record since then. Those are things we learned.

I think all of the vice presidents and all the engineers that saw that really took that to heart. Because even now, we’ll get it in a meeting room, and one of the vice presidents that hasn’t been as directly involved with the task we’re working on, if he sees something that’s like, “Hey, why are you doing it differently than we would do it in flight?” They’ll bring it up, and they’ll get on your case about it and say, “It’s a little bit harder to do it on the ground that way, but we’re going to do it, because that’s where we’re going to have an issue.” I think that’s probably my biggest lesson learned out of those anomalies.

Hackler: When you first started launching, the launches were done out in the Pacific. Can you talk a little bit about the reasons why you started launching from there, and then why you decided to move to Cape Canaveral [Air Force Station, Florida]?

Giger: We had always intended to have multiple launch sites. We had actually originally tried to launch out of Vandenberg [Air Force Base, California], but ran into some scheduling issues there with the Vandenberg range. Being a commercial company, Elon was definitely keen on, “Where can we go that makes it easier from a regulatory aspect, from a schedule aspect, to launch a rocket?” Particularly a new rocket. Kwaj was still an Army base [Ronald Reagan Ballistic Missile Defense Test Site], but being out in the Pacific, there are, in a sense, somewhat looser regulations for getting approval. Then obviously it’s on the equator, which is hugely beneficial from a performance standpoint.

I wasn’t privy to why exactly we chose Kwaj, but I did go out there when it was basically just a small little island with a tent on it, and helped build it up, which was a really cool experience. Literally, we had to get everything we wanted barged in, and took a month to get there, so we became really good at schedule logistics, “How do we ship things there?” We also flew things. We flew rockets on [Boeing] C-17s [Globemaster III aircraft] out there, which was pretty cool. I think we did also realize that because of those logistics it’s difficult to maintain that. The bigger the rocket, the bigger the stuff is, and it just gets to be a bit cumbersome to get it all out to Kwaj and launch it. I think that’s probably one of the big reasons.

Then obviously, working with NASA, we understood that the synergies of launching out of the Cape, with being close to Kennedy Space Center and working with Johnson [Space Center, Houston, Texas]. The history of the [Space] Shuttle Program, and all the other NASA launches out of there—it’s a great location from a strategic standpoint too, for launching to the Space Station. I think that’s what brought us back to the Cape, and fortunately Florida became available from Titan [rocket family retired in 2005], and it’s been a good home for us for about five or six years now.

Hackler: Can you describe your working relationship with NASA? We understand you were the primary interface for the COTS program. How was that different from working with the ISS [International Space Station Program] Office, because you also had to meet their requirements?

Giger: When I transitioned to the lead engineer position in 2009 is when I became the primary interface to COTS. I definitely interacted with Mike [Michael J.] Horkachuck [NASA COTS Project Executive] and Alan [J.] Lindenmoyer [Commercial Crew and Cargo Program Manager] a lot before that for specific milestones, but that’s really the time when it became a very close relationship. We learned a lot from each other I think. Again, like I said initially, the COTS office was very small, which I think was great.

Alan had a really small team under him. It was basically Mike Horkachuck and Warren [P.] Ruemmele and a few others that would come and help us with our milestones, and they would pull on other technical experts as needed. That became more and more and more. The best thing was that Mike knew enough about all the different systems that he could help make judgments quickly, without having to confer with a huge team. He was able to understand the issues we were going through, and digest those and process those, and allow us to keep lean and fast, which I think was a key to the success.

After 2009, Mike and I talked multiple times a week. I gave him status updates on all the developments, and then when milestones came up, there was definitely quite a bit of—I wouldn’t call it negotiation, but clarification of the deliverables for those milestones. The Space Act Agreement, which I think is great—in this type of program, when you’re trying to look at something that spans several years, and you’re trying to lay out milestones, inevitably you’re not going to get them 100 percent right.

You’re not going to know three, four, five years from now exactly what specific deliverable, or how exactly you’re going to meet the intent of the requirement. You know the ultimate goal. You know that you’re going to meet all the requirements, and you’re going to deliver a vehicle. But for any given specific milestone, I think it’s best to leave it a little bit open so that as you get closer, as the vehicle, the design matures, the COT ops [operations] mature, you can really address what are the concerns and what are the key deliverables.

That’s really what it came down to, because luckily the Space Act Agreement was written with really just the high-level key points in there. We had the understanding, and NASA had the understanding, that we’re going to prove to everyone that we’ve matured the design, we’ve done our due diligence. Even though the Space Act Agreement might only call out three or four very specific things, we would come up with lists of dozens or sometimes even hundreds of items that would be delivered to NASA to show completeness, whether it was presentations or analysis or design documentation reports. A lot of my time was spent ensuring that we had fulfilled the requirements on all fronts, in all the departments, that we had provided a complete picture of where we stood.

Then, as we started getting hardware—the first couple years a lot of it was paper and analysis, as it should be. We do development testing of piece parts, but as we really started building up the test vehicles for the C1 and then the C2 mission, we ran into integration problems, as was expected. So we worked a lot with Mike on, “Hey, we tried to put this box in and it didn’t quite fit, we need to adjust something,” or “This harness, one of the pins didn’t work for us and we need to pull the harness out,” and, “We’re getting this weird noise feedback on this one channel.”

Those came up regularly, as expected with new integration. It was good working with Mike, because he was here a lot of the time. Or he at least knew the system very well, so we could just talk quickly and say, “Hey, we’re working through this, we’re going to get back to you when we have a full story.” It was a really good relationship. He’s like, “Okay, thanks. We’ll pull in a couple experts on the NASA side, and then we’ll tag up tomorrow or the next day and debrief and make sure everyone’s good with the plan.” That was good.

Hackler: Is it possible that you can give an example of one of the deliverables that needed clarification, and how the process worked?

Giger: Sure. We had outlined in the Space Act Agreement a Demo [Demonstration] Readiness Review. It was one of the milestones, there was a Demo Readiness Review before each one of the missions. I think the idea behind that milestone was basically to show that we had completed the vehicle, the test article, and were ready to go fly. Some people might call it synonymous with a Flight Readiness Review, but it was done earlier on.

If you read the milestone, it was as high level as that. It was basically, “SpaceX should show that they’re ready to fly, that the Dragon is done, that the launch vehicle’s finished.” But there’s a lot that goes into that. How do you prove that? Mike and I sat down for several weeks and broke that down into, “Okay, let’s take Dragon, and let’s take Falcon 9. On Dragon, what do we think would be needed to show completeness?” We’d go through each subsystem: avionics, propulsion, structures. We have all these components in propulsion, like engines and propellant tanks and valves, and we’re going to show qualification for each one of those.

That was a fairly obvious one, but we came up with a list of 100-plus items. We’re going to show acceptance testing for each one of those components that are actually on the vehicle, to show that they’re flightworthy. Then we’re going to show analysis that backs up our testing, of we tested it to this level, but why did we think that level’s good. It’s structural analysis, [technical] memos, CFD [Computational Fluid Dynamics] memos for fluids, and then more test results as well. A lot of it was test results that we did. We ended up coming up with a list for the C1 mission. For the Demo Readiness Review, I think there was 300 items on the list.

So from a half-page Space Act Agreement milestone, we knew that SpaceX had to show completeness to be ready to fly. We thought it was imperative that we do that. NASA had the same agreement, but it was “These are what we think are necessary,” and not, “Oh, we just have a list of documents and we’re going to generate documentation for the sake of documentation.” It was always, “We need this documentation, because both sides, SpaceX and NASA, think that it’s value added.” It actually proves that we are verifying the design, or showing that the design meets safety intents, or meets mission intents. That was, I think, a good thing we did.

Hackler: In the original Space Act Agreement there were three demonstration missions for the Dragon, and the last two later were condensed into one. Can you talk about the process, from your point of view, and how you worked with NASA to make that possible?

Giger: NASA was great for being open to the idea, and I wouldn’t say it was combining the missions. The idea was we knew C1 was going to be considerably different than both the C2 and the C3 missions. C1 was designed to be single string everything. Zero fault tolerant, which was not the intent of the Dragon right now. It was really to prove out a lot of things, like the thermal protection system and communications. Really just fly a spacecraft for the first time, more than a ten minute rocket launch mission, and it was hugely valuable in that sense.

We knew that we were going to make pretty considerable changes between C1 and C2. The idea was always to make C2 and C3 virtually identical from a hardware perspective, because we were really going to prove that Dragon’s ready to go to the Space Station, and obviously you can’t make big changes between those two. As we got into it we realized if we’re going to build basically a complete Dragon, and go two and a half kilometers below the Space Station, and establish bidirectional communications, and actually work with the astronauts, work with the Mission Operations Directorate at NASA—if everything’s going well, and we’re meeting the C2 objectives, let’s be open to the opportunity of continuing on potentially.

It wasn’t necessarily combining. It was like, “Let’s go do the C2 mission. If everything’s great, and we have a perfectly healthy spacecraft up there, let’s press further.” I think Alan Lindenmoyer liked that idea, because it gets you to your goal, and it gets you there sooner. If there are problems, we would ensure that we were always safe. If we did the C2 objectives, and we said, “Now we’re going to start getting closer to the Space Station,” and then we had an issue with our proximity sensor or whatever, we could always safely get away. But we would have learned that on that mission, versus going to a whole ’nother mission and getting all the way there and then saying, “Oh, now we still have a problem.”

We really presented it, “Hey, it’s a risk-reduction measure.” We were never saying, “We don’t want to do the C3 mission.” It was, “Let’s try to see how far we can get,” because just like on the ground where it’s test as you fly, the further you get or the closer you get to the final objective, the more rocks you’re going to upturn and the more issues you’re going to work through. We knew that going in, and fortunately we did pretty well. So we went through all the C2 objectives, and then obviously got to the Space Station.

Had some issues that came up with our proximity sensors, but worked through them real time. Both sides understood the vehicle so well that when we said, “We’re going to make these adjustments to flight software so that our LIDARs [Light Detection and Ranging] and thermal imagers change their algorithms slightly,” everyone understood that, and we were able to do it real time. Just like I said, I think when you first outline the Space Act Agreement with the milestones, you might not think through all the permutations and possibilities. A few years in we realized, “Hey, if we’re building the same spacecraft for C2 and C3, let’s take advantage of that opportunity to go as far as we can. Ensure we’re safe doing it, but take advantage of that.”

Hackler: Because you were going to the Space Station, you had to meet the ISS visiting vehicle requirements. Can you talk about how you worked with the ISS Program Office, and what sort of changes did you have to make to the vehicle in order to meet those requirements?

Giger: Fortunately we had access to the SSP [Space Station Program] 50808, which are the visiting vehicle requirements, early on in our development. We were able to keep those in mind throughout our development, but really the engagement with ISS picked up right around the time I took over in 2009, as we were starting to really flesh out verifications. A lot of what we did was take each one of those requirements, and you actually need to write out how do you meet the intent of that requirement, whether it’s through analysis or test or inspection.

We spent a lot of time working with Kathy [Kathyrn L.] Lueders and Angela [T.] Hart and her teams, going through each one of those requirements and saying, “If it says that the vehicle would be two-fault tolerant”—that’s a big overarching one—“how do you prove that?” We’d come up with multiple different tests or documentations where we would show that.

There were things that definitely drove some changes, sometimes even late in the game. One of the things we didn’t really have to deal with before—if you’re flying your own rocket, away from a space station, we didn’t have to deal with electromagnetic interference as much. Because the Space Station has a lot of different antennas on it, it radiates a lot of different things. Dragon, conversely, does the same thing. We had to go through this pretty new test for us to show that we wouldn’t interfere with anything on the Space Station and cause issues on their side, and vice-versa. We actually found a few things that we needed to correct after that. Do some additional shielding and modify some components slightly to ensure that both sides weren’t going to be affected by that. That was an interesting change that we did.

The other one was the bidirectional communications with the Space Station. That was something new. There were some existing systems out there, but early on we came up with this idea of CUCU, which is the COTS UHF [Ultra High Frequency] Communications Unit. That was the first piece of hardware we put on Space Station, which was really exciting. I think we did that in 2009. We went up on the Shuttle, and we designed both sides of the system.

We used antennas on the Space Station, but we designed our own avionics box to control and power that, and then we had the paired box on Dragon. Putting that up there, and checking it out, and then really crossing your fingers when Dragon got there for the first time, “Are we going to get data? Is it going to communicate? Is all the analysis going to match up?” It was a big change we had to put in there and accommodate for ISS, and it worked out really great, and we’re using it all the time now.

Hackler: In addition to NASA, we understand that other federal agencies were also involved, like the FAA [Federal Aviation Administration] or the FCC [Federal Communications Commission]. Did you have any role in communicating or negotiating with them?

Giger: A little bit, yes, particularly late in the game with the FCC. C1 was fairly basic, it only had an S-band system on it. Then with C2 we had CUCU, which is a UHF system, as well as S-band. We had S-band going to the ground, as well as up through the TDRSS [Tracking and Data Relay Satellite System] satellite constellation, so there was quite a bit of back and forth between what exact frequency are we going to use. I think we changed it a half-dozen times actually, because we could only radiate at certain frequencies so we’re not interfering, then at certain power levels as well. We ended up coming up with operational workarounds to ensure that we were only radiating away from Earth.

That was interesting, because being a commercial provider, getting those additional approvals where if you’re doing a government launch can sometimes be waived, or is just taken care of by the government. It was interesting working with those agencies, and I think it was new for them too. The FAA—we were the first ones to ever get a reentry license. They’d never done that before. Working through, “We’re going to show you that we’re going to land within this rectangular box in the Pacific,” and prove to them that we could control Dragon in the way that we wouldn’t impact land or impact anywhere that was habitated was a long process.

We worked a lot with our [Washington] DC office to talk to them directly in multiple analyses, but they were very involved with all of our reviews along the way. Which I think was good. Now that we’ve gone through it, it should hopefully go a lot smoother. I think we were sort of the guinea pigs, trailblazing for this new type of approach. So there was definitely a few bumps in the road, but I think ultimately now we’ve gotten through to a process where it’s making similar endeavors, just like we’re doing with crew now, a little more straightforward.

Hackler: Overall, how much, in your opinion, do you feel like working with NASA has impacted the design of your vehicles, and even the structure of your company, because you have to meet their requirements?

Giger: I think it’s been both-sided, in the sense that SpaceX has changed somewhat because of NASA, and NASA has changed somewhat because of SpaceX. Before the COTS program, SpaceX—it was a much younger company at the time, and operated more free-form than NASA. NASA at the time was very used to cost-plus contracts, and very detailed oversight and insight of the contractors. I think it was a learning experience on both sides. NASA learned from us that there might be alternative ways to approach the same problem. Like I said, SpaceX is very key on “test as you fly.” Do a lot of testing, don’t necessarily analyze everything to the nth degree. We’d rather just go test it and get actual data. That, I think, took a little while for NASA to get accustomed to.

At the same time, I think SpaceX learned that we need to be more rigorous about how we document issues that we come across, and make sure we’re fully getting to root cause, and reflecting that back into the design. I think they definitely helped our quality process, our mission assurance process. How we look back and review all the issues we have along the way was probably the biggest impact I see from a process standpoint.

From a design standpoint, I think it was really driven by the requirements, which inherently made us add things or change things differently than we might’ve if we weren’t going to the Space Station. Overall, I think the Space Act did allow for a lot of flexibility to SpaceX, to all the participants in COTS, to have a flexible design. Which was nice, and I think was very important to SpaceX as well.

Hackler: Did NASA share any technological types of lessons learned that influenced your vehicle?

Giger: Yes, Mike Horkachuck and Warren Ruemmele were very good about looking at our system, seeing how it was similar or dissimilar to Shuttle, Apollo, Mercury, Gemini, any other program in history, and trying to share those lessons learned. For example, parachutes. We were able to get a lot of data from the Apollo Program, from the Orion Program even, and leverage lessons learned from them on that.

A lot of joint technologies, too. We learned about PICA, Phenolic Impregnated Carbon Ablator tiles that we use on our heat shield, which was originally developed in conjunction with NASA. We learned a lot from how they did that, and they helped us bring that technology in house, which was great. Now we build our own variant of that in-house. There were numerous kinds of examples of that, where they shared technology or lessons learned that we then either incorporated in the design, or took that technology to the next level here, which was great.

Hackler: What sort of role do you see for commercial spaceflight in the future? Specifically, one goal of the COTS program was to help instigate commercial markets. Do you see SpaceX working a lot more with NASA, or what sort of other markets have you been able to enter or open up as a result of this partnership?

Giger: I’ll probably let Gwynne Shotwell comment more on this, but NASA really was a trailblazer when it came to this, and I think it was really important to get this commercial venture underway. If you look back at other technologies such as the internet and email and things like that that were originally started by the government, I think there was a lot of value to at some point enabling that technology in the commercial arena.

You can come up with things like Google and Facebook and Twitter, Dell [Inc.] computers, and all those great things. I’m hoping we’re going through maybe a similar paradigm in space. It was government for 50, 60 years, and now we’re saying, “Let’s see if we can do this in a new approach, in a lower-cost approach, while still maintaining safety and reliability,” and then maybe even introduce new technology along the way by bringing in fresh, new approaches.

We have a lot of people now at SpaceX from the automotive industry, and airlines and aircraft, and civil engineering, and from all different arenas. I think by cultivating a mixed environment here, you end up getting the best of all the different worlds, and ultimately making a better product. I think NASA will continue to be a leader in pushing commercial to allow NASA to continue to focus on great, new technology, but then also partnering with industry and commercial providers to see what new ideas we have out there, and to provide a continuing service to them.

On our side, it’s definitely opened up new avenues. I mentioned that we had concepts of Dragon early on, and now that we have a version of Dragon we are interested in marketing other versions of Dragon. We have the DragonLab Program, which is a variant on Dragon where we’re looking at keeping Dragon in space for scientific research for extended periods of time. We definitely have had discussions with Bigelow Aerospace and other commercial providers that are interested in Dragon or a Dragon variant to fulfill their needs for commercial ventures. I think by NASA enabling the technology, it’s opened a lot of new business ideas, and it’s just great for the industry overall to open up new possibilities.

Hackler: We have just a few minutes left before our time allotted for today is over. I wanted to ask Rebecca Wright if she had questions.

Wright: I just have one. The SAAs allowed such flexibility, but what would you think is the biggest challenge of this project, of doing this new form of business?

Giger: I think it goes back to making sure that people have the right mentality on both sides, that people are open to doing a different way of business or taking a different approach, and aren’t necessarily stuck on, “Just because we’ve done this in the past, it’s the right way to do it.” I think what made COTS successful was having the team of Alan Lindenmoyer and Mike Horkachuck, and all the people that worked under COTS, coupled with the people on our side at SpaceX, having that approach to being open to changes or different ideas.

I think if you don’t have that, that could be a big road block. Like you said, the SAA is flexible, but it can also be constraining at the same time because of flexibility. You could get into a situation where both sides don’t agree on how to proceed with a milestone, or fulfilling expectations, and that could easily cause a kind of stalemate, I think. It’s pretty important to have a good working relationship on both sides to ensure that you can meet the objective while not getting bogged down in any sort of bureaucracy or paperwork exercise.

Wright: You had these milestones, so you had somewhat a constraint of a schedule. Did you find that you found yourself having to build a schedule for working with the COTS expectations, whereas maybe before if you were just developing on its own you would not have?

Giger: I personally think it was good. I think it motivated us in a higher extent than pure internal motivation. Because yes, there was money attached with each milestone, which was important to our company, and it really kept us focused. “Hey, next month or next quarter we have these milestones coming up.” As I stepped in the lead position, really every day I was thinking about what do we need to accomplish today so we stay on schedule, and if not, how do we get back on track and fix the problems we’re having? I think having the milestones, the intermediate milestones, was actually a really good driver to keep us going forward, and keep us on track for the ultimate goal.

Hackler: Thank you very much for your time this morning.

Giger: Sure, thanks for having me.

Wright: Appreciate it.

[End of interview]

Return to JSC Oral History Website