РАСШИФРОВКА 🔗
IN ORBIT: A KBR PODCAST
Season 5, Episode 8
“Digital Engineering and Bringing the DREAMM to Life”
INTRODUCTION
Hello! I’m John, and this is “In Orbit.”
Welcome to the podcast, everybody!
Wherever you are, however many times you’ve tuned in, right now we’re just excited that you’re with us and staying in our orbit.
We’ve got another great episode for you if we do so say ourselves, and we DO.
We’re returning to the realm of technology, specifically digital engineering.
The name alone sounds intuitive, but digital engineering encompasses more than you might think, particularly when it comes to developing cutting-edge, innovative solutions for government and defense clients.
As you might have guessed, experts at KBR are at the forefront, applying AI design and modeling, automation, digital twin and more — along with rigorous testing — all across the system life cycle to deliver solutions faster and more efficiently.
We’re going to talk about all that, about current and future digital engineering trends, and how KBR experts are deploying innovative digital engineering approaches at the KBR DREAMM Lab — that’s “DREAMM” with two Ms, and you’re about to find out why.
INTERVIEW
John Arnold:
And with me here today to talk about it is Gus Jordt, Air Force acquisitions digital engineering lead with KBR's Mission Technology Solutions business. Welcome to the podcast, Gus.
Gus Jordt:
Hi, happy to be here.
John Arnold:
We are thrilled that you're with us. Before we get started, as is our custom, we want to get to know you first, give everybody listening an opportunity to get to know you. So, would you please just tell us about yourself and your background, your career journey and how you ended up at KBR.
Gus Jordt:
Oh, absolutely. I think, ever since I was very young, I was very interested in more of the math and science technical subjects, also very interested in computers and programming and all the things it could do. We got our first family computer when I was in high school and I think, within a month, I was showing my parents what to do and how to do it, pushing the limits of what it could do, very exciting. So, when it came time to choose a major for college, I naturally gravitated towards computer science and that's what I studied at UC Berkeley along with electrical engineering and just dove deep in anywhere and everywhere I could, every class, just loved all of it and found a group of friends that I could explore every aspect. We built our own computers, we hacked the computer at school.
John Arnold:
I was about to say, were you a hacker?
Gus Jordt:
We did a fair share of hacking. Exploration, a technical exploration-
John Arnold:
Sure, sure, sure.
Gus Jordt:
... but all good and just loved what I was working on. And when I went to college, part of my approach to paying for it was getting an Air Force ROTC scholarship and very fortunate that that funded my education but also meant I was an Air Force lieutenant upon graduation and my first job was in flight tests at Edwards Air Force Base testing satellite launches, cruise missiles and other types of vehicles using an airborne telemetry platform called ARIA, Advanced Range Instrumentation Aircraft. So, that was an extremely fun job, learned a lot about the Air Force and how operations work and how flight tests works but it was a divergence from computer science, computer engineering but I did always find a way to sneak it in other places.
So, I would download the satellite trajectory files and do a live fly through of modelling and simulation that they had no interest in but I thought it was fun and presented it, thought that was cool but I always maintained some connection to that, say, how can I apply computer science or a computer algorithm to help here in every aspect of my job. My Air Force career, very thankful for it, very fortunate, I got to work at the Langley Air Force Base with the Air Operations Center, again, a big deep dive into how the Air Force works in terms of executing a war and then also how to apply computer architectures to make that more efficient.
That was the whole role of the AOC going from several days of putting together an air tasking order to doing that within a few hours and automation and computers were a big part of that. Also did a job in England where it was very much intel focused and I was there during a period where we were focused on Africa and a lot of activity in Africa as is there is today piracy, terrorism and we were seeing the explosion of intel used to gather information and process that and to make assessments and inform our operations.
So, again, it was, “How are we applying our tools to automate that information flow and get us to a place where we can very efficiently deliver these assessments?” And ended up at my career back at Wright Patt where I was mobility directorate, managing all the hundreds of programs and mobility directorate, helping the program executive officer do that and supporting him and his staff and then finally I retired out of the F-15 program office with one of their large programs focused on electronic warfare.
So, a lot of different activities, a variety of things, I like to say I did a lot of things in a lot of areas but maintain a connection to computer science, computer engineering. I did go into aircraft manufacturing right after I retired and was made the senior director of supply chain of a manufacturing company and, again, I just saw tons of opportunities where we could use the power of big data and optimization to make each person more effective and efficient and being able to make decisions ahead of the problems that we foresaw in terms of part shortages or saving money on different parts.
The company was good at what they did but had been very traditional in its approach so a lot of my efforts there were to bring forward modern approaches to that so that we could be a lot more informed about the decisions we were
Load full transcript
making about what to buy and how to buy, how essentially trade-off between the reliance on a part being there and also the cost we wanted to pay. That was a lot of fun, COVID hit, that changed the world of course, air travel was reduced to a fraction of what it was, it hit that company very hard and, also, it gave me an opportunity to really think about what I loved. I was enjoying myself but the company as a whole was manufacturing designs that were already made and just making sure you built them reliably which is a massively important part of the industry but I think my heart was wanting to go back to develop technical solutions and also applying the latest that was out there. Autonomy was growing, artificial intelligence was growing and I just wanted to get more into that.
And I found KBR, actually, through an old colleague when I was active duty and they had this role where they were developing autonomous systems for the research lab and that's where I joined and then started my journey at KBR.
John Arnold:
I love this route. I've been scribbling down notes, from computer science to telemetry to operational improvement to electronic, that's quite a journey, that's spectacular. It's pretty amazing.
Gus Jordt:
It's been fun. Yeah, absolutely.
John Arnold:
And I love to hear about people who, throughout all that, they maintain that air of interest and fun in what they were doing and it certainly comes across in your explanation of your journey. This is something that some of our listeners may be familiar with and maybe some of them are not and then, certainly, people outside the company might not be familiar with this. But it's a capability that has certainly ramped up more in the past few years and I would imagine, likely, since you've been on board in that post-COVID time and that's called the DREAMM Lab. Would you tell us about KBR's DREAMM Lab?
Gus Jordt:
Oh, yeah, absolutely. So, thinking back a few years where KBR was, and I should mention, at some point, as our division leadership and OU [operational unit] leadership decided to focus more on digital engineering, there was a creation of a role at the division level and I took over the role at the operating unit level and created the DREAMM Team. And that's an acronym, I think it's a catchy one in some ways but it's very intentional and that stands for Digital Research, Engineering, Acquisition and Materiel Management. So, basically, the intent is to apply digital engineering across all phases of a system’s life cycle. From the research and development portion to it, you're going to engineer it, you're going to acquire it and you're going to support it through its lifecycle, there are opportunities to apply digital engineering to all of those phases and achieve benefits.
And so, in terms of the lab and why it got created, we certainly had capabilities and projects and people working in this space and we realized several things. One was that it was a fast moving. So, the methods
and the problems and the challenges you're working on today are going to move very quickly. So, that was one piece. Also, our main customers, the Air Force and DOD as a whole, they knew that they want to achieve these benefits, they didn't always know how. They weren't the experts on the application or the benefits that they could achieve but they said, "Hey, this looks, like, good, we want to apply it." And also we started to realize the way you make the case that you are competent, not only competent but proficient in this area is that you are delivering creative, innovative, cutting-edge solutions.
And so, we also noticed internally how are our people equipped? Well, typically, we would propose on a contract, we would get that contract and then we would give them software and tools, but they're all being used on that current contract. How do we develop solutions, creative, innovative solutions that are meeting our emerging needs and also staying ahead of or keeping pace with that rapidly changing environment? And having a dedicated laboratory space where you would have the computing power, you would have the tools and the data, architectures that would enable that kind of innovation and collaboration was very much needed. That became the idea for the DREAMM Lab.
And, originally, it was four computers in a office and it was a prototype but we did use that space to run a project that made it easier to take requirements from an existing static document and to populate a system model on the order of hundreds and, if not, thousands of requirements to reduce that manual input greatly and also make it so that system model was more up to date and synced up with what that program is trying to accomplish. Demonstrated that success, showed that to company leadership. Byron Bright saw some promise there and invested the money to make this, a real deal, a full lab. And now we have the full lab there at our Beaver Creek location and it's equipped with the team workstations and four original servers that we had are still there, still trucking along. And also we added a data wall which is very impressively big, and I'll have to get the specs on that. But what it does do is it allows for a couple of things, the display and the sharing and the communication of a lot of technical content at one time.
If you're looking at a big system model, you need some real estate. If you're looking at a simulation but you're also analyzing data at the same time, you need some real estate so that is super helpful.
John Arnold:
Outstanding.
Gus Jordt:
Also, if you have a lot of content to bring together, just having real estate to work with that. So, it's interactive, it's touchscreen. You can bring people in to display to that screen remotely. You can also push your display to other people remotely. It's integrated with Teams and KBR's internal digital engineering environment as well. So, that's what it is in a nutshell. And also the purpose being to promote and ease
the innovation and collaboration, help us partner with our customers, we host technical reviews, we host engineering efforts, we host offsite technical efforts on a regular basis and also it's a great space for showing new customers, potential customers, what we've done and how we've done it.
John Arnold:
It's wonderful for me to hear this. I've had the opportunity to do a little bit of marketing writing for the DREAMM Lab at KBR and so it's nice to now get a different perspective on it directly from an expert from the inside, I'm enjoying this. And Gus, you mentioned Byron Bright, that's KBR's chief operating officer for those of you listening who don't know. Would you give us some examples, I know we can't talk about anything confidential or privileged or anything like that, but cutting edge, innovative solutions, those are words that people throw around a lot. Let's really look more in depth at what kinds of projects KBR teams and customers are working on right now at the DREAMM Lab.
Gus Jordt:
Absolutely. I think one that comes to mind is our work with future tankers. In general, this program office is working to build the next generation of air refueling for the Air Force and there's been, I think, a variety of strategies they've pursued to do this but what KBR is doing is leading the system modeling effort for that program office and we use the lab in a variety of ways. And this is definitely an enterprise architecture model that the team has built and, right now, since it's very early in the development process, it's very much modelling and representing all the hundreds of requirements, concepts of operations, all the various needs and stakeholder impacts and perspectives in one place and represents the authoritative source of truth for the program's technical vision of what the system needs to be.
Through the different, I would say, evolutions of the program it has supported a tanker recapitalization effort, now it's being focused on next generation aerial refueling and it's going to be the way of which we capture all the different variations of designs, all the different proposed solutions and enable the team to assess those different aspects in a more efficient way where it's all tied and linked together in one place. Among other things, the DREAMM Lab is a big part of that.
I mentioned the customer collaboration in our DREAMM Lab and taken advantage of that collaborative capability and the large real estate to look at this large complex model and get input from a wide variety of members of that team. I'm happy and proud that we're able to provide system modeling experts to do this work but, really, the value that you get out of it is if you're going to be able to pull the knowledge and expertise from the other members and get it to be represented in the model effectively and the lab has certainly enabled us to do that. So, that's one project that definitely comes to mind.
John Arnold:
Excellent. I'm sure that the hundreds, if not, thousands of touch points, all the aspects of hardware design, how they relate to program architectures and everything else with any given project would be staggering for the average Joe to try to understand so it gives a deep appreciation for what you and your teams are doing there at the DREAMM Lab. Digital engineering we've alluded to so far in our conversation but we're going to take a little deeper dive in that topic specifically. Digital engineering has quickly become a standard capability and by standard I just mean it's ubiquitous regardless of industry even with KBR from our sustainable technology solutions business with engineering, procurement, construction and all the different technologies that we have, monitoring, maintenance, what have you.
So, would you explain to our listeners what the basic, building blocks of digital engineering are and what the intrinsic benefits of digital engineering are for our customers? Obviously, focus on defense in this case.
Gus Jordt:
Sure, absolutely and it's always worth talking about. And honestly, whenever we talk to someone new who's interested or curious, we usually start out with a definition and some basic fundamental building blocks. And we like to point out that digital engineering on its own is not meant to change drastically the critical thinking and the process by which you design a system by understanding the functions that it's supposed to accomplish and then identifying subsystems that do that and breaking that down, integrating together and then building that up as a physical system. That is not ... We're not diverging from that in any major way but we are applying modern digital methods and tools to make that more efficient in several ways and there are several benefits. And when I say digital methods and tools, I'm talking about, for example, I referenced an authoritative source of truth.
So, before, let's say, a non-DE approach, would use isolated stove-piped efforts that are exchanging maybe reports and presentations to each other and that is a way to communicate but that can be duplicative, there is a versioning problem there. So, you received a report, as soon as you get that, it's probably a bit out of date because someone had a conversation in the hall two days ago that changed what you're doing in that report, some programs are very fast moving and that's actually the point. If we're all working from the same source of truth, once someone makes an update, then everyone sees those updates live and then everyone knows what they're looking at is reality and what they can base their work on. I think in other efforts, because of this issue, you see people over-engineer their portion of the system to take ... Account is like, "Well, I got to over-engineer my portion because next week someone's going to reduce my margins and I have to account for that."
So, this prevents that and allows you to go faster. There's less rework, there's less excessive over-engineering, that
still happens to a certain degree especially for safety and reliability but you have less waste in the system and you're able to go fast because of that. And if you're able to move quicker to engineer a solution or you're able to more quickly evaluate options because you're using a digital approach, you can have a higher confidence in the solution that you do build.
John Arnold:
Right.
Gus Jordt:
And for DOD systems, there is definitely a schedule component of it. Each program office is trying to hit a milestone by a particular date and oftentimes it's very difficult to move that milestone so you're trying to get as good as you can by that milestone. And so, if you can get to a higher confidence solution earlier, that's a benefit you have in the system. You've been able to evaluate more options, assess them, trade studies, collect more data, analyze that and then make selections that you can be confident in.
John Arnold:
Right.
Gus Jordt:
And because you're analyzing more options, you are more able to find optimal solutions. So, the solution you actually get is better with the digital solutions, you can be more quick in this analysis and optimize and automate a lot of this work. So, oftentimes, we talk about system modeling and that's a big part of it, we refer to that but what this is also going to include your modeling and simulation, your data analysis, your infrastructure that supports all of that and also your business processes, how the program office itself is just exchanging information internally and with its stakeholders. If they're working within an environment that slows that down, that will impede some of the benefits you have but it's applying those digital tools and methods to the same system engineering process that we know and love but to make it more efficient, higher confidence, more optimal solutions.
John Arnold:
Excellent. Thank you so much for the clarification. Where does KBR fit in as far as current trends in digital engineering and in what ways are we set apart? How is KBR differentiated?
Gus Jordt:
Absolutely. I'll start with specifically with the customer set that I support and then speak more generally from there. KBR has a long history of supporting a wide variety of DOD customers in all services and helping Army, Air Force, Navy, Marines design, develop, deploy and support those systems. This was before the recent push towards digital engineering, we've been there and enabling success for our DOD clients. And so, now, because of the expertise that we have and we've been growing in digital engineering, we've been applying those benefits across the board on those programs in a very, I would say, integrated and cohesive way. And so, that is, I think, a very strong differentiation point in terms of the number of weapons system programs that we are a part of in the DOD is among the industry's most and then our application of DE is having a very large effect.
And so, if there is a new program that comes along, we have a lot of areas of success we could point to and say, not only have we done it, we've done it well and in a wide variety of programs. So, that really sets us apart in very many ways.
John Arnold:
Right.
Gus Jordt:
And then that extends to, with recent acquisitions and new members of the team, that extends to the space environment. We have a lot of work with NASA, with the space command as well so it's not just DOD. And also, I'm learning more and more about what we're doing overseas in our city design work and our oil and gas and our sustainable energy efforts as well. So, we learn more about that and we be able to harvest the best of what they're doing as well. I think another key aspect is the behind the scenes collaboration that happens across these different divides. It is a big company but it feels very small because I can reach out and touch someone working a similar technology or digital method or tool but for literally dozens of other types of customers and be able to pull them in and we have many times. Hey, we're having this problem, I think you've solved it, can you come in and talk about what you've done and we've been able to leverage that. So, that's a very good benefit as well.
And I think, beyond that, it's a very innovative company so a lot of tools that we've developed internally that we make for government customers that are pushing this state of the art. And part of this ... Some projects that I'm aware of that are really pushing this direction is applying Generative AI in design tools and modeling tools. And not to replace what our system modelers do or system engineers do but to really supplement what they do. When you have a large document to analyze and to decompose into a model or to inform that model, Generative AI can be a massive tool to really streamline that effort and get you to a good starting point. What we're doing with Cloud is very impressive, what we're doing with digital twins is very impressive.
Right now we have a project with our internal research and development which is essentially realizing that data exists in many formats and tools and domains and then being able to pull that into a common data as a service architecture such that you can easily flow data across these domains and then make your analysis more efficient across these domains. So, we call that lucid dream and so, anyways, it just represents some of the innovation that we do in the field that's setting us apart as well. And I'll hit two more just quickly.
John Arnold:
Yeah, sure.
Gus Jordt:
We have a lot of work in the test area. So, test is ripe for benefits for digital engineering and we're on the forefront of applying those methods to that. If you think about test, test basically take a large number of requirements, whether it's developmental or operational tests, and then design a set of test points for that, collect data and analyze that data and then write a report on whether we developed the right system or
developed the right way. And MBSC and digital engineering are really strong tools in that effort and we're on the forefront of making that happen. So, in terms of what differentiates us is our ability to apply this to all the key areas that our customers are needing it.
John Arnold:
It's encouraging to hear about all the behind the scenes collaboration and then, when I have conversations with people that talk about just using digital tools like AI, Generative AI, things like that just for the sake of using them, you get into a little bit of trouble because there's no strategy behind it. So, it's always encouraging to hear from experts like you that talk about there being a real impetus and purpose to using AI, digital twin tools like that. In your estimation, Gus Jordt, what's next in the field of digital engineering?
Gus Jordt:
Yeah, it's a good question. So, I've seen a progression and, speaking about the DOD and Air Force experience, there was a strong push by Dr. Will Roper, assistant secretary of the Air Force for acquisition technology and logistics who made the case that digital engineering and DevSecOps and open architectures are keys to accelerating our capabilities as an air force, as a DOD to ensure that we can meet the need of the threats that emerging near peer competitors are bringing to us. And so, at that time, I think there was an awakening and a realization, hey, these are powerful tools, these should be part of our set of weapons that we take against these problems of complexity, of schedule challenges and cost challenges.
And so, at the beginning, there was definitely an attempt to become aware and then learn how to apply the tools, learn what problems to apply them to and where can it provide an understanding and we in KBR we saw a spectrum of perspectives on this. Early on it was some folks were very deep into it and knew exactly what they wanted to accomplish and we were happy partners in that journey and we had strong buy-in from leadership. Others were not as well-informed but they knew it was important and they had a lot of questions and weren't sure what to do or how to do it. That was a few years ago, now, the rapid pace of change, we're seeing just about everyone in a leadership position understands, hey, this is part of the game, this is part of the landscape. Not only do we have to do this, we have to do it well to really achieve the benefits that the war fighter deserves.
And so, rather than just having a system model or having an ability to do modeling and simulation, we're seeing a lot more push to integrating those things in various ways. For example, if you're working on a weapon system, yes, have a system model for your particular missile but what are you borrowing from that other missile that does a very similar thing, can't you reuse parts of that? Is there a government reference architecture where all these missiles should be part of that same architecture? And also, how is your system model integrated with how you're simulating that and how are you tying those results back into the model to reinforce the lessons you learned, the knowledge that you gained? So, we're seeing that the emergence of the need to integrate across a lot of different dimensions, across the tool sets, across different programs that are similar and across different programs that are not so similar.
For example, one of the programs I do a lot of work on is focused on applying autonomy to intelligence, surveillance and reconnaissance and we have a very robust digital engineering approach there that I've been very happy to be a part of and help lead. And now the question is how do we use that model and that data that we're building to enable the other systems that interact with us do that more effectively and so that integration across the divides for this approach is becoming more and more important. And the other one we mentioned is how do we use automation and AI to do it even faster. How do we ensure those tools are enabling us to do it faster and well? There is a double-edged sword there. If it's not well-trained or if it's not-
John Arnold:
Right.
Gus Jordt:
Or if you rely on it too much or if there's not enough checking, then you can get yourself in a bad spot but we're seeing some benefit there that we're hoping to harness. So, those are a couple areas. We will see more GRAs form and we're a part of developing those government reference architectures and helping them be compatible. For example, the company's part of an effort to build an aircraft GRA, we're also part of an effort to build an autonomy GRA, we have autonomy in aircraft so those two different GRAs have to talk and then, the system models underneath, how do they talk so a lot of work to be done and we're seeing a lot of that.
Also, the emergence and the importance of a robust and capable digital engineering environment, that is a very strong trend as well. So, these same organizations that are realizing I got to do this, I got to do it well are realizing, hey, maybe the infrastructure that I have isn't the best for that task, what is the on premises, what is the Cloud, what is the server architecture that best answers that question and also best manages my constraints and cost and limited amount of people that I have.
John Arnold:
Right.
Gus Jordt:
So, those are the challenges and trends I'm seeing.
John Arnold:
Yeah. The bottom line is always important but it sounds like there are lots of exciting possibilities in the field. And I'm wondering which of those that you mentioned or perhaps one that you've not mentioned, what are you most excited about? Something that maybe is going to make your job easier or something that's going to maybe blow the doors wide open as far as an increasing efficiency or speed, what are you most looking forward to?
Gus Jordt:
Well, I should ... I guess I'll add one more to your list and this will probably be the one I'm more excited about. So, we've
mentioned a couple of times, we've mentioned digital twins and it's good to describe that a bit. If you think about any physical system, if you can represent that unique system in a comprehensive way, you've achieved a digital twin and there are benefits that come with that. Now, let's think of an engine on a large aircraft and you have a digital twin and, if you could introduce all the physical effects that engine will face in its lifetime, you can predict and foresee maintenance issues, maybe problems in system design, maybe operation optimizations that you could do and so there's a lot of benefit.
Now, there's a lot of levels to digital twins. On the more extreme level, you have a digital representation of a particular physical object that exists in the world. So, you might have hundreds of aircraft and you have a different digital twin for each of those aircraft and, if you can achieve that, that's awesome, that's incredible because then you could predict particular impacts of physical effects on a particular platform.
John Arnold:
Right.
Gus Jordt:
Now, that does take a lot of processing and data and overhead and I don't think we're there yet across the whole system, I think we're there for some subsystems which is great. More often you see a digital twin which represents the platform in general, right?
John Arnold:
Right.
Gus Jordt:
So, not every single one but, hey, for C-17s, this is a digital representation and we can analyze the effects in that C-17 virtually before we see it in the field. Let's say we upgraded the engines and we could model that with the digital twin, you can see those effects. So, a spectrum there. And then also there are digital twins of maybe subsets of that system, maybe it's not the entire physical environment that it's replicating but maybe just the electrical loads that it's going to replicate. And people use digital twin in that spectrum and I'm not here to debate the usage but just recognize there's a strong range there. So, that is a trend, for sure, we're seeing the desire and the push and the need for digital twins across more and more systems and I think what is exciting me is that we're getting to a place where the processing and the data and the Cloud performance is going to enable more and more robust digital twins in the very, very near future.
And also, the tool sets that we're developing and the others that I've seen to integrate the data across those different domains enables the robust digital twin performance that you really want to see. So, not only what is the plane's layout and twinning that and not only the electrical loads and twinning that, but also, like I said, the physical effects of the winds and the landings and everything else you can start to model. And so, with that, you get to a very, very exciting place of really leveraging these tools to save on maintenance and operations and extend the lives of these platforms even further. So, a lot of benefits to be gained for that so
that's pretty exciting work that we are definitely on the digital twinning production side and also the data integration side internally in the DREAMM Lab.
John Arnold:
Very, very cool, very exciting. I've got one off the cuff question for you. You mentioned that you served in the Air Force so, first of all, let me backtrack a little bit and thank you for your service. Secondly, KBR is in the middle of a global campaign called We Do Things that Matter and, obviously, there are tons of defense department contractors out there. What's your pitch for why KBR? Why does this feel like a special place to be right now?
Gus Jordt:
Absolutely. I think that's a multifaceted question and I say that because there's actually many reasons why that you could point to. I talked a little bit about our presence on so many different weapons systems and that's certainly a reason why anyone could choose and make a good selection on choosing KBR for a project. We bring that strong history of expertise and performance across all services across almost all our platforms and I'm very proud of that and it's very impressive. And I would say, and I've seen this and I've been able to talk to my colleagues in the industry, our internal collaboration is, not only very valuable, but I think, a lot of times, unique. I think a lot of companies, for whatever reason, are organized among these divisions that are, for better or for worse, are isolated but we've definitely created an environment where there is a collaborative and very friendly relationship among all the people doing similar work across all of our divisions and serving all of our different customers.
The IRAD work that I mentioned is partnering with our team that's focusing on Army helicopters. Now, I probably will never work on an Army helicopter but we're partnering with them because we have a very similar problem set. So, that internal collaboration helps us do a couple of things, flow those best practices and lessons learned, helps us shift resources and expertise to the place that matter most and it also makes it so that we're continually at the forefront. Me and my projects and my team is not going to see everything there is going on in DOD but, because we're all, on a weekly basis, sharing our insights and our knowledge and our observations with our colleagues across all these other programs, we're able to be at the forefront. We're able to say, "Hey, that's something my colleague over there is doing that's very relevant to my customer, I'm going to go reach out, get a meeting and try to figure out how we can apply that."
So, I think that's a very strong benefit, it's not one that's easy to see externally but I see it on a weekly basis with my colleagues as well. I think the focus and the freedom to innovate is super important. I'm lucky to be in a company and have leadership where I say, "Hey, this is a customer need that I see growing, here's my proposal on how to meet that need," I get support and say, "Okay, that's great. Let's see what we can do and make that happen. How can we get you resources and who can we bring onto a team and how can we organize around that?" Now, there is always going to be the questions about resources and ROI which are fair and have to be answered so it's not a blank check but, if you can make a good case and you can bring that, be able to articulate that, then you'll get support for sure. So, without that type of perspective, we probably would've never had that prototype DREAMM Lab, we probably wouldn't have our full DREAMM Lab now and other types of projects that we're working on.
And I think that does a couple of things. Not only does the innovation itself which can be valuable but probably larger than this particular field is, in general, the industry and the country as a whole is in a competition for strong talent. And if you can keep people very fulfilled and excited and motivated on things they're passionate and excited about, then you're going to retain them, then you're going to keep them and grow them and develop them into lifelong members of the team which can only help out. So, those are different ways KBR becomes, I think, the best option for when you say why KBR.
John Arnold:
You're talking about passion and excitement, you're certainly come through, they're very evident and I appreciate you taking one off the cuff to humor the old podcast host. Gus, is there anything else you'd like to leave our guests with before we let you get out of here today?
Gus Jordt:
Yeah, one more thing and it's probably an addendum to the last answer. When people talk about DE, I think there's a little bit of tension there. Part of that tension is, hey, this is new, this is different, why do we have to change. Right?
John Arnold:
Right.
Gus Jordt:
There can often be a change mindset challenge there and maybe there's assumptions or inaccurate conceptions of how it applies or the benefits you see. And that is one challenge that we've seen across ... I talk to my colleagues across the company, that's common. So, we've, through collaboration and discussion, developed some principles that I think are useful to point out because, as with any new tool or technology, it's never going to be the silver bullet that is going to solve all your problems and make all your issues disappear. It is another tool in the toolbox too and, when applied correctly, you can see those benefits.
And so, one of the things we've talked about is you really got to understand, talking about system modeling in particular here, understand why you're modeling. What is this model supposed to do for you, what are the questions it's supposed to answer, what is the tangible benefit or artifacts or deliverables it's going to do for you and work hard to define that upfront because, if there is this unclear understanding, then you're modeling for modeling's sake and you're quickly off the path and then it'll be unclear what you're delivering and why.
I think it's very important to make what they're doing accessible and consumable by all the team members. Not everyone that's a decision maker or everyone that's got an important stakeholder or just a contributor is going to be an expert in this and it has to be broken down and related to what they're doing, related to the process that they're working or what they have to deliver. And when you do that, then you'll start to see the light bulbs and the excitement and the interest and, really, the cooperation and collaboration on that.
So, that's a big principle that we talk about a lot. Also, you don't have to do it in a day, slow and steady will win the race. Some of these systems are pretty big and complicated, you build a confident and expert team that can tackle this, it's going to take a little bit time and allow that. And then, if you stay consistent with those efforts, before long, you turn around and like, "Wow, this is an impressive model that has a lot of information and start to answer a lot of my questions." Yes, it wasn't going be built in a week, it's going to take a little time especially with the big complex projects.
And this is probably not for us to really affect but it's important to keep in mind. We've talked about that change of mindset that happens, that is really enabled by and sometimes limited by whatever leadership exists on that team. So, if you've got leadership buy-in and they support you and they speak about it positively, they're encouraging the people to do it, you're going to get buy-in a lot more quicker and be able to accomplish more. If there's hesitance there or it's not clear or, for whatever reason, they're just not supportive, it's going to be very slow going and hard to make any progress.
So, if there's one person or a small group of people to get on board early, it's that leadership team and make it clear to them what are the benefits of what you're doing. Yeah, that regular stakeholder engagement is super important, it ties in with this other stuff but, really, you want them understanding what the model is and what it's doing for them on a regular basis because you're not going to get it one go, one overview of the model is not going to do it so they really got to make that a regular and continuous effort.
And like I mentioned before, the infrastructure is a big piece of that iceberg is under the water. It's always hiding there and it's something to tackle early, figure out, make sure you have something that supports the objectives of the program because that infrastructure, licensing, training is a big factor that gets overlooked too often. And I think part of ... I mentioned training, training is not a one and done thing, you got to do that continuously. Not only for the folks that are on the team executing and building the system model but other folks who are joining and, as they join and they learn some, there's going to be other things that they need to learn as well. So, training's got to be
a regular activity with this because it's new, it's not like people have been working in this mode for very long.
And I guess the last thing is I think people who do this type of work, digital engineering in general, brilliant people and they would love to invent everything and they probably could but, from a deliverable perspective, especially for those leading these teams, try to figure out what we need our team to invent and what exists out there that you can reuse because you're going to move a lot quicker and accomplish more to integrate and partner, that's been a big aspect of our team. Find, develop and leverage those partnerships where they're providing technology to make your systems and your solutions even better but also providing them access to a customer base that they may not have access for, those partnerships can go a long way to really multiply the benefits you can provide.
So, it's just a top level summary list of principles I think is important, things you got to think through as you make that strategy, as you build that out and as you continue along that path. It's not going to happen instantly, it's going to be an effort but, down the road when you're delivering that system and all the questions that people are asking and you have those answers because you've already looked at it thousands of times in simulation or down the road when it's time to do that system mod, you know exactly what the interfaces are and how the data needs to flow because you have a strong system model and strong interface model to support that. Those types of moments, you'll be a lot better off, and for a service and a DOD that's focused on lifecycle management, that's super important.
John Arnold:
Outstanding. Man, thanks so much for a super interesting conversation today. We appreciate your time and being with us and we'll definitely look forward to having you back at some point to talk about what's next in digital engineering. Gus Jordt, thanks so much.
Gus Jordt:
You bet. It was super fun. I appreciate it.
CONCLUSION
Teamwork making the DREAMM Lab — and digital engineering innovation — work.
It makes the rhyme long, but you get the idea.
I had a blast speaking with Gus Jordt and want to thank him so much for joining us on the podcast.
If you’re interested in what Gus had to say about digital engineering, or if you want to learn more about other KBR Digital Accelerators, you can head over to KBR.com and do a deeper dive there.
If you like what you heard today and have an idea for an episode — or if you just want to say hello — please email inorbit@kbr.com.
And as always, we want to thank you, our listeners.
I don’t know about you, but the world feels tumultuous.
Hopefully, the podcast is something you can come back to for some cool information or just a pleasant distraction.
Whatever the case, we’re grateful to you for spending some time with us today and for keeping US in YOUR orbit.
Be kind to each other, and take care.