ERP038 - IT and MSP Industry w/ Kevin Behr

Welcome to Evolved Radio where we explore the evolution of business and technology. Today on the podcast, I'm joined by Kevin Bear, Chief Scientific Officer with Praxis Flow. It's going to be a really interesting conversation, we're talking about the IT industry and the MSP industry as a whole. And really fascinating discussions about what the industry has come from and where it's headed. As well as how you can remove some bottlenecks that form in your organization. How you can properly train middle management and early adopters in your organization and how you can continue to grow the organization. So that the skill set matches the needs as you continue to grow for the team. Uh Kevin is a really interesting thought leader around uh the IT industry space and all things DevOps, management ops, everything. He's also been a co-author on several popular books including the Phoenix Project, which is something a book that I often recommend and this is a going to be a really cool conversation. It's a bit of a long one, but I encourage you to stick around because it really has a ton of great nuggets in it and uh hope you enjoy this one. If you enjoyed the show, be sure to subscribe on iTunes, Stitcher or wherever you get your podcast from. Also, be sure to check out the web page evolvedmgmt.com/podcast for show notes, links to my guests and to check out previous episodes. It's a bit of a long one, but I encourage you to stick around because it really has a ton of great nuggets in it and uh hope you enjoy this one. If you enjoyed the show, be sure to subscribe on iTunes, Stitcher or wherever you get your podcast from. Also, be sure to check out the web page evolvedmgmt.com/podcast for show notes, links to my guests and to check out previous episodes. Also, be sure to check out the web page evolvedmgmt.com/podcast for show notes, links to my guests and to check out previous episodes. Now, let's get started. Joining me on the podcast today is Kevin Bear, Chief Scientific Officer with Praxis Flow. Welcome, Kevin. Hey, thank you. It's great to be here. So, we had uh connected because of your work on the book uh the Phoenix Project, which I was uh uh heavily recommending to a lot of people. And it's kind of an interesting introduction, I think to IT in general. It it serves a kind of a a story around a a development shop. But it's very IT heavy. And I I always feel that there's a ton of really interesting lessons in that book about how to approach IT in general. Lean methodology and just sort of the the things that you generally experience in any type of IT department. So, first off, really appreciate your work in contributing that along with your your co-authors. I was going to say, it's a group effort and uh the guys. Really helped uh both George and Jean really carried it across the line uh at the end. It was it was a big deal. So, my uh my great gratitude uh to the partners on that. Yeah. And I I I think it it also serves as a a bit of a road map for some of the discussion that we're going to have today as well. Because of sort of how it it's uh it's serves as a bit of a template, part of the reason that I recommend it is because so many of the stories are applicable. And you know, when I recommended to people, they're like, oh yeah, you know, I've got this problem going on and it sounds exactly like a lot of what is being described in this book. And because it covers sort of the the business, the IT and the development side of things, I think uh that's that's sort of the course of the conversation today here as well. So, I think that'll be uh serve as an interesting backdrop too. Well, that's great. That's great. I'm glad it's relevant. I mean, the goal when we started writing that book, um, you know, was really to try and capture. Uh the essence of what it's like to operate and, you know, if we stated those things in in a kind of just. non-fiction or even creative fiction style, uh non-fiction style, you know, it would have I I think been a lot more dry. And hard to understand without the conversations, the interactions and kind of the context of the whole business. Yeah. And and so we really realized um and inspired by largely by Elihu's uh Goldratt's book The Goal. Um which was a seminal book that came out in the early 80s. Um very much a similar concept, um you'll notice it the plot devices are kind of similar. About a guy named uh Alex who uh takes over operations at a manufacturing plant. And the business is incentivizing the plant to do all the wrong things, but then coming back and cost cutting the plant because it's not performing. And so, um he has to figure out his constraints and work through the human organization. And this book has inspired a lot of people over time. And so, I like the Socratic format Jean and and George and I did. And so we decided to kind of write a Socratic novel, um that brought together all of our experiences. And all of the research that we've been doing uh for for many years in and out of thousands of IT organizations between us. And kind of amalgamate true stories, true characters, put them in fictional settings to try to create an understanding in from multiple perspectives of what it feels like, right? Yeah. And some of the things you can do to intervene and how hard they are to do. Yeah. Um so. Especially especially when they involve people, right? Oh yeah, yeah. Complex adaptive humans we call them. Yes, exactly. They do whatever they want. Um. And that's one of the harder parts and I think in the Phoenix project you see a lot of people that are both intrinsically motivated to solve problems. And people that are extrinsically motivated to solve problems, I by money. And so, you see that even the the combination of that, not everybody's a true believer in the book and yet things still get done. So I think that's really important in the context of business. Yeah, for sure. Yeah. It it it takes a tribe and people will have different motivations and uh understanding how people uh come together. And and serve a purpose despite sort of their different perspectives is really, really important. I think it's it's a large part of why people feel that it's, you know, it resonates true. Like it it just feels familiar. The the descriptions that even that you suggested there of uh uh it's it it it really serves as an important backdrop for sure. Yeah, yeah. I really feel like that anytime everybody kind of collectively air quote drinks the Kool-Aid. Um first of all, that that that seldom happens and then when it does, it's an indicator of a lot of really bad things. You know, one or two things. One, you've got founder paternity uh syndrome where, you know, the founder's hung around too long and and there's like a cult of personality and people will do anything that this founder says. Um which, you know, can be good if they lead you down the right path. Um. Uh the other is uh you know, the danger of um being like actual Kool-Aid. Which largely means that um you're talking about a substance that consists of no substance, a lot of sugar and a lot of dye. And it wears off very quickly and people get really, really angry once it does. Right. Yeah. And so, you know, that kind of uh trendy uh methods de jour kind of movement. It's what we wanted to point out is is that these things all interlock, it's not one method rules them all. There are places where you use different techniques and different thinking processes. And and the the goal is to be able to uh learn and um like Barry O'Reilly. A close friend just wrote a really, really great great book from McGraw Hill called Unlearning. Which is actually just as important as learning. Turns out you have to unlearn old skills to actually either A, prompt the desire for a new one or actually adopt and gain the value from a new set of skills. So, you see an organization unlearning, learning, trying lots of different things, some succeeding, some failing. But um when the tribalism isn't working for them, that's ultimately where they're at their lowest and weakest. Yeah, and I think that's a really important point you bring up unlearning and relearning will probably be one of the most important skill sets in the future, right? Yeah. I mean. Barry O'Reilly and and check it out, I mean, uh Barry's a really brilliant guy. Very astute guy uh in the lean community. He actually was uh the co-author of Lean Enterprise with uh Jez Humble. Um and there's another person whose name I forget, not because they're not significant, because I'm forgetful. Um. And uh but the the book is really powerful talking about some of the skills we're going to need to run lean enterprises. And they're not lean. And I won't break the story for you. Traditionally, they're lean thinking. And. And I think this unlearning thing, you know, Elihu Goldratt had a really, really great uh hypothesis that that he made. Which was that, you know, uh business uh you know. Technology can add value if and only if it eliminates business limitations. But key uh in that same notion, it's a it's a work he has called Beyond the Goal. Uh the key key part of that same notion is you have to understand the rules that were put in place that allowed people to live with the original limitation before you remove the limitation. Otherwise, they will act like it is still there with the new technology and you won't get any of the value out of it. So part of it is understanding why, how did we live with this before because we do all these countermeasures and all these crazy things to live with these constraints. And technology's job is to bust constraints. And, you know, and and and to come through and allow for more flow and create these solutions. And so, you know, if we don't understand how they lived with it, we're not going to understand how we get the most out of what we put in. And the classic example that Ellie gave back in the day was everybody put in these MRP and ERP systems. And MRP, the reason why people put them in was it was too expensive for you to do materials requirement planning. In other words, figure out how much you have in stock of what stuff and parts to be able to make the new batch of orders so you can figure out what the net is and you have to order. Right. Yeah. Right, and it was so costly to do this, they could literally spend all their time doing it. That they actually reduced the time that they would count that stuff down to one day a month and what happened is these new MRP systems came out. And people ran them one day every month. Well, all of a sudden, by not changing the rule, realizing the technology doesn't have that limitation. You should be running it every day constantly to know exactly what you can do. And once people finally figured that out, they got value. But before that, they're like, this stupid system doesn't do anything for us. It's the same problem. It's like, well, you use the same rule. Yeah. So, you know, that I think is a is a big part of it is, you know, our job as technologists. Is we we do a lot of problem solving and I think we do some really good jobs listening to the pain and the problems. Now we have to get better at saying, so how did you live with this? Yeah. You know, and taking notes so that we literally remove the log from the trail. So they stop stepping over it. Yeah. Even though it's no longer there. Like we say, look, it's not here anymore. Yeah. It's it's it's an interesting uh topic because it's something that I tend to talk a lot about. Um whether you're just a uh a service entity or just running any type of business. You tend to look at at uh technology as having some magical effect. Like if we find this one piece of software that does this thing, everything will be better. And then what people find is like the the technology is the easy part. And then but you hit those cultural constraints and those people issues and those are the tough parts that don't really get factored into making change in an organization. And it's absolutely the hardest part of the change. Right. And I I think, you know, um there's there's some various t-shirts running around by this. Which is, you know, you have problem, I make software. And and and I always joke that there's a chasm between those two things. And then after those two things, right? Which is once you've made software, you have to keep making software. Yeah. And and at some point, right? And and and not all problems are solved that way, a lot of it is the way the humans do things in the first place. So, yeah. Cool. So. Um we'll maybe explore a bit of your your uh origin story. You're uh working uh pretty heavily in the enterprise uh IT ops space and DevOps now. But uh want to give us a bit of your background and and how you've come up uh to the position that you're in now. Well, yeah. It's interesting. It was uh. In the 90s, um a uh a friend of mine and actually a mentor, uh especially uh at the time. Uh uh started a we intrapreneur to company out of Micro Age. Um you know, Micro Age being a Fortune 500 systems integrator back in the day. Um and uh, you know, they they loved um doing the work they were in. But Scott and I had a vision, um uh clients were asking for more than just buying things. They were asking for really true design. Um and things, you know, at that point in time, um, you know, we're talking about uh layer three hitting the core of enterprise networks. Layer three switching, right, and routing being a thing. And this really required more than bringing engineers in, setting everything up, rack and stack and config and leave. This required an ongoing managed notion that and a capability to manage it that a lot of these large companies just didn't have. So, we spun out and on day one had a client. Um so. We we had a a business that was in the black. And we really started building a managed services business in the 90s when there just really wasn't anything like this. And. Uh I shouldn't say that. I mean, our only analog was really outsourcing. But what we were doing was more than hands and tasks. We were actually responsible um for both very sophisticated enterprise applications that had global implications. Um and then also we picked up a lot of mean, you know, small medium business. Um because there's a really interesting line where the stuff just gets too complex for them to manage. They want all the advantages, but they don't want to staff up and run the thing. Right. And and so, you know, with those lines of business, we um saw the opportunity there. Um, you know, when we did the business planning, obviously it was very attractive. Um being able to leverage what we had built in the integrator space as a one-to-one kind of model with engineering. This was a many-to-one model with engineering. So, the real work become became building the management system. And the kind of overall structure to allow this both to start, operate reliability reliably to build a strong customer base. And then really ultimately, how do we scale this thing so that we can actually build something that's going to bring in. kind of revenue we need um to grow this even further. And um so yeah, that was a a really fun experience for me. Um out of it, by the way, a lot of the work uh Jean and I wrote a book back in 2005 and George. Called Visible Ops. And Visible Ops was something that we really struggled with, um as a core tenant of our business. Would in scalability, we needed to create operations that ran efficiently and predictably. And we started entering into this really nasty environment called co-managed systems. Where you've got clients that are touching systems while you're touching them. And it's just a recipe for heartache and headaches, right? And pager calls going off all the time. And so, you know, we had to figure out, what is our system of control going to be? And how are we going to help our clients by separating and understanding every change of a desired state to their systems and that it's matched up with some intentful, purposeful action, not just entropy or being compromised or those kinds of things. So, we developed that out of there and that was through a lot of pain. And. You know, learning the hard way because MSP clients pay you essentially, you know, especially in the SMB space for one thing. To be invisible. And and so, you know, one of the hardest things you have with a client like that is you only ever hear about things when they go wrong. And the only time you may hear about the good side of things is if they give you a reference. Right. This is I I often compare IT support to like an industry like an insurance. It's not like they just randomly call you to tell you what an awesome job you're doing. It's usually because something is on fire or flooded, right? Yeah, exactly. Yeah. Yeah. That's a good point. I mean, I had to talk to, you know, commercial liability insurance the other day for the business. Because I I you know, running the as a president and I run that part of the business and and you know, you're thinking like, wait a minute. Why do I have to be on the phone with these guys right now? It's not like a car crashed. You know, and and then, you know, my daughter proceeds to total a car and then I have to talk to him about that too. And but you're right, it's and what I looked for in that interaction was. How this is going to be a lot of friction, how can they reduce the friction of this? And so I realized as a business owner what was important to me was stuff happens. Things break, stuff's complex. But your response and your demeanor in the response and the way you hold my hand and keep me from having to feel like I have to get involved in the process is so key. And I think that being able to have answers that are concise and to sound with precision when you're talking to your clients instead of that, well, we're looking into it. We've got our best people on it. There's a big difference between whether they understand it or not, here's the 15 steps we've already taken. Because we take these by protocol. Before we even talk to anybody, right? Here's the process. And using not only those outage events because you got to come through and you got to solve them or difficulties or performance degradation. But using them to sell your business. In other words, to create confidence during crisis versus deficit. And the way we create confidence is, we all know what it sounds like when somebody's on it. And we have to figure out what our clients think that sounds like and then we have to exceed it. Yeah. And and so, you know, we found out with some clients that they don't care. They just want to know that you know. Right. And so all of a sudden CRM became a part of what we were doing. Yeah. Knowing client dispositions and having every be able to pull up the client and go. Oh my gosh, that guy's a hot head, this is the person that's going to help us solve the problem. Maybe I'll start here, right? And so like that, I think it was unsuspecting kinds of things in as we scaled out the business, which was, how do we move more information around quicker among this team? Because when we were small, we all just kind of knew it. Yeah. But all of a sudden when you scale past like, you know, it's all these Dunbar numbers. It's like when you scale past 15 people. It's like, I don't know if I can trust you. You know, and and. You know what I mean? And so it's like, you know, so that that kind of environmental change. Even though you may not have a ton of staff, if you have 15 people, which is, you know, a decent sized MSP for what a lot of them are. Um and a nice growth number, if you can get the revenue per head out of 15 people that you can get out of five. Right. Um. You're talking a real business. And so, you know, I think one of the problems is a lot of folks in the MSP market when they go to scale beyond that number. Stuff just starts breaking. They take on that client that they wouldn't normally take on because to be honest with you. You could never take it on before, you didn't have enough references or you didn't have enough of those things. So then you take on that big client and they break you. And you've priced it. Right. So that the big client will go with you. And which means, you know, at the end of the month you're sitting back going, wow, we're spending a lot of time on this client. But I'm not getting any money out of it, I could have hired four small clients for this. Yeah. And so there's that mix of business, core competency and then the stuff that just breaks scaling businesses. And, you know, in in the Phoenix project, one of the characters that we wrote about was Brent. And I actually worked with the character who really is Brent, um and an MSP. I worked with him at a lot of places. Um. We started up a big big regional ISP back in the, you know, early, early 90s before it was cool. Um in the Northwest. And so Brent and I have worked at multiple companies together and he always becomes the Brent. And. Um at the MSP, you know, we had one Brent and then we got another Brent and then we got another Brent. And all of a sudden you're sitting here going, oh my gosh, how do we get all of this incredible knowledge concentration? How do we start actually a journeyman type of program, an apprenticeship to bring in folks that are just learning break fix? They want to go to the next level into engineering, they want to learn how to handle clients. So it it can be a little hard to start to to diffuse that knowledge. And um. So that was a big thing where I used the theory of constraints to do that. So, you know. How do you break that cycle? Yeah. Can you expand on that because I I know that this is something that people struggle with. Like I joked, like Brent is everywhere. He's in every company. And that's one of the parts that I find people resonate the most with is when they read this, they're like, oh, I've got this guy and he's just like Brent. So, can you maybe expand on on the approach that you took to break out that knowledge? Yeah, I mean, the problem, first problem with Brent are is is that um their skills are um they're not confined to a functional area. Right. So, what Brent's become is boundary spanners. And they not only learn a little bit about everything, after a while, they learn about everything. And how everything's connected. And I'll tell you one place to look for Brent. Is they emerge out of networking stars a lot of times. And the reasons that that happens versus a lot of sys admins, although it happens from sys admins and DBAs too. Um is is that network people, some of them that are boundary spanners innately and very, very curious about applications and everything that rides on the network, they know how everything's connected. And they know all the conversations that are happening across the network. And so they have a much more systems view of what's happening already than a lot of people do. If I worry, if I'm a sys admin, I'm worried about servers. Or virtual machines or or in many cases, um containers and then even more serverless type things now. And and so. Um that's my universe. But when you don't understand how it's all connected, you go to the network guy, right? So what happened is is out of the networking team, we would put really sharp people in there because it's getting more complex. And and at the beginning it was a very much the core of our business. Um. And then, you know, you get really well-rounded individuals that come out of there. And in an MSP, especially a smaller environment, you tend to wear multiple hats. So it's one of those environments where you get a lot of exposure to a lot of things. We would always joke, it's time to, you know, flip the switch or put on another hat right now. Like, you just went from solving a network edge uh BGP routing problem. To now, hey, now you got to run in and figure out why the antivirus updates are blowing up all the machines that our customer just installed, right? Like. And even though we didn't do it, right, um and they didn't tell us they were going to do it. And they made an outage. You know, it looks like we did. So we have to step in and help them and um so, you know, you're you're constantly changing what you're doing. Which is also part of the thrash. And I talk a lot about unplanned work and visible ops, we all did. And in being an MSP, it's it's so hard because it becomes your staff light. And it becomes a responsiveness game. Like. Yeah. Constantly, it's not even fires, it's just you have to communicate. Some clients are really needy. Yep. Um and that's a good thing. You know, uh uh. You know, for for an MSP, that means there's a there's a value perception there. Um. And so, you know, that means they all have needs at different times and they want different things. And so you don't get these standardized requests like you do in a big organization with a lot of process. A lot of functional alignment, you know, for responsibility. So by nature, and this is why I love MSPs, a lot of them are just living DevOps organizations. They may not be writing a lot of code. But they're cross-functionally just working. Right. It's like a startup. And and so it's really easy to develop one or two people that are the senior people out of these groups that know the most. And they become a constraint. Because they know the thing you need to know in order to do what you have to do. And so you have to get it out of them. And a lot of times they're like, it's just quicker for me to do it than to explain it to you. Right. And so when you hear that phrase, that's that's that means you have a constraint. And you have a person who's making themselves a constraint instead of taking the longer view. Which is if I show you the next time this happens, you won't have to do this. Right. And it got so hard with with some constraints that you literally have to say, no, you don't get to use a keyboard. You have to channel what you're doing through somebody else. And. So for certain things, that's what we had to do. And it seemed wasteful. Right. And I kept having to remind, you know, uh people in charge saying, listen, we're investing in scaling right now. We're also eliminating bus problems. If Brent, if I bus or, you know, you know, God forbid, got pneumonia or something like that, was out of the office and in a hospital, how do we do these things? So it's not viable for the business to just have one person. And so what we decided to do was also Brent's become expensive over time. Because they tend to be senior, senior people. So one of the things I wanted to go to work out was, okay. If the Pareto concept is true in the sense that there's an 80/20 rule, it also means there might be a 20/80 rule. Which is, what is the 20% of your work I can learn that allows me to function at some higher multiple percentage of your what that, you know, in terms of what it is that's your job. And so that became the thing right away is learning 20%. Which. Sounds simple, but it ain't so simple. Because it means you have to know what it is. So need for collecting data. Yeah. You can't walk up to your branch of the world and say, so what do you spend most of your time doing? They spend so much time task switching that after a while, they don't know what they're doing. They're literally just responding. People are inherently terrible at being able to judge how much time they spend on what, unless you're doing like an objective time study where you're marking down or recording your time somewhere. If you ask someone how much they time time they spend on what, uh how they account for it in their head will be dramatically different than what they actually end up writing down. Well, and the the just the nature of the environment. The the kind of like alternating between boredom and then sheer overload. Yeah. Like, um it can be amazing. Like boredom would feel like, crap, I can finally get to those projects I know I need to do so that we don't have that problem next time. I'm not referring to it as actually idle time. It's the things you should be doing. And and then there's all the stuff that people want you to do. And there's that tension between, I know I need to or else we're going to have that problem. And when you have that problem because you haven't been able to do it, morale really suffers among the team. Yeah. And and I think it's a really important part of where apprenticeship really comes in because it's a lost piece of our industry and I think it's going to be coming back more and more as technical schools and universities continually fail at educating us. Um less on functional tasks and more on the holistic nature of what it takes to run a business. And it's all divided up into parts. Are you suggesting um that like you mentioned journeyman and the apprenticeship and things like that being uh probably more practical? And I I think I strongly agree with you if this is what you're suggesting that the on the job training is probably where you should spend the majority of your time versus more structured uh course work, right? Yes. Yes. Absolutely, I believe structured course work is great for some things. And for some uh in an engineering capacities, learning things line by line, precept by precept makes a lot of sense. Um. And respect for prior art is huge. I'm not I'm just saying that for for a lot of people, it's not the path right now because those schools literally in university are moving too slow. They can't universities just can't gear up to change your curriculum as fast as things are moving. Yeah. And and um. And and even worse, DevOps is something people are teaching the tooling aspects of inside of universities because that's concrete. Teaching people the social aspects, which is really the socio-technical part of it is really where the magic happens. Um which is, you know, people working machines working for people instead of the other way around. You know, in this scenario. Um. Automating toil, right, as opposed to making it so people can't learn. Because, you know, fundamentally, I have this controversial belief that learning is a human right. We shouldn't be throwing people into jobs where all they do is piece work. That can be automated. If there's no judgment required for your job, then why isn't a computer doing it? And and and or something automated, right? Like so people can learn. And and and so. You know, journeyman and and the ability to to kind of have apprenticeships. Also allows you to do something we used to do back in the day when we were running businesses. Which when we were grooming errors to positions, we would make them as a part of their tour. Work different parts of the business. Because while we're taught in business school all the parts and then theory we're supposed to be able to run the whole, we're never taught about how people run the parts. And what's really important is orchestrating people's performances together. You know, in order to get a result. And so, you know, I think that only can happen in companies because every company culture is so radically different. Um. Inside of the company, you know, Toyota really embraced training within industry. The notion of you're learning all the time, building learning corporations. And so having just a hair of formality to that and pairing people, giving them rotations. It's a little more expensive in the short term, but for the MSP owner who's trying to figure out how to get to the next level. Giving yourself more response options in the face of chaos. Which is what that does. It spreads out that knowledge. It gives you the options to say, no, no, no, Brent cannot work on that. Can you fight the 20% that you know how to fight that's the first 30 things Brent taught you to do anyway? So that when you bring Brent in, Brent's dealing with edge cases, which is where Brent are great. Right. But they're not dealing with, did you try this, did you turn it off and on again? Did you, right? You know, all those basic things. Because what we find is is that the Brent will rush to the fire. And nobody will have done the basics. Right, because we know that they can rely on someone that can get to it in five minutes, right? That's the other thing. In the name of helping the customer. Which is always the right thing at an MSP. We want to give him the fastest solution. Well, sometimes like you said, speed is one of those things where it's like relative. When you look at the whole picture, you're pulling Brent off of something that's really important. For something that's temporarily important, right? And like, you know, and I think I think that's the big issue is kind of among staff. You know, garnering that judgment is hard. Building that. And that's why apprenticeship even in customer relations. Like, you know, go on for ride alongs with your sales team out to a client as an engineer. It's different. You hear stuff from them that you're like, oh my gosh, did you hear these three things they said? And the, you know, sales person will be like, not really. And they're like. They're struggling with four areas of their business, like we can totally take that over, right? Yeah. And and so you can capitalize on opportunities. But the other part is they finally get to hear what hurts clients. Yeah. You know what I mean? In a way that's so different. This is really, really important. I hope people really take this away and and and noodle on this hard. Because I I think you're hitting on something that is so, so important. I hear a lot from people, they're trying to figure out how to train the the low-level, mid-level staff up to be to to replace the senior guys that have been around and have all this tribal knowledge. And they're wondering, you know, how do I train middle management staff so that I can take off three of my eight hats that I wear running this business? And I think they they naturally reflectively look to some type of training program and they're missing the fact that the training happens on the job. And if you send someone away for five days to take a course, they may learn 10% of what they need, but if you have have them sit with yourself or with one of those senior guys and just job shadow for five days. That probably has a 50% uplift on what they know. So I I think it's really important what you're saying to to look towards the capability of the the internal training for the organization versus that external structured training. I think is incredibly important. Yep. And then the only other, you know, one other thing I think that's really important is is in the MSP business, one of the other problems we have with Brent. If anybody's going to show up at a client site and get executive exposure, it's going to be a Brent. It's going to be for a big problem, a strategic install, a consult with their internal people. About things they need to do, be ready for, you know, hardware refreshes or whatever it is, right? Um so they're in their consultative capacity. The more exposure they get to the sales process, the more they're going to know how to handle themselves. In those relationship processes, right? Because, you know, back in the day, even copier repairmen at Xerox and a lot of these large companies were trained on the things that they don't know. Which is the customer experience. There's a big deal walking up to a machine having the customer there saying, so, uh, when do you think you're going to have this fixed? And the guy just sighs and said. These problems, I have no idea how long they take to solve and this particular manufacturer is horrible with support. So, I'm going to be lucky to get this thing up today. That's what they might be thinking in their head, realistically. But dear Lord, that client has no confidence walking away from him. First of all, you criticize the thing they bought. Yeah. And you don't know if they were the one who thought this was a great idea or not. Secondly, you know, huffing. You would never want to, I always say the demeanor you want. Is the best doctor demeanor. Which is the last thing you want is a doctor to walk up, you look at your charts and go, oh. Oh, yeah. Yeah. You know, and then kind of put him down and think for a second. Right. It's it's those intangibles that we learn during the process of when we understand why they buy. Yeah. And and so. You know, I think that that is so critical to have the sales/engineering team interaction make sense. Because a lot of times engineers roll their eyes at what gets sold. And rightly so. Because it gets so oversimplified. You know, a Brent would hear be like, you're charging them five grand a month and all you think we're doing is that one thing. Holy crap. Do you understand we need to buy a million dollars in software to do that one thing? Like I wish we could have talked. Right. And instead they're like just figure it out. And that's the worst possible place as a Brent because you can. It's just now you're McGyver and now you've created something you're going to always have to touch. And that only you understand. So I think one of the things that's creed is, you know, critical to scaling those Brent is getting them into those conversations early before you pitch stuff that's new. And and understand. That they are going to be the person that walks into the room and says, all of these things are going to go wrong. Right. It's it's why we never ask attorneys if we should start a business. We ask them after we've decided to them because they're all going to be like, don't do it, man. There's just all these risks. Everybody's going to sue you. You know. And you're just like, wow. This is terrible, right? Um. So, but you need to bring them along to tell you how to do it. And and also. To come back and give them the challenge. Which I've done many times, which is, what can you do? For this amount of money. Framing it as both an engineering and a technical problem. That has to fit within a constraint. Now that gets an engineer's mind going. Versus, I sold this thing. Because I'm so confident. You can figure anything out. You know, what sounds flattering. But isn't after a while. And you're also making the wrong use of your brand. What you should be operationalizing and scaling, you're now making custom. And that that just uses your constraints. And all the wrong ways. So thinking about. Selling from your core, not continually extending the core. And asking yourself, what makes the most leverage and highest use of our value people? Um. And and I think what you find is more of that is coordinating what people do and don't know. Working with their thinking, doing less hands-on and getting involved earlier in the sales cycle. Yeah. And turning those folks into pre-sales engineers, architects. Um and, you know, people that ultimately get data out of the organization to figure out what to do next. Um. So, uh, you know, I think that's that's a big deal. And then the other thing that Brent can and should be doing is projecting what uh hearing what customers are trying to do. Um seeing where things are going and maybe ahead of time coming up with some go-to-market ideas that can be tried by sales teams and by founders in the market with early adopters. Yeah. Um. So that that it's it's a big shift to take them from being constrained. In terms of a swing of costs to making them generate money. And. And I think that means you have to expand the staff through apprenticeship. Which by the way is less expensive than paying people that have industry certifications. And or for them to go get industry certifications. That become a real problem for you later on when basically that whole process turns into confirmation bias and they only want to be buying from that vendor. Yeah. Because they know it. They know, you know what I'm saying? Like they there's a there's a whole process involved there. So, um. Yeah, so I think I think the on the job training, which means you have to have a pretty well-stated idea. What you want your staff in terms of values to have and the way they work. Yeah. Um so, I mean, we can talk to Brent about, you know, the what's in the house. But as founders, we got to bring the why that creates the conditions for them to understand. How we would do things and what we would do given, you know, the why. Yeah. And and and we judge your performance based on that. Not just what you got done, but how you got it done. Yeah, and another area that I would say that they could and should spend more time on, especially going into the future is is what I see as sort of a bleed over into the DevOps. Where IT ops and DevOps start to look a lot alike because like you said earlier. If you can automate it, why is someone spending the time to do it? So I think, you know, part of the the skill set that is required for MSPs and IT space in particular in more broadly is automation, scripting. As stuff goes more cloud-based and everything is more service and software defined, that being able to string things together and have scripts respond based on certain parameters. That eliminates a lot of leg work and I think that's a huge space that people could spend more time on. If they had less things that they were reacting to, right? Yep, yeah. And and I think what. I call that, you know, moving to the um moving to more of a cyber liability engineering model. Um like uh basically Google treated uh you know. IT operations as a software problem. So right off the bat. So how do we never have to solve these problems, while we don't do the things that create them in the first place? And so I would really encourage to for a lot of people to say, well, you know. Here's the defense mechanism is we're not Google. Um and that may be true. But it doesn't mean you can't be inspired by how they scale and how they maintain scale. And how they maintain reliability. And and how they maintain control as a set of philosophies that scales from small to big. And if you can embrace the philosophy of determining the objective levels for services before you set service level agreements. And build infrastructure and design things and that's an executive conversation up front with the clients. And you know, what is this thing? If we can start to think more that way, we can engineer more reliable solutions as as an ecosystem and control them with a system that allows us to scale people. So your Brent become cyber liability engineers, why they're better devs than a lot of devs. And they're better ops people than a lot of ops people, um and they're certainly better at configure management, configuration management and architecture than an architect. So at the end of the day, they're sitting here going, whoa, you guys have a problem. Here's the things you need to probably start fixing. And by the way, if you don't fix them after a while and um get this thing under control. Um support's just going to give the support back to you. Yeah. Like. You know what I mean? That's a real problem, right? But and and not that there's a lot of development going on in MSPs right now. I think you're seeing a lot of scripting and I think MSPs by nature have to do a lot of integration development. Because no matter what software package you buy. The correlation engine sucks and you wind up writing some of your own. And and also. You know, interfaces between things so you can have more of a seamless experience. I think you're going to start to see more adoption of open source software. And that's going to require more coding. Um. You know, I'm thinking the balance of op shops moving forward over the next five years. They're going to be at least half developers. And eventually. If we do this right, 80% of them should be developers. You know. We should be taking things that are complex, turning them into things that are more known and then as those rules emerge, we can automate them. And um. So there's that process, which means no, you know. Normal shops like uh MSP shops are going to have to understand agile, source control, tool chains. Things they've never worked with. Why? Even a five-person shop needs to be able to know that the file I've got in my hands is the latest and most correct version. And that if I get it, I can't modify it here. I have to modify it in source control first. That way every time I get it, I know what I've got, right? And so some of these things we've told ourselves are luxuries are now with DevOps and with the higher velocities that our customers are moving at. Um. Because I know there are MSPs right now maintaining infrastructure as a service. And in and and and operating in all the gaps between the applications. And clients are writing software. That's where we're getting these co-managed systems. Where they're doing releases to systems and we're supposed to maintain their reliability. And so, you know. All of a sudden we're like, how do we know who changed what? Well, now you got to move into the realm of desired state computing. Using software like uh, you know, tripwire or upguard or something like that to understand. Hey, detect changes. Reconcile those against your known changes that you're going to make. Hey, we didn't have this in our system, nobody from our group made this. Therefore. You guys made this change. So now the call sounds like. Hey, so why did you guys change this, right? As a in an MSP situation. Non-confrontational, just a question. You already know who did it. So it doesn't have to be like. You're sure who did this thing. You know, and people are doing this kind of blame stuff. Um. So that kind of sophistication is going to require um, you know. MSPs to start to understand the tools used that their clients may be developers are using. Understand about how these DevOps tool chains are going to start, you know, essentially being like release cannons. Where things are going to be continuously deployed by a lot of people. Not continuously developed. There is no release. There's commits and then stuff shows up in production. So. Like this is a new mindset for MSPs, right? Like. It's it's a different way. So having to understand how they work means you're going to need to adopt some of these practices. Yeah. It's it's really interesting. We we look at the evolution of this space, what we're talking about is like coming from the the systems integrator. Where we bought we bought X, can you install this in our system? Okay, thanks, see you later. To the consultative on like, well, we want to understand how these things fit. And can you help us make these things work better? To the managed service model where like, this is yours to run, but I'm going to define the budget. And expectations of of service. To now where it's very, very fluid, right? That. Exactly. I think what you're describing there around like using tripwire and uh definitions management of what's in in production. Used to be kind of limited maybe to compliance or to enterprise, right? But now, I think you're right, where everything is is in an agile development phase where nothing's ever complete. So you have to watch it while it's working because it's not like you have a three to five year life cycle on this stuff. You have like a. One to two month life cycle, right? Right. And I mean. And there's there's a lot of keys here to prevent MSP from having to have a lot of institutional overhead. Like a lot of audits and controls. If you can make systems attest to the things that they've done. I'd trust a system log over a human log. Any day of the week, right? Yeah. So the job for MSPs become take the toil out of controls. And actually understand that those controls that need to be in place, you know, regulation. Um the way to eliminate separation of duty problems, which is one of the things that causes. A lot of bloat and staff, um in some organizations, if you handle a lot of small banks or if you handle a lot of. You know, they they want to see these huge separation of duties charts. You get to say, hey, listen, it's not a thing because we have all these controls before anything actually happens. We have preventive, detective and corrective controls. We know who does things. Matter of fact, one of my solutions or one of my suggestions is, and I think a lot of MSPs have done this. Is to move to provisional access for people. In other words. Access is given out by systems based on what it is you're trying to do. So that they're correlated. So whenever you have somebody logging into a system and making a change, it's in a change record. Or we know what why. And that access disappears after a period of time. Right. It's not always static. And static access causes MSPs. Audit trouble like you wouldn't believe because as an auditor, and my I by the way. I recommend that every MSP sends somebody off to get their certified internal system uh system uh audit. The CISA for IT, which is the auditor for IT, um that they pass their CISA exam. And you study for it. Because now somebody on your team knows what audit is. What controls are and what's important. And how auditors rely on your controls if they think you use them. And and so. The whole idea with controls is really simple and we've gotten way out of this whack on this. Is, you know. The the first part is in the military, they inspect people's bunkers or beds, right, for a reason. A lot of people think, oh, this is stupid. They're just actually control, making discipline. And the real reason is is that wars are not fought nine to five. And if you wake up in the middle of the night. And it takes you 20 minutes and it takes the next guy 14 minutes and it takes the other guy 30 minutes to figure out how to get your clothes on, your kit, where your rifle is, how you load it. Right. It's you're all going to die. And so the. The, you know, your sergeant will come in and inspect the conditions are ready for battle. It's called management inspection. That is the essence of, so what must we control to do our mission? And know that we can do it well, right? Because that's a detective control. Him coming in there or her going in and saying, you know, I can't bounce a dime off the bed. That means it's not made right. And that means there's variance between you and him. And I don't like that. And um so. So we've lost touch in the managed service environment because a lot of it is so, I hate to say the word. Hair on fire in terms of business, like the business, not the not the intelligence of the way they're run. Um. That um we don't get time to eat our own dog food a lot of times. Which is, you know, those projects that we all want to get to that we know we should do that reflect our values. How we want to operate. So I would submit to MSPs and especially owners, um and management of those groups that if you do not do that. If the if you hear a lot of that lament among your smart people. You are you're going to have longevity problems with your engineers. Um. They will inherently walk away from an environment. They don't think that they reflects them. Um and they'll see that as a need to move on to another level of opportunity. So consistently allowing your brands and the folks that are the most constrained organization. To get freed up like we were talking about before and then what is the new job that you're giving them? How do we get these things? Get some of these practices that are correct that are going to help us be more efficient and effective. Um. And sell to our clients our process, right? Um. I think that's different. And then the second thing I think is is there's a huge opportunity for these MSP shops that outsourcers do not have because of their rigidity. And that is. Is that MSPs have the option to say to a development department on the customer side. Hey, could we have DevOps style interactions with you? Could we build tool chains together? This stuff makes us sticky as MSPs. Yeah. Right. First of all. Secondly, we're now working with their teams in a way where we have empathy for each other. Can detect what it is they need before sales is even involved. Design solutions together. Come back and literally drop Easter eggs in sales people's baskets. Going, by the way. We just came up with this whole new project, you're going to have to monitor it. You know. And and you know, and you know, heaven forbid, I think we might have to charge them more. And they might get more value. So that crossing over, not only develops continuous business opportunities, it creates continuous value for the client. You're not just seen now as a as a person. Who you call when there's a problem. You have you might have a weekly uh WebEx to work with their developer teams to talk about release cadences. Talk about a new tool that you both need to install and get trained on together. Or, you know what I'm saying? Like some code you could both work on for an APIs so that their system could reach out to your monitoring system. And know state before it does a big job back on their end. So. There's like ways to become sticky and more valuable. And most of all, more important to your client's operations. It's going to require you to think a little different. You're going to have to have some people that can interface. Across those client lines, well, they tend to be Brent and so, you know what I mean? Or junior Brent, right? And and so. I think that kind of stuff is is how do you turn your Brent into a people that have suffer from toil? Um and and put them where they need to be needed. Which is really both helping mastery at the at the at the level of engineering and and ongoing daily operations. But then also helping create and productize new offerings for clients. Where you have that cross-functional or even cross-organizational, you know, company alignment together of. When you move left, I move right, we have a dance moves. And that stuff is not only sticky, it's almost unheard of for clients. And when they have that. They feel elated. Yeah. Um. So, you know, rather than have the MSPs become the new wall that people throw pigs over. Um. You know, and they're like, geez, how do we monitor this thing? How do we how do we even understand when you're making changes to it? Well, that DevOps style collaboration will be like, oh, your application changes these 10 files. Every 15 minutes. We should not be monitoring those files for change. Like. Because they're going to go off every 15 minutes, right? And so, you know. Like I I think that kind of stuff, the direct developer interaction. Is what some people long for to be able to do a better job as an MSP. Like, if your log made sense. I could actually act on it. Like my systems could automatically pick up that error message and do a whole bunch of things to solve that problem automatically. So, you know. Um so I think that stuff we've been craving is now available. We just got to be brave enough to start to talk to our clients differently about that stuff. Yeah. And um. And it also means it opens up the startup world potentially for MSPs. Which is. While they're still young and while they really want to focus on development, those scale points that they hit are going to be like. Hey, we can't afford to build up a whole IT group right now. We just need you to manage these three servers. And people in MSPs are often like. Startup, kind of a risk. Can they pay their bills? You got to figure that out. But if you're not taking up startups, you're not developing future business opportunities. And or people that go other places that give you other business. So. Like I think. That that's a big deal too, they will that's your best opportunity to DevOps with the team. Before they start building operations. And stay with them long term while they grow. Um. So that's that that's a, you know. I'm excited because those are the folks I think will be the most willing to try a new style of collaboration. Yeah. Right. Um. Oh, the the future is very cool. I I think this has been a a fascinating discussion. I really appreciate your uh your input, Kevin. And uh want to be sensitive to time. So we'll we'll look to to wrap up here. Um I could carry on, I'd love to have you back in the future if you're up for it. But this is. Love to. And love to. Love to talk with uh with other MSPs too. I mean. It's a like I said, it's a spot that's sweet uh to me. Because. It was one of the first uh job opportunities that allowed me to transcend all areas from engineering all the way up to the Chief Operations Officer. You know, those things. And and really try to understand, um, you know, how do we make the relationships. That our people are capable of the real asset, not just the technical capabilities that we have. Yeah. So true. And providing confidence. And I think great MSPs provide a lot of confidence for a lot of people. Awesome. So if people want to follow you online or reach out to you, any channels you would suggest? Um, well. I I I operate on Twitter, um, which is so I'm at Kevin Bear. Just like my name is spelled uh with Bear being B E H R at the end. Um all one word. Um. And uh you'll be uh my um author site Kevinbear.me will be up in a couple of weeks. Um working on a new project, which is going to be exciting and um and I'll be blogging there again. Um about some new things that we've been building over the last two years um in my practice, Jane Bloom and I. And some other folks have been building some really fun stuff, um so look more to hear about that. Um. And um we've been working a lot in the enterprise and global space lately at Praxis Flow and we've just learned so much over the last two to three years. I I can't wait to share it all, we've been distilling it for a while. Awesome. But look for me up on Twitter to be talking about that. And other random things. And then uh at at the Kevinbear.me. Uh site is is is the other channel. Okay. Well, we'll link to everything in the show notes. And uh once again, really appreciate your time, Kevin. This has been great. Hey, thank you. And uh look forward to talking more.