NASA Johnson Space Center Engineering Director Julie Kramer White discusses the skills required to be a top-notch engineer.

Julie Kramer White: There’s a difference between engineering opinion and engineering judgment, right? So, engineering judgment is based in physics and experience and data. And so really holding our folks accountable to stay grounded in those standards, tailor them as applicable, right, but not confusing engineering judgment from engineering opinion to really just stay grounded and true to those best practices.

Deana Nunley (Host): Welcome back to Small Steps, Giant Leaps for the final segment in the Engineering Best Practices series. I’m Deana Nunley.

On this NASA APPEL Knowledge Services podcast, we tap into project experiences and share best practices and lessons learned.

During this four-part series we’ve had the pleasure to chat with agency, mission directorate and program engineering leaders. Today, we take the conversation to the center level and get the opportunity to chat with Johnson Space Center Engineering Director Julie Kramer White. Julie, thank you so much for joining us on the podcast.

Kramer White: Thank you for having me. I’m looking forward to the topic.

Host: With more than 30 years’ experience as an engineer at NASA, you’ve had the opportunity to work with a wide variety of engineers. Based on your experiences, what would you rank as the top five skills required to be a top-notch engineer?

Kramer White: Top five skills? Well, I think you have to start with technical excellence. So technical domain, I think really everybody gets that one. That’s kind of the obvious one. Be really comprehensively good at something. It’s probably less important what technical domain it is that you choose to excel at, but it’s important from the perspective of having done it. Having come from college, had to learn a specific domain, work your way up through that discipline, and become known as an expert in that area.

I think the second thing I would say is you start looking towards more experienced engineers. Better engineers would be systems thinkers. So very seldom do our widgets operate alone. And those widgets need to be integrated to make successful spacecraft and successful missions or campaigns. So just kind of above that technical domain would be that being a systems thinker and understanding how your system operates amongst a myriad of systems that make space flight successful.

I think something that’s super important for NASA engineers is to be curious. And I say NASA engineers specifically because I kind of feel like at its heart, that’s part of our reason for being, that intellectual curiosity, not just check the box, not just get it on with it. But to really, really, really question do we understand the physical phenomena that’s going on there? And that’s part of what allows us to do things like generate models of things that people have never modeled before, physics-based phenomena. And so I think that’s really a big part of what NASA does. So that sort of intellectual curiosity about what is going on and improving understanding is super important.

Maybe a little surprising to some people, the next two have to do with communication. So, it would be both be a good listener and be a good communicator, kind of as four and five. When you talk about being a good listener, diversity of experience and perspective is so important. And really, the harder the problem, the more important it becomes. We’ve got a lot of really talented people in the agency and in the commercial space industry. And so kind of being open to what other people see and perceive about what’s going on is always best in terms of getting to the best answer.

Number five, it would be communication. Basically, everyone I talk who’s in engineering school or beginning engineers, I talk about the importance of communication. It’s just super important in everything we do at NASA and in aerospace in general.

Host: Why is good communication so important in engineering?

Kramer White: Well, good communication could be as simple as asking the right question or providing the right data to a customer. You want to be able to kind of get down to the heart of the matter in a concise way and be able to give your boss or your customer the right data to make the right decision. But it’s also about being able to make a cogent or compelling case for why to do or not do something, which is a big part here of what our engineers do here. Communication is such a foundational part of leading people in terms of building trust and credibility with your customers. And really, from an engineering perspective the big thing we do, I feel like, is we provide the correct data to allow managers to decide on risk. So if you can’t communicate, you can really understand your technical domain, but if you can’t communicate it, it’s like a tool that you can’t use.

I used to joke that when I was younger that I really made my living on the fact that I was a universal translator. So, I could sit in a program meeting and I could listen to the program manager and I would turn to the engineering team and I’d say, ‘Well, what they’re really concerned about is X.’ And then the engineering team would say, ‘LA, LA, LA, LA, LA,’ and the program manager would look at you like ‘What?’ And I’d say, ‘OK, what they’re really telling you is this.’ And so, just that process of being a conduit for those engineering folks, to be able to communicate clearly and concisely with the program manager, is actually a super valuable skill in and of itself.

Host: For engineers who find that effective communication doesn’t come naturally to them, what advice would you offer to improve this skill?

Kramer White: Sure. Big shocker that most engineers are ISTJs, so they tend to be introverted, a lot of them not necessarily great communicators. A lot of people are always surprised when I say I’m actually an ISTJ as well. I’m pretty introverted. And so I will promise you it is something you can learn to do. It’s really just, it’s a matter of practice. I think a lot of times engineers are very detailed oriented so they can get lost in the details. So it’s taking a minute, really knowing your audience and their capabilities and their limits, is important when you’re trying to communicate with them. And as you probably are well aware, engineers really like to be right. My husband tells me this all the time. So it’s a good part about listening and leadership to be able to listen to input from your customers and maybe come at the argument kind of a different way if you’re not getting there.

And I always point my younger folks to, there’s a series of training and books. Crucial Conversations is the title of the book. And I really like it because it teaches you kind of how to step back and be able to formulate and communicate in a situation where stakes are very high. Not necessarily speaking to space per se, but in situations where it might be kind of an emotionally loaded conversation where either you feel very strongly about it or your customer feels very strongly about it, and you’re just not getting there. So how to kind of step back, get people listening, and be able to communicate the important parts and why people should be listening. So I always try to point my guys to that. And like I said, it’s really just, it’s a matter of practice.

Host: Yeah. And we have a Crucial Conversations course that we offer on our Apple Knowledge Services website. We’ll be sure to post a link to that related to this podcast.

Kramer White: Yeah, absolutely.

Host: So, we’re winding down a four-part series on engineering best practices. Much of our focus during the series has been on the role of chief engineers, engineering leadership, safety tenets, and sharing engineering knowledge. In today’s episode, we want to spend some time talking about engineering best practices — in practice. So, do you have examples of engineering best practices — in practice — at Johnson Space Center that you could share with us?

Kramer White: Sure. I think you’d be hard pressed to find any engineering organization that doesn’t have lots of documentation on best practices. But some of my favorites and probably the best-known ones around Johnson and probably across NASA in general would be things like 7120 and 7123, which they are somewhat project management. So, the project management guys may go, ‘Hey, those are mine, not engineering’s,’ but they are engineering’s as well. They define key systems engineering attributes about your program. They define expectations for milestones and kind of what kind of engineering products should be there. And then below those, there are whole tiers of engineering best practices, whether those be specific specifications associated with development of specific systems, or whether they be general specifications. If you’re talking to some folks, say at Goddard, they would talk about Goddard’s Golden Rules, a generalized handbook on kind of how to certify space flight systems.

We use JSC 8080 here at Johnson. And it basically is lessons learned after 60-plus years of human spaceflight. Things like separation of critical systems to maintain redundancy, or best practices in environmental test and how much margin you should have in the test based on what kind of environments you’re testing, or best practices and how to correlate models and what kind of correlation coefficients you should have in correlating those models. Based on just a lot of experience and failures, and therefore knowing kind of how much margin you want to build into that system. So there are lots of best practices.

A lot of them are specific to centers. Although we do try, as a community of practice to try to get everybody on the same standards. Sometimes there are some differences, human spaceflight say to satellites or rovers. They’re there for reasons. And I’m sure we’ll talk more as we go through this process about why the requirement is what it is, or why the margins are at Johnson versus Goddard or versus somewhere else. Those are for reasons and they tend to be important reasons. So understanding the why is super important as well.

Host: Well, and continuing that, what have you observed at JSC in terms of the rigor and discipline it takes to define and follow best practices?

Kramer White: Well, it takes a lot of rigor to define them because engineers don’t like to write down lessons learned. That’s the big problem. Once you get done with the cool stuff in the lab, who wants to sit down at their computer and actually write all that stuff down? So it is a little bit of a challenge for us sometimes to maintain the discipline to write that down, to update standards. Usually if I’m sitting in my conference room and I say, ‘Hey, we really need to talk about having a standard on that,’ everybody starts looking at their shoes, because nobody actually wants to write it. It can be a painstaking process, frankly, sometimes to write some of these specifications. So it does take some wherewithal. But in general, it is a good thing to do it because it helps us maintain that continuity generation to generation and helps us get those lessons learned.

I would say the biggest challenge we have perhaps in following those procedures would really be that we have what I would like to call a healthy tension, kind of always that exists between engineering and programs. The programs will talk about engineering will always find more work for to do. We have to maintain cost and schedule, and better is the death of good enough, and all that stuff. And that stuff is all very true. But I think in terms of the way we provide healthy tension into that system is by defining lessons learned, understanding those lessons and best practices, and how they apply to their specific program. So we even see, we all have the same pyrotechnic standard that bridges all of our major human spaceflight programs. But we encourage our folks to be focused on the proper way to apply those standards for any given program and to tailor them appropriately, whether it be based on the risk posture of the program, based on where they are in their development cycle. So there’s definitely a tailoring process there that needs to occur.

And that could be a big challenge for our folks to know when is it good enough? And so that’s where having an organization that has a lot of continuity historically, kind of understands the why of a lot of these requirements. Our younger folks can go to the graybeards and ask them kind of what their thoughts are on a given application. And so that’s where the depth of the organization really helps in trying to do some of those things.

But I think the thing we need to avoid, there’s a tendency when there’s a lot of cost and schedule pressure, folks will say, ‘Well, I think it’ll probably be okay.’ And that’s engineering opinion. But there’s a difference between engineering opinion and engineering judgment, right? So, engineering judgment is based in physics and experience and data. And so really holding our folks accountable to stay grounded in those standards, tailor them as applicable, right, but not confusing engineering judgment from engineering opinion to really just stay grounded and true to those best practices.

Host: Do you have a couple of engineering stories that have stuck with you?

Kramer White: Oh, well engineers always have engineering stories. I’ve worked on every human spaceflight program since shuttle. Gosh, such great programs and such great people and stories, in all of them for sure. But I wanted to pick a couple that I think will be relevant in terms of some of the things we’ve talked about in what it takes to be a top-notch engineer. But also some of the things we’ll probably wind up talking about around engineering excellence. So it wouldn’t be a shocker that one of them would be a big incident, and so let me talk a little bit about Columbia. Columbia carries with it, gosh, so many lessons learned that are attached to engineering excellence. I think a favorite engineering saying, but one that couldn’t be more true is, always listening to the hardware.

Even if you don’t think it could be possible, when the hardware is behaving in a way that it wasn’t designed to behave, really dissecting that and really working to root cause in order to make sure that you’re not fooling yourself about, ‘Oh, well, it’s probably OK.’ Well, why? Why? You ever heard that thing you have to ask yourself why like seven times or something before you get to the end of it? But to be very curious when the hardware is not behaving the way you thought it should behave, and making sure you understand why, in a physics-based way, why that is happening. You don’t ever want to be sort of caught in what you would call a failure of imagination. I can’t imagine that failure, so it can’t be true. And the hardware’s talking to you and we need to pay attention to that. Columbia had a lot of those hallmarks in that disaster.

Turning to perhaps just a very different scenario, something like Ascent Abort-2. So as a chief engineer on Orion, we wound up executing an in-house flight test program called Ascent Abort-2. And I think that one is just really a good case study in persistence. Never be afraid to ask one more time. So this test had happened after sort of years of just can we do this in house, because we’re not getting there and we think we could bring it in house and get it done faster. One more time. Every budget cycle, I would go into the project manager’s office and say, ‘Hey, really, look. We ought to talk about doing this in house.’

And finally, if you really feel like you’re not getting what you need to be getting, just continue to be persistent, continue to ask, continue to elevate, just hang onto it and keep arguing for it. And eventually if you work on your communication, and you work on the argument, and you bring the data, eventually you will get to the point where folks will understand that we’re missing something and that there is a better way to do it. So I think all engineers have to be curious, they have to be flexible. They have to be willing to come at problems different ways sometimes to get them solved. And I think something like Ascent Abort-2, where we wound up bringing a bunch of work in house to do it, it’s not intuitive that we would get that done faster. But in the end it wound up being a big win for the program and coming at a really crucial time. So I think there are just so many stories out there with good lessons learned for engineers about how to get stuff done.

Host: Julie, even when the workforce has strong engineering skills and follows best practices, failures can still occur. What are your thoughts on failure and how engineers can best learn and grow when they do experience failure?

Kramer White: Sure. What is it? You’ll hear the expression space is hard. And it’s hard in an environment that’s extremely unforgiving, so you almost can’t even imagine that we do the thing we do without incurring failure. I think that balance is not wanting to have failure while at the same time realizing it’s inevitable, and it’s part of the learning and growing. As hard as failure is for us as an organization, we all foundationally know that is part of the process. It’s part of learning and growing as an organization. I think the best thing we can do is to build on it and really inform our understanding. So I think what we try to make sure our younger engineers know is there’s nothing better than to actually build hardware and let it do its thing and learn from that.

So, whether it’s prototyping or simulating or bread-boarding, nothing will tell you the reality of what’s ahead of you faster than prototyping the actual hardware and putting it through its paces. And part of the paces you’ll be going through is failing. You’re going to build it, you’re going to think you’re really smart, you’re going to think it’s going to work. You’re going to put it through this environment that we call simulated environment on the ground that’s going to try to replicate the environment it’s going to see in space, and it’s going to fail. And it gives you a chance to redesign it, make it more robust, understand how the system is working. And that’s the best kind of knowledge, the best way to learn and grow around those failures.

Host: Do you think experiencing those failures that in some ways seem inevitable, is harder on a young engineer than someone who is more seasoned and has been around for many years?

Kramer White: Mm, that’s a good question. I think it’s hard for different reasons. It’s hard for a young engineer I think because they feel like they’re trying to prove themselves and they see maybe failure as embarrassing or maybe a little bit of a hit to their ego. I think probably they feel worse about it than we would want them to feel about it. We would look at that and go, ‘Well good, then you’re going to learn.’ I think a more experienced, seasoned engineer may be a little more grounded understanding, ‘Hey, I’m going to learn something through this,’ but they also, the failures tend to be more spectacular if you know what I mean. So the more senior the engineer, then typically the stakes are higher and the mistakes can be bigger.

But at the same time, it is fundamentally the same. You have to walk away from that failure and say, ‘What could I have done better? What should I do better in the future? What lesson learned would I take from this? And do I really understand the why so I can carry that forward appropriately to the next program and not do it again?’ It’s the doing it again part that can be problematic.

Host: How do you expect engineering to evolve during the careers of NASA’s young professionals, say over the next 10 to 20 years?

Kramer White: That is a great question. As a matter of fact, I would kind of say that is the question that is in today’s NASA. Probably the question that I spend the most of my free time thinking about, not that I have a lot of free time, but the time I do have, or when I think about talking to our young professionals, what is it I see for them in the next 10 to 20 years. I think the biggest thing is that NASA’s no longer alone. When my mentors were here, it was NASA leading the way with a handful of steadfast prime contractors and subcontractors that did 90-plus percent of the work. Gosh, probably more than that, probably 99 percent of the work. And that’s not the case anymore. The commercial space industry is growing at a quite amazing clip. And virtually all segments of it, whether it be satellites, whether it be human space.

So, there’s just a lot going on there. And that provides unique opportunities and unique challenges to NASA as we transition in today’s environment. So what I tell my folks is I still require that we produce engineers that have technical excellence and are innovative. To do the jobs that we envision in the future for you, it still requires that you have experience and scar tissue of hardware development, because I need you to be leaders. I need you to be people that can both help commercial companies that are trying to break the barriers and get into space, and for us as NASA to turn to the next page in our book, which is cislunar and beyond. So I still need you to have these hallmarks of technical excellence. And then on top of that, I need you to be leaders because I need you to be leaders of industry, leaders of international partners, integrators of campaigns that have widgets that are government-provided, industry-provided, international partner-provided.

And so, it’s all the same base skills of technical excellence that I needed before, but now I need you to up your game now and be people that can remove barriers, people that can communicate, lead, integrate, all those things we talked about a little bit earlier in terms of what it takes to be a top-notch engineer.

Host: Really interesting. A final question as we close this series on engineering best practices. Reflecting on your observations and experiences across NASA programs, such as space shuttle, International Space Station and Orion, how would you summarize engineering excellence?

Kramer White: Oh wow. That’s a tough one to put kind of into an encapsulated answer. So I’ll take a minute and talk about something I always think about when I’m in the middle of a really tough problem. I always revert to what we call the seven elements of flight rationale. As a matter of fact, I know a couple people that have like big posters of it printed and stuck on the walls in their offices. And it came out of Columbia actually, but, but it was intended to say, ‘Stop and look at what you’re doing, and does it have all these hallmarks?’ And it was specifically talking around flight rationale, but I think they’re good things for all engineers to ask themselves about the engineering work they’re doing. And the seven break down kind of like this.

One is: Do you have a solid technical understanding of what’s going on? Do you understand root cause? And we talk about that a lot. I talked about it a little bit earlier in terms of understanding the physics, the fundamental understanding of what’s going on.

They talk about, do you understand what’s happening relative to experience? How is this different? How is it different than what we’ve experienced in the past? And under this banner, I would say we watch for things like normalization of deviance, which was something we saw both in Challenger and in Columbia, where the hardware’s speaking to you, you see it happening, you don’t really understand why it’s happening. And then you convince yourself, you rationalize to yourself. These are all words you shouldn’t have in engineering, right. I’m rationalizing to myself. So making sure we understand the condition relative to experience.

We ask ourselves, have I worked the bounding cases? You’re always kind of looking for the corners of the box. This is something actually that NASA does really, really well. And some people will say we overdo that. And I will say, ‘I disagree.’ I think that’s our job is to kind of be looking at the corners of the box. It’s something, like I said, that we do really well in making sure that we understand the bounding cases that we could encounter in a mission. We ask ourselves, ‘Is the process self-limiting? Is there a physics-based reason why sort of what we’re seeing today is the worst case that it will ever be?’ It kind of goes hand in hand with the bounding cases. Do we understand the margins? Are the margins understood? How far are we from any kind of performance cliff? Do we understand how the hardware’s performing and how it could fail? And so demonstrating that we have the right margins is obviously super important in everything we do.

And are we doing assessments based on data? And this is the data versus opinion thing. Let’s not talk about opinions, let’s talk about data. Let’s understand the assumptions and gaps and articulate those to our decision makers. So I think it’s super important that we make decisions and assessments based on data. And then do we understand how any other given element might interact with the element we’re talking about? So, this is the cross-element integration.

So, these seven elements of flight rationale, solid technical understanding, condition relative to experience, bounding cases, self-limiting, margins understood, assessments based on data, and interaction with other elements. These are great questions to ask ourselves, and I think really are the basis of engineering excellence in terms of the data and the answers we provide to our customers about operational spaceflight programs. I think the work we do really requires that we be innovative and ground ourselves in best practices, but always understand why things are happening. And so, when I look at these seven elements of flight rationale, to me, they really summarize good engineering work around operational spaceflight programs, which is how I’ve grown up at Johnson.

Host: Julie, it has been great having you on the podcast. Thank you so much for sharing so many insights, your experiences, and observations. This has really been rich. Thank you.

Kramer White: Oh, you’re very welcome. Thank you for having me.

Host: Julie’s bio and links to topics discussed during our conversation are available at APPEL.NASA.gov/podcast along with a show transcript.

We’d love to hear your suggestions for future guests or topics on the podcast. We’ve received terrific recommendations from listeners in recent weeks. So, thank you very much for that. And we plan to feature those topics in upcoming episodes. If you have a suggestion, please share your ideas with us on Twitter at NASA APPEL – that’s app-el – or contact us via the NASA APPEL Knowledge Services website.

As always, thanks for listening to Small Steps, Giant Leaps.