Latest / You've Been Heard / 407- The Day IT and OT Finally Talked w/Bill Markut

Transcript

407- The Day IT and OT Finally Talked w/Bill Markut · You've Been Heard

0:09
Speaker A: Hello everybody. Welcome to you've been heard the technology podcast and today we've got Bill Market. So Bill, do me a favor and tell us a little about your journey and your story and how you've been heard.
0:24
Speaker B: Well, I'm going on 36 years in it this spring and I graduated from Milwaukee School of Engineering with a degree in computer science and a degree in industrial management. Worked 20 plus years in IT consulting in Wisconsin, moved to Tennessee about 12 years ago and basically have worked in a software engineering role for most entirely my entire career, especially on the Microsoft side. There were some years during the consulting area that during Y2K and that that I basically picked up all kinds of technologies, Lotus Notes and Domino and things like that just to keep yourself employed. But oh, I remember that, yeah, fun times. For about four years ago I was a senior engineer on an MES project here at Grangas. We deployed a PSI metal solution in our biggest plant in western Tennessee. And afterwards a president of the company asked me if I wanted to take over the development area of Grangas. And I've always purposely stayed out of management because I really liked being hands on technical. I liked being able to solve problems and innovate new solutions and new technology and things like that. But I also realized that I'm in my 50s and I really didn't want to manage or train new managers. So I took the role and worked in that role for a couple years. I had a really good development team. About two years ago there was some reorganization in our group and I was offered the opportunity to take the directorship role and I did again begrudgingly. Didn't really want to move up into an area that I really didn't know a whole lot about, meaning cybersecurity and infrastructure and networking and things like that. But being a lifelong learner and I enjoyed the challenge and I think I've prospered somewhat in this role. I think I'm doing all right. And part of my mission, I think when I took the position from the president of the company was that I wanted to not only modernize our platforms because as a manufacturing company, and I've seen this for 30 some years, that we're always about 20, 25 years behind the, the technology curve and I wanted to not only modernize our platforms but I wanted to improve our business continuity and our business resilience because we had a lot of single points of failure and things like that, that obviously downtime is the evil topic in manufacturing. So I've got a five year technology roadmap. Now and I'm just pretty much starting at the beginning of that roadmap this year.
3:15
Speaker A: And so one of the things that many of our compatriots or our peers struggle with is putting together that roadmap and presenting it to the executive leadership and getting some feedback. How much did they just take the roadmap that you presented? How much back and forth was there on the creation of that roadmap? Because that's definitely part of the times that they're listening to you.
3:49
Speaker C: Most IT leaders don't need more technology, they need less noise. Over the years, infrastructure quietly gets complicated. Multiple locations, multiple Internet providers, different contracts, separate bills and reactive support. Nobody plans it that way, it just happens. What we do is vendor neutral advisory. That means we don't sell platforms or force change. We start with low friction areas. Internet, telecom, Microsoft licensing. Places where complexity builds quietly and can usually be cleaned up without disruption or capex. Sometimes we find savings, sometimes we find nothing. Either way the outcome is the same. More clarity, less distraction in it. That's boring in the best way possible. If you want a second set of eyes from people who sit on the buying side of enterprise infrastructure every day, just go to you've been heard.com and answer the questions to simplify, streamline and save.
4:44
Speaker B: Yeah, there's been a lot of back and forth about the roadmap, not only between myself and my management team here in Grandis, Americas, but myself and the global Grangas team located in Stockholm, Sweden. It has been basically just sustaining itself and basically been in a reactive mode for Grangas, but bought this company out of bankruptcy from Noranda back in 2016. But even long before that happened, Noranda was more in a sustainability mode as far as it goes. It's just like, let's just make sure that we're open every day and that's it. That's why I have two ERP systems, the newest of which is AX2009. So the other one is a 35 year old flat file system. So when I come in and I say, oh, I want to improve our MES and standardize it across the board and bring in a new ERP project, I want to bring in a new data architecture as a foundation. That's a lot of change and that's a lot of, there's a lot of discussion to be had there because there's so many different systems and the management team, I've got a great management team here in Americas that I work with. They're very cooperative, they're very supportive, but I still have to educate them a little bit. And whereas a lot of people will say, well, you should be doing the ERP first. And I disagree with that notion. I feel like the problems and where we make the metal is out on the shop floor. And I want to kind of build up from that shop floor and basically build a data architecture and standardizer MES and then bring in an erp because I don't believe the ERP makes us any money. I think it's just something out there that you have to have for compliance and for a form of business continuity. Right. You still have to have it.
6:43
Speaker A: But I was at a conference one time and somebody said you can take and optimize your billing department and you can make them the best billing department you've ever had with the least number of people. How much did that bring to the bottom line? How much did that change the enterprise? I have to admit that I was really energized when I saw your history and the fact that you've got that OT and the IT piece. Because I read the Phoenix Project and the goal and between those two, that whole methodology and that change from just the manufacturing piece of it through DevOps that the Phoenix Project talks about, I wondered how much of that kind of experience and how much of that you've gotten to see or that you're starting to influence and change.
7:35
Speaker B: Yeah, that's been a big area. In fact, I mean I've read the Phoenix and I've read the other couple books associated with that, but. And my development manager actually made that an after hours project for my development team where they actually did a book club type thing on the Phoenix project. So that is another one of the initiatives that when I decided I wanted to take this role is that we needed to establish credibility and collaboration with our operations folks. Because in the past we were very siloed. And part of that, it wasn't so much the technology part of it, it was more of the people part of it. And you had people on both sides that are very protective of their areas. And I've been working, you know, it's a continuous improvement effort. Right. But I'm continuing to work with our operations folks, our main plant. And I've established a lot of headway with them, a lot of trust and I mean that's the big. To let them know that I'm not. I know it is known as the department of no. And that was one of the first things that they brought up to me when I approached them about this. And I'm like, no, no, no. I says my philosophy and my managers know this is that we're not going to ever just say no. I said we're always going to say no, but we can do this or no, but how about this? Or it's always going to be discussion. Because if it's a need, then we got to figure out a way to do it. Because I know as a software engineer, if I had a security or an infrastructure person telling me that, no, you can't have permission to do that, well, I'm going to figure out a way to hack my way into that, you know, so we can either do this the easy way or we can do this the hard way. And I'd rather do it the easy way and talk to people and gain their trust so that we can not only work with each other and have it be a better environment, but we work for the same company. Right. We both, our goal is to push metal out the door as high quality and as fast as we can. And the IT strategy is we gotta do it in a very secure way. And the OT strategy is we gotta do it 100% uptime. And somewhere you gotta collaborate between those two and you're never gonna have 100% security. You gotta be able to mitigate things that come up and incidents that come up and you gotta be able to respond quickly and detect them quickly. But, but from an operation standpoint, you're not going to ever have 100% uptime because you're going to have to be able to patch some devices and you're going to have to do some kind of upgrading yourself. So it's just a matter of coordinating that change management and just coordinating that culture that we're here to help.
10:20
Speaker A: Yeah. Oh man. I didn't even think about that aspect of the challenge. I was thinking about the operational technology and figuring out how just typically it runs behind. Unless you're in that billion dollar organization that is trying to produce things at the front side of this, there's a couple of them out there that are doing that kind of stuff and that automation and the robotic and all of those things. But otherwise, if you're at a company that's been established for a long time, it's hard to switch those out because this is truly changing the engine while the plane's in flight. Yep. And so what are some of the things that you think that, what's a myth that CIOs hold on to that you think we should let go of?
11:09
Speaker B: I know one of the myths is that technology is easy to Implement, and it's quick to implement. For instance, obviously in today's market, one of the things that keeps coming up is AI. Right. Everybody wants to do AI and I have to kind of. That's where you have to. That's where it really helps to have some credibility because you have to kind of rein them in a little bit because AI is not going to be the answer to your problems. Data is the answer to your problems. But if your data is garbage, your AI solution is probably going to reiterate and regurgitate that garbage. So one of the myths, I think, is that we need to really take a step back. And if you haven't invested in it in a decade or two, it's really not realistic to think that you can implement AI solutions just out of the box into your environment. Yeah.
12:04
Speaker A: You mean if we haven't kept up with modern methodologies and technologies, we can't just leap to that?
12:12
Speaker B: Yeah, yeah. I try to illustrate the fact that we have so many data silos, not only between OT and it, but even between IT systems and between other OT systems. You have multiple sources of data and it's just like nobody, depending on who you talk to, whether it's a plant manager or automation person or somebody in the finance department at corporate, everybody's got their own view on what a metric is and what the data is telling them. And there needs to be some kind of refinement and construction of basically a data philosophy and data architecture. And that's kind of what we're doing with Unified Namespace.
12:52
Speaker A: Oh, all right. Now that finally lands in a different light because I saw that on your, I was looking at your LinkedIn and going through that, and you mentioned the Unified namespace. But now I'm assuming that Unified Namespace is the way that you're taking the, the data from all of those different sources, all of those different endpoints, and finding what the commonality is and getting all of that into the same data architecture so that you can ask the questions of multiple machines, even though those machines do different things, but they all turn on, turn off, produce. I'm assuming it's something like that. Am I in the right neighborhood?
13:34
Speaker B: Yeah, you're in the right neighborhood. I mean, major principle of our roadmap is decoupling our major systems. So we want to eliminate as many of our point to point integrations as possible because they're expensive to maintain. They're basically throw away if you happen to be standardizing your MES platform or bringing in a new erp. So we're looking at going to an event driven data architecture and basically what that entails is a publish subscribe type philosophy where MES may or your OT sensors may publish a bunch of data out and that data is going to give you not only just the data value at that moment, but the context of that data value at that moment. So that's what it adds. That a normal data warehouse probably cannot illustrate as much is the context of that data at that moment in time. And I'm working with a group, a vendor from Ectobox and we're actually working a pilot project right now on our quality initiatives between our casting and our rolling lines. And the concept behind that is we'll get all the sensor data that we have, plus whatever we can get in the future, but also align that with what ERP says it has for that data for that coil and what MES says it has for that coil and be able to throw everything together and I guess for lack of a better term, maybe like a lake house where you can actually do drive analytics and you can have real time, one source of truth data in front of the operator at all times. So you're not now rolling a coil for an hour and doing two or three passes and then realizing that you've got defects, that you've just wasted an hour's worth of production time and maybe £20,000 of material. So that's the goal and that's why we're trying to implement that data architecture in conjunction with standardized mes, so we can get that, we can prove that concept and scale that out and then hook in the new ERP as a subscribe mechanism and a publish mechanism. So ERP could publish to the UNs and everything else that needs to access that data will be able to subscribe to it. So based on the event, so it's, I'm still learning the process and the vendor that I'm working with at Ectobox, they've done a really good job helping me out and they're working with my development team right now and our data analyst on coming up with these pilot projects and establishing what we can do as far as not only data quality, but visibility and things like that.
16:20
Speaker A: Okay, let me, let me change tax on you a little bit and dive into your recent history. If you could fix one big challenge in IT leadership tomorrow, what would that be?
16:36
Speaker B: I think I'm kind of, I don't know if it's based on my education, where I went to school. I went to Milwaukee School of Engineering, and it was a different type of education than I think that a lot of people that I notice in IT management, they come more from an infrastructure background and everything is the infrastructure related. And for me, I think being in a role that I'm in right now, I spend as much, if not more time dealing with the people and the culture than I do the technology. For me, the technology is fairly. Well, I'm going to say easy, but I know it's not easy, but it's pretty straightforward, right?
17:17
Speaker A: Black or white?
17:18
Speaker B: No. Zero or one? Yeah. The people part of it though is something that I don't see. I've worked for some good IT managers and I've worked for a lot of really bad IT managers and it's usually they're very short sighted, very averse to changes, averse to losing control and especially infrastructure folks, they seem to. I've known past managers that were very averse to cloud technology because they wanted to be able to see their servers in the data center. And I don't think that the old school IT management philosophy works today. I think you got to be able to communicate with people, you got to be able to communicate with your management team and you got to be able to. In my case, I got to be able to communicate with my board over in Sweden, which is a whole nother story because it's a different, it's a different culture, it's a different way of doing things. There's other regions in our global company. We've got Granges, Europe and Gringos Asia. They do things a little bit differently than I do and everybody does their own thing. And I just, I don't think there's a lot of flexibility sometimes not in grandest necessarily, but in other companies. When I was in consulting it was very like we've done it this way for 35 years and we're going to keep doing it this way. It's just like, well, I guess that's not going to. That's the antithesis of innovation. Right?
18:40
Speaker A: So yeah, so how do you fix that? Since you're now the director, you've got reports reporting up to you and some of them are responsible for that infrastructure. I'm sure that you're not handling all of the infrastructure and all of the OT and, and the MES and the uns. Yes, you're responsible for all of it, but you've got to rely on your team. So if you've got a team member that's doing this, how do you fix it?
19:03
Speaker B: Well, fortunately, when I took over this group, we lost a few people But I considered that addition by subtraction I think I was able to rebuild my department and I've got a excellent team, albeit a very young and not real experienced team. But my managers are fairly new at managing. They're great technically and security wise. And then our younger staff level people we're probably talking, with the exception of a couple that I have probably 60 some years experience with, most of them are probably less than 5, 6 years experience in it. The way I handle that is that when I brought these people in, I didn't necessarily look for the smartest person. Although that, that's a perfect scenario. Because you like, like everybody else. I like to hire people smarter than me because again, coming from software, I don't know the first thing about networking and system admin and stuff like that. But I'm looking for people that have initiative and I'm looking for people that are looking to innovate and looking to scale outward and modernize and, and actually move into the, you know, I'd like to say the 21st century, but in some cases in manufacturing you're looking to move into the 20th century. But it's just a mindset in a personality and a culture. And my group, they know that they can suggest anything to me. Now that doesn't automatically mean they have carte blanche on implementing whatever they want to implement. But my development manager's got a lot of leeway as far as how he architects solutions. My infrastructure manager is doing a terrific job trying to remediate a lot of old legacy platforms and legacy domains that we're trying to retire and get rid of so that it improves our cybersecurity posture thus far. I mean, even with the uns, which is such a new concept, the data architecture, I mean, there's some resistance in my development team, there's some resistance in my infrastructure team about it because nobody knows quite what the outcome of that's going to be. And everybody's kind of, they're not against it, but they're just not sure they're for it. And again, I think it's a little bit of lack of control or loss of control that sometimes scares people. But having said that, they bring problems to me and they bring their opinions to me and we have good conversations, good discussions. Some of it I do make changes in my process, others I just go, well, let's play this out a little bit longer and see how it goes. And that's where taking small steps and pilot projects and things like that really come into play. Because you're not investing six months or 12 months of time into something and then just saying, oh, this doesn't work.
21:51
Speaker A: So, yeah, scrap the whole thing. And then. Yeah, well, back to your coil example too. The hour of heavy work into it when there was a defect, that was when you have the context that the sensors already recognized.
22:06
Speaker B: Right, exactly. The faster you can detect the problem, the least expensive it's going to be for you. With the goal in mind that we want to get that 40,000 pound coil out the door and ship to our customer as quickly as we can and make sure it's good quality. We still need to make sure that we're doing it in the most efficient and quality way.
22:28
Speaker A: Sue, what part of your day to day brings you the most joy? What fires you up the most?
22:37
Speaker B: I think I'm going to go back a couple months ago. I mentioned the pilot project we're doing for the UNS initiative. Part of that was an event storm that David Schultz ran from Ectobox. And basically what that is coming from a software background again is basically it's kind of a discovery requirements definition.
22:55
Speaker A: Right.
22:56
Speaker B: But the thing about it was, and anybody that follows me on LinkedIn would probably saw pictures of this at some point, but we had sheets of paper all the way down the hallway at our facility in Huntington. And basically what we were doing is documenting the process of casting our cast house. And it wasn't so much about documenting the process that was impressive or that got me going. It was the fact that we had electrical engineers there, we had process engineers there, we had mechanical engineers there, we had quality people there, we had IT people there. I had infrastructure there, I had software developers there. Just seeing everybody like talking to one another and having a conversation on, well, how does this work? And then the other side would answer the question. That was exciting to me because that was the first sign that I could see that IT and OT were actually collaborating. And I think that was a big. I'm not going to say that was the instigating factor that has like got us over the hill, but it definitely was an exciting moment where that's what we need to see moving forward. For everything that we do, we need to be able to do that same conversation for any. We just got to remember that we're coming up with a common solution that we both like, not so much that benefits one side or the other. We're doing it for Grangas, we're not doing it for it or doing it for ot.
24:23
Speaker A: Yeah, breaking the silos and the organizational team. Everybody's a team member. All of us working towards the same goal versus IT and operations and the electrical and the mechanical and the different groups.
24:38
Speaker B: Everybody's. Yeah, exactly.
24:40
Speaker A: They finally see the big picture.
24:42
Speaker B: Yeah. And David made the comment that he goes. He goes, I was really impressed that everybody was talking to one another. And he goes, knocking those walls down that silo. And I'm like. To me, I'm like, it looked like we were taking a sledgehammer to those walls because it was just unbelievable how they were all like, gathered around talking to one another and there was no defensive posturing or anything. They were actually engaged in talking about not only what was happening now, but what could happen in the future as far as what is the perfect scenario. And we had a similar discussion like that regarding cybersecurity and ITOT security, because that's something that we're working on as well, outside of UNs, but kind of related to UNs, but the fact that we want to be able to lock down some of this OT hardware that scares ot because they need to be able to access Those machines at 2 o' clock in the morning sometimes.
25:37
Speaker A: Yeah. They want to roll over, grab their tablet or whatever device they have and take these things.
25:42
Speaker B: Right. And as I said previously, I am not a no person. I am a no. We can't open it up to everybody to log into, but maybe we can create these separate groups and isolate this and do whatever we need to do. That's where I rely on my tech teams a lot because I'm always constantly pushing, you know, telling them, push the envelope. What is the best possible scenario that we could do to make this secure and make it flexible without putting us at increased risk. And I said, if that fails, then we just back off a little bit and try something else. But we need to fail fast and just keep moving towards that initiative and don't take. No, we can't do that as a. As a solution. That's not a solution.
26:30
Speaker A: Okay. So did you have any times in your career thinking back that point out that you think a little differently than those around you that either within the IT world or just in the world at large, you know, like, when did you realize that you were built a little differently?
26:55
Speaker B: Probably pretty early on in my career. I think that's why I went into consulting, because I came out of school and worked for Baxter Healthcare and Caremark International, and so I was in healthcare probably for the first six years of my career, and that was not an industry I enjoyed working in. Yeah, I moved into consulting because I enjoyed providing solutions and Talking to the pro, the people that were having the problems. Whereas in healthcare I found out that a lot of it was being told what the problem was, maybe third hand and coming up with a solution that after working on it, you know, back in those days, everything seemed to take 12 months to do. You implement the solution and then you realize you really didn't make any effort or any improvement to the bottom line. You're talking about EBIT and stuff like that. Quite often you actually didn't even make the person's job any easier. You made it more difficult. So I enjoyed going into consulting. I was able to market myself, kind of establish my own desires as to what kind of projects and what kind of business sectors I worked in. And that's kind of where I developed the people first attitude. And the fact that again, the technology solutions, there's enough examples of good technology application out there in the world that there's usually something. Very seldom are you doing something totally brand new like earth shattering. That's going to be the first of its kind. For me. It's more important to find out exactly what the problem is and apply those principles to that user or that. Or in my case, a work center type problem. And I think so I guess to answer your question, I guess really early in my career even going at msoe, not. It's not like a liberal arts school like a lot of my friends went to. My friends went to a liberal arts school. I was doing heavy engineering classes my freshman year and I'll be honest, I thought I was going to flunk out of there before I could graduate. But I ended up graduating and realized that engineers are a different personality than maybe accountants and stuff like that. And you have to establish your ability to communicate with multiple types of people and multiple types of personalities and be able to not only communicate with them, but to actually hook up with them and connect with them on a basis that might be different for various people in your own department even. And I think that's what's helped me today is that some people need a little bit more attention than others. Some people need a wake up call every once in a while. But everybody's different. You can't like just have a magic wand and, and treat everybody the same.
29:39
Speaker A: Yeah, I, I hear something in you that I've found in myself too, which was the need to understand. Why? Because there's so many times that somebody would call me to their desk and say, okay, I need this. And they tell me how they want their Excel spreadsheet or they tell me how they want this thing done and, and I watch so many people in it just hear that and go, okay, I can do that and run off and go, heads down and go do it, bring it back. And by the time they bring it back, it's already too late because the person has found a way to hack in and get around that security constraint and they've just figured out another way. But we never hit the target. And so I always stopped. Okay, what are you trying to do? What it. What's the goal behind this spreadsheet? Because they talk to me in the language they know. And you and I, we've learned through our education of all of these different things that sometimes we can provide the same solution through a completely different path.
30:44
Speaker B: I totally agree. And one of the things that I kind of emphasize with my team is you can talk and you come up. You know, I know you have all these brilliant ideas to innovate and technical solutions for problems that you see yourself, but one of the key elements to being a manager, especially of a technical manager, is the ability to listen. And I said, because like you said, the user comes up to somebody in my plants and say, hey, I need this spreadsheet to do this or I need a new Excel spreadsheet to track this. And they put it together without even thinking about the technical debt that they. Here I am on one side of the department saying we need to decrease our technical debt by 10 or 20% every week, a couple hours every week, eliminate an access database, eliminate an Excel spreadsheet or something. And then I got another group within it or like you said, rogue it that creating new spreadsheets and it's just like, no, no, stop it. It's just like you're making things more difficult here. So that's a problem. Rogue it has always been a problem and always will be.
31:48
Speaker A: Yeah, but you got any common sayings or quotes that you tell the team all the time,
31:57
Speaker B: bail fast. I'm not real big on expressions. I try to talk with them. And I just had a summit a couple weeks ago. I brought everybody in from the other three sites into Franklin here. We're located in Franklin, the corporate offices in Franklin, Tennessee. And I brought everybody in from my Arkansas, North Carolina and Tennessee plants and we got around and we had some breakout sessions where I kind of mixed up the groups and got everybody talking to one another and about basically kind of around talking around our roadmap for the next five years. And then we did some other non technical things like a service project and went to a Predators hockey game and things like that. I just try to have a good team culture where everybody's comfortable with talking with one another and everybody. When I first moved into the development manager role, the infrastructure, the development and the plant teams were all very. We talk about silos between IT and ot. Well, it was very siloed Development. Yeah. Development and infrastructure and the plant teams really were very segregated out. There was not a whole lot of communication or working together whatsoever. And since I've taken over as director now. Well, I, I did work on trying to mitigate that a little bit when I was a development manager. But since I've taken over the director role, we're collaborating all together. We're, you know, one of my expressions is that we're four sites, but one.
33:32
Speaker A: Okay. No, I like that. So as, as we head towards the end of this, we've got a big question for you and we want you to, we want to hear what your prediction is 18 months from now. What will everyone in it be talking about that, that everybody ignores today? So if I was to. Well, actually, I don't want to put words in your mouth. See if you can and make that prediction again and a little more succinct.
34:02
Speaker B: Okay. I would say in 18 months IT executives are going to regret not looking at OT skill sets more closely when hiring their IT support people.
34:18
Speaker A: Okay. All right. And. And I kind of heard that. I was thinking, and, and I was switching because of, like you said, transportation experience, lots of knowledge and experience there. So I'm thinking instead of ot, I'm just thinking operations and, and that one kind of carries across all industries. That. Yeah. That the IT people need to understand the business.
34:41
Speaker B: Yep. Yeah. Yeah. And that's definitely, I mean, that's one of the first things in our onboardings is that everybody has to do a plant tour. Everybody has to walk through and see what the processes are and see what happened from the, from the beginning when that coil is casted all the way through to the fact where it gets to the shipping docks, they need to be able to see what the processes are, need to look at the manufacturing recipe and the routing that it goes through. And obviously they're not going to pick all that up at once. I mean, it took me a couple years to understand the full scope of the business, but yeah, you have to, as a. Whether you're IT or ot whatever, you have to understand the scope of the business and how the business works, what drives the business. And I think maybe another aspect of that 18 month question is the fact that I think executives will see in 18 months that it is not just a cost center and it's not just something that keeps you going day to day that it should be driving the business. I mean obviously the salespeople drive the business and the customers drive the business and all that, but it needs to be able to drive the business because it can provide the technology and the solutions. But where we lack a lot of times is the communication of that and proving that to the management team. And I think once you can do that then I think that opens the door for or increased EBIT and great end of the year bottom lines. So which is.
36:16
Speaker A: That's the goal?
36:17
Speaker B: Yeah.
36:19
Speaker A: Back to all the way back to the Phoenix and Phoenix project and the goal. So Bill, tell me a little about Bill outside of the office and you got anything that you want to promote, you want to bring up or.
36:36
Speaker B: I am going to be going to the Pruvit conference in Dallas in two or three weeks. That's Walker Reynolds conference where OT vendors and integrators come in and they don't just talk about theoretical solutions, they actually execute those solutions. So I'm excited to see that. Not that I'm going to be programming OT solutions or anything, but it gives me the ability to talk intelligently to my OT folks and kind of say, hey, have you thought about this platform? Have you thought about this? So I'm going to be going there and then I will be on a panel discussion in late April. MX0 Southeast in Greenville, South Carolina. I'm going to be on a panel discussion, I think, if I remember correctly, talking about ITOT convergence. So that's a really good conference to go to. If you've never been to it and you're interested in ITOT type industry 4.0 topics outside of that, that I. I try to keep a good work home life balance and. And so I continue to do things outside of work and disconnect from my laptop as much as I can. So.
37:45
Speaker A: Nice. Yeah, it's important that we maintain that balance. I know when I was early in my career, working all the time at the expense of the family and everybody else was part of who I was. But now it's really important to be able to disconnect.
38:00
Speaker B: Yeah, it is. You get burned out. It's really easy to get burned out. And fortunately or unfortunately I'm old now so I can kind of detect what I feel in that way. Whereas 20 years ago I was really burned out and I don't think I realized it for several months and it basically made me change jobs and wasn't happy with what I was doing, wasn't sure why I was in it. And then I figured out and been prospering ever since. So. Right.
38:31
Speaker A: Truly appreciate your time this morning and and today and thank you for joining us on you've been heard and we'll help you to get hurt a little bit more, put you out there and and everybody that's been listening, please hit a like and let us know that you've seen us on whatever your podcast platform that you're finding us. And thank you very much, Bill. You have a wonderful day.
38:54
Speaker B: Well, thank you, Micah. This has been, it's been great. Thank you for having me. I've only known your community for a little bit, but I'm liking what I see and I really like the fact that it's just it people like me and not having to deal with all the vendors and everything.