Using Systems Engineering for Global Technology Deployments | Work Done Right with Mark Litke

Wes Edmiston: 

Mark, welcome to the show.  

Mark Litke:  

Thanks for having me, Wes. Excited.  

Wes Edmiston:  

Yeah. We’ve worked together, we’ve talked to each other quite a few times over the years, but I haven’t heard a whole lot about kind of your life in Boeing and even some of your life within that.  

Could you describe a little bit of the experience that you took away kind of your learnings from working inside of massive companies like Boeing or know, what you learned in those big companies? 

Mark Litke:  

There’s pros and cons to it.  

The pros and cons to a really large company like that is you get know, if you stay there for a good number of know, I’d say more than three to five years, you do get exposed to other types of jobs, other types of expertise, other types of people that you wouldn’t normally come across.  

Right. A company like Boeing has a defense group, a commercial airplanes group. It’s got all sorts of different engineering and testing and marketing and sales organizations, and you do get to see a lot of it depending on your role.  

But a lot of times you don’t. So you end up sort of kind of, well, why are we selling airplanes? What’s going on? Or take Shell. If you work in a business unit, like a downstream unit, the upstream, you may not ever really interface with them.  

In some companies I know, like in Shell, they do promote every three to four years or so, changing your job to a different role to get to see a different part of the company, you get a bigger kind of understanding of how it all comes together.  

So I think when you come into a smaller company, some of the functions and tasks you have to do, you may not have been exposed to in the past. And so you do have to learn quite a bit. It was always someone else did that, right?  

In a small company like Cumulus, you have to do that. But all in all, there’s so many resources available. When I was doing flight tests at Boeing, we were flying airplanes almost every single day, and there’s a whole crew of people that are going to repair and fix and prepare the plane, and a whole crew of engineers who designed all the systems and wrote all the test conditions.  

And then my job, my little job, was to just kind of make it all come together and run the test. But it was cool to see, hey, I didn’t even know we did that. I must have said that 100 times. I didn’t even know we did that.  

So it gives you ideas of other things you might want to try and do. At the end of the day, big companies have a lot of process and rigor they have to put into things. So you do learn to kind of be detail oriented, because whatever you do is going to get handed off to someone else and they have to take it on and it’s got to be right.  

So I would say that’s probably what I would have taken away from it.  

Wes Edmiston:  

Yeah. Having been in, we’ll say, a similar situation right. Working for Shell before this, and then obviously coming into here with Cumulus, it’s a really good point to make about there’s a lot of opportunity for exposure, but it’s like the opposite of the opportunity for exposure in a small company, right, where it’s.  

Where in a small company, you’re, like, thrust into it. It’s just a matter of, you have to do this because somebody has to do this, and we all need to pull as much weight as possible, so we’re all doing the work.  

Whereas in a large company, it’s like if you’re willing to learn more and you want to, you have the opportunities to kind of take on more, right. Just out of the sheer volume of work that you’re doing in the company or the company that the company is doing.  

So did you find yourself where you would kind of venture outside of your lane whenever you’re working with either Boeing or Shell to kind of are you a generally curious? 

Mark Litke:  

I do. At my role at Boeing, I got to see a lot of different organizations.  

I got to see customer facing and internal organizations, and I sort of ended up in my path of kind of getting out of engineering and into more of a commercial role because I tended to kind of enjoy that side of that job right.  

Interfacing with customers. And curious, like, hey, well, what do you do on a daily basis? How did you get into your role? You start asking that question because you don’t know, right? You start straight out of college.  

You’re like, how do you even get your job? And that’s cool. Who else does that type of stuff? So, yeah, in general, curious, and a lot of times you ask those questions, and you go, I don’t want to do that job.  

I don’t want to go that way. So you kind of have to plot your path in those big companies, you. Went from engineering into kind of business development, which those are very different worlds to be in.  

What was it like kind of making that transition from the objective discipline of engineering into kind of the more soft, skills oriented business development? It wasn’t like one day I woke up, and I was doing a different job.  

Right. I think through different roles, you go from a purely engineering role, where you’re very internally focused. You’re looking at a product or a specific engine component or whatever it is. And then I was into that flight test job where I was able to kind of interface with customers and having to deal with pilots and customers and engineers and ground crew.  

You start to kind of develop a skill around being able to explain things in different languages effectively. Why is this important to you? And why is this important to you? And why do you care? Why should you care?  

As you start to get comfortable in that world, you kind of naturally trend towards more externally facing roles. So when I went from a pure engineering job into more of, my first stop was obviously flight test.  

And then it was more of like, what would be the right word to put it? Kind of a representative role. So when I was at Mitre, I was doing foreign military sales. So it was an organization at Mitre that kind of facilitated the procurement of from one DoD through the U.S. DoD of in this case, it was like landing navigation, airport systems. And so you don’t really have a customer because it’s not like that. But you do have a stakeholder. You do have someone who’s paying, and you have to kind of get yourself to where they’re at and listen, right?  

You got to make sure they’re happy that you’re delivering what they want, even though their customer effectively someone else is their customer. But you start to get good at that, and then you just kind of keep going, right?  

And now it’s like, hey, you can talk about a product. You can talk to customers. You can talk to stakeholders, you can manage expectations. You can understand requirements. And then you kind of end up more in towards a more salesy technical sales role, right?  

Now, you’re the technical sales guy or whatever it happens to be. And then if you get good at that, you just kind of keep going. And so the pendulum kind of slowly swings through different roles to where now you’re effectively doing business development, trying to make money for a company.  

Yeah. So that was really kind of that step change process kind of through the way that was the natural, organic progression of it from engineering through, like you said, kind of technical liaison almost into more of a business development role.  

Yeah. And some people don’t want to do that, and that’s fine. Right. I have friends who I worked with at Boeing who are still doing basically the same job, and they love it, and that’s great, right? That’s just there was so many people there who are just pure airplane nerds, and that’s exactly who Boeing should have working engineering at the Boeing Company is airplane nerds who just love it and live it every day.  

I am an airplane nerd, but my personality was much more outgoing, much more type A, much more, hey, let’s go find a problem to solve type of type of person.  

Wes Edmiston:  

Yeah. Has that been since day one? Have you always been extroverted and really social?  

Because that is a very characteristically that is atypical for somebody that goes into engineering.  

Mark Litke:   

I think it’s probably more my personality. I mean, I grew up playing every sport you can possibly play.  

I was on teams when I was a kid. I was just always outside. I just wanted to be outside doing things. I wasn’t much of like, hey, I want to watch a movie, or kind of introverted focus on something. I was just outside, and it was like, hey, where I grew up in Northern California, it was very rural, so there wasn’t like I couldn’t just walk to know.  

And so I’d be home from school in the summer, and my parents would be at work, and it was like, well, I got to go find something to do. And so you’d have to go outside and make up a game or go on a hike or whatever it was.  

And I think it just ended up being personality trait of being kind of outgoing, curious, trying to talk, understanding things and talking about it. Yeah, there’s a lot of engineers out there that again, I have a lot of friends.  

I went to engineering school who are just like me. They were just outgoing, sports related people, and they ended up. You know, coincidentally doing basically the same thing I do. So I think it’s just kind of how you grow up, what you do.  

Wes Edmiston: 

I don’t really think it’s something you can learn. It’s like trying to learn to be an introvert is very hard. Right. It’s probably impossible, so someone go in the other direction. It’s probably the same challenge. With having traveled around to different locations and implementing different technologies. Have you seen, say, like, a different appetite for technology in different areas? Have you seen basically different needs?  

Also, where maybe here domestically, in the States, we’re focused on one style of technology, whereas maybe in APAC, they’re looking at something different? 

Mark Litke:  

Everywhere I go, people are genuinely curious about new things.  

People want to know what’s going on, what’s new? What are you thinking about? How are you doing it over there? Obviously, nowadays, there’s no real lack of access to information. Everyone can kind of see things and listen to podcasts.  

And whatnot about technology? I think each region of the world that I’ve been to, I haven’t been everywhere, obviously, but I’ve been a lot of places. Culturally, there’s a different kind of adoption process, if you will, in the US.  

In a lot of industries, it’s kind of fail fast. Right? Let’s try it and see if it works. If it doesn’t work, okay, it didn’t work, we’ll move on. In other places, it’s very thorough. Right? We want to make sure it’s right.  

We want to derisk it. We want to kind of see how it affects everybody else. And then in other regions, they’re just like, no, we’re good. Sometimes access to capital, maybe the economy isn’t there, maybe there’s an exchange rate.  

I don’t know what it happens to be, but I think in general, what I have learned from doing this all over the world is more so an understanding of. Culturally how to kind of operate and do business there, because I don’t think the answer is ever.  

I don’t want to improve or innovate or find new things to do. It’s just this is how it’s done. You know, if you go to Asia Pacific, in some countries it’s it’s just like the US. Very fast. Hey, yeah, we want to improve, we want to get better.  

Let’s see what it’s all know time zone challenges there that make the process hard. If you go to places maybe in, I don’t know, other parts of the world where maybe they’re not ready yet for a technology like this, they’re kind of still figuring it out that’s okay, that’s the world we live in and you have to understand that.  

And I think that’s where kind of being that curious, outgoing person of just going, well, what’s hard about this, what’s interesting you, what are your challenges and trying to kind of meet them where they’re at every time.  

I’ve really enjoyed being able to travel all over the world. It was something I really wanted to do when I was younger. Obviously being an aviation geek, I can sit on airplanes all day long, but I was always just really interested in going other places and seeing new things and cumulus.  

Now I’ve had the opportunity to go with Shell as we started out and getting cumulus out the door. I was very fortunate to be able to travel to some places that I would never have gone to for any reason other than work.  

Right. You go to a place called Messira island, Oman. It is the most remote place I’ve ever been. It’s like you land on the moon and you’re like, what am I doing here? And you go there and it’s just fantastic.  

The food’s great, the people are friendly, and little experiences like that are always very cool.  

Wes Edmiston:  

Yeah, it’s interesting and exciting to think about that there’s those areas out there. But also to me, it kind of speaks to the idea that.  

That in these different implementations, in these different locations, the problem is different. The problem is very different in India than it is in the United States as opposed to it is in Oman, right?  

Labor rates are entirely different. What they’re building oftentimes is very different. Some areas are more modular focused and fabrication yard oriented versus others are the on site implementations. 

And it sounds like you’ve been open minded in at least trying to break down kind of what the needs are from the different areas and understand kind of what they’re saying whenever you go there. And you’re not just kind of that salesperson that has the watches in the trench coat, right?  

Because nobody wants to be around that person.  

Mark Litke:   

Nobody does. I try very hard not to be that person all day long. I think you made a good point, right? The problems are very different. But they may be different one place to another, but in that location, that’s their problem, right?  

And what you find is people, no matter where you go, are very good at saying I’ve got this problem, I’ve got an issue. This is how I describe it. This is what it is in Shell, we had some cool projects where that was sort of the whole point of the job was sometimes to kind of sit down and basically systems engineer the problem back, listen, hear them and turn it around and say, this is what your world looks like.  

And here’s some of the areas where, whether it’s technology or process improvement may be able to help. And I think you’re always more successful if you listen first and talk second. I think a lot of times that guy in the trench coat with the watch is the talk first and never listen type of person.  

You just can’t, right? I heard someone tell me once you have two ears and one mouth for a reason, right? No matter where you go in the world, you have to. Meet everyone where they’re at, right. Whether know, adopting some of their know, going, like, I’ve eaten all sorts of crazy types of food, no matter where I’ve been.  

That again, like, I never would have eaten ever here in the United States. But you go there, and it’s like, holy cow, I just had a camel burger, right? Who’s going to eat a camel burger here? But it’s like, this is what happens.  

And if you go in with that kind of mindset of like, I’m going to try things, meet you where you’re at, understand your culture, relate to you, try and really put myself in your shoes and listen, good things happen.  

Wes Edmiston:  

Yeah. First off, I suppose there’s no better way of celebrating hump day than with a good camel burger. I don’t think it was a Wednesday. You touched on the systems engineering a little bit, and I kind of wanted to dive into that real quick.  

While we’re on the subject, is there anything I guess, could you provide a description of kind of overall, what you’re talking about whenever you say systems engineering and then maybe touch on some of the frequently identified issues solutions in order to help out some of these sites that you would go to?  

Mark Litke:   

Systems engineering is an engineering discipline, right? You can go to school and get a degree in systems engineering. My degree was aerospace. But what systems engineering basically tries to this is day 1101 systems engineering explanation.  

So if anybody listens to this and I get this don’t go nearly in depth. I’m putting a little disclaimer on it here.  

Wes Edmiston:  

Disclaimer has been made. You’re not technically a systems engineer by discipline. Got it.  

Mark Litke:   

But what a systems engineering approach to I mean, you do it kind of all the time, and I think a lot of times people don’t even realize they do it. It’s, it’s at the core, it’s a way to evaluate trade offs.  

So if you think of anything as a system, it can be the engine on an airplane, it can be the air conditioning in your car, it can be your household. Finances can be considered a system. And what systems engineering does is it tries to essentially model those systems in a way that reflects back the behavior of how they happen.  

So if you’re going to model the engine in an airplane, you’re going to have the various systems down to you’re going to have your turbines and your compressors and your thrust reversers, and your generators, and your bleed air that comes off of it.  

Those all start at a higher level system, which is the engine. And then you’ve got systems and subsystems and subsystems all the way down. And the kind of very powerful thing about systems engineering is if you do it right, it sort of takes objectivity out of it.  

So if you’re going to say, what’s the best? And it comes back to that top level, if I want my engine to put out x 1000 pounds of thrust, what are the trade offs in my smaller subcomponents and systems that are going to get me there?  

And if I change this thing, what happens over here? And it’s a really interesting approach because like I said, if you get enough data and you build the system right, it becomes just almost like a bunch of levers you can pull and see what comes out the end.  

And so as I’ve done this in practice, whether it was like one of the best ones we did was for maintenance in refineries and downstream facilities, and I think it was an approach to that that may have been relatively new when we did it, or at least maybe like the first time they thought of it.  

It allowed people to kind of go, well, all these in this case, there was a lot of technologies that were, we should try this, we should try this, we should try this. And what ultimately happened was no knock on any individual technology.  

But if you couldn’t show why technology a fit or why and how it fit into the system and what it was proving versus what the end goal or the requirement of the system was, it was very easy to say, this isn’t going to solve the problem.  

Because if your goal in your system is to reduce cost by X percent, and you have the data in your system model to show how much things cost and what the ROI is on each one, it’s very easy to say, well, I can put this technology in here.  

I could throw everything at one technology, and that would solve my problem. Okay, but that’s going to screw everything else up. So it was kind of a very powerful way to say, this plus this, plus this here, here, and here gets you the result you want.  

And if someone said, Well, I don’t want to use that technology, it’s like, okay, that’s fine. It’s a system model. Like, we can plug things in anywhere you want to go, and it becomes just a very cool tool to think about really large things.  

Wes Edmiston: 

One of the things that you said whenever you were talking about the different areas, the different regions like APAC, United States, South America, anywhere else, and their sort of mentality whenever it comes to technology implementation is you said parts of APAC are very deliberate about implementation.  

They plan everything out, and they want it to go kind of perfectly where, whereas maybe here in the States, we just will say, hey, let’s try a pilot, and then we’ll go from there. It sounds like the systems engineering approach is kind of leaning more toward what it is that some of these places over in APAC already do kind of.  

Kind of kind of naturally, but it’s helping people to identify the right opportunities to follow. Right. And like you said, just kind of objectively, right? Let’s eliminate the subjective ideology of, well, I like this one better than that one.  

This is just a simple let’s boil it down to the numbers, right? Let’s reduce it down to to really what matters to the business, to the site, to everybody involved.  

Mark Litke:   

We wanted to avoid the hippo principle.  

The hippo principle is the highest paid person’s opinion. The hippo principle, right. So you do see a lot of times where you live in a world and I’m sure you’ve experienced it, where the hippo principle comes roaring in, right.  

And it’s just highest paid person’s opinion. And with systems engineering, even if you do it very rough cut, right. Let’s just kind of get a high level analysis of what the heck your thing is and then let’s figure out what the challenges you’ve outlaid fit into your system.  

Now, you can really kind of rein in that opinion element of it because sometimes you’ll see that people will want to try something that’s very low cost, real easy. Right. And it’s like, oh, we did it, we got something in.  

And it’s like but it didn’t do anything. And a lot of times people will want to kind of jump three or four steps ahead because the technology they want to try is the cool thing of the day. But it’s like, yeah, but you can’t get there until you do these three things first, because of your system.  

Wes Edmiston:  

I just like it because it takes as much subjectivity out of it as possible. Yeah. Was there anywhere that. I guess that hippo person. The hip person that is. Were there any instances where maybe after you did your system study, once you came back and you provided what your outline was or the report, whatever you would call it, was there any time where that person was maybe surprised by what it is that you came with?  

Or was there any where maybe there was some level of objection to that? And what sort of technology maybe again in this downstream example, what sort of solutions did you find that would best help these sites?  

Mark Litke:   

So your first question, I mean, the answer is yes to both, right? The hardest part about managing those opportunities is that it’s not an immediate thing. So the work is the work. You have to build the system model, find the data, layer it in, and then you have like you ever seen those?  

I don’t even know. It’s like a picture, a painting where it starts really zoomed in and it zooms way out. All of a sudden, it’s like, oh, I was looking at an alligator. And at first it was just this little green blurb.  

That’s kind of how systems engineering happens is you have to really start granular where you don’t know what a problem you’re solving. Yet a lot of times you don’t know what the answer is. And a lot of times people are like, hey, I need the answer.  

And you’re like, hold on, we will get you the right answer. And as you kind of zoom out and zoom out and zoom out and things scratches come into focus. Oh, my God, I didn’t even realize that this talked to this over here.  

So as an example, that one thing would be we did some work in maintenance and downstream. And when you make the architecture, as I’ll call it, of a maintenance system at a chemical plant, refinery, whatever it is, it doesn’t really matter.  

And you start to kind of show how maybe. A mechanical contractor. And the job they’re doing in the field actually connects through four or five different nodes to the procurement person buying a material or someone up redlining drawings in a drawing repository.  

And you start to zoom out and you say, hey, for these people over here to do their job, they need access to all these people. And you need a way to communicate and show how it all comes together. And the problem you explained to me was that this person doesn’t have a clue what’s going on over here.  

And a solution to that problem is to put something in the middle or whatever the answer might be. And that’s what kind of the zoom out is. It’s like, oh, my gosh, this group is having non productive time waiting on something, and this person doesn’t know what to order.  

And it’s like, oh, it’s the same problem, but two people are having it, so let’s try and resolve that problem and that’s that system architecture model, because if you hadn’t thought of it that way, you might have two solutions that just kind of perpetuate the problem.  

Right. It’s like, we’re just going to make you wait less for somehow start work, go now type of thing, and then, well, just order a lot of it, and if we whatever we don’t need, we’ll throw away type of thing.  

And it’s like, no, let’s pull back. Let’s look at the problem. Let’s write it down as a requirement. The guys in the field can wait no less than ten minutes to start their job after getting their permit.  

Okay, well, what goes into that? What are the things they need? And it’s like, okay, well, they need the materials to do the work. Let’s go back up the chain and find out, well, where are the materials?  

Are they in the warehouse? How’d they get in the warehouse? Who ordered them? Where does it go? When was it ordered? What was the work order? And that’s what you find. And it’s like, oh, my God, this is an easy fix to solve these two problems here, and it’s right in the middle.  

Wes Edmiston: 

Yeah. That just speaks to the fact that whether we’re talking about on a project, whether we’re talking about in an operating facility, we are all interconnected. And kind of the obvious answer isn’t always the right answer.  

And. And maybe it is like you’re saying that people don’t even realize that we are all interconnected, but we’re all in pursuit on a facility for the same end goal. So it’s very likely that if you’re experiencing a problem kind of tangentially or adjacent to one person yeah.  

That likely. You’re going to feel some level of side effect of that as well.  

Mark Litke:    

Yeah. And I will say that that example I gave, I think people who have a lot of experience in the world, I’m not saying anything they don’t already in their gut recognize like, there’s a problem here and I need my stuff and that person orders my stuff, whatever it is.  

But what the systems engineering kind of view of it does is it says, here’s a way to solve it and here’s how much that thing to solve it costs and here’s how much time or money it’s going to save you if you implement it.  

And then you can say, do I want to pursue it? Yes or no? Will it work in my It architecture or will it work in the field? Then you get into more evaluations based on data decisions, not an opinion, not, well, I need this and then I need this and then it’s like, whoop hippo, right?  

And that’s what happens.  

Wes Edmiston:  

Yeah. And I imagine it helps you to, if anything, provide a longer term roadmap for implementations. Because maybe this year’s budget, we can only take care of three of these things or implement three of these technologies.  

So let’s target the top three, like the highest value add, and then next year we can roll into something additional and we can map that out for the long term rather than, I’m experiencing these problems and you’re experiencing some different problems and the budget ends up going to whoever yells the loudest.  

Mark Litke: 

Right. And it makes investment decisions somewhat easier as opposed to and frankly, we talk a lot about there’s a term in the industry, pilot purgatory. And I think a lot of times when anything ends up in the stage of pilot purgatory, it’s because the job it’s supposed to do isn’t well defined.  

What’s the job to do a lot with all this AI technology that’s coming out, there’s a lot of really awesome things you can do with chat. GPT ish like large language models, generative AI eye, stuff like that.  

But what’s the job? That the AI, whatever is going to do. And if you can define the job, it’s this job, then you can get a tremendous amount of value out of it because you can describe what it’s going to do.  

But if AI for AI’s sake, it’s cool, be fun, but it will only get you so far because it’s a hammer looking for a nail type of solution sometimes.  

Wes Edmiston:  

Yeah, definitely. And there’s certainly enough examples of hammers looking for nails out there on the open marketplace right now.  

Through the work with systems engineering, I imagine you were exposed to a lot of different technologies. And if anything, it kind of speaks to just this interest that you’ve had with technology and different engineering solutions throughout your career.  

You recently presented at the CTMA Conference, is that right?  

Mark Litke:  

Yep.  

Wes Edmiston:  

Where you ended up winning the People’s Choice Award for your product. Would you mind kind of explaining what the CTMA Conference is and what it is that your product does? That was the winner?  

Mark Litke:  

Yeah. So CTMA and there’s another group called NCMS. It’s organizations that look at this is my first time there. First time kind of involved in the organization, but it’s really about maintenance and materials in the DoD.  

So how do we and it all goes back to the kind of the strategic themes of national security and readiness and reliability of the US military. And so I’d worked with the DoD in the past, so a lot of the themes were relatively the same.  

I had to kind of dust off my acronym library to understand what all that was. But know, we presented a technology from Cumulus. It’s called weld scout. And basically what it is is it’s a technology, know, you can use the letters AI to describe it.  

And what it does is it identifies anomalies in welding scans. And so traditionally, for different types of welding applications, in this case, it was phased array ultrasonics. The raw data would come in from the scan in the field and a trained inspector would have to go through these data files and dig into them and identify the anomaly one by one, or no anomaly one by one by one by one.  

And it’s pretty slow, right? Because it’s like being a radiologist. You have to look at these things and understand what you’re looking at. So you have to be very well trained. In the case of this technology, there was a couple of reasons why we started working on this.  

It was one, there was a lack of inspectors to do that job and there was a tremendous amount of work to be done. And so it was a project schedule impact. And so what we presented, or I presented down there is hey, if you’re doing a material inspection and you’re using phased array ultrasonics or ultrasonics, which we’re going to get this into, what WeldScout does is you set its left and right limits.  

You train it on the scans and it’ll tell you here’s all the anomalies I’ve identified on all these scans within these left and right limits. And. An enormous workload off the Inspector to have to dig through and find the anomalies.  

Now the Inspector can do the Inspector’s real job, which is to say, what should I do about this anomaly? Is this really something that’s wrong in the weld? Is it a defect in the material, whatever it happens to be?  

And it just kind of sheds that dull work of finding the anomaly, because the real goal is, what do I do about it?  

Wes Edmiston:  

Whenever you’re scanning through whenever your eyes are tracking through hundreds and hundreds of feet of scan in a day or however many hours it is that you’re doing this, I imagine there’s a significant amount of eye fatigue and you could probably end up missing a good amount of issues just out of the fact that I don’t know if you’ve ever tried to read something on a screen for 5 hours straight.  

You’re going to start missing words after a while, if not whole sentences. And very similarly, these techs, whenever they’re doing this pat scans, they can easily miss large swaths just because their eyes are strained.  

Mark Litke:   

Yeah, and there’s examples of that. I mean, we highlighted one where there was a missile tube weld, and the first passive inspection missed a defect in the weld. It was 100 inch long weld. And now the second inspection caught it.  

But regardless, the second inspection caught it, the first one should have caught it, but they had to go back and reinspect the whole thing and do a bunch of rework and stuff. I remember back when I was doing the unmanned aircraft stuff, the mantra was always, people would say, it goes back to this job to do what’s the job to do for an unmanned aircraft?  

And it was always like, well, any job that’s dull, dirty or dangerous, right? And so you go, okay, yeah, I understand. Why a drone? For whatever reason, it’s dull, very dull, long flights. It’s maybe not dirty, but definitely dangerous.  

But it’s like, okay, does it fit into this window of a dull, dirty or dangerous thing? And for augmenting or being a force multiplier. I keep going back into DoD land. A force multiplier for the inspectors in a dull task is exactly the job that this is supposed to fill, and there’s a tremendous amount of value in it and it’s a helping thing.  

It makes you more productive. I actually think in a lot of these cases, there’s a perception that it’s taking away, and I actually think in these cases, it’s actually identifying and honing in on the actual trained skill.  

So it’s making you more skillful, not just wasting your time on the BS fluff that’s in the middle.  

Wes Edmiston:  

Right, right. It’s like if you have a weld inspector with years of training, this will make them better.  

And it’s like, you’ve been trained to do this, you’re an expert. Awesome. Let’s help you be more expert and not remove and say, well, maybe all that training you did, you don’t really need all that. Right?  

It’s like, no, you do need all that, and this will make you faster, more productive, be able to do more. So I think it’s a helping, not a hurting. Mean, I’ve talked to a lot of folks, PAUT has really been on the rise here lately over the last several years, just especially out of the fact of not having the risks of exposure to radiation like you would have if you were doing conventional RT or something of that nature.  

So PAUT already has kind of a leg up in certain areas compared to some of the other forms of volumetric NDE and being able to help provide a solution that would make it faster and higher integrity. It sounds great.  

I guess it’s no wonder that you all won the People’s Choice Award at this conference. So congratulations. That’s huge news. Good for you guys.