fbpx

About This Episode

EPISODE 7 features Dara Sabahi. A former chief engineer at NASA’s Jet Propulsion Laboratories. Dara has lead an extraordinary career in space travel. Leading teams and solving complex problems on numerous interplanetary expeditions. We take a deep dive into Dara’s team building mindset. Sharing his top five tips on keeping momentum through intensive projects, and working through failure to find results. 

Dara’sTop 5 Leadership Tips:

Below is a summary of the Top 5 Leadership tips shared during the interview this week. Take a listen to the episode to learn more about the thoughts behind these tips –

  1. Empowering Your Team
  2. Active Listening
  3. People Matter Just As Much As The Project
  4. Don’t Stop After The First Success
  5. Generating Momentum In Your Work

We hope you enjoy the episode. You can find even more Full Stack Leader episodes here:

https://www.wondermentapps.com/fullstackleader/

Show Transcript:

Ryan: Hi and welcome to this week’s episode of the full-stack leader podcast. We’re here with Dara Sabahi. He is a retired chief engineer. At JPL and has worked on a number of amazing space projects over the course of time. 

 We’re excited to have you here with us, Stara. Maybe you can give us a little background on what you’ve done and where are you? 

Dara: Hi, Ryan, and thank you for having me here. Yeah, it’d be my pleasure to give you a little bit of background. So Ali started at the jet propulsion laboratory in 1989. I was already mid-career at the time, but my previous career was not aerospace, so it was not just starting a JPL. It was also starting aerospace at the same time.

I worked for a couple of years as a stress analyst, and then I got. Well sort of lucky in which, I realized both my seniors and myself realized that I had a talent for system engineering. And for some leadership after a couple of years, I essentially had system engineering or chief engineering leadership roles until I retired about a few years later.

Most of my roles, most of my technical work involved landings on other planets, predominantly Mars. I mean, I did work on missions for Europa comments, et cetera. However, Moore’s Berbee is where we actually implemented projects. And we had landings. I had five landings on Mars and I had a leadership role and they included.

Mars Pathfinder spirit opportunity, Mo Phoenix and curiosity. The follow on missions, of insight, perseverance also uses the same technologies we developed for Phoenix and, and curiosity, in addition to doing Mars, landings also were heavily involved in large space deployables. So these are interesting in their own right.

In which you have to put very lightweight systems, fold them together and then deploy them into large antennas in a space. And they required their own unique way of  dealing with that. Right around the end of my career at JPL, I was working on a Europa Lander. I was the chief engineer for Europa Lander.

And when that mission went on a hiatus of extended wait, I felt like it was time to retire. 

Ryan: Yeah, it sounds like you have experienced a lot of different sides of the space exploration that we’ve been doing over the last few decades. I’m really excited to talk to you about these and get your insight on what it takes to actually put teams together , to pull this stuff off.

It’s really the thing of dreams for somebody like me, but you are somebody that was actually on the ground executing on this and. Really opening up our ability to see what the universe has all.

Dara: Of course, well, my role predominantly or chief engineer at different levels or lead system engineer now different levels means that I would work either at a subsystem level, for example, like mechanical system, chief engineer, or a sub assembly level like entering the center manding or a whole project level.

So I’ve done it all. Literally multiple times. And the projects that I’m focused on or that I was involved in really branch out into two different things. But I did almost all of the Mars landings out of curiosity. And I did a number of large space, lightweight deployables. So these are complex in their own way, which means you got a package, extremely light components that we deploy to become large antennas.

Typically.

Ryan: Yeah, that sounds like an amazing pathway and journey. 

Dara: It was interesting Ryan and it tells you the ups and downs. It was more like riding a roller coaster or like a battle campaign. So it was both emotional up and down and crazy at times.

Ryan: Right. , I can imagine. What are some of the kind of common battles that you would face while you’re in it? 

Dara: Well, interestingly, most of the battles, even though the core of it would be technical, the difficulty will be people. So I had some extremely complex problems to deal with, for example, on Mars, Pathfinder, which was the airbag Lander.

We had to balance this. At which the airbags come back, the surface of Mars with the largest size of mouse, massive airbag they could fly. And the two different balances normally means that if our Smith was more than 20 meter per second, you’re going to blow those airbags. We’re going to tear them right up.

So that was pretty complicated, trying to figure out how to get those air bags to the surface at that velocity, without any attitude control without any. 

Ryan: Yeah. And  there’s a lot at stake with that I imagine as well. Correct. 

Dara: I guess it was actually in hindsight a lot more than one would have realized at the time in the mid nineties, we thought this was a one-off project.

And, you know, it’d be interesting to do if we didn’t know where it was going to be. But in fact, that was the project that opened the door to all the follow on missions, to the spirit and opportunity, rovers to curiosity and a fall on Rover that’s right now on Mars. And I forget the name and every time I don’t work on something, I forget their name.

I don’t know how that works. So most of the Mars missions that you’re likely to have heard about over the last 20. Got initiated in fact, by Mars, Pathfinder, and not from Mars Viking, which is sad because working so the winter on a hiatus where everything died on well after Pathfinder, everything was energetic.

We had a lot of the Mars missions and in hindsight, a lot was riding on pattern.

Ryan: So I have so many questions about this. But , one of the ones that comes to mind, especially in the world of leadership, right, , as you’re embarking on some of these new missions that in this particular case opened up a series of other very impactful missions, that really may have changed the course of the world.

How do you get a group of people together to try and solve problems? A problem, like the airbag problem, and work on that in a way where. You can hit the deadlines that I assume you were having to hit within that period. 

Dara: Yep. I’ll answer your second common first that planetary conjunctions are very unforgiving.

So the deadlines are unforgiving. You got a launch or you missed your opportunity for years. So to go back, how do you put the team to. And there is no one size fits all. I can give you examples of situations and I can give you certain rules of Tom, but at any given instance, the complexity and nature of the problem, the availability of the right people, or the, sometimes the wrong people.

Ah, The bandwidth of your organization and the supporting organizations all come into play. And oftentimes you have to make dynamic decisions that attempt to balance all of the available constraints into the best possible solution. That’s long winded, but I hope it does address the person in some way.

I can give you some particular examples. 

Ryan: Yeah, I think that would be good. I do understand what you’re saying. And I think it is looking at the entire landscape, no pun intended with the Mars Rover, but looking at the entire landscape of the team that you have to work with, and the scenario and situation, what do you think is the main driver in that situation?

Do you think that the kind of ticking clock is the main driver, or do you think, like having the right specialists within the environment and being able to work with them and. This leads to my bigger question of , how do you see  picking the right kind of people to work with in these scenarios?

Dara: So my experience has been to have the right generalist is the key. It’s the first decision point for me working as a chief engineer, I knew that I couldn’t be a chief engineer on a mission in which I could never wrap my hand around it without having a lot of support. These are extremely smart generalists that could also do my job, that could be deployed to do large segments of the job.

So from my perspective, where, from where I’m sitting, it was always the generalist that I was most interested in. So even if. Getting someone for a mechanical system or avionic system, it was really important that they were broad enough to understand other systems and how systems integrate and be able to lead across multidisciplinary organizations.

Ryan: So these are kind of the foundation players that you need to be able to have it. And then would you bring in specialists for very specific types of things that you had to deal with? 

Dara: Absolutely. So, especially as where all are always required, they’re always needed. And we were really lucky at JPL because we have a unique pool of world-class specialists that you basically cannot find anywhere else.

Yeah. So we knew who can do what, where as a specialist, the problem oftentimes became how to get the generalists together because they would be the most in demand. Since you need them full time. You don’t typically need this specialist full time. You need them a fraction of their time. Then the problem that they need to attend to is, correct.

We were lucky we could count on an organization that had the bandwidth and the specialists that could help us out. Oftentime or problem was getting sufficient leadership, technical leadership in place with sufficient general band, but to be able to handle the job. 

Ryan: Yeah, it’s interesting because.

We talk a lot in leadership about creating a vision for how to approach something and really guiding people towards getting to that vision. And this is one of those instances where the vision is at least in a very simple high-level way, pretty straightforward. I have a vision to get to Mars, right?

And a, and the land, a Rover on Mars, I think , as you get into the deep. Execution aspects of leadership. You’re talking about, like, how do we actually bring that vision to life? What are some of the ways that you inspire that combination of generalists and specialists to actually execute on something big and complex and, with such unusual environments as this.

Dara: Okay. That’s a very good question. Interesting question. Because I did develop a unique methodology, which is seldom used. I found that. Resolving or figuring God how to bring a large group of oftentimes diverse teams together with different interests and different objectives into one integrated objective was the beginning.

It was step one to solve a complex. So I’ll give you a little bit of a story. Uh, they had an organization issue at JPL in which an external management consultant was brought in. I was a participant and I saw a technique, which I really liked later on. I adapted that technique to come to an agreement, not consensus, which is, I don’t believe consensus is achievable, but come to agreement across very diverse members of.

 Let’s say you want to land in Europe. Europe has a high radiation environment. It’s got a very poor citrus surface glacier, like surface, and everybody wants to do it a different way.

Some use solid rockets, some use airbags, some they won’t use penetrators. Someone has to give a soft touchdown. The sky’s the limit and people get really entrenched in their methodology. So how do you do this? How do you bring them all together? That’s not just the team management also has different viewpoints, but the technique I usually used to use was.

Make it a creative workshop usually spend two, three up to four days just to bring the team together into one concept rather than multiple concepts. So I used to accelerate concept development rather than spend the excruciating amount of time and options. What would you use to do is first accept all ideas and all opinions.

They all go to the board. They all got listed. No criticism was a lot. I specifically, specifically this, a lot of criticism, as a matter of fact, I used to joke that if you criticize something, then you have to defend it. Or you’re not part of the 

Ryan: story. I love that approach. That’s great. Yeah. 

Dara: So if you criticize something, you have to defend it.

If you want to stay in the game. Yeah. Now they usually have a time frame for it. And after about four hours, you  would see ideas running God, all the crazy ideas. And I would put enough crazy ideas in first to encourage people with crazy ideas. So I didn’t want to have people get defensive and try to just have the best idea.

So I’ve used myself as a Guinea pig or as the example of you can say stupid things and it’s okay. That’s great. Then what would happen is that you will see some exhaustion set again, and everybody coming to realize, oh, how are we going to do this? If there are so many different ways of doing things, the next step would be, let’s do categories.

Let’s get these and put them into batches. Let’s say you got a thousand ideas. Usually there are only a few hundred only. Let’s create batches of ideas, things that worked so well together. And then let’s substructure those batches into mission classes, meaning things that have to work together. And eventually we will be done into three or four or sometimes up to half a dozen classes of missions.

Now this takes a great deal of expertise to get hundreds of ideas into half a dozen, but usually this was a room of. He came down to half a dozen. That’s the tough jobs stuff, the stock, 

Ryan: You really whittle it down to that kind of core group of ideas that would actually be implementable. 

Dara: Exactly.

So I will tell you one thing, those who are familiar with describing a crane, landing of curiosity in, in which he came down a rope rather than landed on rockets. Well, that was done in exactly this kind of session. I was leading the session or used to call myself a facilitator in these cases. And this was exactly the way we did it.

The idea was that we wanted to learn. , we don’t have enough mass to have a Lander and a Rover. So we want to land on our wheels. What is the best way of landing on our wheels? And starting with that sort of charter, we went through  lots of ideas and a lot of constraints and the number of incredible thinking and innovations that came out of a single workshop where everyone was focused on the, and finally the solution wasn’t.

Eventually, they came up with a sky crane. And when Davey bought the other, that two day workshop, we were all committed to Skyping. 

Ryan: Did you see that commitment happen on an incremental level with the team or was it like light bulbs flashing off to people? As people were coming on board to the idea.

What was that 

Dara: like, the dynamics are sort of interesting the way I recall it was that we were having a hell of a time until the end of near the end of the last day in which most, everybody was not coming around to one way of doing things because we hadn’t solved the big problem of,, attitude control on a rope basically, then two bodies.

Near the end. There was this flash of genius, a lucky light bulb from two individuals having a conversation. And, I was actually overhearing them and all of a sudden a new concept came up and that was this guy, CRE and. Almost immediately, everybody started warming up to it. So they were all exhausted from not finding a path we could all agree on.

And the moment people saw the pad that was an acceptable compromise across the board. I actually didn’t have to work from there on it. It occurred on its own, the team converged on that topic, on that approach. 

Ryan: Yeah. This is a great moment to talk about leadership because what I’m hearing and I could be wrong.

But what I’m hearing is that you let the teams really work on coming up with their solutions and talk it out and make it happen. And then as it started, as it really started to come to life. People immediately gravitated to it. It kind of found its way, but you had to let the teams work that out, um, versus potentially forcing it on them.

Correct? 

Dara: Absolutely. Going into this. I have my own opinions and ideas, so I was a chief engineer, very experienced. So I didn’t go into that, without any biases, but I was committed, totally committed to doing what the team combated. The team is the group that does the job.

So when I was the chief engineer, I was aware that I don’t do the job. My team does the job and they have to be empowered and they have to have ownership. They can’t be forced to do something when they are hesitant, forget the situation in which they’re completely against it. Even hesitancy has a huge cost associated.

So getting everybody aligned along the same path, even if there wasn’t like a hundred percent consensus with a 70% consensus and a 30% agreement that, okay, we are willing to go this road. I would have achieved most of what we wanted to do, which was empower and enable the team to do the job.

Ryan: How did you deal with any kind of fears around failure? Because it seems like in this case, and I think this is relevant to anyone who’s going through leadership, they probably feel about this themselves, but in this particular case, you really have large investments going into this.

You have an extensive amount of manpower and how did you deal with the team being afraid that it wouldn’t work? 

Dara: Well, that usually was almost very, the hesitancy for most people comes from the tool. I used most to deal with that was to give them examples of success where even more complicated than difficult problems were encountered and solved, and basically remind them that we are capable.

We as a group are capable of solving those problems. So there will be two categories of fear. The one was the fear of it won’t work. We will basically have egg on our face with something that doesn’t work right. Brilliant engineers literally can solve any problem as long as it is within the realm of possibility.

And usually I used to remind them of all the problems you’ve solved before, and that typically works. The other problem that occurred. The other fear is that they make it work , on the, on earth, but when we launch it, the mission fails and there have been sufficient failures to have that fear to be invalid here and there.

My argument was very simple: it is incumbent on us to test this properly. Anything that’s tested properly will not. The only residual risk of failure is some environment that we are not aware of. And there’s no way we can cover for that. So 

Ryan: testing for the known factors really starts to drop the anxiety around that.

Correct? 

Dara: Exactly. So I would always be committed as a technical lead. I’ll be committed to that. The monument of our work was not going to be the design, how cool it is. It’s going to be the testing. That was the monument. That was where most of our energy, effort and creativity would go to figure out how to test properly.

And this is complicated, right? Because when something’s landing on Mars, where the atmospheric pressure is 100, the first gravity is three eight suffered. And there were temperatures that were cryogenic a lot of times, and there’s what you do not get in that environment on earth. So testing it properly, especially when multiple events are occurring back to back and back-to-back, and you can only do it in increments on earth.

Well, that takes a lot of creativity and a lot of planning and figuring out how to do it, that you’ve covered for all, all the spacecraft behaviors. 

Ryan: Yeah, every step of the way, it sounds like it’s crafting another level of exploration and opening people up to engineering solutions. 

Dara: Yes.

Yes. They’re techniques that oftentimes I would use to maintain momentum, even if we occasionally were heading in the wrong direction or I sense we would have to backtrack. I would never lose stagnation individually. You’re sort of stuck on whether we do now. This technique.

Was intentional. I, like everybody else, was afraid of falling flat on our face, but I had faith that solutions were going to present themselves. If I keep up momentum, if we stagnate in one place, all the ideas will stagnate around the one location and the ideas that would otherwise be available to solve the problem, but never come along.

If that makes any sense. 

Ryan: It makes a ton of sense. I actually think it’s a very profound thing that you’re saying is just the basic momentum. The basic philosophy of something will open up opportunities. And it’s a great reminder, because it’s easy to get stuck in the scope of a problem. And I think.

What you did highlights an example of something that has a huge scope to it. Right? But you can get mired in the scope of a problem, become fearful of it, and then not know what to do or not know how to keep moving. But keeping moving is really a key element to have the life breathing in and out of whatever project it is.

Dara: Yeah. And essentially it is really a model of life in life in evolution. Everything has to keep moving forward. They stagnate and they don’t have a chance. Technical developments, complex ones, are, in my opinion, very similar. Momentum has to be maintained even if you occasionally have to take a wrong turn and go down the wrong path, but you still have to.

Ryan: All right. Well, I think that’s a great segue. As we head into our top five tips, I really appreciate you taking the time to give us that rundown. We could talk forever about this. I’m sure there’s endless amounts of stories that you have. But I really appreciate you sharing an inside look into, at least one of those particular missions.

 How amazing thank you. 

Dara: My pleasure. 

Ryan: Listening to Dara. It dawned on me how the scope of a project can really test a person’s leadership skills in his world. He must consider the same important elements. Most projects face bringing a diverse set of skilled team members together, working toward a goal or a deadline and creating something that is truly polished.

But for many his mission objectives had other unique amplified elements. Including the unknown, not just working with unknown variables, but also working with unknown environmental conditions. It reminds me that tech leadership is always multi-dimensional, but often the qualities of those dimensions and their mysteries vary greatly.

 All right. Welcome back. We’re here with Dara and we’re excited to hear his top five tips on leadership. So let’s not waste any time jumping right in.

 Darra gives your first. 

Dara: Okay. First it is sort of like a go back to the conversation we had and I need to emphasize it a little bit. At least in my perspective, the most important thing I learned and became the cornerstone of how to do my job is the realization, acceptance and surrendering to the fact that my team does the work they do bulk of the work I don’t.

So that created a lot of. Decision points. And a lot of the techniques that I had to implement meant that I had to basically empower them and enable them. I had to make sure they had ownership of their job and they weren’t doing their job because they were told to do it. They were doing it because they were heart and soul committed to something they owned.

It was their idea or partially was their idea. They. The other aspect of it was credit that nobody had to feel at risk, that I was going to take more credit than they did. I would always go into the background and make sure they were in the foreground and the credit would always flow in the diary. So they never had that concern or fear , that they wouldn’t get the credit for the job they’re doing, that they’d be upfront and, you know, upfront and center.

This level of empowerment worked very effectively. Oftentimes when I had teams, the stronger members would do large portions of the job without even my participation, given how big the job was, then I could focus on helping those who needed the help of. 

Ryan: Yeah, I love that. I think that there’s a special space for leaders to actually step back and let people come in and rise to the challenge.

And I think it’s an easy thing, especially when you get into the credit thing that you’re talking about for people to lose sight of. And you actually lose the power of the team when you put attention on who’s getting, what credit, when does that happen? And if you can facilitate an environment that opens it up, but to me, 

Dara: Yep.

I’m going to give you one example, is that a mission that we do? And every Mars mission that we did, we would do a video at the end, which will go very public. And it was called the seven minutes or the eight minutes of terror when I was the Phoenix. More of a lead for entry, descent, and landing. they had already started this and I made sure I was not in the video.

I made sure that the working members of the team, the people who were even working at a  very detailed level were front and center on the video that went a long way, making the team extremely comfortable for the actual landing that was. 

Ryan: Yeah, I think that’s really powerful. You actually see, I think a lot of , the big tech companies are doing presentations similar to that, like Apple and Microsoft and Facebook where they’re really bringing a lot of the engineers forward to share the work that they’ve done.

And I think it’s incredibly powerful, because it is a big group effort across the. 

Dara: So that also segues to my next point, which is again about people. It is about listening. Most people who are new to technical leadership often try and feel like they know a path that only if they were everybody would do what they wanted because they have this vision.

It’ll be okay. So they tend to project more rather than listen, more projecting to others by, by basically speaking their ideas constantly. It doesn’t really matter. So I found that even the quietest voices on my team have extremely relevant things to say, and I had to listen. So my typical approach to the team was making sure that I am listening and more than I am projecting that I’m making sure that every quiet Mouse even those who squeak and barely want to say anything, because they don’t want to, the hassle is being.

I would even have sessions in which I would put all the members of the team together. And again, without allowing any criticism, have everybody speak their heart, what their concern was, how badly they felt about something, would they fall on their sword over something? I basically had these sessions of everybody spill your guts out.

When I felt like it, the team as a whole didn’t feel like they were being listed. 

Ryan: Do you feel like you have a safe environment for that, like that you took the time to cultivate the support within the team members to open that up? I mean, I know you had sessions for it, but would you work on that all of the time and the communication.

Dara: Yes. I always felt I had a safe environment because I knew the technique and ours had members of the team, other leaders that I had placed that also were familiar and comfortable with the technique. So I could trust that I had the, I had grabbed her on my side. I had enough people on my side that if there was any undue altercations, we could resolve it.

Ryan: Yeah, that, that was a great rundown. Let’s go ahead and jump to tip number three.

Dara: So again, we’re back to people and you will notice that you know of my tips, two of them are going to be about people because men you’re in leadership. It’s the people that matters 

Ryan: I completely agree. 

Dara: One of my findings early in my career was. When you’re designing something, a complex interactive system, the team is integrated into the hardware.

It’s a hard thing to describe, but there is no differentiation between the two; it’s a continuum. The system and the team are the same or one on the same. And the example I would use is that if you put two entirely different groups of people and give them, tell them to go design something complicated, two different products will come out.

So when you have two different teams, so different products coming, that means that your team was integrated into the. So you have to be very cognizant of that. And that also means that the meek members of the team and weakness often time is not that, that individual is weak it’s because they are not in the right place.

They are not in the right interfaces would basically introduce the highest 

risk. So being cognizant of how important people are, is to balance everybody’s job based on their capabilities, based on their bandwidth and their school. and that became a cornerstone of how I did my job when I, whenever I had the team.

Initially spend the time to gauge how they are without making very strong commitments of who’s going to do what. And then I continually balance their jobs, to the point that everybody felt comfortable and suited to their job and worked well together. And that’s why I came up with reasonably good systems because the team that was integrated to the system was working.

Ryan: How did, how do you think that plays into people protecting their job titles and people trying to like work in hierarchical positions within an organization. Do you have to balance those aspects of it as well? 

Dara: Absolutely. That happens all the time. One of the biggest risks you run into is that everybody’s worried about where they are in the organization box, what their title is, what their predators are, and that’s a distraction.

So a lot of my job used to basically work with those people to essentially convince them that they were in the right place, that what they were doing was going to work for them, that the alternatives they were thinking about. I was not as attractive as they perceived because ultimately being on the classic project that they were on.

No matter where they were on the organization chart was going to give them open all the doors they wanted. I oftentimes succeeded in doing this now there are people that are stubbornly cleaned into what’s my title, et cetera. And sometimes you just have to make it up a title and give it to them literally.

Ryan: Yeah. I think it is. It is this balance of, What you’ve achieved or the accolades you’ve received within a specific type of role and actually what it takes to get something done. The actual implementation of getting a Rover on Mars, right? Like the, so like once you’re in that bubble of lack of actually executing on the project, it makes sense.

Like we kind of have to work with what is and make it happen. So that balance is achieved when you’re talking. 

Dara: Yes. Yes, exactly. 

Ryan: Great. All right, let’s jump to tip number four. 

Dara: Okay. So I’m going to switch a little bit too technical. 

But what I’m bringing up really applies to any technology. One of the biggest pitfalls I discovered was prematurely believing in good results. So you do a test. It gives you exactly the result you want, and you say, hallelujah, I did it. I’m successful. I’m done. Move on to the next. So to that, That’s what I used to tell myself.

And there is no word that one of successes could have a lot of associated caveats. You did not discover, or it may not have been a success at all. And there may have been embedded flaws in it that you didn’t discover. Actually, I got it. Really carefully examine the successes, making sure that it was truly a success and it wasn’t some kind of false Mirage.

And I’m going to give you one interesting example. Okay. I’m going to go back to Mars Pathfinder because this example comes from there. We had to do a solid rocket motor drop, these were deceleration motors, and we would drop a platform in the desert on a parachute.

The rockets would fire and we would measure how much impulse they gave us. It sounds simple, but test after test failed simply because the parachute wasn’t big enough, the pin wasn’t in place, et cetera, different test failures. When we had the successful test. Everything was successful. We measured the impulse, but the parachute, the cargo should fail to come on and the hardware hit the ground.

So we didn’t get it. This is my own failure, which has become my lesson in this case, was that later on I sat and I was looking at the high speed recording of the rockets, and I saw this, unanticipated behavior in the rocket image. The big plume of the rocket solid rock and model should be pretty consistent.

And I noticed that he wasn’t in one image, the floor will be smaller in another image with.  My lead engineer, who was, we used to say the, or resident rocket scientist also felt a little bit more impulse, which is very technical, but the message, the moral of the story is something was wrong.

And I had a successful test after a lot of failures. I didn’t want to entertain something that was wrong. I wanted to just be successful and move on. 

Ryan: Yeah. Yeah. And I, that is like having that kind of exhaustion from the whole process. Correct. Right. It makes you just see what you want to see in the test.

Dara: Exactly. So the test was successful from what we were testing, however, in the process of testing. Another failure mode was discovered, which originally destroyed the data acquisition system. We didn’t see it until we were able to literally get the components of the data acquisition system already constructed.

And we realized that rockets had gone. They were basically when a rocket goes unstable, it’s a, it can blow up on you. So, and this was a very unique historical event, never seen before multiple unstable in phase things. The VR things that happened to you, but the moral of the story, again, was you have successful tests.

Don’t throw up your hand your hat and don’t say, I am, I’ve done it. You’re good to go. There may be embedded or hidden problems that are a lot worse than what you were trying to measure. Yeah, that 

Ryan: was a good example. Yeah. Because those, those, those, those experiments can lead to very kind of tight sliced looks at what you’re trying to find.

But I missed it. Finding huge things that you can’t, that you weren’t testing for in that environment, but maybe you needed to know about 

Dara: yes. And you wrote the right word too exhausting when you’re exhausted. You just want to move on. And most people are stressed and exhausted at that point. The motivation to call it a success and move on.

It’s pretty high. 

Ryan: Yeah. And there’s a lot of potential danger in doing that, especially with something with this kind of scope at stake. Yeah. All right. Wonderful. Thank you. That’s another great story. That was amazing. Let’s move on to tip number five. The last one, 

Dara: The last topic is important enough that we touched on it in the previous conversation.

And I want to sort of bring that up and that is essentially how we generate momentum. The generation of momentum means that people are doing work that is moving forward. Even if you have to backtrack in the future, it creates a lot of complexities that you have to be ready to deal with.

One is that. Making decisions on 70 percentile information being a perfectionist would lead into a stagnation point in which you’re just trying to Polish the cannibal and get everything just right to move on. Well, forget the criticism you’re going to get, if things go wrong, just accept that criticism and move on.

And when you make decisions on 70%, there is a small chance that you’re actually going to get. Some areas where you may want to do something different. Now, those are tricky, meaning that if you change, you could create an unnecessary improvement, without, and undermine your momentum. So you have to be very careful only when you really feel it’s warranted.

Then you have to basically accept that you made a mistake. And move to a different concept or changer, but all of this essentially revolves around maintaining that momentum. If you have to change something, do it quickly. I never used to hesitate when I had to change a design or when I had to accept the change, there is nothing worse, nothing more caustic than everybody constantly regurgitating.

Should we change it or should we not? Or. The amount of unnecessary hallway conversations and unnecessary acts they create. It’s too much of a distraction. So if you have to change, do it quickly, , the first approach is to develop the intuition of whether you’re at 70% all information. And if so, proceed, don’t hesitate.

Ryan: Yeah. And I think you bring up an interesting point, that I think sums up a lot of this conversation for me, which is the power of the collective group that you’re working with. And in this case, maybe scientific or engineering. Like built within the total group is often much more powerful than anything an individual can bring to the table.

So stalling out on any individual’s fear or any individual’s lack of knowledge is somewhat problematic when you really have access to a much bigger kind of hive that you’re thinking about that you can tap into. And so keeping the momentum going so that you can open those up as powerful.

And, and I see that within a lot of what you’re talking about. 

Dara: So Roy, you got it just right. You nailed it. That’s exactly the problem. The highest risk is that individual is yourself. If you’re the one who they think that damage is worse than any member of your team hesitating, 

Ryan: cause it’s easiest for you to block the whole thing.

Yes. 

Dara: You can stop everybody and create this almost like a psychological environment where everybody becomes. unstable and insecure about what they’re doing. 

Ryan: Very, very important lesson for leaders. And I think it’s one they can be simplified down to don’t get in your own way. Right.

That’s a kind of classic statement, but I think the more nuanced and. Appropriate version of this is that you, we really are dependent on lots of great minds in technology fields to create and invent and come up with things. And we have to open up the path for them to do that. And as leaders, it is our job to open up the pathway for that.

And I think you’ve done an amazing job of showing exactly how that works at some of the most complex scientific levels that we run into here, in any of the work that we do. As people. So I, it’s amazing to hear this. 

Dara: Well, thank you. I think it resonates very well with what I’m saying. And essentially, one last note I believe is that in implementing all of these different points and ideas, there is the factor that there’s no one size fit.

Every situation is different. And in every situation, the path is somewhat dramatically, drastically, and sometimes slightly different from the last situation. So that just big, that’s just occurs with you paying attention to the differences or individuals paying attention to them, differences of their new situation, to deal with it 

Ryan: and enjoying that.

 That is actually enjoying the fact that everything is a little bit different and you get every new project you enter, every new company you start, every new experiment you run. You’re  going to be in something that is fluid and different and requires you to actually enjoy the process of figuring out.

And working with people to do that. Yeah, exactly. Great. I love it. Thank you. It was a true pleasure to talk to you today. I appreciate all that you’ve done for , really, mankind in helping us explore some of these new spots, but, really appreciate some of the thoughtfulness and depth in your leadership that you shared.

It’s really powerful. So thank you for joining us, 

Dara: But it was my pleasure, Ryan, and thank you for having me. 

Ryan: Alright. Great.

One thing that keeps coming up for me, as I listened to Dara balance, balancing a team’s capabilities, balancing the distributed workload of the project and balancing how you as a leader, bring both inspiration and. Haitian. I deeply appreciated the magical qualities of this type of engineering.

He helped lead. He got to help lead missions to space, a dream. So many of us have had at some point in our lives, but I also recognize that what he is bringing to life as a leader is very much consistent with even the most boring unglamorous software project. The balance aspect is consistent no matter what.