Host Andres Almeida: Some of the most important moments in spaceflight happen long before a rocket leaves the launchpad. By the time a spacecraft is ready for liftoff, thousands of decisions have already shaped its trajectory. These decisions happened in design reviews, test stands, and manufacturing floors. They also happened during difficult conversations.
Today I’m talking with Erika Alvarez, deputy director of the Space Systems Department at NASA’s Marshall Space Flight Center in Huntsville, Alabama. She’ll talk about her career and dive into the “test like you fly” approach, an engineering philosophy intended to reduce surprises. How does an engineer take on this mindset? Let’s get into it on this episode of Small Steps, Giant Leaps.
[Intro music]
Welcome to Small Steps, Giant Leaps, the podcast from NASA’s Academy of Program/Project and Engineering Leadership, or APPEL. I’m your host, Andres Almeida, and I’m here with our guest, Erika Alvarez.
Host: Hi, Erika, welcome to the podcast.
Erika Alvarez: Hi! I’m happy to be here.
Host: Can you tell us about what you do Marshall Space Flight Center?
Alvarez: At Marshall Space Flight Center, I am the deputy director of one of our largest engineering organizations here, called the Space Systems Department.
And we work a lot of avionics, software, hardware manufacturing, analysis as well as systems integration. And we work on life support systems for crew to process urine and carbon dioxide in space.
Host: In your experience, what does it take to get the most performance out of a spacecraft?
Alvarez: One of the ways that we kind of look at trying to improve performance, of course, is mass reduction.
So, anything we can do in reducing mass systems that are not critical to the flight. We sort of look at, “Hey, are there some more novel ways to dual purpose a lot of the equipment that we have in order to reduce complexity and also schedule to develop that equipment?”
I would say we also have a tendency to really look back at our requirements and say, “What are the key things that we have to carry to go execute a mission?” because every pound that we take to the lunar surface is worth its weight in gold, as well as considering that we have to bring back samples and we want to take scientific payloads.
So, any inefficiency that you have in your vehicles, you’re losing potential science and equipment that’s needed for crew. And so, in terms of risk, we tend to always look at, you know, what are our safety factors? What are our normal processes?
And if there’s any way that we can try to work around and say, “Hey, this process was really written for something that’s not applicable here,” we tend to kind of look at that, too. And also, our production and making our hardware simple so it could be easily produced.
And that’s a balance, because sometimes fine-tuning mass, you could spend a really long time designing and fine tuning a design, but at the same time, we have to – performance is also schedule. And so, if we can accelerate the schedule by maybe making something a little bit not as fancy, sometimes that’s an important performance metric, too.
Host: By “not as fancy,” does that mean you’re maybe looking at hardware that’s been tried and tested, like heritage hardware, maybe something that’s already been used?
Alvarez: I’m thinking more of like when we build a simple piece of metal that goes on the rocket, and we get a design, and our designers are very sophisticated, and they’ll put in a lot of design features. And then we will take it to a machinist, and machinists will say, “Hey, do you have to have all these little grooves and edges and all these things here? Because can I just put a curvature on here, and that way I use the same tool the whole time and just machine this a lot faster, and we’re done?”
And typically, the designer’s like, “Yeah, I didn’t really need all those features in there. I just put them in there, because the CAD program, you know, put it in that way.”
We do a lot of that designing for manufacturability and production, so that we can rapidly produce things quicker. And sometimes that schedule gain will really help us, you know, get things done and out the door a lot faster.
Host: You were lead systems engineer for many years on the Space Launch System rocket before Artemis got its name. What did that entail?
Alvarez: The SLS time was really interesting, because I was there since the beginning and inception of us architecting that vehicle.
And we had numerous rocket designs, everything from the shape of the outer mold line or the shape of the outside and how that affects the aerodynamics of the vehicle, and ultimately, the loads that get put on all the hardware.
I led a significant trade study to try to reduce mass in our upper stages in order to be able to carry more payload, more performance, allow more mass on the Orion capsule that carries the crew up to lunar [orbit] because that is a direct shot entry: one burn with an upper stage that inserts you into lunar orbit.
There’s no rendezvousing with other propellant depots or anything like that. And so, performance was king.
All the trades that we did on that rocket, as we tested and learned and evaluated and went into wind tunnel testing (we had aerodynamic testing), we went in and looked at all the loads of all the structures we were constantly trying to iterate and fine tune how we were flying the vehicle and how we were throttling the engines, and what that sequence looked like, and how we were doing our shutdown sequences in order to make sure that we weren’t putting a lot of loads on the stack.
The rocket also has a launch abort system, and that launch abort system has to be fine-tuned depending on the faults that the vehicle detects. So, I learned a lot about software. I learned about fault detection.
We did all the software in house here at NASA at Marshall Space Flight Center, and so how the software responds to all the critical faults that it’s getting, and then how that sends commands to the crew or the capsule, or the launch abort system or the flight termination system.
We had to do all those trades and sophisticated software design in order to be able to ensure that we had the highest probability of mission success for all the highest probable failures that we could see.
So, I learned not just about the physics of the rocket. I actually had a very strong background in propulsion, so that was an easy thing for me to slide into with all the propulsion integration. But [I] also learned a lot about fault management software and how all the avionics systems operate and respond and work to everything, including the flight computers and our navigation.
And so, having an aerospace degree and an aerospace background really helped me kind of scan across the breadth of all these different disciplines in order to do that integration role. And then on top of that, you just have requirements and how you do verification and how you do a certification, and those processes. Those things you kind of learn along the way, as long as you understand the physics.
Host: And I have to mention the SLS mobile launcher. You worked to set the requirements for that.
Alvarez: Oh, I worked a ton with the Kennedy Space Center team. They’re a great team down there in Florida.
So, every time we would make changes to the rocket or the vehicle, we had to make sure that the Vehicle Assembly Building with the platforms and the heights, that we were making sure that we had good access to be able to get in, do the assemblies, do the checkouts, the integrated testing checkouts that we do, as well as for rollout and on the pad.
And then, because during rollout and on the pad we are sitting on the mobile launcher, there’s tons of plumbing, electrical connectors, purges, all kinds of access that’s required. And so, we worked all those interfaces jointly with the Exploration Ground Systems team that’s down there at Kennedy and here with the vehicle, as well with, as well as with Orion.
Host: There have to be so many meetings, right? So, how do you avoid overloading your team (overloading yourself) with meetings?
Alvarez: Wow, meetings. That’s my favorite topic.
[Laughter]
So, you know, usually the most efficient meetings are, like, the quick standups that we have, like we would have every Monday morning.
We would go through every discipline, boom, boom, boom, boom, boom. What are the issues that are going on with manufacturing? What are the issues that are going on with our electronics? What are the issues that are going on with our testing? We would do that very quickly every Monday morning as a standup so that everybody had a status across the vehicle of everything that was going on.
We would do something very similar with our cross-program partners that were down on the Orion side in Houston, and also with the Exploration Ground Systems team that was down in Kennedy. And that helped everybody just get in alignment of what are the big issues of the week that we’re working right now that we’re having to resolve.
We would also set aside time to have more strategic engagements about every quarter where we then would say, “Okay, here’s some things that are just not closing, and we need to really get this resolved.”
And we would have an issue resolution team, or a tiger team, or a team that would really be set up, and like, this is all you’re doing until this problem is solved, in order to try to make sure that we have a very good targeted use of people’s time, and we’re not just sitting in the status meetings endlessly all day every day. That’s just completely inefficient, and then you’re asking everybody to work after 5 p.m. if you’re doing that.
Got to always look at [it] and think, “Do I really have to have this meeting, or could this have just been a simple email and move on?”
Host: And I’m sure the whole time you’re also thinking about capturing, documenting all this knowledge, everything that’s happening while the hands-on work is happening.
Alvarez: Yeah, I know, like, our schedulers were amazing. As we got closer and closer to the first launch to Artemis I, I remember that we just had a lot of verification work to close and a lot of things to make sure everything had been checked out and completed, and everybody was running in parallel at the same time.
And so, I finally just set up a war room, and I said, “Okay, guys, every single day we’re going to come here. You’re going to tell me: Did we sign off on these things? Did we not? What’s the holdup? What are we waiting for? Are we waiting for something from a vendor or provider? What’s the delay?”
And the schedulers would come into those meetings. They’re like, “This is perfect because now I’m getting all the data I need, all at once. I’m finding out what the delay is, “and they can make sure that they’re tracking and flowing up and out to all the programs, like, what is the status of us actually reaching completion?
And that’s a really hard job to do, because I find a lot of integrators are — we have some that are really good at starting things and doing all the early trades and the architecting and, like, figuring everything out.
There’s some people in the middle that are integrating and just slogging through. Like, once all the issues start to hit, you’ve got to close all those things.
But then you have to have a really good integrator that’s a closer. Like, “Alright, guys, we’re here to close. We got a schedule to meet. We got to go do this, and this is how we’re going to do it, efficiently and stay on top of it.”
So, I had to kind of mind shift once we got to that point of getting closer and closer to certification. I’m like, “Okay, guys, I’m about to be all up in your knickers. I’m sorry, but this is just what we’re gonna have to do.” And it worked out.
I mean, it really was great. Artemis I was just one of those moments that I’ll never forget because all those meetings like you mentioned, statuses and more rooms and issue teams and traveling, you know, across the country, and working with suppliers, like, it finally all came to fruition. We knew, okay, we built an excellent launch vehicle.
Host: And what was it like at the moment of ignition, because you’re probably not thinking about the meetings, all the long conversations? You’re thinking about that moment. You’re here. You made it.
Alvarez: It’s funny you say that. One of the thoughts that comes to mind is all the people…
Host: Yeah.
Alvarez: …you’re thinking about, all the people that you did this for, all the people that helped, all the people that were part of it, all those moments that we had, you know, working together, working through issues.
It’s kind of like that, that blinking moment that you have of looking past, you know, all these photographs of memories, kind of all going through at the same time as we saw ignition.
And it was a night launch, so it literally was pitch black, and once that vehicle lit, I mean, it was like a sunrise.
And you just are thinking – it’s funny that you obviously you don’t know what you’re going to think. And the things that you’re thinking through, of course, are, one: You’re thinking, “Just go, go, go,” you know, just, “Okay, this is happening. It’s going, it’s working.”
And two: all those leading thoughts of all those people that you worked with, some that passed away and didn’t get to see the vehicle launch before they passed away. Those are all the memories that you have of all those team members that you worked that with. It’s just a bond that you’re always going to have with them for life, really.
Host: What you’re describing now, do you remember holding this in your mind during the space shuttle’s Return to Flight era following the Columbia tragedy?
Alvarez: I was just going to mention that, because the space shuttle Return to Flight era was really a very close knit family that we knew the seriousness, and we were waiting for the CAIB Report result. And we knew that something had gone awry, you know, during that launch and return and what the failure was, and trying to work through all those failures.
And getting down to every little nitty gritty detail to make sure that we understood root cause, and also understanding that part of the root cause was cultural. You know, people not maybe willing to understand that they had always seen what we call a “normalizing of deviance,” where, “Oh yeah, we always lost tiles,” or, “We always had foam that not lost tiles, but lost foam that had maybe damaged some tiles, or lost some foam here and there, but we don’t know that it’s really related to the tile thing.”
You know, you start to kind of normalize these things that you see that are not okay, because you’re not thinking of that long term consequence chain that could happen and the residual risk that’s building up every time you fly. We took that return to flight so seriously.
I mean, we worked just day and night, as if we were flying in order to find the root cause so we could get back to flight. And then once we got back to flight…the way that we looked at all that data, and we continued to question things, and we did all the post inspections, and we would look at every little thing – because we did not want that to happen again.
And a lot of what I learned in my career was from that older guard of folks that were here with that space shuttle experience. We carried a lot of that forward into Space Launch System, and then moving forward into all these new Artemis systems, you’re always going to carry that remembrance with you, that if you’re not careful, there could be something that you could miss.
So, always be on the lookout of listening to when someone’s saying, “Hey, this doesn’t quite seem right.” You’ve got to pay attention.
Host: I’ve heard you emphasize a “test like you fly” approach. Why is that mindset so important in engineering?
Alvarez: We take the “test like you fly” approach very, very seriously as a core tenet of something that we do in order to be comfortable with eventually flying our systems.
And that’s because on the ground, you have so much flexibility and time to think and time to set up a facility or a bench test, or it can even be something as big as an integrated test with multiple programs. And the way that you can simulate that, and also, if you can have hardware in the loop while you’re simulating it with software, you can catch whether it’s a software issue, it’s an electrical controls issue, is it really a performance issue with your hardware?
And trying to fine tune all of that before you get to a larger integrated scale will pay itself off in dividends, because once you start to integrate all these systems together, and now you’re trying to troubleshoot, you’re holding up hundreds of people.
And you have easier access when you’re always doing something at a bench test level, at a laboratory level, at a test stand, or somewhere where you actually have a lot more data and instrumentation that you can actually then see what is happening.
Because by the time you assemble and you put everything together, now you’re working integrated issues of all these things being integrated together. You should be solving different problems, as opposed to these small things that you could have done at a breadboard level.
So, “test like you fly” is – look, I mean, we have to do it. When you skip those things, then you’re risking finding a whole lot of little things that could add up to something bigger at a larger scale when you integrate because by the time you’re flying, now you’re really limited in the access you have and what mitigations you can take. And at that point, you’re mainly looking at operational changes and we try to avoid that if possible.
Host: Can you think off the top of your head of a lesson learned that avoided something, avoided possible complications down the road?
Alvarez: Right now, I happen to work in an avionics area, and so we get a lot of spacecraft and things that come through for integrated testing through our facilities.
And lots of times it’s as simple as something was soldered backwards. This connector didn’t have a good connection. And when we did vibe, it shook it off and it disconnected.
Host: Yeah, vibe as in vibration testing, right?
Alvarez: Right. All these little, tiny things that add up, right? I know, with a lot of our large structures, you know, we can go in there and do structural testing, and we like to do, if we can, if we’re allowed to, of course, we’d love to be able to test it to failure so that we can understand what we call the “edges of the box,” or the edges of our certification, and how hard can we push the system, if we get asked to do that in an operational mode where we have to go and push something past its limit.
I can tell you on the Space Launch System our first flight, we did tons of evaluation against different winds, what the loads would be, how the dampers would respond, all the connections, all the joints.
It paid itself off because, sure enough, a hurricane came through Florida when we were sitting out there on the pad, and we were asked, “Do we have to roll back, or can we ride out the hurricane?” We had done all the testing and analysis to be firm and sure. “Yes, this is a little one. The vehicle will be fine, no problem.”
But we had to have all that data and all that information that we had ahead of time in our evaluation work and our testing and our analysis to be confident and look someone in the eye and say, “Yep, not a problem.”
Host: Right, you’re not just making a decision on the spot our feelings, just going off vibes.
Alvarez: We call that “shooting by the hip.”
“Yeah, I think so. Kinda maybe. Probably?” When I hear those words, that means, “Okay, you don’t have an answer for me.” And as a decision maker, that’s not what you want to tell a decision maker. Like, “Well, I kind of think maybe, but we’re not sure. And you know, it makes us a little nervous, but it’s up to you.” That’s not an answer, that’s not a, that’s not an answer based on data. It’s not a data-driven answer.
You should be able to say, “Yes. This is what we’ve done. This is our limitations. This is when things no longer look okay for us and we have it based on this data that we’ve performed here,” or previous experience, or previous hot fire of an engine, or previous structural tests that we did, or wind testing.
Or, “Here’s our analysis, and here’s how much margin we have.” You should be able to have that at your fingertips.
Host: What are you excited about now at NASA?
Alvarez: I am so excited about: I spent almost five years at Headquarters. After working Space Launch System and helping stand up the human landing system program with our whole insight processes and our subject matter experts.
I had a great experience of going to Headquarters to help, kind of stand up how we were doing all the integration across the Artemis campaign, and the Artemis campaign has so many different systems that are just a wide variety of contract mechanisms and providers and developers and international partners and different groups, and how are you integrating all these things? That was a huge challenge, you know, to really try to figure out how we’re going to get all those systems to work together.
Now, with the Ignition event, you know, that we’ve had at NASA, and the administrator declaring that we’re going to have a Moon base, and getting everybody really focused on all the challenges around the lunar surface, everything from navigation to lighting to power to logistics, and how do we mobilize things, and how do we pick our sites, and how do we actually start to deploy the things that we need to have a long-term presence, and our habitation systems and crew systems – I mean, it is so exciting and invigorating, and we are seeing just industry and all our partners, and everyone at NASA is just so excited and ready to go.
Because on the completion of Artemis II, my team also worked on a lot of the cameras and the imaging and all the high-speed videos, and how excited the world was about Artemis II, and having the crew finally on board and completing those missions, I think we see a glimpse into what is the art of the possible in us being on the Moon and having a longer term stay.
And so, you know, as a manager now, if I ask an employee, like, “Hey, we need to go run this testing, can you stay an extra day to do this?” They don’t blink an eye, because we all know what this is for and what we’re working towards, and we’re all aligned for it. That is very powerful when it comes to trying to do something as complex as what we’re trying to do.
Host: That’s great. My final question for you, Erika, is: What was your giant leap?
Alvarez: When I was asked to go integrate and work on the rocket, I, you know, having been an aerospace degree and more mechanically inclined – because the beginning of my career was all around high-speed turbo machinery –I said, “How would I be able to understand this whole rocket? Like, I don’t.. I’m not an electronics engineer, I don’t understand software.” Like, there were things that I still had to learn that I didn’t know, but the background and the foundation that I had and working on very complex machines and making those and analyzing the data and understanding that physics, it gave me a basis for being able to be comfortable to step into that type of role.
And once I worked on Space Launch System and a system that complex and coupled with all these other vehicles and interfaces that that gave me my second giant leap to go be able to integrate Artemis. And I said, “You know, I’ve been there developing all these systems where you’re just like, you want people to go away, leave me alone, because I don’t want to hear about all this integration stuff,” but it’s those difficult interface points that are the highest risk of emission, that if you didn’t do enough testing on it, history has shown where a lot of our failures occur when you’re trying to integrate disparate systems that aren’t working together day to day. Those were my giant leaps.
It was like, “Why would they think somebody like me could go integrate this whole rocket, and then why would they think that I would know how to integrate this whole Artemis thing?” And so now I’m really hopeful, and I’m seeing a lot of people working, what’s going to be long-term Moon base and our nuclear missions, and I tell them, “How are you integrating it?” and just start asking those questions.
Kind of plant the seed of start thinking ahead now, because those are things that will eat your schedule. It’s going to eat your lunch when it comes to making sure.
That everything’s ready, and when you get down to a final certification review, those are the things you’re going to get asked. So, being able to ask those early, I feel comfortable now that having taken those giant leaps, you know, I can be smarter about asking our team early on, “Hey, you need to be looking into this ahead of time – not just one step ahead, but several or many.”
Yes, I’m a chess player. You got to think multiple steps ahead. I always tell them that.
Don’t just look at what’s right in front of you: You’re going to miss the big picture.
Host: Love it. Well, thank you, Erika. Thanks for sharing everything and thanks for your time.
Alvarez: Thank you. It was a pleasure talking to you today. Thank you for having me.
Host: That’s it for this episode of Small Steps, Giant Leaps. For a transcript and other episodes, visit nasa.gov/podcasts. While you’re there, check out our other podcasts like Houston, We Have a Podcast, Curious Universe, and Universo curioso de la NASA. As always, thanks for listening.
