Simplicity and the Renada mission.

SPEAKER_02 0:00

This is the How to MSP podcast. I'm your host, Andrew Moore. I heard this years ago and it really resonated with me. Because everything I do, it's how simple can we make it? I'm obsessed with like simplicity in everything I do in my entire life. Because as soon as it's really simple and repeatable, it gets done way more accurately.

SPEAKER_00 0:22

That was Connor Fagan. Connor is the founder and owner of RENADA, a UK-based consultancy specializing in Halo PSA implementations and technical optimization for managed services providers. Working with over 300 MSPs and growing, RENATA is a premier consultancy regarding MSP optimization. Today we discuss setting expectations in your MSP, building accountability into your processes, and why AI may not be a magic bullet for your business. All right, welcome to the How to MSP podcast. My name is Andrew Moore. I'm your host, and today we are meeting with Connor of Renata out of the UK. Connor is the good day. Cheers. All the things. Yeah. All the uh so Connor is the owner and founder uh of Renata, and they are one of the world's leading specialists in the Halo PSA uh deployment and uh integration into managed service processes. Uh, but that's not the only thing they do there. And it's not the only thing that Connor does. So uh Connor, I'm uh interested to hear a little bit more about how you guys function, what you do personally. Um why don't you tell the team about who you are and what you do and uh where you physically are today, where does the podcast find you?

– Meeting in "The Dungeon": Connor’s remote office.

SPEAKER_02 1:48

We're still hung up on world's leading specialist or whatever you just said.

SPEAKER_00 1:52

Um everybody here in the US knows you, which means that if you're in and people in the US know you you're worldwide, we're worldwide.

SPEAKER_02 2:00

Yeah, we we have partners all around the world, right? But I, you know, you find me in what I've called the dungeon, right? This is an office I renovated last year attached to my house. Every wall is black with a bit of decor behind me. Um it's not finished, it's a standard kind of thing. But I'm in the UK, in the north of England. Um, you know, our team is fully remote, so yeah, stuff like worldwide or people knowing us, it's just uh I I I try and not really think about it because I'm just sat in this little four-walled box, right? And I see my team a handful of times a year, and we're all just living our own lives. But yeah, today you find me in the dungeon, which is uh the new place to hang out, really.

SPEAKER_00 2:37

I love the wallpaper back there, it's very cool.

SPEAKER_02 2:40

Yeah, I need to put some pictures online actually. I've done like different themed all around the room to give it a bit of colour. The wife was like, it's gonna be like really dark in there if you do everything black, like the AP's black, the AC's black, like everything's black, and I'm like, yeah, it's the one room in the house that is like mine. Um everything else is, I don't know, the wife's and the kids, that's it. But not the dungeon.

SPEAKER_00 3:00

Um, so a little bit of your journey. How did how did you get to where you are? What are you guys up to over there? Just briefly kind of filled the team in on um on you know what it is that Renata does, what it is that Connor does, and what differentiates you guys in the in the space.

– From Curries to CTO: Connor’s journey.

SPEAKER_02 3:17

Seems to be a bit of a common story now. When I said it four years ago, I was quite unique, but everyone seems to be saying it now. Halo asked us to help them four years ago, is the long and short of it. Um to the backstory is I've been in IT over 10 years now, 15 years now, I don't know, too long. Used to work for Curries in the UK, which is my first IT role, which was fixing laptops and tablets. Then I started my first company, which was like a mobile laptop tablet repair company. That didn't work out, as first businesses typically don't. Um, I then moved up north with the wife or girlfriend at the time, um, started working in education, so did that for seven years, found my niche, which was infrastructure. So started, I was an infrastructure manager of like nine schools in the UK, and managed the entire IT estate, really, um, but mainly focused on infrastructure. Um, then verged into MSP world, um, went private MSP, um, then went into education MSP as CTO. And when I was there, we went through an acquisition. Um, and I got a piece of paper on my desk, which was, Connor, what stack are we using? And I replied, I don't like either company's stack. Maybe now is a good time to, you know, look at what's out there. Fast forward 12 months, we'd migrated to Halo, was about 60, 70 staff at the time. Um, did that for a couple of years and then left to start RENADA, which was supposed to be digital transformation, but for the SMB sector. And my wife's worked in care all of her life. She used to moan all the time about their systems. And whenever I saw her laptop, she died a bit inside, honestly. Um, and I really wanted to go in and be an advisor, but not an MSP. So, you know, one of the things I've always struggled with as an MSP is trying to convince a client they need this thing, right? Because they just think, oh, we're just trying to sell to us again. I was trying to bridge that market by being a consultant, but not actually doing any of the work. Just going in, being a friend to, you know, Andrew, who owns the business, doing an audit, and then going, listen, I can be a bridge between you and the MSP. I can be an advisor of any big decisions you need to make, but here's where I think you need to be. Here's the report. Check me in whenever you need me. And then I was trying to build like long-term engagements where I check in once a year, do an update, see where they're at. Um, long story short, Halo said, Can I help? And here we are three and a half years later.

unknown 5:35

Doing that.

SPEAKER_00 5:35

So do you do you do any of the configuration on any technical assets at this point? Or are you just strictly consulting and or you know, helping with the maybe do you do configuration within the Halo system itself, or do you just advise people to get stuff done?

– Partnering with companies, not products.

SPEAKER_02 5:51

No, so we're we actually all we really do is configure technical solutions now for our partners, be that automations, be that mainly in Halo these days. So we know we do, I say most of our work is in Halo, but we are Ninja One partners, so we help MSPs, you know, manage and monitor Ninja, set it up, audit it. Same with Hudu. Uh we're doing loads with SIP at the minute as well. Um, got a great partnership with them with ProSerf partners for SIP. So leveraging Halo is the I don't know, the glue, if you will, and then yeah, leveraging tools around it. Um we're really, really intentional with who we partner with uh because we partner with companies, not products. And therefore, in the three years, we've not changed our vendor stack at all. Um, we're not just moving because there's a better margin or a new deal. It's what is the best tool we believe on the market today for you as an MSP? And what are we best at? You know, I often joke with people saying, you know, I'm not tied to Halo. Halo just is right now with the best PSA on the market. And if something better comes along, then we will explore that. Reality is with a team of six now with four years into Halo, it's not just going to be an overnight shift, but I like that mindset because it keeps both sides accountable. Halo needs to still keep putting out good work and being a great company, because if not, consultants will stop, and consultants need to be doing the best with Halo because then we're adding as much value as we can. And it's, I don't know, kind of a two-way conversation with it.

SPEAKER_00 7:13

Yeah, no, and I I told I tell all of my clients, and we do, we do work in, you know, whether it's data or it's connect wise or whatever. But if I if I started an MSP from scratch today, I'd start it with Halo and Ninja. Like there's just a lot of really great configurable synergies between those two products together and scalability, which I think I'm starting to see kind of a shift in the market as this first tranche of MSP type companies are starting to age out, right? And you're getting, I I feel like almost like this new wave of next generation software and solutions for the MSP space, where you've got younger people stepping in that are starting to take over or start MSPs. And it's just I think that we're gonna see a real renaissance uh over the next like 10 years. And it's not even particularly around AI. It's just the tools are changing, the direction of owners are changing, the buyers are changing, right? Like the people who are buying MSP services are they grew up with technology, they understand technology, they they um have configured things themselves in the past, right? And so I think you know, what we wanted to talk about today was really focused around how to set the proper expectations within your business for your clients, um, which I think is a fantastic way to approach where we're going as an industry. And so I'd love to hear your thoughts on, you know, as I've set the table here a little bit, how do you feel like the industry is changing and how you pull that thread through when it comes to making sure you're setting the right expectations within your company for your clients? Like, where do you see things going with that?

SPEAKER_02 9:07

I think something to add before I go down that rabbit hole is something you said a minute ago, which was you would start an MSP with Halo.

– Why Halo isn't for everyone.

SPEAKER_01 9:15

Yes. Because I wouldn't really what would you start an MSP with?

SPEAKER_02 9:22

The cheapest lightweight system that I could start with. And I get asked this all the time because people are like, oh Connie, if you start an MSP, you'd obviously start with Halo. And like, no. The amount of engineering we've put into Halo for our partners and for us over the years would detract from me starting an MSP. And to be fundamentally clear when I say this, I don't think I could start an MSP in this market, discuss it for another day. I don't think I have the skills to do that. Um, but if I was to start an MSP, the the tooling would be at the bottom of the barrel. Um, but the reality is, is Halo as a platform really hones to MSPs that want to refine their process, right? And when we're talking in a minute about expectations, they can really refine expectations, workflows, process within a platform. If I'm starting a net new MSP, I don't think I'd want to spend hours and hours each week refining my tooling. I want to be out there finding clients, you know, seeing what they need before I start building my company around what I want. Um, you know, we can we can say you would go and attack a vertical, but if I was starting an MSP, I don't even know if I know where I'd end up within a vertical. You know, I might target, I don't know, lawyers, for instance, end up, I don't know, getting an in with a big agricultural company, and before you know it, I'm down that rabbit hole. And yeah, so I think for me, Halo is fantastic once you're kind of matured a little bit, once you've had three to four to five years of growing pains to understand what works, what doesn't work. I think, and this is why we've kind of got our ICP now, which kind of is if there's less than five of you in an MSP, and again, it's variable, but depending on how long you've been in the platform or had an MSP, depending on where your journey's at, I don't think Halo's right for everyone. Because of the time required to build it and the pain you may not had yet to know what you need.

SPEAKER_00 11:18

That's an interesting point because I feel like in my consulting, there are certain companies that haven't reached a level of operational maturity where they're ready for bifurcation of roles and responsibilities as an instance, right? The owner is not ready to potentially offload part of what they do on a daily basis to another person because they just don't have the time or the service delivery platform built out yet to start moving account management roles and sales roles. So they have to get to a certain point where they're even ready to make that change. So that's an interest. So I'm I'm guessing based on what you said, that from an operational maturity standpoint, that a company has to get to a certain level in order to be able to take advantage of tools like Halo, because otherwise it it the the scar tissue isn't there to be able to understand what they actually need to do in order to deploy something like that. Is that kind of along the lines of what you were thinking?

SPEAKER_02 12:18

Yeah, I think one of the things I've really observed over the past few years is what ConnectWise was really good at, for instance, is their community, right? Where ConnectWise with IT Nation over the years of years had great documentation, great literature. They told MSPs how they should work. So the platform or the product of ConnectWise set the expectations for that MSP. This is how you should work, this is the best way we think you should work to achieve the best output. They did loads around reporting and how what good looks like. And they defined MSPs what expectations or what outcome they should expect if they followed this process, right? And they did that for decades. Problem is, and as we spoke about earlier, the landscape is changing now because a lot of MSPs are going, well, I don't want to work that way. I want to be a little bit different. What if we want to take on this? Or what if I want to, you know, tweak this? And the difference between something like Connect Rides, which is fantastic if you want to be led with something like Halo, is you can go, well, I want to build it my own way. And I want to set my own rules and my own workflows and my own whatever. And that's where the real nuances, I think, are starting to show between MSPs that work in a certain way and want to be really handheld in their operations, which is fine, by the way. I get it, versus MSPs that really want to carve and be unique and differentiate in the space. Um, that's where these new toolings are coming along, which are more, more platforms. And I use that word quite openly, but they are more platforms. I think a lot of engineering, a lot of building, a lot of ownership of the product, um, as opposed to something like ConnectWise and Autotask, which is, you know, you work in this way to achieve this outcome.

SPEAKER_00 13:59

Yeah, I noticed that when I work with my clients that are on ConnectWise, there are certain things that we have to do in the way that we build our processes that have to work around the way that ConnectWise is created, right? Like, and then that's gonna happen with most tools, but the level of flexibility I don't think is nearly as there when it comes to ConnectWise as I've seen it with other platforms that may be more software-focused, API-driven, where there's a more flexible, as you put it, like platform, almost Salesforce-esque, where it's like we're a platform. We've got a lot of ability to create customization and overlay and integration. How do you want to use us versus here's how you should use us, if if that makes sense to you.

SPEAKER_02 14:46

Yeah, and that tracks back to where we talked about, you know, um, I think it takes a certain buyer to get the most out of certain modern tooling, right? A lot of modern tooling is a little bit more open than it ever once was. APIs now are whenever we look at products, we're the first question is do they have have an API? You know, we've just gone through a HR platform review, and every question or um I was kind of given to doing it, it's like, does it have an API? I don't even know why yet. I just know if it doesn't, it's going to bottleneck me at some point. And it's such an interesting way. Like, if we look at all the partners we work with, what we're really trying to advocate for is you need someone internally who's a little bit developer-y, right? Who wants to learn APIs and maybe a bit of JavaScript and a bit of AI and automation. And these were skills that I didn't know when I launched RENADA. I didn't know what APIs were hardly. I knew what they were. And a few vendors at the time were saying you can connect to it, but it was never a thing. Whereas fast forward four years, if you're not using an API, you're kind of getting left behind. Um, you know, building middleware as an MSP these days is becoming a standard process. The problem is no one knows where to begin because none of us are developers, right? Or typically none of us are developers. Um, and it's really expensive, and again, coming back to expectations, to hire a developer because we don't know how to manage them. You know, we I own an app now. I don't know how this happened, but we we own an app now, and we speak all the time about hiring our first developer. I I don't even know, I have no idea how I would manage a developer, how I would interview a developer. Like they could just, I would have no idea. When how long does it take to fix this thing? They could tell me an hour or tell me three months. I have no way of benching, right? And this is kind of where we're at in a landscape now where things are really shifting. And what was once fixing a server following a guide is becoming, you know, how do we API into it to run an automated script ahead of time? You know, how do we become proactive rather than reactive? Um, it was always something we used to say years ago, but now it is becoming more and more prevalent when you see it in MSPs, right? Those that are proactive are automating, using AI. Um, and it's a really exciting time for someone like me. I think that's why Renata does so well, because we get to play with the latest technology all day, every day and go, well, how could we fix that problem? Um, and that's kind of where we get excited, really.

SPEAKER_00 17:13

Well, and you had you had mentioned that you don't take on that many projects. As a matter of fact, I tried to reach out to you guys recently to to take on a project for a would-be client of mine. And you were quite clear. You're like, I don't have the bandwidth to do that, even though I was asking a favor, and it wasn't, I wasn't offended by it. I just actually really appreciated the honesty uh about what you guys could do from a quality standpoint. So, you know, I I'd like for you to dig into that a little bit because I think from an expectation management standpoint, a lot of MSPs fall into the trap of saying that they can get stuff done in order to try to drive new revenues, generate business, move their company forward in some way. And I feel like you do in a lot of ways that if you're not setting expectations properly, you're not creating that very beginning kernel of trust, which needs to run through the rest of the relationship. So, how have you guys really adopted that strategy into your core values as a business, what you guys do to manage your accounts, to bring on new clients? Like, how do you manage expectations with new opportunities? What does that look like?

– Trust is earned through budget and transparency.

SPEAKER_02 18:27

Curious thing. It's taken me years, and I'm still not great at it with terms of new business and saying no, because I just want to help people. I started this to help, right? Um, it's not revenue generating, and people keep seeing our prices going up. And I'm like, I have to do that because you know, we're trying to produce amazing outputs, but there's only so many hours of a day. Um, running a consultation company is the hardest thing I have ever done because I had no idea and still really don't, how to run a consultancy company. And what I'm actually really saying is I don't really know yet how to sell time for money. Right, because that's in essence what it is, it's a one-to-one relationship. So setting expectations for us is is super critical in everything that we do because I go in with the mindset of, well, I just don't know what I don't know. So when I launched this years ago, month-to-month contracts were what we did and we still do, because I was very open, like, I don't know where this is gonna go in 12 months. I don't know if this is manageable, I don't know if the price is right. And we're very open about that, right? When we're taking on a project for a client, we budget it and we will die by our own sword because I'm gonna say to you, Andrew, what is this piece of work worth for you? Right? What do you want to spend on it? You might go a thousand bucks and I go, okay, and we'll sit down as a team and go, if this shoots over budget by double, triple, quadruple, is that worth it to us? Are we learning something from it? Right? Can we reuse it for the client? And you know, we don't just steal the work we do for you, Andrew. It's not what we do, but you know, we'd have a conversation. And a lot of the time MSPs go, yeah, sure. Right. Um, you know, we've got some work on at the minute, and the client goes, Can you automate this thing? And we're like, I don't have a clue how long this could take. It could take five hours, it could take a hundred hours. Like, I I don't know. Like, what's your budget with it? And they're like, Oh, you know, just go so far and then circle back in. But at the very beginning, we've been transparent about that. What we don't do is just start down this road of going, yeah, we can do it. Get$3,000 in, and you go, where are we at? And I go, Ah, we're close. And then get to$5,000, and then people go, Ah, we're nearly there now. Because you feel like you've been suckered, right? Um, and that's all our engagement with our partners kind of go on that. You know, I said to you at the start of this call, trust is a core for value at Merida. Um, and trust is earned, right? You have to earn trust. Um, our partners invest in us every month by paying us, right? Um, to deliver um products or outcomes. Um, and we have to build the trust that we can do that to their budget. Um, if if we start going over budget on tasks that we've scoped for and it costs them, well, they won't trust us to do any more in the future, therefore the foundations of what we're trying to build have been broken down. You may not know this. Um our internal target, our ceiling of full is there's four of us consulting or doing consultation work. Um divide that by three, so hours in a week, our target, our ceiling is 33%. If we have uh a client, you will commit to four hours a month with us. We therefore commit to four hours a month for you in terms of work we can do. Um, and we cap our ceiling at 33%. Um that for us is full because we may go over on certain tasks. We're still learning. We need time to learn how to do the thing you want. And we shouldn't you shouldn't have to pay us every time we need to learn.

SPEAKER_00 22:04

So you had talked to me about the ambiguity trap, right? And how you set expectations with your clients and what you recommend to MSPs about setting expectations. What is the ambiguity trap? What does that look like for you when you see it? And how do you steer clear of it? And how do you advise your MSPs to steer clear of it when it comes to how they're managing their internal processes or they're handling their clients' relationships in regards to how you're getting your system set up to support that? Like what does that look like?

SPEAKER_02 22:41

So to kind of spin it, I see the ambiguity trap on the output. Right. Like we're engaged by MSPs to help solve problems technically. Right. An example could be, I don't know, um Connor, we we keep having client servers go offline, right? How do we build alert in throughout of hours engineers so we know when they've gone offline, right? I spin it on its head and go, why are they going offline in the first place? Oh well, we didn't patch them, why not? Because Andrew forgot to patch it, right? I then, you know, I taught myself out of a lot of work, honestly. It's kind of a problem I have, but you know, I I want to help. But for me, it's it's about I I call it looking inwards, right? So whenever there's been a problem in in IT that I've dealt with as a manager, right? Because I've managed all my career basically, I go, what didn't I give my team to solve that before it was a problem? Right? Was it training? Was it clear expectations? Was it process? Um, was it permission, right? Was it ownership? A lot of the time, if you don't give ownership, people think, well, it's not my problem. Um and very much for me, it's it's looking inwards and trying to remove any ambiguity. I'm quite black and white as a person. Did you tell this person to check that server on Wednesday? No. Then how would you expect them to know to check that server on Wednesday? Right? Is a is a s is a super, super simple thing. Um, so for me, the ambiguity is is it surfaces on the output for me because that's where we get dragged in. There's been a problem, there's been a crisis, there's things not working, how do we fix it? And a lot of the time I have to ask people to look inwards, right? As bad as that may sound. And I'm like, well, how have we got here? So in answer to your question, I think um, in terms of identifying it, it's always a little bit too late. Because something's happened to get there.

– When process kills ownership and creativity.

SPEAKER_00 24:36

Yeah, I I I I totally understand where you're coming from. And I think part of the root cause of some of that ambiguity when it comes to managing teams within a small business, I won't particularly say just MSPs, but within any company, right? You have people who are special. And those people are entrepreneurs. For whatever reason, they are built differently. They are very good at what they do, they are passionate about whether it's helping people, building technology, doing something. Uh it could be a bit tailor, it could be whatever. And when they start to grow their business, they bring people in to help them to continue to make this business special. And as an example, they'll bring a service manager in and they'll say, Well, why didn't why didn't you look at those servers? And they were like, I didn't know I was supposed to. And they're like, I can't believe this. I don't know why you're like, like, and what I've had to continually remind my clients of is your employees aren't you. If you're a manager, if you're an owner, that you have to realize that you're wired differently than some of these folks, and that if you're anything other than completely clear with them, it's gonna be really hard for them to know what you want. It's rare that you find somebody that thinks like an owner that will work in your business. If you do, you've got a special person. But otherwise, you have to really, you don't have to spell it out completely, but pretty much is the way I talk about it. It's like you won't, you don't want to remove their ability to be thoughtful and strategic, but you certainly don't want to leave any room for misinterpretation of what your expected outcomes are. Um and I and I think that that balance and being able to tell an owner how to do that, and then having them create processes and whatnot so that they don't eliminate their team's ability to work as a team, to understand things kind of at a higher level when it comes to building out outcomes. I think that's the real skill in management is understanding how far you take that. But I really liked a post that you had had put together, um, I think it was yesterday, about too much process leads to like unfortunate. I I think it creates some ambiguity. It creates a lack of really being able to think because you've eliminated everybody's ability to make decisions because you created too much process. So how how have you been seeing that play out in your clients and within Reneda's business? Like, what are you seeing there with that?

SPEAKER_02 27:16

I think a key point that you kind of touched on then was from an owner perspective, right? If I was to hire someone, and we have this now with our internal IT Renator, I'll be honest, it's a bit of a mess. Um, we don't have clear ownership, right? What a lot of us do in technical is, you know, I hire someone in to manage the servers. And we don't always tell them what we expect, but we tell them how we expect it, right? In the form of a guide or a SOP, right? So rather than me saying, right, you're responsible, Andrew, for servers. I expect them to be up 24-7, I expect them to be patched, I expect a handful of things, it's now yours, you own it. What we do instead is go, okay, Andrew, every Wednesday at four o'clock, you log on to the server, you make sure, and we we end up building all these guides and all these processes in place that people have to follow. The problem you have with that, and the post last night about bureaucracy was if you follow that guide and it still isn't patched, who's to blame? Because the owner will think it's you because I've given you ownership of the servers, Andrew, but you'll think it's the owner because you didn't say in your guide that if the server's not on, I have to turn it on, right? To be facetious here. I think when you're in we see this across certain clients we've got, um, and we're trying to steer it, but when you have so much process, everything that you do is wrapped in process, that becomes a blame game. You didn't put it in the process. You didn't tell me I had to do that if this tangent came about. You remove the ownership layer and the accountability layer because people are just doing what they're told to do. Whereas if you step back a little bit, I think a good leader does this, step back a little bit and set expectations clearly, what good looks like, right? I think this is a fundamental failing that every business does, really, right? What do we expect good to look like? If you give somebody that and say it's yours, you typically, with the right person within the company, and that's a whole debate for another day. But if you've got the right bums on the right seats, um, you get way better outcomes because of that whole accountability piece. And because you've set clear expectations on what the outcome needs to look like, that person can do their own plans or guides or whatever they need to make sure their inputs are correct to deliver on those outputs. Um and I know I use them words probably a little bit too often, but for me at Reneda, we're doing tasks all day, every day. And the one bit of the business that has spent ages to refine and get perfect is scoping of tasks, setting those expectations right at the beginning. What are we gonna do? What problem are we solving? How long is it gonna take? How much time are we spending building versus documenting versus handing back? Because once you know all of that, you can make an informed decision. I could just say it costs you a thousand dollars. But then when something starts to go awry, that's when I think worlds come tumbling down because there's just a complete lack of a trust, but B, no one knows where to stand really.

– The Escape Room exercise: Seniors vs. Apprentices.

SPEAKER_00 30:17

What you say tracks, because I I was fortunate enough to go to a leadership conference once where they had some, I think they were Navy SEALs, um, you know, the American badass, you know, super soldiers. And one of the training things that they talked about was that they really focused on what the objective of the mission was versus following orders specifically to the letter. And the example they used was there was this group of people that were supposed to go to the top of this building and they were going to secure the building, right? So that they could then be able to get line of sight on a specific road. That was their objective. So the outcome was get line of sight on that road. And they were told to go to the top of this building. And when they got to the top of the building, uh, they realized that there wasn't enough cover for them. So they knew what the outcome was. So without having to go back and ask for permission, they just went down to another floor, secured that floor where they had cover and they were able to uh uh fulfill the objective. So that was something that we injected into our process systems a lot, which was let's talk about what we're trying to get accomplished here. We're gonna come up with a framework for how we're gonna accomplish it. And if you have to deviate from that slightly, that's fine, right? Unless there's something that, you know, you've got these out-of-bounds areas, don't do this specifically in order to achieve your goal. But you do want to make sure that you've got an understanding of what the outcome needs to be and setting that outcome. So to your example, your goal is to make sure that these servers have an uptime of four nines, right? Therefore, if the server's not on, maybe you should turn it on, even if it's not explicitly written in the SOP, right? I I feel like that's a really misunderstood part of process development and training for individuals because if you're focused so much on the process and not on the outcome, people put blinders on and they don't think about what they should be doing. They think about what they have to do. And I think that removes critical thinking skills, which are, I think, frankly, more important in our industry than any other, other than maybe being a doctor uh in our industry.

SPEAKER_02 32:32

And it kills not just critical thinking, but you know, creativity as well. Um, I ran some training um years ago um with a technical team I had where um you're familiar with like escape rooms, right? You go into a room, solve puzzles to get out. Um I did an exercise where I paired all my engineers together based on level. So apprentices, level one, two, three, senior engineers, and basically put them on separate tables. And it was escape room themed, basically. The idea was to log into the computer and tell me what the uh home page was on the browser, right? So it was stupid things like no fuse and a plug and the password was a very basic encryption underneath, and just stupid stuff like that. Before I started the exercise, the aim was, or I thought the outcome would be the apprentices would finish first and my seniors would finish last. And I thought that because my seniors have been with me for years, and I thought they would overthink it, right? Did the entire exercise and it almost played out perfectly. The apprentices came second, the level ones actually came first. Seniors didn't even think because one of the seniors was a good friend of mine at the time. He knew I was into cryptography at the time. He thought this cipher I did was some crazy crypto thing that I'd, and it wasn't. It was just I think an up arrow was an uppercase and down was lowercase, left was like back a letter, and right was forward a letter, right? So a B was an A or a C, whatever. It was super simple. Um, the point of the ramble, though, there is when we look at teams and look at solving problems, the higher up the ranks you go in an IT company, the more you learn about the problem and the more guides you've followed and the more processes you've done. So a simple problem, you always go to the nth degree of, right? I can't log into my computer, it's DNS, right? I've learned by doing this link. It's always DNS. It's always DNS, right? And you learn this kind of by, I don't know, almost like you're kind of indoctrinated in a way, right? Because it you've been stung so many times down the line that you the process could be to check DNS. Whereas someone that comes in fresh can't log in. Well, that's the question are you typing the right password or is caps lock on? Right? And I think when you're doing tasks and telling people they have to do it in such a certain way, almost the more senior you get or the more times you've done it, you stop looking outside, you follow your blinkers, right? You follow what's directly in front of you. Whereas someone that's new or fresh or hasn't done this will typically ask why a lot more, right? Which is great for certainly creative thinking. Um, and I I generally feel that if you are complete blinkers on, that is great for people who you don't want to think about the outcome. If you need to put a door on, right, you need to put hinges in a certain place, that is perfect if the hold is square, right? If it's not square, you need to start thinking about it differently. Following a guide to fit that door is never gonna work.

SPEAKER_00 35:32

Well, what you wanna be able to do is create some sort of framework, right? So like there's a there's there's a difference between my my my former service director used to tell me that he would tell his team that there's a difference between a process and a framework. And that a process was something that you had to follow specifically, whereas a framework was a general guideline to getting something done. I think that level of nuance can sometimes be lost on an immature organization because we're so driven by knowledge base and SOPs, right? Like we've been we've been basically spoon-fed for the last 20 years that you have to write specific processes and and and and outlines for things that, you know, these knowledge base articles for things that need to be done. Whereas a knowledge base is like, here is what we know. It's knowledge. Here's what we know, here's what we think you should be focused on. Versus the, I would say the knowledge bases are even more framework-y and open-ended than SOPs, right? So I I see the difference. I don't know that there's a good way of solving for those differences because I feel like the one thing that managed service providers try to do that that I agree with, but I also feel can be a detriment to them in the long term, is we as managed service providers want to create a consistent quality of service over and over and over again so that the end users have a very um repeatable experience every time that they work with the service delivery team. And by creating rote processes for everything, then they think that that's the way to get it done, where I think that there is some variance in the way that people solve problems because you're dealing with humans, right? And so I very much see that there's a difference between going to McDonald's and going to a higher-end restaurant where you have a waiter who helps to account for variations of the delivery of the outcome in order to drive a better experience. So I think that there's a balance there where you have to figure out how to train people to know what processes have to happen. And then they help smooth and fill in those gaps in order to create a better experience. And I think that's where people are losing their way in the MSP space because they're so focused on these KPIs, these outcomes, like get the door hung, get 50 doors hung, right? But then you've got clients that are coming to you with all different sizes of doors, right? And want one to open one way and one to open another way, and one's got a window and one doesn't. They have all these things that they need to do. And they're still using these KPIs to measure whether or not you got these doors hung. And I think they're using them, you know, as you had mentioned before, they're using them kind of as a whip rather than a, you know, as a as a punishment to kind of hold people accountable w rather than trying to measure what these outcomes are.

SPEAKER_02 38:34

I think it's really hard, right? Because, you know, we get asked all the time about like dashboards. Can you build me a good dashboard gunner? I'm like, I can build your dashboard, sure. But what are we solving with it? Because if I just give you 50 numbers that you've got to make green, what is that talking to? Right? A bit like SLAs, right? What does an SLA tell us? Well, it's a window of time, right, that we're gonna do something in. It doesn't tell us about quality. Doesn't tell us about happiness of the client. It just says that we ticked a box, right? I'm gonna respond within two hours. What's the quality of the response though? Right? I'm gonna solve it within four hours. Okay, but I could solve them all in four hours and they all get reopened again. But if we're looking at this metric, which is resolution versus, you know, CSAT or quality or reopen count, which is more important, we're not addressing the problems that exist in front of us, is a long and short of it. Um, a bit like that crappy, really a door analogy. Once we give people these processes to follow that are really linear, as soon as we have to divert from them, depending on who you are as a person and depending on what the recourse is, right? If you normally get chastised for not following the process literally, then you don't want to go off piece a little bit because I'm not allowed. Or last time I did that, I got shorted at. So then you end up pushing it back or escalating it, and you end up with the post last night, the whole bureaucracy post, right? Where if you put in too much process in and people are blaming each other because of the process, you can get a real hostile work environment, a really poor culture, because we are not setting expectations correctly on the outcome, but setting expectations on the input in this side, saying you must only do what I tell you to do out you're doing it wrong, which I don't think helps anything, really.

SPEAKER_00 40:20

So my question my question to you is how do you make that balance? What is the balance that you strike when it comes to setting expectations and generating outcomes and balancing what those outcomes are against the processes for the inputs? Because I know that that's gonna come up. People are gonna say, well, listen, I love what you have to say, Connor. Very academic. How do I apply that? What does that look like in my business? What does that look like if I'm configuring my PSA? What does that look like when I'm developing processes inside of Hudu or whatever it is I use? How do you explain that to your clients? What do you tell them? What's the advice?

SPEAKER_02 41:02

So multiple things, really. So I love processes when something is repeatable. And I don't just mean kind of repeatable, I mean repeatable. Onboarding a user is a very repeatable process. We have to go through the same hoops, do the same things every single time. There might be some variance in job title or, you know, mold, but it's exactly the same thing. There's a process for that. And the good thing is about that process, once you nail it, you can automate it. All right. That's kind of where we're going in industry now. So when you're looking at SOPs, really, it's really, really highly repeatable things. Alternatively, the other times I think like guides or SOPs are really useful, is very bespoke things, right? Let's say I look after I don't know what it was. It was kind of a like an energy plant, but they used cow shit. I don't, I can't really remember what it was. Like they just took manure and made energy from it. It was a long and short of it. Um, their software was crazy. It was written by some Spanish development firm 20 years ago. You had to do things in a very certain order, else it would just not work. Um, and if it didn't work, you're speaking to someone in Spain on their time zone for thousands of dollars an hour to try and fix it and everything was just crossing your fingers. A guide needs to be in place for that. Right? You cannot deviate. Problem solving, though, incidents, if you will, stuff coming into the desk. Well, what does good look like? Is the client happy at the end of the call? Do we need every problem to go and try and find a guide that may or may not exist for a problem that may not even be the same? It might present the same. The client can't send an email, but how many guys do you want me to check before I give up? Right? Before I I call it, you know, no good. Um so I think when you're trying to really ascertain how far you should go with a process or how far, or maybe you should start a process, I think you should be asking about the repeatability of it. How much can we, or how often do we repeat this thoroughly from end to end?

SPEAKER_00 43:16

And then people are gonna start asking, well, that sounds like a really good way of approaching it, because then I can use AI to do it for me. And I know you've got an opinion about that because I don't know that you know I think you and I agree in some regards is that AI isn't gonna solve every problem on the planet because it's not built to do some of the things I think people have been told to believe it should do, if that makes sense.

SPEAKER_02 43:46

I get really hung up on it. So, like we're seeing loads of AI in the space for inbound of tickets, right? Let's say incidents again, where AI is presenting the resolution or the perceived resolution based on the tiny window. With data it has, right? The problem you have with this again, you know, going 360 back to expectations is what are our teams supposed to do with that information? Are they supposed to blindly follow it? If they don't follow it, but it was the answer they chastised because they could have done it quicker. What what are we asking of our staff here? Why did you follow that guy? Why didn't you research it yourself? Well, I thought I was supposed to follow the bot. I followed the bot, I've taken the server down. Why did you follow the bot? Like, I feel like you're adding such ambiguity to like what they're supposed to do because it's presented with a perceived solution, right? This is my concern with it. We don't really put this in place for anyone because I don't quite understand how to deliver it without causing damage. What is it? Is it a helping hand, is it? Like, I don't know. Like, you could argue, well, they could go to Google and make the same mistakes, but when you go to Google, you're asking the questions to try and find the answers to something you need to know. Whereas AI is giving you what it thinks you the answers are to questions that might not even be in front of you.

SPEAKER_00 45:06

Well, and I I think I listened to a a really interesting podcast recently where a gentleman was talking about the future of AI and education of the workforce. And his position on it was AI can be really good at eliminating these rote tasks. Update the status of the ticket, make sure that you've got a contract attached to the ticket or agreement, however you use it in your PSA. Like all these things that we expect our technicians to do, the PSA should be able to do a lot of that work. So what does that mean? Well, you've eliminated basic task level work, the stuff that a process is good for, like check this box, do this, do this. His position is AI is not going to eliminate education. AI is going to exacerbate the need for education. Because if you're not teaching your staff how your business works, what your outcomes are, how to critically think, when AI eliminates all the task level work, you're going to be left with a bunch of people who only know how to do tasks and they're not capable of making those decisions. So I think that what you're saying around how do you set expectations, how do you drive strategy and thought process into what you're asking your team to do actually lines up really well with what that gentleman was saying. And what I'm really kind of starting to lean towards, in my own opinion, of what AI is going to do for the workforce. It's not going to eliminate jobs. It's going to change the function of jobs to eliminate repeatable process rote task level work and require people to actually think for the first time in some of their careers.

SPEAKER_02 46:59

We did a series on AI the first time and ever since this came out, just before Christmas, around how you could use AI in your MSP, basically. And there's not a lot that I think you should be using AI in your MSP for. We have AI auto triage, right? It can rename the summary of a ticket, it can set the right categories and give it a priority. People ask me how valuable that is to an MSP, and I'm like, like, it's great at catching P1s a bit quicker if you've got loads of tickets sat that I haven't been looked at for an hour. Like categories are great, I guess. Like, do you report on categories now? No. Then what pollen is it fixing, right? Um, I was quite I'm quite data driven, so I use categories loads in a former setting, right? It was the the way I made decisions, basically. But we had a mature team that was taught around it and we leveraged it and we set expectations and all of that, and it was a part of our language, right? A lot of MSPs don't care about that, which is fine, you haven't got to. Um, but you know, on an inbound of a ticket, for instance, AI is uh fine, right? It's average. Um, I think AI for me is just really good at gathering loads of data together, is a long and sort of it. Like taking, we use it for recording transcripts, right? You can take loads of data and summarize it great. We use it for account management, you can look at loads of different ticket data and put it in a nice paragraph. A lot of the things you're seeing with AI at the minute that they're really party tricks, really, are algorithmic by nature. Uh, what I mean by that is is we used AI to auto-schedule all of our tasks into our diary, right? We gave it all of our appointments, we gave it the time and the start date of the task, and we threw it at AI and it would pick the best slot and it would do it, right? Problem is, it would every day mess up. It would put it over another task. It didn't consider you had a lunch break there, and it was failing over and over again. We rewrote it fully with JavaScript, and it has been flawless ever since. Because it's very simple. When can we do it is a fixed parameter. How long does it take is a fixed parameter. They're all fixed inputs. Therefore, we don't need AI to tell us when to do it because we already actually know this. AI is great for POCing, right? Without trying that with AI, we probably never would have got here because we don't know JavaScript. And AI helped us to write, I'm gonna say some of it, all of it. Let's be realistic here, right? Who are we kidding? Um, like AI is great for that, but I think, and I say this all the time on various podcasts and chats with people is what isn't what makes a good MSP, right? The service we provide to our clients. I've never had a client in any sector go, be really good, Kunef. When I ring you up, I've got an AI voice assistant and I could spend 15 minutes arguing with that before I could speak to you. No one's ever requested that, right? No one wants that. It's great to fix certain problems, like booking a flight. If you want to change a flight, I don't need to wait and hold for half an hour to speak to Dave. If I could do it via a phone assistant, fantastic. If I could securely reset a password via it, a whole other debate for another day, fantastic. Certain things it is quite good for if you can trust it, right? Which is a whole, again, another debate. Um, but I think, yeah, what are we, what are we trying to solve, right? I always come back to this, like what problem are we trying to fix? And this is why I think this topic today around expectations is so hot for me at the minute, because I'm all the time getting dragged into conversations where if we just looked at what the problem was and actually set better expectations at the beginning, we'd have way better outputs nearly all the time. That's without using AI or any other fancy tooling, just simple human conversations and simple clarity can solve a lot of problems we have in not in our industry, just in life, honestly. If in in so many walks of life, if they just set better expectations, you'd be so happier, right? You'd you order a takeaway and they say it's going to be half an hour. If they told you it was going to be an hour and it came a little bit earlier, you're way happier with that because they set better expectations. Um, it's not unique to our sector. It's just a recurrent problem that if we spend a little bit more time at the beginning could massively help us all down the line. Or at least I that's what I feel.

SPEAKER_00 51:21

No, I I agree with you 100% because I believe that trust is the key to success for any service business, whether that's restaurant hospitality or whether that's managed IT services. If you set expectations through your marketing and then you fulfill those through your sales process, setting additional expectations that are fulfilled by the operations team. The operations team is managing expectations through their account management. And you just create this perpetual opportunity to generate goodwill with a group of people to help them achieve their goals. That's the most important part of what we do. We are, you know, MSPs, TSPs, whatever you want to call us, services the middle name, you know, the middle word in every one of those names. So I agree with you 100%. I think the challenge that a lot of people have when it comes to providing service to kind of take it all the way back to expectations and why they're important and why it's a challenge is I feel like there's just a lack of wanting to say no. People are just really wanting to make the client or the other person, you know, their teammate, whatever, they just want to make them happy because that's why they got into this. They got into it to help. And I think that's the challenge of knowing to say, when I set expectations, it actually benefits both of us and it makes us both feel better rather than just us saying yes. And I think that's where MSPs really struggle is where do they start? Where do they begin the process of trying to set expectations? Where do you see MSPs really needing to set those expectations when you're in Halo or you're working with them on some sort of a process development project? Where do you see the need to really dig in and say, man, I wish I just started setting expectations here? Where does that typically happen when you're working with companies?

SPEAKER_02 53:19

I think it's with their own internal team. I think it's with the staff you've got. Staff you already got employed, right? The people around you. Does everyone know what good looks like? I had this debate a lot with MSPs. This person in your sales team, or this person on the project team, or this person on second line, do they know what good looks like? And I don't just mean we've hit all these dashboard numbers that are green, because it doesn't mean a lot to us. It's not a visceral reaction when there's a widget that's green. It's not like, yes, I'm nailing it, right? It's I'm not gonna get shouted at. It's the reverse, right? And I think it's it's yeah, what are we what are we trying to achieve? What does good look like? And just my head's racing a little bit just because it's funny. I've never really connected the dots before. Something he said a minute ago really resonated with me about AI. I think my frustration with AI is you can't clearly set expectations with it. Like you tell it what you want and it may or may not do it. No matter how what guardrails you put in place, um, it will just not do it. Right?

SPEAKER_00 54:20

Like that's so I talked to a developer friend of mine. I'm glad you brought that up. He says that's a feature, not a bug. AI is developed specifically to create this illusion of creativity and interaction. And so, therefore, variance is something that's built into it by default, which is why you found so much more success with creating a script to execute something versus allowing AI to do it, because without guardrails of application management in the way that AI processes information, it's built specifically to do exactly what frustrates you about it. Like that's that's your problem.

SPEAKER_02 54:58

No matter what controls, like there's something called temperature. I compared AI a lot. You can temperature like zero is don't be creative, a hundred or whatever the parameter is, is be free, right? You can temperature zero and lock that in and say, never do this thing. And one day it'll just go, ah, screw it. Right? Like, I'm gonna do that thing anyway.

SPEAKER_00 55:16

And that's I've done that with prompts. Like I've told the prompt I was like, do not do this. And then it did it, and I went back and at some point I start yelling at my AI, and I'm like, why did you do this? And it's like, oh, I'm so sorry. Yeah, yeah, no, I totally did that.

– The power of letting go and saying "no".

SPEAKER_02 55:31

I had it today. I was I was doing some book tracking on on the app we have, uh you trying to use the MCP server again. Just look at the bugs and telling what's going on, and it was like uh billing issue and people using it without subscription. And I'm like, what in the like I was like to AMI? I was like, how have you because it's looking at all the logs, right? I was like, how have you discerned how have you figured that out? Like, what you're telling me I'm looking at on this screen going, they don't my children, oh, the hypothetical corner is what there could have been there. And I'm like, Jesus, what are you doing to me? Like I'm sitting here thinking I've got non-paying subscribers and errors coming out. It's like, no, looking at your code, this is what could have been the errors. And I'm like, geez, like I just I nearly had a heart attack this morning, about half nine. I've come in, cup of tea, I just you know, have a look at a few errors from last night. The minor for what it's worth, absolutely load of crap. But um, yeah, it's like, oh yeah, unsubscription. And I'm just like, and it's like, oh, I just assumed, right? Um, and I think the anecdote, right? Um, or whatever it's called, of you know, assumption makes an ass out of me and you, or you and me, or however the hell it is, um, is I think that's where, you know, going back to your question about what problems do we see a lot, it's that assumption layer, it's that assuming, it's that, and we call it expectations, call it whatever you want, but as soon as you start assuming someone's going to do something that you want to do or the way you would do it, you're in for a really rough day, especially as an owner, right? Like, I care way more about my company than anyone I employ ever will. And you have to be realistic with that. Um, I was at an event a few years ago and someone said to me that the best thing you'll do, Connor, is stop expecting people to do it the same way you do it. As soon as you let go of that, you'll grow more as a person or grow as a company, or you know, whatever you're trying to do will will be freed up. Saying no is exactly the same thing. There's so many great analogies for saying no helps you grow or whatever. I'm gonna butcher them. Google them in your own time if you're out there. But there's there's so many things that, or so many people, so many analogies, which is saying no helps you grow, that you have to start believing it. And only by doing it do you actually understand what that means. And I think what it means a lot of the time is um, you know, I follow a lot of tradespeople because that's a hobby of mine for some reason. Um, and the joke is they always like price up something too expensive not to get the job, right? Rather than just saying no. Um, can you fit a bathroom? Oh, it's gonna be a nightmare. No, I'll do it for$10,000. Suddenly you get the job and then you're in this world of hell. You're four months overdue because you don't know what you're doing. You never wanted to do it in the first place. Like your team are screaming at you because you they didn't know what you were supposed to do, and you could have just said no. And it's not about saying no and suddenly your bank account gets massive, right? That's not it's not it doesn't, it's not a direct correlation, but it's happiness within the team because you know they're doing things that you agreed you were gonna do, right? Um, I think one of the biggest things we see in large MSPs is a big disconnect between the sales team and the engineering team, right? Things are sold that we can't do, right? Because that there's that disconnect all the time. And just by being really clear and having real clarity on what you do do and what you are good at, when you start saying no to things you're not good at and focusing on the things you are good at, everyone within the business is happier. Your sales team can sell it better, your support team can support it better, your finance team can reconcile it better. As soon as you start doing something completely abstract because the opportunity was there, the entire business crumbles because you've all got to now figure out how to sell, buy, manage, support, whatever it is you've sold that week, basically. I think comes back to your question.

SPEAKER_00 59:12

And I think to that point, there's two points that I that I want to drill in on just real quick that I that I really liked that you said. One was letting go, saying no. I see that one of the things that I also learned in that leadership course from the Navy SEALs was uh it's better to get 60% out of somebody autonomous of the work that you could do at 100% than for you to have to continue to do that work. Because at some point you can get them to get to 80% or 90%. Your first time around, they may only get 60% of it right or accomplished the way that you would do it. But they'll start owning the process. And that's how you start building a team around you and you start creating opportunities for people to learn and grow. So you have to be able to say, that person's never going to be as good as me at doing that one thing in that one way. But they'll get there if that's what they're focused on, and not me trying to do it and do 16 different things at the same time as well. So that that's a really important aspect of of what I think you you just said of being able to let go. I think that's well the irony is the way you think you do it, that probably isn't the best way either. That's a that's a true point. And I think that I don't I don't know if that was in the article that you posted, but I think s no, I think it was something else that I read recently said um when a company has an owner or a leader and they are the best at what they do within that business. That's that scales up to about a hundred people. This was their their hypothesis. If that person is still the best person at everything in that business at a hundred people, they'll never get over a hundred people. They have to have people that are underneath them that are better than them at sales or better than them at operations management. Because once you start getting to a certain size, that that thing that you were just talking about, which was my second point, with these creating processes and expertise of skill between departments, that's where I see the most trouble with an MSP. What we start to see is you can be really good as a smaller MSP, but when you have departments and then you have to span work between departments now that you've created a sales group and an operations group, where there that issue that you get between the two teams is because there's not a clear understanding of a process that has to happen in order for sales to do something that operations can fulfill. So you get this thing that I call pig tossing, which is you take this big gross thing and you throw it over the fence and hope the other person can catch it. Um, I think that that's, in my opinion, where processes become really important. I think that that interdepartmental communication, interdepartmental work, I think is the key to where you should maybe start looking at putting processes versus creating frameworks within departments so people can think autonomously. But if you have to move that work between different groups, I think that's where maybe a process might be better served.

SPEAKER_02 1:02:28

Really interesting then, some actual icon of advice, I think, here. When you're doing that exercise and you start asking those questions, you need to make sure you're asking what MVP is, or what the smallest barrier is, or the smallest thing you can do to achieve that. Right? An example being if a client needs a new laptop and the sales team needs to buy a laptop, what is the minimum amount of information the sales team need to deliver on that? Is it just rough budget and timescale? Is it rough budget vendor and timescale? A lot of the time we see because we're in an industry of built around guides and FAQs and SOPs and all of this, we go, okay, well, the technician then must provide the RAM, the CPU, the operating system, the due date, the budget, the 54 things, then you bottleneck the business. Because the inputs on the technician, which have never really been employed to do sales, now have to think about every single tangential variable to be able to get the sale to the sales team. So what happens is they either don't do it or it sits at them for a week. So when you're trying to build any process between even departments or any tasks you're doing or anything really, what's the minimum we need? And if you flip it on his head a little bit, to get the outcome, the laptop to the client, what does the client need to answer? What do they need to know? So I think when you're starting any process, and I'm a big believer of, you know, um, it's an American app in a match. They keep it stupid simple, is it? Or keep it simple, stupid.

SPEAKER_00 1:03:55

Keep it simple, yeah, keep it simple, stupid.

SPEAKER_02 1:03:57

Keep it simple, stupid. I learned this, I learned, claimed that very well, but I heard this years ago and it really resonated with me. Because everything I do, it's how simple can we make it? I'm obsessed with like simplicity in everything I do in my entire life. Because as soon as it's really simple and repeatable, it gets done way more accurately. As soon as something's really abstract and really complex and really complicated, there's bound to be loads of errors, it's bound to cause friction, it's bound to cause frustrations. And the end goal could just be a laptop for$500 and you know, people lost their minds for two days over it. Um, and I think the companies that, again, going back to the very beginning of this call, transition into Halo, they're going, how how clean, how easy, how simple can we make our business? What are we doing? Monitoring security, monitoring patching, helping clients. Let's focus on that and do it really well and really easy. So we can divert more energy into, I don't know, AI or automation or whatever the other fun stuff we want to learn is.

SPEAKER_00 1:04:56

Well, and I I like what you said about, you know, that specific example for a laptop. I see it in a in a when I look at processes, I've really become accustomed to looking at things from theory of constraint, which is work in, work out, where are the bottlenecks, bottlenecks being a requirement for a system, there will always be them, right? They will always exist. So where do we want to put the bottleneck? And so when you look at a process like that, when you talk about simplifying it, you have this issue where a technician has to figure out what does this client need in order to achieve this outcome of purchasing this laptop and have all these, I have 15 different decisions that I have to make versus taking that decision point, which is your bottleneck, and moving it to another part of the process. So, what we would recommend to our clients was you sit down and you go to the client and you said, We've got two laptops. There's an admin laptop and there's an accounting laptop. And here are all the specifications that you're gonna go ahead and make the decision that we're gonna do 80% of the time. So we don't have to bottleneck it with the tech. So now we've eliminated that friction of being able to wait for that. To happen and the sales team can just show up and say, pick one of these two options that everybody's already agreed to, back to setting expectations. And you already know from a client perspective, this is how this should work. This is about how much these are going to cost. And any deviation from one of these two assets is going to require a custom build, which will then move to a two-week turnaround time because they're going to actually have to have an engineer involved to look at it to figure out what I need. So I love that analogy because I think that sets the table for the idea of how do you use process to set expectation and how do you take work that could be better used in a different or could be better served in a different part of the process. How do you move that work so that you eliminate friction and create higher capacity in certain areas of your organization or higher throughput, I guess?

SPEAKER_02 1:06:47

Yeah. And my my post on LinkedIn last night basically said, you know, we we built a process six months ago. We had a BCO in. We sat down, we went through every single nth degree, every single thing, every tangential variable. And we built a process in, and it was this monster of a workflow in Halo. And it was marvelous to look at, right? Took months, hundreds of hours to build it. Ruined us as a company for three months. Absolutely ruined us. Because everything was wrapped in process. Nobody knew what good looked like at the end. That wasn't the question anymore. It was, what have I got to do to get to the next step all the time? I've got to escalate to you, you've got to review it, I've got to go back, Connor's got to do this. And it was just like we just become robots clicking buttons to move the milestone one step further. And it was horrific. Like it literally ruined us because the question was, and you know, going full circle is no one knew what the expectation was of them other than to click the next box because there were so many boxes to click to get to the end. Because I thought the problem was actually output. When it wasn't, it was input. It's typically, from my understanding, typically always input. Um, I was too focused on why didn't we test this thing properly to have now five test procedures and four plans and how do we know what to test? Well define it at the beginning, as opposed to just saying, can we test it? Right? Like a very simple thing, clarity at the beginning, make sure it's tested. And if you don't know what that looks like, ask for help from a colleague. But I tried to, and again, failing on me, we learn, predict all these outcomes and all these tangents by dictating what I wanted the outcome to be. That everyone who was doing the task or doing the thing failed to ask what good look like, failed to remember that we're trying to help a client with a problem. And instead, it was this big arduous process of really passing the book, if I'm being honest, you know, blaming each other. Well, Connor never typed in this box that you wanted the test strategy to be this. Well, but I didn't write that up last night and it's changed. And you end up just cycling through documentation and notes and SOPs and guides and all the time to almost not be called out for it failing, right? And I often call it the enterprise way. An analogy I can make with this is loads of small businesses don't have many like HR policies, right? You can go on holiday whenever you like, Andrew, right? And then one day you take the piss and you ring in a day before, and then there's a policy you have to book in a week in advance. And as companies grow over years and years and years, they get all of these policies in place because one person might have done something a little bit off piece that ruined it for everybody else, right? I'm now always trying to be really mindful of that in every interaction we're doing with clients, with our own internal stuff, by saying, is it an anomaly or is it we just never set expectations correctly at the start? This is why this has happened as a byproduct of it. Is it unique to us as a business? Is it individual? Is it a training problem that actually I just need to sit down with Andrew for half an hour with before I put in this new way of working for the company?

SPEAKER_00 1:09:43

I I think that's an amazing place to wrap things up today. Um, I I'm really excited about the conversation that we've had. Um, so thank you for for your time. Um Connor is an expert at process management and integration of technology systems into managed services groups and beyond. And so I'm I'm glad that he was here. Um we have one last thing to do, which is I'm gonna ask you a few questions, uh, if you would be so kind as to answer them as honestly as possible. Um what is the best book that you ever read that helped you in business?

SPEAKER_01 1:10:21

So uh I can't read books. Okay.

SPEAKER_02 1:10:26

I have never read a book um in my entire life, which um I didn't tell you ahead of time because I thought it would be quite fun. Um spoke about earlier, I recently got diagnosed of ADHD, which answers the question as to why I can't read books, because I will read a paragraph and it will disappear from my head. Um I've never done, I can't do, I've never been never done any tra I don't have any any any no certifications, no degrees, can't struggle to sit through training, never read a book. And I think just to summarize the the hour of chat we've had, a lot of it for me has been learned through feeling and getting feedback from teams and clients as to what has or hasn't worked. So in terms of the best book, I I physically it's it's been a frustration for mine for 33 years until recently as to why can't I sit down and read a book? My brain doesn't allow me to do such things.

SPEAKER_00 1:11:16

So let me follow up on that. How do you how do you stay on top of things? Like what do you, what, what do you do? Because there's I'm sure that there are other people out there that are like, awesome, like I'm struggling with the same thing. Like, so how do you stay on top of stuff? How do you know what's going on with the industry AI? Like, how do you even know how some of the you know stuff should work when it when it comes to interacting with with putting processes and systems together? Where do where do you where do you educate yourself? How do you how do you learn things?

SPEAKER_02 1:11:47

So I am, I would say 99% of my learning has been YouTube for my entire life because it's been around me growing up. I learned to do uh networking by Eli the Tech guy, if anyone knows him from years and years ago. Um, I watched every video of his endless times on domains and forests and you know, VLANs, and I'm I learn visually and then by doing. Um so for me, I I keep up to date by every night watching YouTube for hours in bed and just being hungry and curious.

– Worst sales calls and the "Bellend" explanation.

SPEAKER_00 1:12:19

That's awesome. And I've heard very similar things from people. I'm uh I did not grow up with YouTube, so to me it's it's been super helpful in a lot of ways because I can watch somebody do it, so I'm like excited about it. But my first I'm old school, my first is like, where can I go read about this? So I have to try to find a book somewhere. But YouTube's been invaluable for I'm sure everybody that has ever been a network engineer in the last like 20 years. Like it's been a big help. So that's cool. Super cool. All right. What's your favorite curse word?

SPEAKER_02 1:12:53

Yeah, so I like curse words that can be used interchangeably for things that are good or bad. Okay. So my I don't even want to say my okay. And it's the C word, and I'm not gonna mention it. I'm not gonna drop the C word. It's a heavy word, right? For me, if you say it with intention, it's a really powerful word. Um, no ambiguity with it. There you go, set expectations. When you use the C word, you know exactly where you stand with it. Um and that's that's why I like it. It's that it's it always gets a visceral reaction no matter who you use it on, no matter what time of day it is.

SPEAKER_00 1:13:27

Um is there, I'm gonna ask, I'm going off script, but I want to ask you because I don't often get a chance to interview someone from another country. So is there a which wouldn't be super because I know that some might be that wouldn't be like super offensive. Is there a word that you use in the UK, like bollocks or something? Is there something that you guys use that you're just like, this is my favorite like local colloquialism, like kind of catch-all for a curse word? Is there one that you you like there that you'll kind of use?

SPEAKER_02 1:13:59

Yeah, I got one for you.

SPEAKER_00 1:14:00

Yeah.

SPEAKER_02 1:14:00

I don't know if you guys would use it or not. Uh so we use like bell end as a very common term.

SPEAKER_00 1:14:06

No, I don't know what that is.

SPEAKER_02 1:14:08

So you are a bell end, can refer to as like dickhead, right? Uh but yeah, bell end, there you go. That would you would hear that a lot in the UK if you're getting swore at. I wouldn't use it in a in a fun way. Um but yeah.

SPEAKER_00 1:14:26

All right. Learn something today.

SPEAKER_02 1:14:28

Um I hear using it now. Yeah.

SPEAKER_00 1:14:31

It's gonna it's gonna be built into my vocabulary. Um who's your favorite band or musical artist and why? What what are you who do you like?

SPEAKER_02 1:14:40

My favorite band's a band called Antishikari. I've grown up with them as like the 2000s rock punk emo type phase. I've listened to them for yeah, 15 years plus now. Um I was almost gonna name my son after them, but I turned out not to have a son and had a daughter instead, so we had to pivot. Um, we were convinced my second child was gonna be a boy, but a girl popped out. We didn't find out it was a surprise, we just mentally got it was gonna be a boy. Um, I was gonna name him after the lead singer, but we didn't. We had a girl, so she's called Renee. So yeah, Bangkok Enter Shikari. I like the band just because they're diverse. They've changed genre throughout the years, a bit like what we're to do in our sector, right? We have to be nimble, we've got to be quick on our feet, we've got to be on our toes. As you mature, you change the way you run your business or what you care about or what your values are, right? They shift with age. And that band, I think, for me, has just grown up with me and has have shifted and changed not to fit the mainstream. They're not a mainstream pop band, but they're just, I don't know, they're just fantastic.

SPEAKER_00 1:15:43

So you said they're like kind of rock, punk, parent, like are they like paramour? Like where like where do they fit in to like where where would they fit in? Like on the like what would be more of an equivalent kind of big name artists that people might realize like know that that would be equivalent to them.

SPEAKER_02 1:15:58

I don't know where they would position these days, if I'm being honest. Um yeah, similar to that paramour era, they were definitely about that paramour era, there's kind of like rock heavy streams.

SPEAKER_00 1:16:07

You're like rock emo, and I was like Paramount like kind of more like I saw them live. They were really good. They put on a great show if you're into that.

SPEAKER_02 1:16:14

Yeah, they were at the same festivals as them, basically. Uh a little bit more edgie, I guess.

SPEAKER_00 1:16:18

Um I mean I love punk music, so I'll have to check them out.

SPEAKER_02 1:16:22

Check them out. I'll link you afterwards.

SPEAKER_00 1:16:24

Love it, yeah. I need it because I'm gonna put it in the show notes, so definitely send me a link. What's the worst sales call? And you don't have to name names. What's the worst sales call? Client meeting, personnel meeting. What's the worst experience you had dealing with somebody at work? Like, what is it?

SPEAKER_02 1:16:42

I've only had one.

unknown 1:16:43

Okay.

SPEAKER_02 1:16:43

Which might sound crazy, right? Um, again, on topic today, my pricing's on my website, you know what you're paying for. My funnel is YouTube first, you know what you're getting. If you get through price and liking me, you know what the call's going to be about, right? It's again, I I hate ambiguity. You've kind of probably got this from this call. I hate the unknown. Um, kind of goes in my anxiety. So I had a sales call once and it was passed across to me, and I didn't know the person. And I said, no, I'm not interested, right? Because this is why I hate referrals as well, because they don't know me at this point. So I have to sell who I am as opposed to with my funnel, I'm just telling, well, finding out what pollen I can fix for you. So I got a sale passed across to me. Started the call with standard Connor, right? Forgetting he doesn't know who I am by any stretch, which might seem really arrogant, but that's just, you know, most people have spent 20, 30 hours watching me on YouTube or listening to my shit on LinkedIn, right? So like you kind of, you know what you're getting. Um, and was just saying to him, you know, this is what we do. And he was like, I want to do it on my own. And I'm like, well, I want to consult in this company, so I I won't do that. And basically the guy just shot the call down and basically said I'd completely put him off the product. He was never going to buy it again now. It was the worst call he's ever had, um, and just went in on me basically for 10 minutes. I ended the call with him, um, cancelled my entire day because he just completely threw me. Um, rang actually uh head of EMEA Ninja Sales and a guy called David at the time, um good friend of mine, and rang him and was like, because he you know did works in sales, I was like, how the how the fuck do you deal with this? Like, I can't do this, right? I'm too, I don't know, I just want to help people, right? And I was just trying to be honest and like, you know, buying this product is really hard. It's gonna take a lot of hours, but that's where we come in to help. So you don't have to waste all your time. It's like, you've insulted me, I know how to do IT, and you just didn't get me, right? Um, and basically what what David said was um, you don't know what has happened in their day leading up to that conversation with you. Their dog could have died, something bad could have happened, their partner could have left them, and you was just an easy avenue to vent. And you can't let it get you. Um touched wood, it's never happened since, it won't happen again because I'm a bit more aware of understanding people don't know me, which again sounds really arrogant, it's not how it sounds. Yeah, that was just the biggest shock to me. Like the guy hated me and it was a shame because I just wanted to help, right? Like, I don't, you know, we turn business away. I'm not trying to like power sell or aggressively lock people in. I'm just trying to just help with the problem if you've got it. Um so yeah, that that sucked at that. Um ruined my entire day. But we learned from it.

SPEAKER_00 1:19:25

As long as you've learned from it, like I think a lot of people will just be like, people are assholes, and so you know, that guy was just an asshole. But I think it's it's one of those things where that's some of the best advice I think I've ever heard a partner give another partner, which is, hey man, sometimes people are just having a bad day and you you got the shit end of the stick and I'm sorry. But because some of the that's true, I've I've actually had I've had situations where things didn't go well and there was a some back and forth, and then someone called me a couple days later and they're like, hey man, like I'm sorry. Like I should I this was what was going on with me. And I was like, oh, yeah, that or I was dealing with somebody at a client and they came in on me and I escalated to the owner of that business, and I was like, I don't, I'm not gonna be okay with this person talking to me or my team like this. And they were like, listen, this person's wife just got diagnosed with cancer, or you know, their kid was in a terrible accident. Like, and you're just like, oh. I mean, it doesn't necessarily make it right, but it also helps you to understand that like it's not always personal and people aren't always just you don't lose faith in humanity as much. You just kind of realize like everybody's got their own stuff going on.

SPEAKER_02 1:20:35

Well, it's a great summary to this call, right? And it all comes back to expectations. If you're really clear up front with your expectations, then I think you'll have a much happier life, right? In that situation where I've I've seen MSPs where their engineers are getting abused by end users, basically. And I'm like, I wouldn't. There is no way I would ever allow that at Renada. Um, I would be in there on a call within minutes, and my team know that. So my team are trusted in that. They expect me to handle that. Um, so yeah, I think it's people can be shit, right? I can be shit. You know, I wake up grumpy some days and I'm not the best me, right? Um that happens, and I think, yeah, being aware of that is helpful. I see a lot of LinkedIn posts about people emailing and swearing at people. I'm just like, yeah, I could get it though. Like something like 94 sales emails, it's really frustrating, right? It's it's how you take it is you know, offense is taken, not given, right? A lot of the time, but you can certainly imply it. And I think that sales core with me. I think you wanted to make me cry, certainly is what it felt like anyway. So yeah, it's a tough one.

unknown 1:21:40

Yeah.

SPEAKER_00 1:21:41

Well, thanks for sharing that. That's great for everybody to hear how how you got perspective on it. Um well, just to kind of like wrap up here, I always like to know if there's someone out on the channel that I should talk to that I haven't talked to yet or that you might recommend. So is there a person out there that you think would be great to share their story or something that somebody's been coming to you with that you're like, man, you should talk to this person because they've got a real unique perspective on stuff. Like, who do you who do you recommend people check out? And maybe I can entice to come talk to me for a few minutes.

SPEAKER_02 1:22:11

So um I'll I'll shout out Chris. So Chris is our factional coup, VCOO, whatever you want to do it. I reached out to Chris a couple of years ago from Ethicai. Um, he he loves reading. Um, I actually use Chris as my source of books. It's a running joke. Like, just give me the highlights, right? Of like this thing you've learned. Um, he's he's geek. Where I'm obsessed with technology, he's obsessed with business, right? Okay. And just for everyone today, I'm not telling you I know the answers how to solve all these problems, right? It's I'm just trying to make you aware of these problems probably exist. And these could be some ways you might try and approach them, but I'm no business expert. Whereas Chris has, yeah, um done the research, walked in those shoes, I guess. It's very ops-heavy. Um, read every single book about how to grow business and what doesn't work and what does. For me, I'm more reaction-based. I've felt it, I've learned by failure really. So I we work with Chris, have done for a few years. He's kind of keeps me sane and level-headed um and helps me on the operation side where I'm most inexperienced because I'm leading technical teams. I never ran a company before. So yeah, I I'm shouting out Chris today from Ethicai.

SPEAKER_00 1:23:21

I love that. And I'm and what was Chris's last name again? Chris Cook. Chris Cook. Um, I think it's I think it's refreshing to hear a leader in the in the channel that says, I don't know everything and I rely on other people to help me be smart. I think that that's a really great lesson for a lot of people to to to take from this conversation today, which is you may not know everything, so you should probably find people that do. And I'm hoping that uh that that message resonates with folks because you know, coming back to full circle, setting expectations where you're like, I may not know everything, but I can certainly find somebody who can help us, I think is the crux of what a great service delivery team does, which is just to say exactly we may not have been great at it. We're experts at it, but we'll figure it out, right?

SPEAKER_02 1:24:11

The best saying is you just don't know what you don't know. Um I use it all the time, I overuse it really, but it's true. And everything I do, I'm almost quizzing myself of what don't I know about this? Like, where am I gonna get stuck and what's gonna trick me up, and then that's where I go and seek help, or that's my team, or you know, um I say we all grow or fall together at Reneda. Um, a lot of decisions we make are as a collective. So yeah, if we're doing something we've not done before, we agree with it as a team, as a collective, and we jump in. Um it doesn't work out. Well, we all had our input, we all tried, and we'll fall together, luckily. Um touch wood today, that hasn't happened, but you know, it's it's we do it as a as a company, so yeah.

SPEAKER_00 1:24:56

I love that. I love that. Well, Connor Fagan, thank you so much for your time today, and I look forward to continuing to watch great things out of Renata and continuing to work with you with our clients to drive outcomes. So thanks again for being here.

SPEAKER_02 1:25:11

Cheers, Andrew. Thank you very much. Cheers.