NASA Johnson Space Center
Oral History Project
Commercial Crew & Cargo Program Office
Edited Oral History Transcript
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
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?
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.
That’s really exciting to be able to work on it right out of
school, and get started with something right away.
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
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
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.
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?
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.
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?
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
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.
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?
No, not for the original COTS proposal. Since then I have been, for
the new commercial crew stuff, but not originally for COTS.
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?
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.
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]?
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.
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?
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
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.
Is it possible that you can give an example of one of the deliverables
that needed clarification, and how the process worked?
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
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
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.
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?
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.”
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?
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.
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?
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
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?
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.
Did NASA share any technological types of lessons learned that influenced
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.
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?
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,
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.
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.
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?
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
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
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?
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
Thank you very much for your time this morning.
Sure, thanks for having me.
to JSC Oral History Website