1

Tom Hoffman

August 1, 2022

Erik M. Conway,

Interviewer

Q: This is Erik Conway. I’m interviewing Tom Hoffman, and we’re both working from home 

today in various places in L.A.

So, Tom, tell me where you were born and how you were educated.

Hoffman: I’m a native Californian. I grew up in Northern California and went to the University 

of California, Berkeley, so UC Berkeley. When I graduated from college, I had originally 

planned to go work in what was the very beginnings of Silicon Valley, but for a variety of 

reasons, I ended up down in the Pasadena area and I got a job initially working as a contactor at 

JPL supporting the Voyager Neptune encounter. Really what I was doing was doing flight 

software testing of the interstellar load, but I was doing operational support, which is a great 

experience because I had watched, as a kid, all the different images coming back from Voyager, 

then to be on the project and to have a super exciting encounter with Neptune. Uranus was kind 

of not super exciting. It was kind of smoggy-looking and it had some interesting science features, 

but from a public perspective, maybe not the most exciting planet. But then Neptune ended up 

being much more like a Jupiter or Saturn, it had a blue spot, and it really just kind of solidified to 

me that I really liked space, I wanted to do whatever I could to bring back more science, bring 

back more knowledge to people.
2

So I ended up moving from being a contractor to JPL employee after a couple of years, 

and then I started working I&T [Integration and Test] roles. I worked a Discovery mission, one 

of the early ones, Discovery 4, which was Stardust. I worked that with Lockheed Martin as 

avionics systems lead. Worked a couple of other missions, including MER, I worked Cassini for 

a little while, but then eventually I ended up on GRAIL. I started out on GRAIL in the Step 2 

portion of that as the flight system manager and eventually became the flight system manager 

and the deputy project manager over the course of that mission.

So, prior to that, I’d pretty much worked about two or three years on each project, and 

then kind of got bored and moved on. At that point in my career, it was by far the longest I ever 

stayed on a project. I was on that for about five years, so good experience. So I haven’t really 

ever done any real work because I’ve always been at JPL. [laughter] Someday I’ll figure out 

what it is I’m going to go off and do, but I’ve been here, I guess, about thirty-four years, so it’s 

been a while.

Q: So you came for Voyager Neptune. That’s 1989. You became an employee around ’91, ’92?

Hoffman: Yeah, ’91, September 2nd of 1991.

Q: And you remember the exact date. [Hoffman laughs.] That’s good. I guess I’m kind of that 

way too. [laughs] So you worked at a Discovery mission before. You were on Stardust as the 

avionics lead.

Hoffman: Right.
3

Q: I’m also working on the next volume of JPL history, so that brings an obvious question to my 

mind, and that is what changes, because Stardust is one of the early “faster, better, cheaper” 

projects, and then we kind of abandon all that and implement the flight project practices and 

design principles. So what changed from that perspective for you, from that kind of deck-plates

level?

Hoffman: It was kind of interesting for me to witness the “faster, better, cheaper,” because I 

know that was the mantra of that time, and while Stardust was being developed, we were about, I 

think, roughly six months, maybe nine months behind Mars Polar Lander and Mars Climate 

Orbiter. They were also being both developed at Lockheed Martin, similar team, similar 

avionics, similar software. Lockheed Martin basically had a product line that they were moving 

through, even though the spacecrafts were different. A lander’s obviously different than a comet 

sample return mission. A lot of the core functions in avionics look the same.

I came on to the project just before CDR, so pretty late in the development effort. I think 

that was largely because my background at that point had been I&T. The person who had been 

doing the job moved off to a different role on a different project, so they brought me in to sort of 

finish that up through launch, so I was actually on that for about—I think I came in in ’97-ish, 

and it launched in ’99. So I did get to experience what was “faster, better, cheaper,” because I 

had, previous to that, worked Cassini, which is definitely not “faster, better, cheaper.” [laughter]

It was better, but not faster or cheaper. Then I worked on a mission called SeaWinds, which 

ended up delivering like five different boxes. It became Rapid SCAT SeaWinds and, I think, 
4

QuickSCAT. But, anyway, that was also not “faster, better, cheaper.” That was more of a 

traditional by-the-book JPL development for an instrument.

So it was very eye-opening to me to see what was going on in terms of the activities for 

both MPL, MCO, and also Stardust. And to the credit, I think, of our project systems engineer, 

Rick Grammier, I think maybe one of the very first project systems engineers—that was a new 

concept at JPL at that time—and the project manager, Ken Atkins, I think really Rick brought a 

few of us on that had Cassini experience, so we knew what maybe the right thing to do was, but I 

think we provided more insight into what was going on in terms of the avionics and flight 

software in some ways than the Mars folks did, because they were really pushed for budget 

pressure and we didn’t have that much more budget, but it seems like we had a little bit more 

time available to spend a little bit more time reviewing stuff, trying to make sure that things were 

right. So we asked a lot more questions and we got, I think, a little bit more support. Even though 

we were still “faster, better, cheaper,” I think we had a little bit more ability to dig into some 

areas, which is, I think, why we ended up being successful.

Q: I was curious, because it sounds like you’re involved kind of right at that key set of moments, 

as well as being in kind of the right places to have some overview of it all, and presumably 

knowledge that you brought into your future projects.

Hoffman: Yeah, and one of the things I learned really from that experience is, it was surprising 

to me the way that they ran reviews on MPL and MCO. It was more they wanted to get through 

the gate than to actually make sure that they got through the gate with the right design and right 

questions answered and the right input, because I remember distinctively a few times being at 
5

some of the reviews, because, again, they were using a lot of the same avionics, C&DH 

[Command and Data Handling] and a lot of the components were the same, so I sat in on the 

reviews, and being a good JPL person, I was asking lots of questions. And I was basically pulled 

aside at one point and told, “Stop asking questions. If you do, we’re going to disinvite you from 

the review,” which to me was like I couldn’t understand that, because I thought that was the 

point of the review. As it turns out, that is the point of a review. [laughs] But it was very eyeopening to me. It opened my eyes up to the fact that really what they’re trying to do is launch on 

time, and that was it, period. They had such a feeling that they had the right design, that they 

didn’t seem like they needed a push to get the right questions answered. And this was both the

JPL and the Lockheed Martin folks.

So part of what we had to do on Stardust was to kind of reset that mentality of “We’re 

going to ask questions and you’re going to have to answer them.” It was very interesting.

To follow on that theme, but after MPL and MCO failed, Lockheed Martin, as a 

corporation, basically did a reset and they really did some soul-searching and figured out that 

what they needed to do is essentially become a lot more, from a design standpoint and from 

digging in and really doing the right kinds of things, they became a lot more like JPL than they 

had been as they went into the MRO, because they had to compete on that. I actually worked on 

the Source Evaluation Board for MRO, and there was a strong competition, and I think Lockheed 

Martin knew they needed to win that competition or they had a pretty good chance they wouldn’t 

be getting the next set of Mars missions, so they really put a lot of effort into trying to win that, 

and they put a lot of effort in showing that they had learned lessons from previous missions.

They’d also had the Genesis kind of a failure, too, when they put the switch in backwards, which 

that was actually a very similar capsule that Stardust used, but for some reason they just put the 
6

switch in backwards. So having had essentially three failures in their most recent missions, and 

Stardust had yet to come back to Earth, right, so their track record wasn’t great, so they really put 

a lot of effort into changing their culture away from a “faster, better, cheaper” corporate-profit 

culture. I think today that quality first culture still prevails within their corporation, at least that 

part of it, they’re much more interested in making sure that things work than maybe worrying 

about making the highest profit, which I think, in the end, probably gets them more work and 

they get more profit. [laughs]

Q: I was recently reading the Genesis Failure Review Board reports, and, unfortunately, they 

don’t really explain how the drawings got reversed, so I guess I’ll never know the answer to that. 

Maybe they didn’t either. I had been under the misapprehension that they had installed the parts 

backwards, when the drawings were actually wrong.

Hoffman: Yeah.

Q: But that’s really interesting. Thank you for that. It’s good to hear that there was some soulsearching at Lockheed afterwards.

Hoffman: Yeah. I mean, both JPL and Lockheed Martin did soul-searching and, I think, realized 

that every mission’s unique enough that you have to treat it as a unique mission. You have to ask 

the same questions again, unless you’re just pumping out the same exact satellite, satellite after 

satellite, and there’s companies that are very successful at that, can become low cost, but all of 

our missions are so different, even if they’re going to the same destination, even using some of 
7

the same heritage, you have different instruments, you’ve got different software behaviors. You 

have to treat it as if it’s a new thing, ask all the same questions, maybe you get all the answers 

that you expect, but probably somewhere in there, you’re going to get an answer that’s different, 

and you go, “Ah! Okay. I really do need to dig in and look at this to make sure it’s going to work 

the way that we want it to work so we can get the science back that we need.”

Q: Thank you. So let’s get back to GRAIL, then. You came on, you said, at the Step 2 proposal, 

is that right?

Hoffman: Yeah. Maria Zuber was the PI. She had gotten through Step 1, so I think she was—

typically you’re competing against twelve or fifteen or seventeen different ones. I can’t 

remember how many there were, but she had run the first gauntlet of having great science, which 

is the first step for Step 1, and we were competing against two other missions. I can’t actually

remember what they are right now, but two other concepts. So they brought me on in Step 2. 

That’s when you typically staff up, because as you know, having done a bunch of Discovery

reviews, the whole point of Step 2 is to show that you can implement it, to show that you have a 

low-risk implementation, you’re going to make your schedule, you’re going to keep within the 

cost, the managed cost, and you have to prove that without having changed any science. So for 

me, that was the first time actually I’d ever worked—well, on MRO I had done an evaluation of 

a proposal and I’d helped write a little bit of the spec-up from an avionics standpoint, but I’d 

never been on the other side proposing, so that was my first exposure to, like, a proposal

response to an AO-type activity, and it was very interesting. I only worked maybe a quarter time 

or something, but it was fascinating to me how that whole process worked, developing the 
8

proposal and then preparing for the site visit, conducting the site visit, and then waiting [laughs] 

and waiting and waiting to get a response back. Luckily, it was positive for us. So, yeah, it was 

fun. It was so much fun, I ended up doing it again later, but we can talk about that later.

Q: So what decisions had been made when you came on? Had Lockheed been chosen yet, for 

example?

Hoffman: Yeah.

Q: What kinds of major decisions had been made?

Hoffman: Yeah, Lockheed Martin had been chosen at the main partner supplying the spacecraft

that was based off one of their DOD spacecraft. It was DOD, the XSS-11, so we knew a little bit 

about it, but we didn’t know too much about it. It was an agency that would allow us to know 

something about the spacecraft, and that was the basis, because GRAIL basically was the same 

concept as GRACE. It was GRACE at the Moon. But the big difference in the significant 

difficulty that we had is GRACE, GRACE Follow-On, and the like, they basically used GPS, and 

there’s obviously no GPS at the Moon. So we had to recreate the concept of GPS, the precision

timing that’s the basis of GPS. The way that we did that was we actually had to build a laser, we 

shot a laser between the two spacecraft, and that gave us our time synchronization and location, 

precise location of the—relative location of the spacecraft. That was kind of the new thing for 

the mission. Other than that, we just had to have a really stable platform for detecting the 

gravitation on the Moon.
9

So one of the concepts I had when I came on is I wanted to make it clear with the 

spacecraft—because knowing Lockheed Martin the way I did, I know that they are kind of like 

“the spacecraft’s what you do and the instruments just get bolted on, and if one or two of them 

don’t work, well, you know, so be it.” Basically I talked with the project manager and the lead 

systems engineer and said, “This is a spacecraft accommodation mission. It’s not a payload 

accommodation. The spacecraft has to do whatever the payload wants to do, not the other way 

around.” And it took probably a solid year for them to wrap their heads around it and realize that 

I actually meant that, because the way the mission was constructed, I was actually the flight 

system manager and the payload was underneath me, which I thought was actually really a smart 

move by the project manager from the get-go to do that, because it is just a single payload. So 

from that standpoint, I just pushed on them, and it came around to them finally understanding 

that concept of really the spacecraft is the instrument. It really is the instrument, and you need to 

make sure that it does exactly what an instrument would do. It’s not your traditional spacecraft. 

So from that standpoint, it was a very interesting experience.

But to get back to your original question, pretty much all the partners were chosen. There 

weren’t a lot of partners. There weren’t any foreign partners, which was on purpose. Maria had 

done a good job getting a strong set of science folks together to support the mission, and I think 

we picked a capable spacecraft provider, and they picked Sally Ride to do the EPO, so it was 

really a strong team from that standpoint. With the heritage that they had to this XSS-11 bus, is 

what they called it, they had a pretty good concept for a small dishwasher-size spacecraft, two of 

them, two small dishwasher-size spacecraft, and we had a lot of excess capability even on a 

Delta. So it was a strong concept. It fit well underneath the cost cap with good margins. We had 

lots of challenges along the way, but it work out generally pretty well. 
10

Everything was well-defined when it came on, even in Step 2, and really in Step 2 we just 

kind of ended up clarifying what it was we wanted to do. Then as we got into Phase B, we had to 

make some changes, but that was within the ability of what we had from a cost and schedule

standpoint to do, and it’s not at all atypical for any mission, frankly.

Q: You mentioned changes. I understand from “Hoppy” Price that Duncan McPherson did some 

rework on the spacecraft at some point, which sounded to me a lot like what you were saying 

about having to make the spacecraft accommodate the instrument instead of the other way 

around.

Hoffman: Right.

Q: So talk a little bit about that.

Hoffman: So, first off, Duncan McPherson, I had actually worked with him all the way back on 

Stardust. We had had a propulsion kind of issue with the way that we were doing unbalanced 

thrusters, and over the course of a really long mission, that was kind of an issue, and we had 

some other propulsion-related stuff. Duncan had come in and really helped us with an 

independent review and some redesign and sort of reset us to a much better state. So I knew 

Duncan coming into the project, I knew his capabilities, but what I didn’t fully appreciate is 

Duncan’s probably the smartest person I’ve ever met. He was absolutely amazing. He has a very 

rich history and wrote a book on ballistics. I would relish having discussions with him at any 
11

point in time. He was a little bit curmudgeonly, but he always was working really hard to make 

sure the thing worked. So we got to know each other really well, got along really well.

So Duncan and myself and then Ralph Roncoli, who, if you haven’t talked to, you might 

want to, basically the three of us, over the course of the project, worked a lot on sort of the 

mission concepts. Ralph’s in mission design. He’s brilliant too. But we kind of worked on the 

concept to make sure that we could get back the science, and we kind of figured out around the 

point of the PDR how we could get an extended mission, even though we didn’t tell our PI. 

[laughs] We kind of figured out, “Oh, we can do this. If things break just the right way, we can 

probably get an extended mission,” which we ended up getting.

But one of the things that we had to do—and Duncan was the lead person—was one of 

the big perturbances on the spacecraft was solar pressure. These are really small. The issue was 

you could account for solar pressure if it was kind of a constant, better than if it was moving 

around differentially, and the best way to make it a constant was to create a perfectly flat surface 

between the spacecraft and the articulated solar arrays. In the original version of the spacecraft, 

there was lots of gaps, because that’s the way you would normally do it. It’s safer. You don’t 

have to worry about anything getting caught or the way that things articulate if there’s lots of 

motion around. Then it’s just easier, and that’s their traditional way of doing it at Lockheed 

Martin.

So one of the bigger fights—I’ll say fights—that we had with Lockheed Martin and, in 

particular, Tim Gaspirini [phonetic], who was the chief engineer for the project, is to get the 

spacecraft to be as perfectly flat on the solar side as possible and to get things tucked away 

underneath it so that when we’re in our normal mode, we weren’t having little things that could 

poke out and create just a tiny torque. Even if, like, the star tracker’s sticking out just a little bit 
12

and getting just a tiny solar incidence angle on it, it’ll torque the spacecraft just, you know, 

nanometers, but that’s all that mattered for our measurement to kind of get screwed up.

So between Duncan and myself, Duncan, from a technical intellectual standpoint having 

discussions, and me from a contractual standpoint having discussions, we finally convinced them 

that they needed to make some configuration changes. Duncan convinced them technically and I 

convinced them from a contract standpoint. It’s not going to cost them that much money to just 

do it. And in the end, they really understood and had an appreciation for what it is we were 

trying to do and why. So Duncan spent a lot of time talking over the “why,” and I think it was 

kind of a hard concept to understand, that just a nanometer can screw stuff up, because that’s not 

usually what spacecraft guys think about. Instrument guys, sometimes, but, again, reference back 

to the fact the spacecraft was the instrument. [laughs] So once they finally got that concept, they 

really embraced it and, I think, worked hard to make sure that everything that we needed them to 

do they ended up doing. So it was good. It was good. But, yeah, Duncan was great.

Q: You mentioned having to work the contract on that score. So the first question I wrote down 

is, how was the contract with Lockheed structured?

Hoffman: It was our typical contract of a cost-plus-incentive fee, so the Phase B contract was 

cost-plus-fixed fee. The Phase C contract was cost-plus-incentive fee, and I purposely put in 

there some on-orbit incentives for them, largely for the exact reason I just talked about. I wanted 

them to be sure that they built the spacecraft to be able to get the science back, so I can’t 

remember exactly what all the percentages were, but a fair amount of it was for on-orbit 

incentives, and that was directed towards getting back. . .what they want is the Love number, 
13

which is the science number, but getting that back to a certain quality was a big part of what they 

ended up getting from a fee standpoint.

Then there was cost and schedule, was the other part, and they hit all of them. They 

ended up getting all of their fee because they came in basically, I think, approximately on cost, 

certainly made the schedule, and the science was great. Now, they had some really bad [laughs] 

technical problems, but they ended up making it in the end.

Q: They had technical challenges. One of my later questions was, what were your challenges?

Hoffman: So the biggest kind of esoteric one was what we just talked about, which was trying to 

get the spacecraft to be the instrument and to have it be predictable, I’ll say. It didn’t have to be 

perfect; it just had to be perfectly predictable in terms of how it would react to solar pressure, so 

that you could get all of the noise sources. That was the biggest one, but there were a bunch of 

other noise sources. You had to get those out so that you could get the signal, which is just the 

little tiny changes in speed that the spacecraft would go through as they hit larger and smaller 

mass concentrations on the surface. So that was number one, and that was probably the hardest 

thing to convey. It took me a while to figure it out, so it’s not surprising that other people would 

take a while. That was number one.

I think from a technical standpoint, we had to make several small changes, I’ll say, to the 

spacecraft, but the biggest—we had two big issues. The first was we were going through design

development at the same time as Juno, so there was a little bit of pressure on workforce at 

Lockheed Martin and facilities at Lockheed Martin, but that all ended up getting sorted out.
14

The other thing that was happening is they were in the process of combining the 

Lockheed Martin facility at Sunnyvale. They were bringing people in from that area into Denver, 

and then they were also combining the assembly facility for electronics devices, which was in the 

South. I can’t remember what—maybe it was Georgia. Anyway, somewhere in the South, and 

they brought that all into Lockheed Martin-Denver. So there was a fair amount of influx of 

systems engineering and flight software people coming in, a slightly different culture, because

they had mostly done commercial satellites up in the Bay Area from Sunnyvale, and then they 

were trying to consolidate their manufacturing for electronics in Denver at the same time. So 

they had these two sort of corporate issues. Bringing the people in from Sunnyvale, a lot of 

people at Lockheed Martin-Denver groused about, but that didn’t end up being a particular 

problem, I’ll say. It was just kind of a cultural issue that sometimes came up, but basically that 

didn’t result in any technical issues.

But trying to create a new manufacturing facility was a big problem, so both Juno and 

GRAIL, we had a large problem getting our boards built specifically for the C&DH. We had all 

kinds of board problems, then we had some parts problems, we had assembly problems. We had 

to put tiger teams on for both of the projects to work through that, and on top of that, we had all 

the typical kind of parts problems that you would have. But the biggest was, we were really the 

first two, I believe, NASA projects to go through the manufacturing there in Denver, and so 

because of that, I think Juno got their C&DH delivered to them at the Cape, and we got ours 

delivered—because they launched, I think, August 5th, I’ll say was the date that they launched, 

and we launched just a little over a month later on September 10th of 2011. So they got theirs 

delivered basically at the Cape. We got ours delivered—the second one got delivered, I think at 

the Cape. The first one had gotten delivered just before it shipped. So we were a little bit ahead 
15

of them. But that was probably the number one problem for both of the projects right up just 

about until launch.

Realistically, though, probably about March or April, I think, we had turned the corner, 

so maybe six months, five, six months out, we had kind of turned the corner and it looked like 

we had good boards and it was getting everything through the test program, the functional tests, 

all the environmental tests, penalty tests. So that was kind of in good shape, a lot being four or 

five months before launch. [laughs] But it was pretty stressful leading up to that, more so for 

Juno because with GRAIL, we could launch a pretty good amount of time about every six 

months. Juno, of course, going to Jupiter, has a much different planetary issue.

The other issue that was unique to GRAIL that really caused a lot of issues was our 

reaction wheels. On each of the spacecraft we had four reaction wheels, and we wanted to have a 

couple of spares, so we were trying to get ten reaction wheels, and remember this is a 

dishwasher-sized spacecraft, so these were small reaction wheels being built by what used to be 

Ithaca and it was Goodrich, and now it’s been bought yet by somebody else, but it was in Ithaca, 

New York.

So we started getting some indications there were issues when they started trying to 

deliver EMs to us, and for whatever reason, they just weren’t particularly stable, and in good JPL

fashion, we had a couple of reviews, then we quickly realized there’s a big problem. We already 

knew the reaction wheels are always a big problem, but I can’t remember, there was some failure 

that was going on at the time.. There was some other issue that was going on on the spacecraft, 

Odyssey, maybe, that was making us worry to begin with.

So we ended up really digging in. I got a bunch of mechanisms experts to go over to 

Ithaca. I went there probably every month, a couple times a month sometimes, to visit with the 
16

project manager and make sure we were getting good progress there. We had a lot of pushback 

initially, as we usually do, but over time, we actually fundamentally figured out what their 

problem was. It took us probably six to nine months, but it came down to something incredibly 

simple, because we had run a bunch of different things and we thought there were all these exotic 

issues, and we thought maybe there was some kind of problem with the control loop they were 

using. It came down simply to they weren’t putting the proper pre-load on a bunch of their 

fasteners. So they essentially were either over-tightening or under-tightening them, and they 

didn’t have a consistent procedure for when they would tighten things to a certain level and have 

a certain range that they tightened it to. Lo and behold, once we figured that out, there were a 

couple of other real minor issues, but that was, like, by far their biggest issue. So we started 

instituting that change and we started getting successful tests, everybody felt good.

The problem then became we had to get ten reaction wheels through the entire build and 

test program and delivered, and those were kind of in the bowels of the spacecraft, so that was 

competing with the C&DH delivery as, like, the number one problem. So the flight units

[00:34:49] were getting delivered almost the same time as the C&DH, so we had these two major 

pieces that were coming in quite late. The reaction wheels was probably a little bit more scary 

because we were pretty darn sure we fixed the problem, but until you actually test them 

individually, you have a hard time knowing if they’re perfect. So it was a little nerve-racking 

right towards the end, but it all came together. The interesting thing is I’m pretty sure that some 

of the issues that company had had on previous reaction wheels probably had to do with them 

not properly pre-loading, because that was the first time they ever did it, and I think in the past 

they just happened to luck out when they had one that came out and worked correctly. And, of 
17

course, then they got bought up and everybody left, so they lost that corporate knowledge that we 

had helped them gain, but, oh, well. [laughs] It is what it is.

Q: I knew we had reaction wheel issues with both Dawn and Kepler, but I thought both of those 

were later. They might not be, though.

Hoffman: Yeah. I can’t remember—there was a specific one that we were thinking about at the 

time.

Q: Let’s see. We talked about the major challenges and what was resolved. Let’s see. Back to 

where we almost started with this, this is also a period where JPL’s implementing its new design

principles and project practices and so forth. How were those built into GRAIL, the GRAIL

project?

Hoffman: Yeah, at that time we weren’t—like, today we implement those as part of the 

statement of work. You put those in there as “You shall follow these or at least respond to them.” 

And depending on the type of project, we may either say, “Give us your equivalent corporate 

policies,” because a lot of corporations have policies, and we’ll do an evaluation, or it could be if 

it’s a Class A-type mission, we could just say, “Just follow ours, period.” But most of the time, 

we do the later.

I actually at one point was a group supervisor, and one of the things I was doing was 

doing design process writing. That was when we were big on process in the early 2000s. [laughs] 

So we were defining process, and that was actually the same time that Matt Landano was coming 
18

out with the design principles, which were initially called the Landano principles. I actually 

knew Matt really well from a variety of past efforts, so I spent a lot of time actually talking with 

him, and specifically some of the design principles we had a lot of discussion about, because I 

used to be an I&T person, so things like the operating hours, one, I really wanted to understand 

what his point was there, and a few others as well. So I was very familiar with the design

principles at that point in time, but I’m 99 percent sure we did not require that was part of the 

contract at that point yet.

We did do, like, I think, a light assessment, because back then, too, there were only like 

forty or something. Now there’s many more than that. So it was not a hard lift. I know 

specifically we did cover the operating hours when we got close to delivery, and I think we went 

and did an evaluation kind of after the fact when we got close to launch. But I don’t remember

there being any particular issues other than maybe the operating hours one. Probably C&DH and 

the reaction wheels I just talked about, they didn’t have a lot of system hours at all.

So, let’s see. Did I answer your question? I’m sort of rambling a little bit.

Q: Well, it sounds like the answer is they’re not in the state they are now, which is itself an 

answer, right?

Hoffman: Yeah.

Q: If they’re not sort of written into the contract, then it’s not as rigorous, I guess, but that’s still 

not quite right. A lot of the stories I get from a lot of people is, “We kind of knew we were doing 

already, and it just formalized that tacit knowledge,” I guess we’d call it.
19

Hoffman: Yeah, and the difference was by the time we got to InSight, which was definitely like 

five, six years later by the time we were writing the contract, that was then in the contract, but, 

again, Lockheed Martin was pretty much already doing most of the things anyway, and it had 

grown from forty to seventy. It wasn’t the 100-and-whatever it is today. [laughs] So, yeah. But I 

think there was enough evolution, especially at Lockheed Martin, of using those design

principles, that they would just know which ones they were probably going to meet and which 

ones they weren’t going to meet, and we already knew, based on past history, which ones were 

going to be a challenge. But we often would just accept their approach because it was meeting 

the intent, if not the letter of the law.

Q: And so there’s a waiver process in that as well. Did you find that to be useful and effective? 

Or I guess maybe another way of putting it, how did you decide what to get waivered out of and 

around?

Hoffman: I thought the waiver—I’m going through this right now on my new project [laughs], 

which was a Discovery project at one point, but now it’s directed.

Q: Yes. [laughs]

Hoffman: So the process, the waiver process is not too onerous, and really what it was originally 

intended, and what I think it still largely is implemented as, is a discussion, so that the institution, 

the 5X [unclear] [00:41:04], whatever the implementing directorate is, the Office of the Chief 
20

Engineer, can look at any given project and see what are you waiving against the design

principle and why, and the “why” is quite important. It might have to do with the way that a 

particular vendor builds their spacecraft or operates their spacecraft, and it could be that that’s 

not the way that you would want them to do it if it was a JPL project, but the assessment option 

is if we tell them to do something that’s outside of what they normally do, their normal process, 

you’re probably taking a higher risk that they screw something up, because now they’re out of 

their comfort zone, so you really need to make an assessment is it really worth doing it exactly 

the JPL way, forcing the contractor to do it exactly the JPL way, and something that’s 

uncomfortable and different for them, is it really worth it, or are you just better off looking at the 

differences and making up the gap in some other way if you need do, and oftentimes you don’t 

need to. And that’s the same even for JPL stuff. There’s some JPL areas that don’t necessarily 

follow exactly the design principles by their process anyway. So it’s always intended to be a 

discussion about risk with the different risk areas and owners, and then making an assessment, 

are you making the right risk call on each individual one. So the conversation is really what’s the 

important part of it and the communication of the risk and acknowledgement that, okay, you’re 

doing these things differently. You have a reason. Is the reason justified or not?

Q: And does that feed into the decision-making about the test program and what kinds of things 

to test and for how long to test them? I mean from the standpoint of GRAIL.

Hoffman: Yeah, absolutely. Yeah, that flows into the overall I&T program, so in terms of what 

are you testing, at what level, what level are you doing analysis at versus test, you know, you can 

run into the problem of over-testing if you’re testing things too many times at too many different 
21

levels. If you do it at the assembly level and then you’re doing it at the piece-parts level, then 

you’re doing it at subsystem level, then at the system level, you know, at some point you run the 

risk that you’re over-testing it, so you want to make sure that you’re testing things at the right 

level of integration. If you waited till the very end and did your test, that’s probably the best level 

of integration, but now you have a huge risk that if something fails, you’re set all the way back to 

square one in some cases.

So there’s an element of trying to make sure you’re doing the right test at the right level, 

as well as are you reducing risk along the way sufficiently. So that’s always the challenge in 

coming up with a good I&T program: not having it last too many years, reducing the risk along 

the way, creating the best value in terms of reducing the risk. Is there a test that you can do at the 

lower level that gives you a lot of value but maybe it doesn’t cost as much? That will allow you 

to not have to do a test maybe at the higher level, where it’s super expensive to do it, or even 

impossible on Earth. Like, we could never do on GRAIL an end-to-end test of our system 

because it’s not designed to work on Earth. And it turns out almost all projects have something 

like that in their system, where maybe their pump doesn’t work in anything other than zero-G, or 

they can’t deploy a boom in anything other than zero-G without a bunch of offloads, and as soon 

as you offload it, you have a test-as-you-fly exception.

So coming up with a test program is always a challenge almost for every project because

there’s certain things you just can’t do on Earth the way that you’re going to operate in space, 

and you just have to figure out what’s the right way to craft a test program that reduces risk.

Q: So on GRAIL, you just mentioned you could never do an overall test of the complete system, 

you could never get the spacecraft far enough apart, etc., so how did you—maybe can you give 
22

me an example of a test that you could do, that would tell you something informative about the 

GRAIL system?

Hoffman: Yeah. So you touched on one of the bigger issues that we had, which is we have the 

laser system that I mentioned before that shoots between the two spacecraft, but the spacecraft

are, like, kilometers apart, many kilometers, and it varies over time how far apart they are. That’s 

all okay as long as you can create the right timing signal so you can figure out exactly how far 

apart they are. So one of the things that we—obviously we can’t do that—well, maybe it’s not 

obvious, but it’s not really possible to do that on Earth, right? So one of the things that we would 

do is we had a test program where we had a test set up on the mesa, because the laser was done 

by Division 33, and even though it’s lasers, it’s very similar—it’s just another wavelength, kind 

of like a radar system.

So we had it set up there, and we could play games with the signal path to try to virtually 

extend it, and so we did some of those things that gave us confidence that once we launched, it 

was going to work, and we knew through analysis we had enough margin, the test program

backed that up, and so we put together a verification program that says, okay, by analysis, we 

have this much margin, we’ve done a test or a series of tests that show that, yes, indeed, that 

margin appears to be secure, and so then by the time—I’m making it very simple. [laughs] But 

by the time we launched, that was not an area that we were concerned about, because we had an 

analysis that showed it was going to work, and we had a test program that showed that our 

analysis was correct. So we were good.
23

Q: Fair enough. I guess we have about seven minutes. Let’s see. So tell me, what was your worst 

moment on the GRAIL project?

Hoffman: Probably when maybe the third or fourth time we had tried to get our reaction wheels 

to work and they still weren’t working. I thought for sure this time they were going to work. I 

can’t remember what number it was. But that was definitely tough, because we thought we had 

fixed it and we’d run some tests at the vendor, and it seemed like it was okay. Then we ran, like, 

a real test, and it still wasn’t working, because basically it was always failing in vibration. As 

soon as we vibrated, it would start behaving poorly. So I think that’s when we—we had already 

been digging in, but that’s when I started flying back like every month to Ithaca, which is not an 

easy place to get to. [laughs]

Q: No.

Hoffman: And ended up with like 100,000 air miles just never flying anything but domestically. 

It was a lot of trips. [laughs]

Q: That sounds painful.

Hoffman: It was very painful.

Q: Reaction wheels. What was your best moment?
24

Hoffman: There’s a lot of best moments. I think when we finally installed the reaction wheels, 

we finally installed the C&DH, we did the check down at the Cape and we knew that it really 

was going to go, that was a great moment. The launch was awesome. Getting into orbit, you 

always can’t take for granted. That was really cool. But then ultimately seeing the data come 

down and having the scientists come up with new findings about what the Moon means, that 

ultimately was the prize. It wasn’t a singular moment where I was super excited, but ultimately 

that’s kind of what the legacy of that project is.

Then it was kind of bittersweet and interesting when we terminated the mission by 

crashing, purposely crashing the two spacecraft into the Moon. That was sad, but exciting.

Q: Who are other key people on the project?

Hoffman: Well, you definitely should talk to Dave Lehman—he was the project manager—if 

you haven’t already. It would have been great to talk to Duncan, but, unfortunately, he’s passed. 

Ralph Roncoli, who’s retired now, would be another really good person to talk to. Let’s see. 

Kevin Barltrop, he was my flight systems engineer.

Q: I don’t think I had that name.

Hoffman: He was instrumental in making sure that the spacecraft did what it needed to do. Mike 

Thelen would be another good person. He’s currently the SPHEREx flight system manager. He 

could talk more, especially about the reaction wheels. He was, like, the lead of that tiger team. 

Who else would be good? You’ve tried talking to Neil Dahya? He’s also a flight systems 
25

engineer doing mechanical stuff. If you wanted to know more about the instrument, you could 

either talk to Charlie Dunn or Bill Klipstein. That’s probably my list of folks I can think of.

If you want to talk to people from Lockheed Martin, I would talk to either Tim Gasperini 

or Stu Spath. Stu’s retired, but he also worked with me on InSight.

Q: I think I know both of those names probably from the research I did in my Mars exploration 

history. I may have talked to both of them.

Hoffman: Yeah, Tim worked on MRO, and Stu—I don’t think Stu ever worked any Mars stuff 

except for InSight. He worked on Kepler.

Q: Okay. Then I don’t know why I would know the name. But, anyway, my last question, and 

maybe it’s too big a question for this late, but what do you think you learned from GRAIL that 

was portable to other projects, that you took with you?

Hoffman: Probably one of the bigger things is a reinforcement of something I learned from 

Stardust, which is there’s more than one way to accomplish the same task, right? So instead of 

saying you need to do it—kind of going back to the design principle discussion—instead of 

saying you need to do it this way because it’s the way that JPL does it, you need to figure out—it 

takes a little bit more time and energy, but you need to figure out what is it that you’re trying to 

actually accomplish.

Like, one of the ones that I always go back to in the design principles is the operating 

hours, right? I actually know from talking with Matt directly multiple times what he’s trying to 
26

accomplish with that. It has nothing to do with the actual hours. It has to do with have you shown 

enough that the system all works together, that you’re confident that when you actually fly it, it’s 

going to do what you want it to do. That’s the intent of it. And it just becomes now a bunch of 

numbers, and the numbers are actually meaningless other than to have a discussion that says, 

have you run the system on the ground enough in the way it’s intended to be operated once 

you’ve launched, that you know it’s going to work? Right? And have you done that for each of 

the payloads? Have you done that for each of the elements within the engineering system? And if 

you’ve done that, then you’ve met the intent. And that’s a specific example, but it applies to 

everything we do, whether it’s design principles or not, is what the contractor or the element, the 

instrument provider, are they meeting the intent of what you want them to do, even if they’re 

doing it differently than you would want them to do? Are they meeting the intent? If so, great. 

That should be sufficient.

It works the same way just with people that work for you. If you tell them you want them 

to accomplish this task, then you shouldn’t be telling them how to do the task. You should be 

making sure that they’re going to accomplish the task and give you the result. How they get to 

that result, even if it’s different from the way you would have done it, is irrelevant, because of it 

helps them get to that result, that’s what you want, right? The results end up making the 

difference. So, I mean, it applies across the board, but that’s probably the biggest thing that I 

carried forward as, like, a reinforcement that that really is what is important, is figuring out what 

the intent of it is that you’re trying to do and then figuring out how you can accomplish that.

Q: So it’s not about the number of hours at all, really. It’s about generating experience.
27

Hoffman: Yeah, exactly, exactly.

Q: All right. I guess we’ve got to go, so I’ll set up another appointment to talk about InSight, 

your other project, or your next project, because now you’re on a third one. [laughter]

Hoffman: Yeah, keep movin’ around.

Q: All right. Thank you for your time.

[End of interview]