Transcript.

Erik: Matt, thanks for joining me on the podcast today.

Matt: Hi, Erik. Thanks for having me. I'm really happy to be here.

Erik: Yeah, I always enjoy understanding the thought process behind books. Because it's a big endeavor to take up the challenge of writing a book and putting your thoughts into words. So I appreciate you reaching out to me about that.

Matt: Absolutely. I'm just looking forward to getting the word out. It was really a labor of love that was really encompassed my journey over the past 15 years or so, which we'll get into. But I think a lot of people have asked me over time when hearing my story about how they could apply some of the methodologies that my team and I had developed, working first in aerospace and then in energy, to deploy technology. I wanted to just put it in a book so that people can do it themselves.

Erik: Yeah, great. Let's start with your story then before we get into the meat of the book. So you were working as head of programs for Shell TechWorks right up until you started your company, Cumulus. So I guess there's going to be an origin story. What was the spark that led you to commit yourself to solving this particular set of problems?

Matt: That's right. It actually goes before joining Shell. But part of joining Shell led to Cumulus. I originally started out in the aerospace industry, as I mentioned before. I was working at a company called Draper Laboratory. They built control systems for aircraft and spacecraft. And in 2010, after the Deepwater Horizon disaster — that's the BP oil spill in the Gulf of Mexico — a number of energy companies came to the company I was working at and said, "We want to learn from the aerospace world how to make industrial facilities, especially those that operate in hazardous environments, how to make them safer and learn what the aerospace industry is built over the previous 20, 30 years, to develop one of the best safety records in the world and apply that into energy. Because the Deepwater Horizon was such a big wake up call, that things needed to get better and that the status quo was not acceptable.

So I started doing that work, leading that effort at Draper. Then eventually, I was hired by one of my customers, which was Shell, to start a center in-house which was Shell TechWorks, which you mentioned, which brought in people like myself who are from other mission critical industries — aerospace, robotics, automotive — to really take a critical hard look at energy and answer that question. How do we prevent a Deepwater Horizon or any other type of disaster from happening again, and use a methodology that had become common in aerospace, which is called systems engineering or systems thinking? That means looking at a facility or a project not as a bunch of individual silos, siloed disciplines, and trades as they become common in energy and heavy industry more broadly. But look at them systematically. So everything is part of almost like a living organism, where something happening way over to the right-hand side could have an almost unexpected impact, positive or negative, something all of it on the other side of the plant and to be able to model all of that.

We started doing that in Shell. We came across the problem inside of Shell, but this applies to the industry broadly of people, frankly. And what you ended up happening was all this technology being applied to planning activities, monitoring facilities and equipment. But then, people would go out to the field to do very critical work. There was very little visibility into what was actually going on. Owners like Shell are entirely reliant on the contractors and the people doing the work to self-certify, yes, I did the work correctly. Unfortunately, very often, that isn't the case. Either the workers don't have the right training, or they're rushing. They don't follow the right procedures. That is the cause of a disproportionate amount of accidents. So we created Cumulus to solve that problem — to bring visibility, transparency and accountability to the humans in the field. So you get the same type of data out of them that you might get from sensors on a pump, or a rotating equipment, or some other type of equipment in the facility.

Erik: Okay. Clear. And so let's dive into this concept of systems thinking a bit more. Because I guess, if we think about this in terms of defining a business model, it's like working in a room with a bunch of guys thinking through the different aspects of a problem. Systems thinking is fairly, fairly simple, right? It's still complex. But you have a controlled group of people. They're all kind of communicating with each other. You can lay out the problem, and you can discuss it from different angles.

If you're doing this in the real world, it's not a group of 15 people sitting in an office. It's 15,000 people, including people that are working on an oil rig and maybe installing a bolt or something. They're a part of that system. And so that seems to be the challenge here. How do you think about this kind of problem from an organizational standpoint, of bringing systems thinking beyond this group of white-collar specialists to a broader organization?

Matt: Great question, Erik. The most valuable element of systems thinking when coming to solving business problems is understanding your level of abstraction. What I mean by that is, you mentioned the example of 15 people in a room and a whiteboard. Well, you could define a problem where that is your universe, of those 15 people, the problem of what should we get for lunch today. You have to look at those 15 people. Okay. What are any dietary restrictions? What do people like to eat? Maybe cultural backgrounds. Maybe look at what foods available as your options. That is your system. But really, that's usually not what people are looking at in the industrial world. They're looking at a plant, or a facility, or maybe a few different facilities. What systems thinking encourages them to do is to understand the different layers of entities that all interact to affect whatever problem it is you're trying to solve. And so you have not only the people in the plants and the equipment but also contractors, the regulations, other facilities, other supply chains that are leading into that facility. And really, to understand who are the players and look at that broadly and understand how they all interact with each other.

What we found when we were coming into this industry, coming from an aerospace background, is that that type of multi-layered thinking simply wasn't common. It wasn't expected. People had their area of responsibility. I'm responsible for this part of the plant. Or, I'm a contract or a procurement person. I'm responsible for the contracts or whatever their specialty has to be. That was very siloed. That's how they looked at things. Frankly, there was a lot of low-hanging fruit where things could get better if only people lifted their heads and worked with others to understand how truly interconnected everything in the plant is.

Erik: The concept makes sense in principle. In practice, of course, this is very challenging, right? Because it's one thing to say we should do this. We should think in this way. It's another thing to actually get all of these people to not just to think in different ways people might want to. But they have incentives. They have operating structures. There are certain processes that are important and that you don't want to just change on a whim because another concept makes sense. So there's a lot of friction in terms of actually making this.

So if you think about an organization saying we want to adopt systems thinking principles in an operation environment, as an organization, how do they start to think through the process? What does that mean in terms of training, in terms of rethinking processes, in terms of maybe compensation or incentive schemes so that we can get the whole organization on board with this new way of working?

Matt: Yep, another great question. It's not really so much. I don't think compensation and incentives are the player, but it's really educating and making it, giving people the opportunity to work with others in their organization and setting the expectation that that's expected. The most effective way to implement this that I've seen is to start small. Don't try to implement systems thinking where you try to say, we're going to improve everything about the plant, or we're going to tackle a macro problem of increasing margins generally for the facility, which has a lot of different impacts. What we've seen as the most effective way to get started is to really look at a bite-sized problem that you can easily solve using this methodology, and let people see the success. Feel good about the success, and get excited about it. Defining the problem is almost half the battle. And if you want to bring this into your team or your company, start with something that's definable. How do I improve safety for a specific activity?

In the case of Cumulus, we started with the problem of, how do we prevent leaking pipe connections? That was a challenge we had across our facilities inside of Shell. We really started looking there and understanding all the different players involved in assembling and maintaining piping connections. But once we were able to address that problem and create a solution, we were able to then expand and say, okay, there's a lot of other challenges at a facility that have a lot of the same characteristics as pipe connections. Maybe it's how we do pressure testing, or how we do welding, or how we do a myriad of other types of maintenance activities. Now we can apply these same methodologies as a bigger scale so that taking one victory after another, and making this seem like not so much a giant top-down change but something that people were excited about at all different levels because they saw the results, and they saw how it benefited them and helped them do their jobs better whatever their particular role was in the company.

Erik: Let's dive into that case of leaking pipe connections a bit. Because I think it's often useful to go deep into a specific example to understand. What was the before in terms of how people were working here, and then what was the after in terms of the way that people were coordinating to solve this problem?

Matt: Typically, in energy, probably about 20% of leaks at a refinery or a chemical plant are because pipe connections are not properly either assembled and maintained. What I mean by maintained is that after you first build your facility, you are, about every 18 to 24 months or so, you're essentially taking the facility apart, doing all the maintenance. That wasn't emergency maintenance but everything that had built up over the past year and a half, and then putting everything back together. You're essentially rebuilding this facility every two years or so.

What typically would happen during these, these are called facility turnarounds, is there's a large turnaround in the plant. There's a whole bunch of activities that the contract workers who are hired have to do. Because again, you've saved up all of this necessary maintenance to do during this facility turnaround. Then the workers go out into the field and do this work. Most of the workers are people who are not regularly at this facility. The population, some numbers I saw at one facility, the population of a plant can go from 600 to 5,000 during this turnaround. That just shows the magnitude of the number of contract employees who come in just to complete this turnaround. But that means that these individuals are not regulars at the facility. They don't understand its unique procedures or whatever other idiosyncrasies the facility has. They're under tremendous pressure to get this work done as quickly as possible. Because every day that the facility is offline could cost the operator of that facility millions of dollars in lost production.

So you're bringing in all of these people, having them perform a fairly intricate task of taking apart, performing maintenance on, and reassembling all these pipe connections. These piping connections are typically carrying hydrocarbons or other hazardous materials, and they're being told to do it as fast as possible. That is why you often get, just by human nature, people under pressure and rushing to finish this work as fast as possible. Things get skipped. People don't have the right training. All the records, by the way, are typically kept on paper still. So even if you do all the planning and scheduling on your computer systems, that goes from digital back to analog. Then all these paper records have to be compiled and collected and brought back into some central location. And so if there was a problem, you might not know about it for days, weeks, even or months after it happened of really some inspection report, if you know about it at all. So that's the situation we were coming into. The challenge was, how do you eliminate mistakes during this process?

Typically, it happened before. There would be new procedures, new paperwork added to correct whatever the most recent accident or mishap was. The expression that you're planning for battles usually means you're planning for whatever happened in the last war. That's the military expression. That's what happens in these activities. You're planning to prevent whatever went wrong last time. So we said, well, let's take a step back. How do we get data out of these workers, and not have to increase the amount of paperwork, the amount of procedures? Because that wasn't making any difference. And so we saw, in this case, that there was a new technology coming onto the market of connected tools. Wrenches and other tools that workers use regularly suddenly had Bluetooth or other types of connectivity. This was just something that was happening in the industry. This wasn't specific for oil and gas. We saw that we could use this connectivity to get the same validation of what the worker did in the field that you would get by having a sensor on a pumper, or on a rotating equipment, or some other piece of equipment. But you get that same data.

Not only are you getting data about who's doing the work, how long it's taking them to do it and how well they're doing it, but the worker also realizes there's digital record being kept of what they're doing in the field. So not only is the sensors and the tool helping you manage his work better. But the worker realizes that there's a priority on getting the work done right, and they should take a breath to make sure it's done, and if there's a preference for doing that work correctly than doing it quickly. Because if you do it quickly but incorrectly, that's just going to cost you more at the end of the day.

We built a prototype of the system. This was back in 2017. We actually first deployed it at a facility in Singapore. Immediately, after the very first time we deployed it, the leak rate went from that 10% to 20% range I mentioned before down to almost zero or something like point 1% leak rate after the facility was started up. So just having that kind of transparency into the work being done led to a dramatic increase in work quality. That really comes out of that basic system, the way we looked at the problem, the way we broke it down and just think about it differently than folks in our company have been trying to solve these problems before.

Erik: Okay. So here, the critical thing was there was a lack of visibility in the system, and you were just trusting all that component elements to do their best and hope that that worked out. That was not working out perfectly. So visibility was the key thing.

If we think about then the deployment of digital technology to address systems thinking, I guess one aspect is this. It's bringing in data from silos. Now all of a sudden, you can look at it from more of a system perspective because you actually have visibility into the component parts. I guess the other part is, then you still end up with this very complex web of data points that you have to make sense of in a system perspective. Otherwise, you can still look at data points in isolation, which I think happens in a lot of organizations.

Matt: Correct.

Erik: How do you think about then as you deploy these digital solutions to support what the process is, let's say, laying that architecture so that it really becomes a system as opposed to a set of isolated silos used by different teams?

Matt: Yeah, that comes up quite a bit, that question and that problem. To reframe it a little bit but then definitely to answer your question, a lot of times, we see companies want to bring in new technology. They're looking at whatever the sexiest technology is at the moment or whatever their friend at the facility down the street recently implemented. We call it 'shiny technology syndrome,' where somebody brought in this great AR, augmented reality system, to help workers and they want to have it too. But then, they bring in this AR System and then quickly discovered that they don't have any connectivity in the plant. What do you know, they can't use the goggles because there's no connectivity in the site, either Wi-Fi or 5g, whatever it might be.

And so part of the system's thinking process is to understand what are, as I mentioned earlier, these layers of abstractions. So you want to bring in new technology. Great. But understand what is it you actually need as the technological foundation to deploy whatever technology you're looking at. One thing as you mentioned is, how do you access your data? What is your data backbone? Do you even have a data backbone? Does that term resonate to you? Where is data sourced? How is data collected and managed, and how would it be accessed by solutions in the field? That tends to be the biggest hurdle. It's data quality and data access to deploying any new technology, for the exact reason you mentioned.

So before you try to go deploy some new system, make sure that the data is in a condition where it can be easily organized and accessed. How are you looking at connectivity? How are you looking at training for your workers? What about any contractual or legal issues with the technology that you're bringing in? All those things need to be looked at before a digitalization team or an innovation team just says, "Hey, look at this. This is going to really change the way we work," and tries to bring in some new technology in a vacuum.

Erik: Yeah, we work a lot with the innovation teams here in China. You can imagine it's all of these challenges of a team in a silo coming up with some ideas that might be great ideas. But they're not thinking through all of the potential challenges. And also, if you're not engaging the other parts of the organization upfront, you might just have frictions. Because now you're thrusting in a new solution on me and asking me to change my processes where I wasn't involved in this before. Then, of course, you have all the policy regulation and cybersecurity challenges that come along with China, right? So there's a whole other set of headaches here.

Matt: I could imagine. But the innovation teams often don't want to do that, not because they're lazy by any means. They're generally not. They're very excited and optimistic and even idealistic about what they can do. It's just it's the hard grunt work of making a change in any organization that people aren't taught to do.

You asked earlier about incentive systems. Well, a lot of times, these teams are incentivized by the marketing value or the demo value. Look at these cool things we're bringing in, whether it's robotics, or AR, or VR, or whatever it might be. That's how they get promoted, and they move on to a pilot. It's great. It's awesome. I finished this pilot. We got a great video. People are excited. Maybe we won an industry award. Then they get promoted and moved on. Then it's someone else's problem to figure out how to actually implement the technology at scale. That was never thought about before. And that's where technology gets in trouble and goes into the dustbin and gets a bad reputation within an organization.

Erik: Yeah, we encountered that a lot on the revenue side of this, where the sales team has little incentive to actually bringing new ideas to the innovation team. Because they're motivated by quarterly or maybe annual sales targets. Then any new solution that's coming out is going to hit the market in three years. And by that, who knows where else? Probably, I won't be selling this portfolio anyways.

Matt: Exactly.

Erik: So you had this experience through your work at Shell TechWorks. Then you set up Cumulus in 2018. When you first set up Cumulus, it was a startup at that point, right? And so you have to be very selective in terms of what challenges you tackle. What was your thought process about, here's what we need to bring to market first, and then here's how we build out a roadmap to add solutions over time, or add features and elements to make a more comprehensive solution?

Matt: When we started the company, we had this long-term vision, which we still have today, that we use this integration of detailed engineering procedures being digitalized and then validated with all kinds of relevant technologies, whether it's digital tools, or gauges, or analytics, whatever it might be, to validate that the procedures were followed in the field.

To make it easy for someone to understand what they're supposed to do, we turn those procedures into these digital workflows, and then validate that that work was actually done properly. That was our vision. We knew you could capture pretty much all the work at a facility in this one system. That was the ideal end state. But we also knew that we didn't have the resources, or the time, or the brand reputation to do that, and to go to a facility and say, "Take all of your work, and put it on our system. We're going to manage it, become your quality control system."

We had to start with something that was very targeted, where we can do one thing and solve one low-hanging fruit and solve it really well. That was the case of Bolted Joint. We started out our product, it really was very narrowly focused on helping companies through the bolted joint assembly and maintenance process, like I described earlier. For the first couple of years, that's what we built and scaled. There was enough challenges and just scaling that part of the business, especially as we got into COVID and everything else, that I'm very happy that we made that decision and didn't try to eat the whole elephant all at once. We started with that very narrow application. We got to experience scaling that and deploying that at facilities on five different continents all over the world. Then we started to add other capabilities like pressure testing and welding onto that platform. Actually, just this year, we're finally able to realize that long-term vision, which is create a system that could really apply to anything. It's very customizable.

Actually, some of the new capabilities around AI and LLMs have helped us build that so that people can use this technology to configure whatever engineering procedures they have, no matter what it is they're doing, into our system and manage that work. That was just a lot further off before the new capabilities came out this year. That's how we've grown and evolved it — really starting off doing one thing really, really well and then growing from there as we gained more experience and reputation in the industry.

Erik: That's a great approach. I think I've probably had 160 or 70 of these podcasts. You see, some companies start with the horizontal solution of saying, we're going to build this horizontal toolkit, and then we're going to find the vertical applications. Then other people start and say, okay, let's find one vertical application so that we can provide value and then try to make it a bit more horizontal over time. I think that tends to be the better approach, right? Because you make sure that you're really solving the problem from day one.

Matt: Exactly. When I was in Shell, we had so many companies, both large and small, come to us and say, "Give us all your data, and we're going to create some sort of value from it." Because we have this horizontal analytics platform or analytics engine that will do all sorts of great things. Well, we, for the most part, didn't have any data at that point. Because it was either, it was so fragmented or in people's heads, or maybe in poorly formatted Excel spreadsheets. We said it just doesn't make sense. You have to start from fundamentals. Going back to our conversation earlier about data, get the data organized which is its own heavy left. Then talk to you about your generic analytics platform because you're just not solving the right problems that way.

Erik: Tell me a bit about how AI and LLMs, I guess the generative AI, I guess, you could probably think about those in different perspectives. Because I suppose on the one hand, the more traditional AI is dealing with how do you manage all of this sensor data and so forth, and identifying trend lines and relationships and so forth. Then the generative AI is a completely different set of problems that it solves organizationally. How do you think about how to integrate those technologies into your platform?

Matt: Sure. Well, for us, it's really about helping, novel ways to help our users set up our system a lot faster. What I mean by that is, typically, before we introduce these new capabilities into the platform, a user would have to take their procedures and turn them into these workflows for workers to follow. We had what we thought was a very intuitive workflow builder with a great graphical interface, low code, no-code system. But it still took time. That was a barrier to adoption for a lot of people. It was either they didn't want to spend the time at all to build these workflows. Or even when we were helping them build these workflows, even if they did, they would only build these workflows out for a handful of what they thought were their most critical applications.

What we did earlier this year in our team, this started off as just one of these 10% projects where the team was working off book to play around with these new technologies. They said, well, what if we can upload a customer's engineering procedure, and then the LLM can understand that procedure and then configure our workflows for the user in a matter of seconds? So you could upload a procedure for pretty much anything. Then the interface we built allows the API to configure that workflow. It presents the user with, yep, here you go. Here's your workflow. So you can, instead of something that might take hours, it literally takes seconds.

What we also built in the ability to do is, if you don't have a procedure, you could ask our LLM to create a procedure for you. So you can say: I want a procedure for inspecting a certain piece of equipment. The LLM takes what it knows from our system. It's also looking at the open Internet. Any other data feeds, we're able to bring into it and say, okay, I understand how Cumulus and users of Cumulus like to create their procedures to guide work. Here's what I know about this particular piece of equipment or this activity. I'm now going to build up a procedure for the user. That latter use case where we're building your procedure for you is the more experimental. Because sometimes the LLM does it better than others. But I can see that that's where the future is going, where you have that real copilot. The worker or the field superintendent is interacting with the AI to say, I want to do this type of work. Tell me the best way to do it based on all the data sources you have. That's the nugget of what we're creating.

But the immediate application is you upload your procedures, and it configures the workflows. There's not a lot of creativity there, but it just helps the user do something in seconds or minutes that would have taken hours before and really smooth this out a barrier of adoption for us.

Erik: Okay. That's a fantastic use case. I'm really interested in this topic because I discuss this a lot with my multinational clients. I don't know if this is a China issue. It feels like it's a global issue, that they're just very, very slow to explore and adopt this. You've already found some high value here, so I just want to get into a bit more detail here. Are you using GPT-4 or one of the open-source LLMs? How did you make the choice of which LLM to work with here?

Matt: Right now, we're using GPT-3.5 Turbo. We've written the system in a way that's largely LLM agnostic. We've experimented with a few of the commercial APIs that are available, and more are becoming available all the time. We're using 3.5 Turbo because that is good enough to do the task that we want at a basic level. But also, frankly, it's less expensive. So as this is still something we've been experimenting with, it's just more economical for us to use that. We do expect, as this becomes commercial — actually we're launching the first commercial version of this in November — to upgrade to more powerful LLMs, whether it's GPT-4, hopefully, Google's Gemini when it comes out, and some other ones that will give us much more multimodal capability. But for development purposes, 3.5 Turbo is more than sufficient.

Erik: Okay. There was a use case that we were exploring. I think it didn't get any buyers, let's say. But the concept was to look through troubleshooting reports. You end up having these PFD files that are just a lot of documentation that's sitting somewhere. It has a lot of information. In some cases, our clients, if there's a problem, they'd spend two months filtering through these files trying to figure out what happened. Did we have a material change, whatever? I was thinking, well, this is just a great use case for an LLM that can go through these documents and maybe come up with some kind of insight and logic. At least, get you pointed in the right direction. But then, the issue tends to be IP concerns of, okay, but we're not comfortable putting this stuff. Even if we are using Azure anyways, we're still not comfortable putting this stuff on the cloud with them.

Matt: We've encountered the exact same thing with our early beta users who have been some of our existing customers, where IT departments are still very concerned. No matter how much assurance you give them about — this is not ChatGPT. It's the commercial API. We're not training our system on your data — people are still in the early stages of figuring out how comfortable they are with all of this. I think that will evolve and get better over time. You'll just have to figure out who your typical adoption curve, who your early adopters are, early majority, late majority and laggards. But that is absolutely a safety concern that we've come up against.

What we hope is that by giving them a use case, that saves them a lot of time. So there's a very clear value in using it. We're talking about engineering procedures, which are of course proprietary but it's not like for uploading financial data, or personal proprietary information, or anything like that. Hopefully, we can get more and more enterprise customers comfortable with it and excited about it. We are seeing some companies really open to taking a lead. But many others are looking at it with a bit of skepticism. Not skepticism of what the technology can do. But as you said, it's IP security, what's going to happen with my data, that kind of thing.

Erik: Yeah, it makes sense. There's a little bit of a black box. In terms of when you put your data in there, at least they want to probably see that over two or three years, no competitors have been on the front page of the Wall Street Journal because of an issue here. Then you gain a bit more confidence.

Matt: Exactly. I'm sure just like you have SOC 2 audits and certifications and other security standards, these bodies will start to offer those certifications to companies like ours that say, look, this company has procedures and protections in place. You can be comfortable trusting them with data.

Erik: Got you. So as I understand the solution stack today, you have the workflow builder which allows you to build these custom workflows, either manually or with support from AI. You've got a mobile app that is used by people in the field to collect data, capture data, or to guide them through. Then you have this control center which is used by, I guess, people back in the offices to have a more of a system perspective of what's going on. Is that an accurate representation? Anything I'm missing here in terms of the solution stack today?

Matt: Yeah, that's a great description. I would just add all of the connected devices that our users are using to perform the work, whether it's tools with connectivity, or gauges, or other sensors that they're connecting with to validate their workflows, that their work was done.

Erik: Great. So if you start looking out into the future, what is going to be exciting for you? I mean, you mentioned already generative AI and other AI tools. What else are you working on today that your customer should expect to see in the next 12, 24 months?

Matt: There's three things. One, as we talked about, is AI. I think I am incredibly excited by the opportunity there. I think any technology has a double-edged sword. So I come to very much believe that the benefits to society will greatly outweigh the risks. I think AI is going through a bit of the trough of disillusionment, I think, in some media circles right now. Because people are saying, oh, these chat bots, nobody is using them as much as they thought they were, or usage is waning.

I think that's a bit of a head fake. Because the GPT wrappers, these chat bots, were really just the early experimentations with generative AI and LLMs. You're just seeing now companies really fully integrate these capabilities into their tech stacks and start releasing commercially products using them. That's going to be where things start to become truly revolutionary at the enterprise level. So I'm super excited about what they're doing. Not only what we're doing but what a lot of other companies are doing as well.

The second is on the connectivity side with tools and sensors. All the time, we're hearing about companies converting their entire fleet of tool offerings into connected devices. If you go to a hardware store today, go to the power tool aisle, and you'll just see connected devices being advertised by pretty much every manufacturer. When we started the company, you could really count the number of brands that were embracing connectivity on one or two hands. So that's a huge change. The more devices that get connectivity, the more valuable systems like ours will be to our customers. Because they'll just bring in more and more types of work, and it just becomes standard.

Then three is, I think, integrations. Enterprise integrations are getting a lot better. Our customer base is getting a lot more sophisticated about integrating different platforms like ours together. There's a recognition that no one platform is going to be able to do everything an enterprise needs. Not to call out any specific companies. But you know, there are a number of brands that say, we are the be-all, end-all. We want to capture the entire industrial enterprise. I don't see that happening. I see it really takes the customers being smarter and more sophisticated and more demanding of their vendors to say we're going to stitch together a suite of solutions that make sense for us. Companies like ours are going to get better and smarter about making it easier to integrate with other solutions so that data can easily be formatted and passed around in order to serve our customers. I think that's a really exciting future.

All three of those things I mentioned, not to get long winded, but they all support each other. The better integrations, the better data access you have, the better AI solutions, you're going to be able to come up with the right answers. The more connectivity we have in the field, the more visibility we'll have into the quality of work.

Erik: Okay. That makes a lot of sense. I've got a buddy right now who's working on a very early-stage startup using generative AI to do those integrations, with a basic logic that human speech is actually a common protocol.

Matt: Absolutely.

Erik: That is agreed upon. It's not suitable for every case. But if it's about, here's the work order. He's actually working on automotive. So it's more of I want to order a coffee, right? You say that to your BMW, your BMW doesn't usually have coffee restaurants, but it's connected to Starbucks. And it knows how to order a coffee. Very, very cool. Well, it's really an exciting space. Anything that we didn't touch on yet that is important for folks to understand?

Matt: No, I think this is great. I really appreciate the opportunity to have this discussion and to be on your podcast. I'm really excited about the future of industry and IoT. I look forward to seeing where everybody goes.