Anna McGowan, NASA’s Senior Engineer for Complex Systems Design, discusses engineering trends and the impact of rapid technology changes.

Anna McGowan: Change is becoming the new steady state. And that change can be superfast.

We need to be open to the fact that the experts that we have on staff today may not necessarily be the same experts that we need tomorrow as new disciplines come onboard for us to use.

Design thinking approaches are really not just for the big-E engineering just before the major requirements are set for the entire system. They are for all along the way.

Deana Nunley (Host): Welcome to Small Steps, Giant Leaps, a NASA APPEL Knowledge Services podcast that taps into project experiences to share best practices, lessons learned and novel ideas.

I’m Deana Nunley.

We’re kicking off a two-part series on complex systems engineering. Today, we’ll consider latest trends in engineering and the impact of rapid technology changes.

Anna McGowan serves as a senior technical advisor to NASA leaders in the area of complex systems design and is our guest for this series. Anna, thank you so much for joining us on the podcast.

McGowan: Thank you so much, Deana. I’m glad to be here.

Host: With the dawn of this new decade, are you seeing a new landscape in aerospace?

McGowan: Yes. What a great question. So, there are several significant shifts in the aerospace industry that have been developing for many years. So, first looking at the company makeup. So, if you can remember when we had a relatively small number of large and medium-sized companies in aerospace. You know, companies like Boeing, Lockheed, Raytheon, and their suppliers. Today, the aerospace industry has a very different and diverse array of numerous small to large companies that include some non-traditional companies that are using aerospace in some really new ways. So, this also means that the applications of aerospace are also evolving. In decades past, aerospace was primarily focused on major and kind of nation-focused purposes, such as defense and commercial airline transportation. But today, we’re seeing a great expansion of applications, of both air and space flight. And, so, things like space tourism, drones for agricultural use, and urban air mobility are no longer some kind of futuristic dream. They’re actually current realities.

So, with this in mind, thinking about funding, previously a lot people used to think of aerospace as a predominantly government-funded thing because there was a lot of civilian defense-related needs. And those are still there, for sure. However, now we have the rise of many very visionary venture capitalists and major companies like SpaceX and Blue Origin from Amazon and others that highlight that private funding in aerospace really changes the landscape and diversifies the opportunities for the future of aerospace. So, it’s kind of exciting to even be able to dream about where that might take us, and with speed.

So, we all know that technology is changing rapidly, right? We’re all changing our cell phones more frequently. But, in aerospace, it was common to expect in the last millennium, if you will, that decade-long changes were relatively common. But today, with the rapid technological changes happening and industrial changes happening as well, that means that the aerospace landscape now shifts much, much more quickly than it ever has before. And this last shift that I mentioned means that the types of expertise that we need in aerospace also changes rapidly. So, previously, the center of gravity for the kinds of expertise you needed often hovered around very classically aerospace-specific expertise capabilities. But today, with the diversity of changes in industry and applications for aerospace, there’s a much greater need for non-aerospace professions. If you can think about fields like data science and information science, social scientists, urban planners, tourism specialties are now becoming a part of the aerospace profession and really blending those skill sets and taking advantage of what non-aerospace professions bring to aerospace really gives us an entirely new landscape that’s really exciting.

Host: Are there megatrends for engineering large, complex systems that are capturing your attention?

McGowan: Yes, there certainly are. When we talk about large, complex systems, we’re talking about things like aerospace systems, naval architectures, and major civil infrastructures, those types of systems. And, certainly, there are a lot of great studies out there describing different megatrends. But today, I’ll just mention a few here. One is the incredible explosion in the amount of data that’s being generated and used each day. Many studies estimate that more than 2.5 quintillion bytes of data are being generated per day. And this is roughly equivalent to like 250,000 Libraries of Congress per day. It’s mind-boggling. And it’s also really powerful and drives and changes how we work.

So, the other megatrend that’s associated with the data is that networks and ecosystems now add to hierarchies in terms of how we organize ourselves, and how we work, and equally important how we understand how our systems work. So, this changes how we might design and engineer them. And so this cyber connectivity enables us to work differently and enables our systems to function fundamentally differently, more in a network or ecosystem.

And so, the next major megatrend I’ll bring up is that the capabilities enabled by additive manufacturing really allow some radical changes. And years ago it was common to think of additive manufacturing as something whose benefits were kind of limited to the manufacturing stage of system development. But now we appreciate that that’s far too narrow of a perspective and the opportunity space is much greater. For example, you could prototype early on to understand and communicate what you, how do develop the design in a new way. You could also begin designing for some new goals. You know, shorter lifespan, more sustainability, et cetera, than you could have before. So additive is really a gamechanger.

Another big megatrend that I mentioned a little bit previously is technology change accelerating so rapidly. And this really affects large-scale systems in engineering in a major way because you’re used to developing, let’s say, an aircraft or a rocket. And you would have that same artifact, that same system, for quite some time because it takes a lot of money and effort to develop that. However, all of our systems now are highly interconnected and interoperable with other things. And so while in the last millennium, it could take a decade or so for a new technology to take root and be used extensively, today it can take just a few years, or even much less, for a new technology to impact our engineered system. And so, because we work in technology, change is becoming the new steady state. And that change can be superfast. And so, if what changes outside of our system is changing quickly and is connected to our system, then that means we also need to be able to adapt our systems to work and do so very resiliently. And for our workforce, this means that from the very beginning of any project we have to prepare for not only continuous change, but pretty rapid change. And so, our systems have to be designed to evolve. And resilience becomes not a nice-to-have, but kind of a crucial capability in our technical systems.

The other major megatrend I’ll bring up is what I’ll call designing the how, designing processes and practices, getting a greater awareness of the opportunities for tailoring and designing how our human and organizational processes and practices integrate with our engineering product. And so being able to take advantage of being able to really create the right methods, processes, and tools and organizational systems to get the right output. And this is especially important as we begin working with some non-aerospace disciplines and begin integrating with aerospace, including, again, like operations science and data science and social sciences working with aerospace.

Host: And so, Anna, what do these trends and rapid technology changes mean for NASA as well as other government agencies?

McGowan: So, I will take a couple of these megatrends and maybe unpack them a little bit. And I think beginning with data is appropriate, since that is central to many of the things happening today. So, we have this great explosion in the amount of data. So, the amount that we’re generating per day is just unprecedented. And that’s really because of the cyber prevalence in nearly all systems. So, this means that our traditional means of handling data will become overwhelmed. And for our workforce this means that we need to be able to design new ways of working with and using extreme quantities of data. And likely this means using some high-powered data analytics and even artificial intelligence. And that’s not just something for the future. That is for now because the data is coming in very rapidly.

And so, also, it’s important to have a very well-designed and adaptable information architecture considered in advance. Previously, when we designed engineered systems, your information architecture wasn’t as crucial or as central to your design and engineering of your system. Now, it is absolutely core to what we must do for all the things that we work on. So, to handle this data, this does mean that we also need to be able to work with some special skill sets. So, for our workforce it means working with people that may have a data science, business analytics, information science background, AI background, or even a decision science or statistical engineering background, to name a few. And so, our leaders really, we need to be open to the fact that the experts that we have on staff today may not necessarily be the same experts that we need tomorrow as new disciplines come onboard for us to use to handle the data well. But the opportunities really are where we should focus.

So, with these new skills and with the abundance of data, we can now then exploit this data abundant opportunity to improve our decision making on our projects and missions to enable even higher quality data-driven decisions. And if you take that to not just the project and mission level, but to the organizational level, then our organization leaders can now consider that anonymizing data from individual projects in missions and then feeding that into like a machine learning system can then generate some really rich insights and help many more projects as we bring it all together and understand trends.

The next major megatrend that I’ll just kind of unpack is this idea that networks and ecosystems can be a better descriptor for our engineering and human system. So, what’s really important here is that cognitively how we frame a problem is how we solve a problem. So, by adding a networked understanding of a system to our repertoire gives our leaders and workforce an additional tool in how we design and engineer solutions and how we operate in the organization. Historically, we kind of thought that and organized things by breaking them down or decomposing them into a neat hierarchical structure. And therefore, we expected most connections to flow through that hierarchical structure. This shaped how we understood our technical system, and even how we formed our organizations. So, while having this hierarchical framework is still definitely useful in many cases, increasingly more situations are better represented by a network or ecosystem.

And why this matters is that for leaders to consider that if your system is operating like a network, this means that you might have some connections that are taking place that are outside of the hierarchy that you have in your mind or even on paper. And so, these connections create innumerable different interfaces. So even if you just have, say, 1,000 components in your engineered system – which today is relatively small – that could create as much as a half-million different potential interfaces, because the computer can actually create connections that the hardware alone we never expected to be there. So, what happens now in the networked or ecosystem environment is that not all possible interfaces can generally be fully tested, and therefore not all possible system states can be fully known.

Now, this sounds really scary, right? And so, how might we handle that from a workforce perspective? So, once we appreciate that there’s an expanding number of potential interfaces in the systems and that these interfaces can be engineering, they can be computer interfaces, they can be organizational or institutional interfaces, or as an interface with the services, or even the infrastructure that we rely on. Once we consider these different interfaces, it gives us a better chance to capture risks to our home system. When we only consider the engineering interface, and when we only consider what we think is in the hierarchy, we miss some important information about what else is connecting to our system.

Organizationally, how we can handle some of this is using some work from an area called high-reliability organizational theory, or HRO theory. Some of the tenets of that theory says have a bias toward experts and operators, and not just authority figures. So, if you consider in advance how might your subordinates with great expertise have an opportunity to potentially challenge authority and even disagree with authority when they see something that needs to be noted. And this can help reduce risk. Similarly, if you’re a project leader, pay attention to what your operators are saying.

When I say “operators” here, I mean people in the trenches, on the ground floor, on the operating deck, you know, on the line, basically. They have crucial insights. We tend to think that our system is and how things are operating are what we planned for or what we paid for to get done. But it’s rarely ever exactly like that. But our people in the trenches, they really know how things are getting done. So, making sure that our operators and experts have a real connection to our risk managers and to our leaders, and that that voice is real. Their input may not come in numerically like we’re used to in generating risk data, but this qualitative data, if they tell you something sucks or it’s not working right, take that to heart and make sure we hear that.

Another important part of working with a highly networked system is preparation for adaptation becomes paramount. So, certainly we’ll have procedures, but we also need to develop procedures for responding to surprise. We should expect some mistakes and some misunderstandings, miscommunications and confusion because everything is so networked. So, in this case, we have to prepare for things happening that we did not expect. So, ahead think about how is my team going to respond to surprise? So, we still have standard operating procedures, and their great guidance. But we can, we do have processes for adjusting those when things come out that we did not previously prepare for.

Host: I want to circle back to one of the trends that you mentioned earlier: designing the how. What makes this so important?

McGowan: So, we tend to treat design as something that is done for engineering systems only. That’s certainly critical. But, in addition, we also need to think about designing how we do things, which can be just as important. This means designing how we make decisions, how we organize, designing how we network and connect. Also, designing how we communicate, collaborate and solve problems. So, if you think about each of us every day uses a variety of processes and practices, standards and even policies. How are we designing those? Because all engineered systems are developmentally path-dependent, to some degree. Sometimes it’s a small amount. But sometimes it’s very significant. So, if you think about it, for the same technical requirement, the same technical requirements going into an engineering system, if you change the people on the team, or if you change the method or process that they use, or change the organization, this can change the final engineering system research, or design, or engineer, even if you have exactly the same engineering requirements. So, taking care to design the how is just as important as designing the what, the engineering part.

And the good news is that there are many different sciences, if you will, that focus on how. Some of these include sciences like decision science, design science, organizational science, network science, data science, technology policy, systems dynamics, operations research — all of these focus on that. What’s interesting – or I think maybe even challenging – to those of us predominantly trained in engineering is that these sciences based on how are very context-based, meaning they’re not purely physics-based. They’re still scientifically based. They’re theoretically based. They’re rigorous and tested and disciplined. However, they necessarily have to be tuned to a certain context, so the context that it’s being used in.

And so we can’t treat them like we would, say, a chemical formula, if you will, or a mathematical formula in the traditional sense, because the same method will not necessarily – or the same how, if you will, will not necessarily – work the same everywhere. So, you can’t just plug and play these methods. What’s also challenging about this is that the return on investment of a different method or process is context-dependent. It depends on where and how it was applied. But the opportunity space here is large, right? So, we have the opportunity to design and update how we’re doing our work to more effectively meet the needs of the engineering system and the people and connected systems that are involved.

Now, one caution for our workforce is that it’s tempting to want to take a method, and I’m going to say like Agile or Lean, or design thinking, and it’s tempting to want to say, “We’re just going to use that everywhere.” And often, that’s not exactly what’s necessary. The engineering systems we’re working with are so complex. The organizations we’re working in are very complex. We’re working, we’re connected to so many different institutions, teams, to make something, to make a system go forward and make a mission realizable, that typically you need a blend of methods and theories to make it work. So, effectively, you’re creating a formula. You’re creating recipes that are a blend of different approaches, and you adjust these as needed. So, it’s not as if you might use Agile everywhere, all the time, or Lean, or design thinking, or whatever your favorite method is. Instead, you might early on use one type of blend of those three or four or other methods, and then you would adjust that blend for different parts of what you’re doing.

And similarly, if you use statistical engineering, for example, a very, very rich area that has great insights about how we can improve and design our how. Similarly, we would adjust our methods and processes as necessary. And what’s interesting, as well, is that some of these areas, there’s a lot of information you can gather online about them. But it’s important to understand how to apply these methods rigorously and effectively. To have an idea and know when not to use a method is just as important as when to use them. But use appropriately, use where they work best, and understanding when not to use a method can mean the difference between an expensive, an ineffective mission, and a highly effective, faster process with less risk. It can result in greater innovation and other benefits that you can achieve by designing your how according to the human system that is working on your engineering system.

Host: Design thinking, as you mentioned, is a popular approach today. Could you give a description of what it is and how it might be used at NASA?

McGowan: Sure. So, the work that has been colloquially called “design thinking” today has actually been around for decades. It just became popularized as a term in the last handful of years or so. But the term makes people think of it as a new fad. But, in reality, this work is often based in areas called design research or design science or design strategy. And again, many people have been doing it for a long time. And it encompasses taking a very holistic perspective of a system that is not limited to purely technical feasibility. Traditional engineering tends to focus predominantly on technical feasibility. You know, will it work? Can we build it? Can we design it? Will it work as planned? That is still crucial and important. I’m going to add an “and” here. And there are other aspects that design thinking takes into account.

Before we even define what technical system we would like to use, design thinking really focuses in that up-front stage, where you really focus on what is often called problem discovery, or exploration, and making sure you understand if you’re solving the right problem. And so instead of starting with requirements, design thinking takes a lot of effort to do. It’s often called design research, and ask questions like: What are the people who would use this system, what do they actually desire? What are their underlying needs? And how do we address those needs? It also asks questions like: What is the business viability of this concept? What are our economic constraints, our political constraints, our organizational constraints? What can my organization actually execute well in this space? So, it considers all three of those lenses — the people or human side of it, and in some case, for NASA, the societal side of it. It considers the business and organizational viability, as well, which again, for NASA, can also be you’re looking from a country perspective, the political or economical constraints or opportunity space, as well as the technical feasibility, what we build and how well it works.

So, design thinking really, again, spends a lot of time and is very comfortable working with very little or no predetermined requirements. It tends to be really great for handling very complex problems where the data is messy, the needs are very complex, and some of the information that you’re looking for isn’t necessarily well-documented. Sometimes the information that you need is not clear, and you’re dealing with a lot of ambiguous data. And you’re often not even sure what information to ask. And so, design research begins with quite a bit of walking in the shoes of those who might use your system, and also considering the beneficiaries of your system who may not be the users but the beneficiaries. What might the public gain from this particular technology, even if they’re not the direct users of it? And we consider that, and also design for that, for example. How might this impact the connected city, as well as the city for which we’re designing, for example?

So, while traditional engineering approaches may assume that the customer fully understands their needs, in design thinking, we assume that the customer can express what they think they would need. But also it is our job to go and understand other connections to the customer’s need that they themselves may not have anticipated, and to make sure that is included in a design, as well. And to think beyond just creating what they said. You know, I think all of us have heard the famous quote from Henry Ford that he said, you know, “If I had asked [his customers] what they wanted, they would have said, ‘A faster horse.’ ” Well, your goal in design thinking, really, is to hear that need and say, “Why are they saying that?” And often when you’re being trained in design, you get these five whys. You ask why five times. Why do you want a faster horse? Why do you need a better saddle? For comfort? Ah, that’s the need. Why do you need this? Ah, because you want to take more passengers. So, you’re translating their needs into criteria that will influence your design. And so, very often in design thinking, it can lead you to a place that you hadn’t previously considered that’s very different than the initial data that you were given at the outset of the project.

What’s interesting about design data, if you will, is that it can be very unstructured and even messy, at first. But this is exactly the space where design thinking approaches can be effective, where you consider things like, “What are some pain points that are not working for people today?” What are some barriers or hurdles that they’re having? What are some financial constraints or opportunities? What are some new capabilities that this organization or area might have that we can use? And hearing from people is really important.

So, while we call it design thinking colloquially, it’s important to recognize there is actually a field of experts out there with very diverse backgrounds that work in this much broader area that may be categorized, again, as design research, design strategy, or design science, that have been working in this space for decades really understanding highly complex problems, really trying to get to, “Are we solving the right problem?” And really designing the how, the what to ensure that at the end when you’ve been done, the solution that you’ve created is what the customers, users, beneficiaries and stakeholders want to see. And in addition, it actually fits with – it’s actually viable from a business model perspective as well. And so, this arena really draws upon people with extremely diverse backgrounds that include engineering, but as well as those in the social sciences and in business as well.

Host: Does design thinking have the capability to be a gamechanger for NASA missions?

McGowan: Oh, what a great question. Like all tools and methods and processes, it’s a function of how well you apply it, and the quality of your application. So, if it’s applied well, and if we take advantage of people who have some great expertise in the various aspects of design research, design strategy, design science, design thinking, then the answer is yes, it can be a gamechanger. And I’ll just highlight a couple different areas where that may be the case. There are some in the broader arena of design research that study the design process, the engineering process. And they literally study how design and engineering teams work, and they will find inefficiencies. They will find ineffectivenesses among an engineering team.

So, using design thinking, the understanding, or design science to study, how was your engineering team working? And where is your team’s ineffectiveness costing you dearly in terms of your final product? So, it’s one area that using the work in the broader field of design science can be very, very helpful, where you recognize that your team is getting what’s sometimes called cognitive fixedness. They’re fixed on a certain solution and can’t break out of it. How can you help that team think of other solutions, for example? The design science studies methods, processes and tools that help the engineering and design team function so much better to get you the right output in the end.

Another area where this broader field of design can be effective is we have improved problem definition and exploration. So, I mentioned earlier that design thinking, as it’s being called today, spends more time before requirements definition than we traditionally do. That time is hugely valuable because with that problem exploration, that market exploration, that user understanding, and that business understanding, then though you’ve spent more time up front coming up with the right requirements, that means that you can move a lot faster. And then when you get to the actual solution, you have the right cost-benefit fit balance in the end. And this, therefore, reduces your unintended consequences of your final design in having recalls or things that happen that were quite different than you expected to happen. So, it can be extremely effective in terms of moving faster, actually, and even costing you less, ultimately because of that up-front work that is done.

One of the things that is done in design thinking to make sure that you hear what the needs are is using something called – sometimes it’s called sacrificial concepts, sometimes it’s called draft concepts, or informal prototypes. You know, we’re used to, as engineers, working with very formal prototypes. And you really spend a lot of time in getting a very shiny object, a very well-honed formalized prototype that’s showing all the engineering functionality. Those are expensive. By the time you’ve gotten there, you’re pretty far down the line in terms of developing your engineered systems. What if much earlier on, when you’re brainstorming and thinking about different approaches, you use some draft ideas that may be cardboard cutouts, may be drawings. They could be any simplified way of explaining what you’re trying to do.

It’s been really shown that if you use those well, they can help your team, your customers, your stakeholders, get a better idea. “Oh, that’s what you’re talking about? Ah. I understand better now.” And, “Well, this part is not what I was thinking about. This part is.” And, “Wow. I’d really like to see this change in a different way.” So, using concepts like very informalized prototypes can help us listen better and communicate much better. So therefore, design thinking approaches are really not just for the big-E engineering just before the major requirements are set for the entire system. They are for all along the way. You know, at the testing phase of a system, if the test engineer spends some up-front time talking with the customer and making sure that he or she understands exactly what they’re looking for and designs the right test program.

At the manufacturing stage, same question. Is this working? How might we use this new manufacturing capability that we have to better meet the needs that you have? Even in operations. Can we go and observe how it’s working today? Can we go and listen to what are the things that are not working in our operations? And does that give us insight about what the real needs are? You know, to give a specific example, let’s say you have a ground test team, and they’ve been operating a certain way for quite some time. And it is working, to be fair. However, a leader wants to make a change based on some insight he or she has. Before we jump into making that change, let’s go and first talk to people and understand what are the ground troops saying? What can we learn from that? And how much money do you have? What are the opportunities and constraints that we have from an organizational perspective? Are there some new things we can try? And then let’s design to meet the needs of the ground troops and the leader within the budget constraints that we have. And therefore, you can really use a design thinking-like approach throughout the engineering research all the way to retirement stage of an engineering system. And if used well with experts that understand some of the underlying theories and capabilities, it can absolutely be a gamechanger for NASA missions.

Host: And we will continue our conversation on complex systems engineering in our next episode. Anna will discuss the human side of the equation – and how to work across technical and non-technical disciplines to enrich engineering development and design efforts.

Many thanks to Anna for joining us for this two-part podcast series. Her bio and links to topics mentioned on the show are available on our website at APPEL.NASA.gov/podcast along with a transcript of today’s episode.

We invite you to take a moment and subscribe to the podcast and tell your friends and colleagues about it.

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