EPISODE 28: INTERDISCIPLINARY INTERACTIONS

Transcript

Anna McGowan: For those of us who really enjoy solving very large, complex problems and making what seems crazy-hard actually possible – and this is what Artemis is going to be all about, having these positive impacts — it means that working across disciplines and doing interdisciplinary interactions becomes key to our success.

Deana Nunley (Host): Welcome back to Small Steps, Giant Leaps for the second installment of a two-part series on complex systems engineering. I’m Deana Nunley.

On this NASA APPEL Knowledge Services podcast, we share novel ideas, lessons learned and best practices especially geared toward NASA’s technical workforce. And today, it’s our privilege to continue a conversation with Anna McGowan, NASA’s Senior Engineer for Complex Systems Design.

Anna, thank you for joining us.

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

Host: Let’s talk about the people and process part of engineering. What are your thoughts on how people and processes impact the engineering product?

McGowan: Well, the vast majority of our engineering products, especially our large scale, more complex systems like the aircraft and spacecraft that NASA works on, these are heavily a function of the people working on their projects. It’s a function of how those people and those organizations interact and the processes that are being used. So, even if we have the exact same technical requirements, if you have different people using different processes, it can result in small and sometimes very large differences in the final engineering product. So, it’s crucial to really understand how these people and processes affect things.

One of the reasons why this is important is that today, for many of our large programs, our teams are not co-located. They’re very geographically dispersed and they cut across multiple organizations.

What’s interesting about that is that the knowledge of our systems that we’re working on, whether you’re working on a satellite or a component of a spacecraft or an aircraft, the knowledge of that whole system is really dispersed across all those disciplines and organizations and institutions. It’s pretty commonplace, obviously, today.

So to understand that our system knowledge is actually held collectively by our very dispersed organization, there was an interesting report back in 1993, believe it or not, that had a quote that said, “Portions of the envisaged system are known to all, but all of it is known to none.” So just recognizing that you can’t go to one person or even a small group of really smart people that has it all together in their head. So, effectively, we are connecting multiple people and interfaces in the organizations and disciplines in order to get our systems engineered.

We’re not just bridging language. We’re also bridging things like assumptions, many of which are unarticulated, and even engineering methods that are different across groups and organizational processes, like incentives and financial processes. So really understanding how these meshing together of different processes and assumptions and approaches becomes important as the engineering leader, when you’re trying to get a large-scale system completed.

Host: What are the challenges of working across teams and organizations for a large project?

McGowan: Research on actual engineering organizations, including NASA, has shown that some of the biggest challenges of working across disciplines are surprisingly not mostly related to engineering or mechanical or hardware and software issues. I mean that tends to be where I go. I’m thinking, “This has got to be a technical issue. Let’s increase the fidelity of our mathematical models and make sure those are right.” Those are still crazy-important to do. Don’t get me wrong. But the research really has shown that the things that make even a bigger challenge for the research and engineering and operations leader are really related to three main areas. One is cognitive, how we think about things; social, how the teams and organizations are interacting; then organizational, how we’re structured and incentivized.

Just to unpack those three a little bit more, on the cognitive side, on the challenges, you have not only different understandings of the same problem. You also have misunderstandings of the same problem. Why this is important is because how we frame a problem is how we solve it. So, for our leaders, being able to provide clarity and reduce confusion becomes really important.

We’ve found that in research, if you talk with a team of engineers, people can have two very distinct views of the system. One is a more modular view of the system. They kind of understand the system as deterministic results, very modular elements, and they can organize the elements of the system accurately in a hierarchical decomposition, and the system behavior has a lot of uncertainty, but a fair amount of predictability.

But then others on the exact same project will view the system as a nondeterministic result of elements that are very intertwined, that can’t really be accurately decomposed. The elements of the system are highly networked and decomposition will effectively lose behavior. In this case, those engineers on the program will probably use more probabilistic approaches and look for ways to address the nondeterministic nature of the system, and both of those views can be on the same team.

Looking at the challenge of social and working across disciplines, this really goes with the health of the social capital of our teams. There can be things like tribalism, mistrust and even egos on a team that can really impair how people share data. There’s a nontrivial amount of discomfort in stepping out of your comfort zone, and that can impede how much information is shared.

So, for our leaders, really building the team to share more information becomes imperative. Even if you have a requirement to share certain pieces of information, team members can certainly share what you told them to share, but there’s a lot of information that you as the leader won’t know needs to get shared, but those people in those individual disciplines will. So, making sure that there’s enough healthy social capital among the team members, that they will share beyond what they’ve simply been instructed to do.

And the last main area that continues to be a big challenge area for working across disciplines is in the organizational area. This means how we’re structured, how we’re incentivized, what kinds of processes and policies we have. Some of these can be conflicting — conflicting objectives and preferences, especially as we span major organizations and institutions even.

For our leaders, what we can do about that is two main things. One is to listen, to really make sure you understand what even the lowest ranking members of your team are saying and what’s getting in their way. So, as we understand their problems, we can start working towards the solutions.

Then it’s to have a design mindset. We tend to look at the organization like we do the weather. You kind of just have to deal with it. It’s raining. You can’t change it; just work with it. But in reality, and in most cases, it really isn’t like that regarding our organizations. We as leaders have far more variability than sometimes we take advantage of.

I’m not saying you can redesign your whole organization, but you might be able to design facets of how your organization impacts your team. You can design new roles for your team. You can adjust some procedures that will better fit how your team is working. So, taking advantage of some of those opportunities to have more variability and design what you need can really be a huge help in making those interactions work better.

Host: From a technical standpoint, how important is working across technical disciplines in particular?

McGowan: So, our technical disciplines — historically we’ve looked at our engineering systems as primarily a function of the major components of the system. But the reality today is that for our larger scale, more complex engineering systems – I’m thinking of our satellites, our rockets, our aircraft, et cetera – the behavior of these systems is very much a function of the interdependencies and the interactions of the components as much as they are a function of the components themselves. So, this means that traditional assumptions regarding system taxonomy and structure may be challenged.

So, our software that’s interconnecting our system can actually connect and control components that we assumed were decoupled or disconnected. So, we have a lot more interactions on our system today than we could have assumed previously. So, this leads to our systems being often not only deterministic, but largely nondeterministic in their system behavior.

So really, our view of our system, of also looking at our engineered systems as a function of mostly modular, major technical components, to looking at our systems as a function of the interdependencies of both technical and nontechnical components, where some of these nontechnical components are some of the things we’ve been talking about, like people, processes, organizations, budgets, stakeholders, policies, et cetera. So, our engineering systems are best comprehended by understanding how all of those facets affect our system.

So with this more complex understanding of our how our systems actually work and what impacts it and how it interacts with all these different disciplines and aspects, it really becomes paramount that we work across all of the interfaces of our systems with high quality, with excellence, because ultimately, the final performance of our engineering systems depends upon it.

Host: Let’s get into a little bit more detail about that. So, what are the benefits of doing interdisciplinary interactions well?

McGowan: Well, some of the key benefits of working across disciplines, and particularly in an interdisciplinary fashion, they really relate to seeing the system better. So, the people on your team will be able to help you reduce some downstream surprises and help with problem mitigation. It can also help with reducing human error, because as we interact we’re learning and improving our system understanding. Therefore, we can recognize trades and impacts that cross discipline boundaries.

The other interesting thing is innovation and creativity. By doing this interaction, we begin to understand that there are some opportunities that sit between our disciplines and organizations that really are full of opportunities for new solutions that we could not have foreseen sitting in our existing areas. So, there are a lot of studies that show that innovation really happens or can happen between disciplines. So, the biggest benefits are getting improved system design or performance, and this can ultimately lead to better system reliability because we simply understand our system better and how it functions, and we understand the broader solution space much more richly.

Now for the project leader, who wouldn’t want to have these benefits, right? Some of these benefits are realized immediately, as your team quickly learns things about the engineering systems as they interact. But many of these benefits, they’re qualitatively clear, but they’re not necessarily traditionally quantifiable, like you would get an ROI on it.

Sometimes upper managers will ask what’s the ROI on specific things. One of the things I wanted to mention here in particular is that although these benefits may be somewhat intangible and they’re perhaps even qualitative, most of us have seen these benefits as we work with these well-organized teams that are across disciplines. This old mantra that says, “If I can’t measure it, I can’t manage it,” that’s just not true.

It’s certainly easier if you’ve got numbers to quantify everything, but if there are benefits to be obtained and something as crucial as greater risk recognition, and as crucial as understanding major interfaces in your system, which can literally make your system go from success to failure, it would be unwise to focus on just things that you can measure with numbers, right? And these benefits of working across disciplines are cumulative.

So, as a leader, the longer you can keep an interdisciplinary team together, the better. But also know that even when there are personnel changes, the person who comes to your team, who has spent a long time doing some cross-disciplinary work in another team, they’re bringing that rich knowledge to your team that you can benefit from. As someone leaves your team, they’re taking it with them as well, and that helps the whole organizational knowledge trust grow, which helps all projects really benefit.

In the research literature, there is a ton of information and research on actual teams to show the benefits of working across disciplines. This goes beyond purely engineering benefits. These include saving time and saving money and even employee retention.

I’ll just mention two areas of research literature, in case those listening want to look them up. There’s an area called positive organizational scholarship, and this has significant information on an area they call high quality connections. They talk about how much more effectiveness you can get if the connections between the people on your team are of high quality, and the negative and often collateral impacts when this is not the case.

Another area of research that I think is really helpful to our leaders is an area called high reliability organizations. This is studied where organizations are operating things that are incredibly high-risk assets, and the operations are very challenging and full of many areas that could be risky. This research is replete with really strong recommendations on focusing on the interrelations of those working together. So, as the risk of your system increases, so do the interrelations between the people on your team have to increase as well.

Host: You’re talking about these interactions between technical disciplines. What are some of the key factors that impact these interactions?

McGowan: There are a number of different factors and I’ll just mention a couple here. One of them is really understanding the type of interactions your team needs for where they are in the engineering process. I’ll take two kinds of maybe polar opposites here.

One is if your team is working with an engineering system, where the components of the system are relatively familiar, how the system is being laid out has some familiarity with the team, versus if your team is having to create or design a relatively new system that’s using components and elements that they have not previously worked with. The type of interactions that your team will need between those two different projects will be quite different. A lot of us like to use the same methods to work as we always have, because that’s where we feel comfortable, but as a leader, it becomes really important to recognize the differences.

As an example, if you’re working with a known layout of components on your system, you know what information to ignore. You know what to act on. You know who to meet with to get certain pieces of data. The organizational connections are already clear. But if you’re creating a brand new system, if you are designing something that has not been there before, what information to ignore will be ambiguous. It’s not a lack of sufficient information. It’s the equivocality with what you have.

You’re often having to improvise new practices as you go, because you’re not sure who you need to connect to and what data to act on, and at what fidelity you need that information. And the organizational relationships are not necessarily clear and obvious. You may have to create new ones and set up new meetings, new review teams, et cetera.

So as a project leader, it becomes important to recognize many different aspects of interactions, including who do you have to connect to, at what fidelity, the length of time, and to recognize that if you’re in the area of designing or creating something brand new, those teams really require a lot of interactions, and a great deal more than a team that is working on a derivative solution of something that has been done before.

So that design and creativity sounds awesome and many of us love those kinds of projects, but wow, in the early stages, those teams will often say things like, “It feels like we’re going nowhere,” because they’re really trying to make sense of what information they need to create that new thing. So, big facets are understanding the different areas that your team needs to work in and how to design that as the leader, and create the right structure for them to work in.

Host: Could you share examples where this has been done effectively?

McGowan: Absolutely. In studying teams or people who have actually done this well, it’s interesting. Many of us would assume that those who do this well are necessarily in some traditional integrative roles, like systems integrator, systems engineers or optimization specialists. Those disciplines and those engineers certainly do this extremely well. But it’s also interesting that there are a lot of single disciplines, sort of deep discipline experts that also work across disciplines extremely well and can be great leaders in this area.

Some of the characteristics they have is that they have a vast social network, believe it or not, and excellent social skills. People actually enjoy working with them. It sounds like a simple thing. But it doesn’t matter how much you know about the system. If you are kind of a pain to work with, it doesn’t tend to work out well in terms of working across disciplines.

Also, these leaders are proactive about building team cohesion. They take great efforts to build their teams. I’ve heard some leaders that really get at this. They’ll say things like, “Okay. We’re locking the door and we’re not leaving until we figure this out and work this out,” whether it’s a technical problem or a mistrust issue or a missing piece of data. It’s like, “We’re in this together,” and they focus on those things.

Leaders who do this well, they have excellent communication skills. They are great storytellers. They can take a big, hairy, complex thing and they can really boil it down to create a story that’s very memorable. They also tend to be very visionary, very creative and, believe it or not, they tend to be kind of risk-taking. They are very comfortable with trying new things, and failing, and trying again, and they’re not deterred by the novelty of an idea or approach.

Why that’s important is that as you work across these disciplines, you’re going to hear things that you’ve never heard of before and people on your team, if you’re doing it right, will challenge how things were done before. These leaders are not fettered by that. They embrace novelty of idea, and they’re willing to adapt approaches to use those. So, they build an opportunity for informal interception between the groups to share ideas. They create working-level relationships. They work on co-location of their teams. They facilitate and intentionally structure cross-disciplinary events.

So, at the heart of what I’m saying is those who do this well, they’re intentional about it. They don’t assume, “Well, I’ve got good folks. They know they have to talk together. It’s just going to happen on its own.” The ones who excel here, they’re rather intentional.

Host: What’s the significance and impact of organizational and engineering structure in elevating the overall quality of interdisciplinary interaction?

McGowan: That’s a great question. There’s a lot of great research here on how structure affects how we interact and how it impacts the final system design. So, first, let me say structure is necessary. We have structure in terms of how the organization is set up, how our programs and projects are set up, how our teams are set up, how our meetings are set up.

On the engineering and technical side of the house, we have structure in terms of our math, our physics models, in terms of our software systems. System architecture has great structure around it. Even a request for proposals has some strong structure set up around it.

So, all of that is great and it’s necessary. However – here’s the however. We also have to recognize that while these pieces of structure that we have enable efficiencies, they also do define and even constrain our actions and our interactions. They determine who connects to who in the organization. They even impact our cognition, how our thoughts are organized and how problems are solved.

There’s an interesting study about a car company, who had “n” number of computers to operate this particular car. They’d always had that “n” number of computers, and they just assumed that’s what it took for that car to operate well. Well, after some time, they reorganized. Immediately after reorganization, the next rendition of that car, without a significant change in requirements, the new rendition of the car ended up having “z” number of computers.

You’re probably guessing where I’m going with this. “Z” is the same number of new organizational pieces that that company had. So, the structure of the organization actually gets reflected right back into our engineered system. We like to think that the requirements of the engineered system should drive it, and it does. It does impact the organization. But also know that the structure of our organization is reflected back into our engineered system.

In particular, if the solution that we need in our engineering system is between two parts of our organization, between parts A and B and their derivatives, it can be really hard to find that solution without a lot of effort by the team or project leader to facilitate an interaction between parts A and B. If we oversimplify the interaction between our disciplines as simply just, “Hand over this piece of data. Hand over this document,” if we simplify it to that, then we are going to miss opportunities that sit between the structures that we’ve created. There might just be a new process that we need to look at that is outside of what we’ve done. Even the structure of our mathematical models can make a difference.

So, keeping in mind that structures can act as constraints, they can also dictate the form of the solution. And knowing that the solution in our engineering systems is sensitive, very sensitive, to the initial problem formulation, how we’ve formed and shaped the initial problem and the taxonomy that we create at the very beginning of our system development process greatly impacts – that structure greatly impacts the solutions that flow downward in the system development process.

So even if we link together known parts, we still may not get the exact or the best answer. So, understanding how these structures can impact our system can be important for a leader, and this is where designing new structures or pathways to connect structures becomes important.

Host: What practical, tangible advice would you offer to a project manager who wants to improve the interactions across a team?

McGowan: I have a couple of things here I’d like to mention. The first thing is remembering that knowledge isn’t just something that can be stored and retrieved like a book, so appreciating that our teams are co-creating new knowledge that exists between what they know. I’ll say that again. Knowledge is actually co-constructed as your team’s interacting.

So, focus on meetings and create physical spaces that actually enable your team to work together and share information and insights. This means that meetings where predominantly you as the leader are broadcasting classroom style are not going to be as effective in terms of your team sharing ideas even if you say, “Hey, raise your hands; mention something.” Literally changing the physical layout of the room can help.

Reduce the size of your interactions when you can, especially your face-to-face interactions. Have only two or three people work in a corner, a whiteboard or a chat to themselves, so they can really get to the bottom or into the weeds of what they need to.

The next thing I’ll mention is recognizing that interpersonal skills are not a luxury in this area. They become crucial. This is not about being a social butterfly. Rather, this is having the professional maturity to really bring diverse groups together.

The other thing for our leaders to do, to enable greater interactions across their team, is to recognize that both argument and ignorance are both inherent and they are both useful. Now this sounds quite strange. Why would argument be helpful? Well, the deal is if you and I are working on a project together and we come from totally different organizations and disciplines, we need to work out our language and our understandings and our assumptions, our processes. We’re going to go back and forth a bit and maybe even argue a little bit about how it, quote, should be or how we’re used to it being done. That’s normal.

So, for our leaders, don’t avoid these arguments or try to stomp them as soon as they come up, but the deal here is to make them respectful, egalitarian, and well-facilitated. Sometimes your job is to technically translate what’s happening in there between the groups in your organization and your team.

Now ignorance, why in the world would ignorance be useful? Well, the reason why it’s inherent is because we can’t know everything. We can’t know what everybody else on the team knows. So, the reason why ignorance can become useful is people who don’t know the other discipline, they’re going to ask some questions that will challenge long-held assumptions in another discipline, and that can spark an idea. That can enable a new thought, and some opportunities and new capabilities that you hadn’t thought of before. It also allows for less constrained ideation, because if we don’t know, we’re going to push some boundaries that perhaps a disciplinary expert wouldn’t have thought of that. So, it can be a really useful tool to a broader team.

People who do these interactions well have great storytelling abilities. I must admit when I first heard this, I said, “That’s kind of crazy. Storytelling, really?” Well, it turns out that storytelling is an incredibly powerful skill. Narrative skills actually help build what the research calls collective mind. This is not groupthink. It’s quite a different concept.

Collective mind is really where you do have diversity of thought. You take advantage of it to solve a really complex problem. I’ll use a quote from research literature that says, “Stories organize know-how. They organize tacit knowledge, nuance, sequence, and multiple causation, and even means-ends relationships, and consequences into a memorable plot.” All of us humans will remember something better if it’s in a story than in a long list of data, for sure.

Host: Anna, these are really practical pieces of advice. Is there anything else that you’d want to share with us?

McGowan: Sure. In the area of working on highly complex systems, the other challenge we have as leaders is that we have to address ambiguity as well as uncertainty. Those words sound like they’re the same, but really, uncertainty is where we actually understand the problem,but we’re missing some critical pieces of information. In those cases as a leader, using more impersonal ways of connecting is fine.

Instant messaging, text messaging, e-mail is great. But sometimes leaders use those when the problem is really ambiguity, where there is some confusion or lack of understanding, lack of clarity. In those cases, you really need to increase the personal interaction and the richness of the communication. So, I’ll tell people, “If you just sent back seven to 10 text messages, pick up the phone. A richer conversation needs to be had.” Very often on these teams, this equivocality of nomenclature becomes a challenge for the team. So, using things like face-to-face meetings, videoconferencing, actual phone calls is much more helpful.

The other suggestion I would give our leaders is to be careful not to replace experts with tools. What I mean here is it’s tempting when you’re creating a project team to say, “You know what. I just want to buy the software tool that an expert would use in that area,” instead of actually getting the expert. But you know what they say. A fool with a tool is still a fool. So it’s okay to have those tools, but you really want to make sure you have some of those disciplinary experts on your teams, because they will understand when those tools won’t work and when they will, and they’ll understand nuance in those tools that others just won’t.

So even short courses that people on your team might take to understand the other disciplines on your team, those short courses are great for awareness and they’re highly recommended, but they don’t compensate for deep discipline knowledge, so making sure we don’t replace our expertise with purely the tools.

Something else that project leaders can do to help with their interactions on their team is to hold what’s called a premortem. A premortem can actually help reduce risks significantly. This is where you create plausible stories about mishaps that might happen ahead of time. Then you take advantage of the diversity of thought on your team and solicit ideas about what could happen and how would we respond.

What this really does is your team members will start saying, “Oh, I didn’t even think that that was a potential area of challenge for us. I didn’t understand that so-and-so knew that. I didn’t appreciate how some second and fourth order problems could potentially connect to create a first order problem.” So, these premortems can be extremely useful in reducing risk on your project and helping your teams interconnect, even before you get into doing a major engineering effort.

Host: When we look to future NASA missions, let’s say in the context of Artemis, how do the principles and approaches you’ve shared affect the success of missions to the Moon?

McGowan: Oh, what a great question. The Artemis mission is so exciting. It really brings NASA to interconnect with many new types of groups that we’ve never really connected with, and new connections to our communities, our local communities all across our country.

What’s also interesting about Artemis is that we like to think sometimes about our systems in a more simplified fashion that have a stable mission, a single function, a single user. Maybe the stakeholders are all the same. But for something like Artemis, we have an incredible opportunity to work with multiple different stakeholders and have many different users of the things that NASA is creating. So, we have a much broader impact.

So, our system behavior is going to evolve as we explore different aspects. Artemis is about exploration. Exploration is about learning. And learning is inherently emergent. It involves pulling in new data and new findings than we’ve had before, and this means we will connect with disciplines, with communities, with organizations that we’ve never done so before.

What an incredible opportunity for not just NASA, but really for our country. It really shows that aerospace is not a narrow field, but it’s continuing to diversify and have many more positive opportunities to impact our world.

For those of us who really enjoy solving very large, complex problems and making what seems crazy-hard actually possible – and this is what Artemis is going to be all about, having these positive impacts — it means that working across disciplines and doing interdisciplinary interactions becomes key to our success, and we actually look forward to these new interactions with new people and new institutions across our country and across the world, and that’s going to be one of the important hearts of making – and I did mean heart – of making Artemis a success.

Host: Anna, thank you so much. This has been an absolute delight having you on the show for these two episodes. Thank you so much for everything that you’ve shared with us.

McGowan: Thank you so much. It’s been my honor to be here. I hope it’s been helpful.

Host: Is there anything else that you want to mention?

McGowan: The one last thing I will mention here is sometimes when we talk about working across disciplines, sometimes it’s heard as a critique to having single discipline expertise and that we’re trying to make everyone a generalist. That’s not at all the case. We don’t want to get rid of single discipline expertise, but rather, we want to connect it and, in doing so, we are adapting that disciplinary expertise as we learn more.

So, we’re respecting the discipline expertise while we are building connective tissue between them, and even creating some new disciplines in the meantime. So, this isn’t about making everyone into a generalist. This is about using the incredible expertise we have to do things we haven’t done before.

Host: You’ll find links to topics discussed on the show and related APPEL courses along with Anna’s bio and a transcript of today’s episode on our website at APPEL.NASA.gov/podcast.

If you have suggestions for interview topics, please let us know on Twitter at NASA APPEL, and use the hashtag SmallStepsGiantLeaps.

Thanks for listening.