Host (Andres Almeida): Behind every NASA mission is an enormous web of decisions, requirements, risks, and work that makes exploration possible. 

How do you plan for missions that may take years to unfold? And how do engineers make decisions when the stakes and the complexity are so high? 

Darius Yaghoubi, deputy chief engineer for NASA’s Planetary Missions Program Office at NASA’s Marshall Space Flight Center, works at the intersection of those challenges. What has he learned throughout his career? 

Let’s talk about in this episode of Small Steps, Giant Leaps. 

[Intro music]

Welcome to Small Steps, Giant Leaps, the podcast from NASA’s Academy of Program/Project & Engineering Leadership, or APPEL. I’m your host Andres Almeida. 

For this episode, I’m at Marshall Space Flight Center in Huntsville, Alabama with Darius Yaghoubi. 

Darius, it’s great to have you on. 

Darius Yaghoubi: Happy to be here. 

Host: Tell us a bit more about your role and what you do here at NASA Marshall. 

Yaghoubi: So, I am the deputy chief engineer for NASA’s Planetary Missions Program Office here at Marshall Space Flight Center. 

The Planetary Missions Program Office, or PMPO, we have about 40 or so different missions that are robotic uncrewed, ranging from in design right now to operating in space right now, going from anywhere from heading to Mercury to out beyond Pluto, anywhere in between, including the Moon, which is a whole kind of separate subset. 

So, as deputy chief engineer, I assist the chief engineer in executing engineering technical authority and overall insight on the technical designs of about 40 or so different missions, like I said. 

Anything dealing with engineering, design, analysis, testing, execution, that kind of stuff, and just making sure that it meets NASA’s standards. 

Host: Would you mind expanding a bit on some missions the program office is managing right now? 

Yaghoubi: I mentioned before there’s about 40 different missions that we’re, that PMPO is supporting in some capacity. 

And the objective of a lot of these missions is they’re not going to be, like, front and center like you’d see Artemis. They might be a low-risk class. It doesn’t cost as much (high risk, high reward type thing). A lot of them have kind of an accepted risk that we don’t have the time and the resources to put as much effort into these, but we still want to at least try them. 

If it fails, well, you know, the mission might have failed, but we can still get lessons learned from it, figure out why it failed so if something similar goes up in the future, we can say, “Okay, well, this one didn’t work quite the way we wanted, so let’s make sure we don’t do that same thing again,” and then maybe the next time around, we’ll, you know, get a better job at it. 

So, some of them are kind of that lower risk class. Some of them are still what we would consider flagship missions, or they are still kind of in the public eye, not as much as a crewed mission, but things like Europa Clipper (which you may be familiar with) that launched not too long ago on its way to Europa now. 

Some things that are in development, so we could be doing stuff that seems like science fiction. Dragonfly is another one that we manage out of PMPO that’s going to be going to Titan, one of Saturn’s moons. And it’s a nuclear-powered octocopter, about the size of an SUV, which all of those things individually sound like science fiction, right? 

But you put all that together, and it’s like, “How are we even doing this?” If you told six-year-old me that that’s one of the missions I’d be supporting, when I was a quote, unquote grownup, I wouldn’t have believed you, you know? 

So, and some of them are just quite a bit simpler. There are small payloads that just might be going to the Moon to look at things that we’ve kind of questioned for a long time but never really had the opportunity to, to say, “How does that work?” or, “Why does it work?” and ultimately might help us understand how the lunar environment works when we ultimately have people living up there. And just, you know, unlocking more of the answers about our solar system that can tell us more about Earth and humans as a whole. 

Host: The topic of risk in space exploration is fascinating. There’s no single answer on how to approach risk. Do you find that to be true? 

Yaghoubi: There’s not really one solid, defined answer for that, but as an engineer, I tend to approach it from a logical perspective. 

As kind of cold and calculating as that may sound, it is rooted in, I don’t want to say rooted in success, but it’s a system that works. It’s establishing what is an acceptable amount of risk for the mission that you’re doing up front before you really do anything, so that the goal posts cannot be moved later on when things kinda get off nominal. 

Certain missions, like, if it’s a crewed mission like Artemis II, that’s obviously going to be the absolute highest amount of scrutiny when it comes to risk, where if it’s something that’s small and inexpensive, there’s a lot more leeway that you can give into that. 

So, it’s really a lot of understanding how that comes into play. If it’s something like Artemis, okay, you know we’re going to look at this to the 10th decimal place [to] make sure we absolutely understand every aspect of it. 

Whereas if it’s a low, like a Class D risk mission, we can say, “Okay, well, this is going to be really, really difficult to test this one small thing, so we’re going to accept that we’re not going to test that, and kind of hope that it works out. And if it doesn’t, well, we probably have a good idea of why.” 

So, it’s really just quantifying it the best you can and tailoring that to whatever the mission actually needs from that perspective. 

Host: What’s a lesson you’ve learned that’s changed how you approach what you do? 

Yaghoubi: In general, soft skills, the further you get in your career, I found are almost as important as the actual technical aspect of it, probably with effective communication being one of the big ones. 

From an engineering, like, pure technical standpoint, you can do two plus two 100 different ways, like MATLAB, on a calculator, in your head – you’re always going to get the same exact answer. But when you’re talking to people, the way they react to that answer is going to depend pretty much based off of who you’re talking to. 

You have to kind of know how to talk to people and what your relationship is with them, what their role is on whatever project you’re talking about. And you kind of have to know from a bit of a personal aspect, where they come from as well, because some people don’t react well to bad news, even if you’re just a messenger. 

If it’s just an engineer, for example, they might just be interested in the numbers, and they don’t really care about anything beyond that. But if it’s a manager, they might be kind of interested in numbers, but also, they might be asking the question of, “What does this actually mean? How does this relate to the project?” 

So, you have to kind of think a lot more about how you approach things. You may be guessing an answer yourself, but the way that you communicate that to different people comes into play and ultimately may impact how things play out in the long run. 

When I first started out, and I was just doing, you know, the analytical design and analysis stuff that wasn’t nearly as much of a thing. It was take a look at what I need to do and do it, and then hand off that to somebody else, and they worry about how to present that kind of thing. 

But now I’ve been here quite a bit longer, I know how you have to kind of approach that to really convey what is needed to be conveyed. 

Host: Yeah, to share that knowledge, essentially. 

Yaghoubi: Right, to, well, to effectively share it so that all the people that you want to understand it can understand it. The person you might be talking to might not have years of experience in whatever it is. 

So, you have to really know how to hit the highlights to the level that they would understand. You know, it might be a scientist who does biology, whereas I’m an aerospace engineer, they know all about life sciences stuff, and I know nothing about it, but they might have something on a payload that I’m working on that is related to both of us. 

So, I might have to say, “Okay, from an engineering standpoint, this is going to affect the biology on your payload in this way,” and they might ask a bunch of questions from an engineering standpoint that I have to be cognizant of them might be not having the same background. 

Host: And anybody can bring in their own biases. 

Yaghoubi: Not just their own biases; their own experiences. 

Host: Yeah. 

Yaghoubi: They might be coming from an academic environment where they have to fight for funding every year, you know? 

So, somebody might be coming in from that background, and then they might start getting worried. “Well, you know, our funding stakeholders are going to be displeased with this, so I have to tread lightly on this one aspect,” where I’m just like, “Yeah, this is the design. This is the analysis. This is what the numbers say, so we got to figure out what to do from that.” 

Host: I think it’s funny we call it “soft skills” what you’re talking about, when these are fairly critical skills. 

Yaghoubi: They, they are critical skills. I will agree with you on that, but from the STEM field in general, when you think of scientists and engineers, they don’t have the best reputation when it comes to these soft skills. A lot of them kind of get into their own area, and they don’t really consider that kind of stuff to be important, because, you know, what they’re working on is the major thing. 

It’s kind of a thing that a lot of people in engineering and science in general have to pick up on as they get further wrong, just because they don’t really take classes on it, they don’t get used to it unless they’re giving a lot of presentations. 

Host: Can we talk about a big news event recently that happened for the agency? The launch and return of the Artemis II mission around the Moon, huge milestone. You have contributed to the Space Launch System rocket. Can you talk a little bit about the analysis work you’ve done on that?

Yaghoubi: Well, I want to kind of preempt it with you mentioned it was a big news event for the agency – I’d say a big news event for humanity. 

A lot of the remarks that astronauts themselves said that they want to represent humans as a whole, you know, not just NASA or any individual organization. So yeah, kind of want to kind of preempt it with that. 

But yes, I did contribute a handful of things to the Artemis program, specifically on the SLS launch vehicle itself. 

I’ve been kind of removed from SLS and Artemis for a while since I’ve kind of moved around a bit since those days. But I worked on the SLS design, specifically on GNC (guidance, navigation and control) and within that, specifically, kind of on the flight stability side of things. 

So, from a technical standpoint, I worked on two very specific systems, one of them called pogo stability analysis, which I don’t know how deep you want me to get into this kind of stuff. 

Host: You can! 

Yaghoubi: It’s a type of dynamic instability that can occur on large scale liquid propel launch vehicles, when the fluid modes of vibration can align in frequency with the structural modes of vibration. 

And if they align a certain way, and things don’t go the way that we want them to, they can kind of match up and lead to extremely high oscillations that ultimately, if they’re left unchecked, can lead to catastrophic destruction. 

It wasn’t really an issue in the space shuttle days, because the engines were designed specifically to mitigate that, but the RS-25s on SLS use the same engines, and the entire rest of the vehicle was not necessarily designed around that. 

So, that pogo stability analysis that I worked on specifically was looking at the dynamic interactions between the actual core stage itself and the actual propulsion system and saying, “Okay, well, what does our pogo scenario look like? And if there is an issue that potentially could come up, what’s the most likely situation that resulted that? And what can we do to fix it so that it doesn’t really become a problem?” 

Host: And “pogo,” it comes from what we think of “pogo.” It’s up and down… 

Yaghoubi: Pogo stick, yeah, up and down movement. 

Host: …of the propellant. 

Yaghoubi: Right. It’s so, essentially, you have propellant flowing through these really long feed lines going from the liquid oxidizer tank down the side, down to the actual engines. 

And it’s a long, thin tube on each side of the vehicle. And as that’s flowing down, if you get some kind of axial vibration pushing up, and it hits it the right way, that can cause a thrust oscillation. That thrust oscillation can lead back into the fuel tank and make it kind of grow until you have what pretty much is a negative feedback loop, and make it grow larger and larger until the vibrations are so big that structurally, it cannot handle it. So, that was one thing I did. 

Another aspect of the design I worked on was slosh stability modeling, which that’s quite a bit more well known, just in general, for, when it comes to launch vehicle design and analysis. 

Fluids within the fuel and oxidizer tank, they’re going to move around a lot. That’s going to move the center of gravity of that fuel within there, depending on the different aspects of the trajectory. It’d be circling around a little bit as the fuel is or the oxidizer is used up, or it could just be kind of crashing from side to side. 

So, that would effectively change where the center of gravity of the entire vehicle is, and as it’s flying up, it’s going to be rotating about that center of gravity, and things like the TVC and the RCS is going to are, they’re going to depend on what that position of that that TVC… 

Host: “TVC” meaning… 

Yaghoubi: Thrust vector control (and the reaction control system). 

So, any rotation that you get from actually induced rotation system from the control system is going to be rotating about that CG [center of gravity]. So, slosh is looking at how that fluid moves around inside, and seeing if there’s any instabilities that that could cause and how the control system can respond to that to make sure that, you know, the system as a whole remains controllable and it does what we want it to do. So, those are the two primary technical aspects. 

But I was also a team lead for quite a bit in my old branch, which was Control Systems Design and Analysis. So I was, from a kind of a more of a management perspective, also overseeing a lot of the work that my team was working on in their contributions to SLS. 

So, I wasn’t directly doing the technical work that they were, but I was working with them to make sure that they had the resources that they needed, and helping them out if they had any issues that they had troubles with, that they might need external support. 

Host: Fascinating. And you’re absolutely right. Artemis II was sort of like a balm for a lot of people. There was an overwhelmingly emotional response to the mission, particularly to the crew. 

Yaghoubi: One thing that really stands out to me is just, well, it’s the kind of why NASA does this kind of stuff. 

We do it for science, right? Since we get funding from the government, we are not looking to turn a profit. We’re looking to do these things to benefit mankind as a whole. The science that we’ve gotten back from Artemis II and other missions that we do all the time, it’s the kind of stuff that makes humans kind of, it advances humans as a whole. It’s for the sake of doing that, right? 

So, a lot of the missions that NASA does do, the return on investment from a financial standpoint, we might not see that for 20 years. 

So, you know, it’s a long-term thing. We do see returns, but at the end of the day, that’s not the reason we do it. You know, we want to advance humans, and we want to get a better understanding of science as a whole. 

Host: And ourselves. 

Yaghoubi: Yes, absolutely. 

Host: Darius, thank you for being here. We appreciate your time. 

Yaghoubi: All right, thank you for having me. 

Host: The episode ends here, but I did follow up with Darius to ask him, “What was your giant leap?” He responded it was when he progressed from running simulations and modeling to becoming lead pogo stability analyst for the SLS rocket. He said this role gave him “ownership” of a specific part of the vehicle design.  

Darius now had to lead a team, requiring him to have a stronger understanding of the rocket system as a whole. He said it involved a lot more interaction with different levels of management and engineering leadership, since he had to break down the results and fine technical details to communicate them effectively. 

That wraps up another episode of Small Steps, Giant Leaps. For a transcript, visit nasa.gov/podcasts. While you’re there, you can check out our other NASA podcasts like Houston, We Have a Podcast, Curious Universe, and Universo curioso de la NASA. 

As always, thanks for listening. 

Outro: This is an official NASA podcast.