#MSP Service Manager Cohort: We Love Service Managers AMA

Whoa, holy—

we're here, we're doing it!

Woo! Man, are you nervous? I'm nervous, I'm nervous. Just, it's, it's funny because I remember starting my career back in 2004, getting a service manager title at Best Buy corporate.

Like, that was a—

that was the The, the cornerstone of me having what I now know as a career and now being amongst all of these service managers, all 50 people that are currently here and 180 that have registered. I think it's time for our voices to be heard.

It's amazing.

I, I can't believe it. Um, and then for all of you guys that are here, uh, we are extremely humbled and excited. We don't know what this is going to become. This is our first ever one, and we're gonna try to make a commitment to make these routine and stay accountable to having all of these and having all of us stay strong and find a way to where we can work with each other because our jobs are probably some of the least predictable. Awkward silence by Todd. Todd's eyes are moving.

Oh man.

Okay, yeah, good. Just got a window got stuck in the, in the way when I hit record. All right, yeah, technical problems.

Well, anywho, man, I think it's time that we get going because we got a lot of, we have a lot of chatter going on. I love seeing we've— Ty, we got a lot of Canucks here.

I know, it's awesome, right? Gotta represent Frosty Canada.

And well, today we're not going to be sorry about anything because if there's one thing I've learned about service management is there's, there's never a right answer. There's never a, a correct decision. We are always living in the gray area.

Yeah, it's definitely something we're going to get into is, you know, the, the— I love the expression lately, the obstacle is the way, right? And just the foundational element of like, as a service manager and as an operations leader, you are a problem solver. So don't be upset about the problems you're presented. Those are your challenges. That is your job.

Oh, and so I think, Todd, before we get going, right, and, and as we made it punny today, right, this is going to definitely turn into a cohort where we're going to share, and I want you guys to participate, and I want to hear your opinions. Because if there's one thing that I have learned about, uh, the leadership world for all people that are here is, right, that we live in the gray, and living in the gray means that We're never going to have the right answer, and the right answer could be right today but could be wrong tomorrow. And I think that's going to be an important lesson that we're going to continue to hear is there is no best practices when it comes to leadership. There are no best practices when it comes to working as a team or developing your team, because there's one thing people aren't— people aren't logical like our computers that we manage.

It's like my favorite expression about project management is it's as simple as who does what by when, and then you add people and it gets really messy.

Yeah, so Todd, tell us a little bit about yourself.

So those that don't know me, run a consulting organization called Evolved Management and helping MSPs to build more profit with less stress. Just kind of taking on the history of my career and coming from the technical world, getting sort of forced to push into operations and a bit begrudgingly, but found out I really loved it for the same reasons that I loved solving technical problems and as sort of a constantly a puzzle to tinker with and figure out and make changes and keep on iterating until you find a solution. I ultimately found that managing people and process and the operations of a business was much the same, right? For all the reasons that you like tinkering with computers and experimenting and trying to find those solutions, as you kind of noted, like you live in the gray and doing that, that level of experimentation. And then when you finally lock that last piece of the puzzle in and magic starts to happen, people's careers start to accelerate, the team comes together, the culture starts to accelerate. It's amazing. It's incredibly addictive to be able to have that type of impact on an organization. So that's what I love to do, is help other people kind of unlock the secret sauce for a lot of those things and try to accelerate their career and help everyone else around them.

Right on. And I guess just for people that don't know me, My name is Kyle Christiansen. I've been in the IT space now for about 18 years and primarily in the service leadership role. And unlike many, many of you, I never had a chance to start off in Tier 1, 2, 3, and so forth. I got thrown right into, hey, here's a bunch of employees, and I'm a 15, 16-year-old kid, and they said, hey, figure it out. So I had to go through my own journey of managing up, which is going to be a common topic. And I started to really build an obsession. So I actually turned around 2 MSPs from 2012 to 2017, 2018-ish as a hired integrator, hired service leader, manager. There's so many words for it. COO. And then I actually created a consulting firm for MSPs, Sierra Pacific Group, back in 2018. I co-founded that. So through a lot of these mechanisms of being able to mature MSPs, one of the common tactics, and I hope I can get each one of you in the Service Manager cohort one of these. You know, accountability became a real big theme in how, right, we get our teams to grow and function. So with that being said, I don't know what happened, I'm pushing too many buttons here inside of Crowdcast. Uh, let's go ahead and get that deck back up because we want to have a couple quick things. Oh, oh man, where's the button for this? We're still getting used to this. And let us know, guys, if you like this platform as well, because this This is a democracy. This is an open forum. We would love to know that. So just so you guys all know, we are going to have another session in April. So let's be accountable, guys, and I'm going to go ahead and put the link inside of Crowdcast to sign up for the next session. Get it on your calendars. One of the number one tools as a service manager that you can employ is time management. So we know that if we block this off right now, we add it to our calendar. There's a good chance I will be able to make it. If you just write it down on a sticky note or you put it in your phone, I can guarantee you some tickets gonna get dropped on your board. Your boss is gonna say, hey, hop in a call with me and we're just going to miss it. And the only way that this succeeds with all of us is if we all together join. Anything on that, Todd?

Just a simple hack. Like if productivity 101 is you don't find time for anything, you make time for the things that are important. So, let's make time for this right now and agree like your calendar is probably busy this week. It's probably busy next week. Is it busy 4 weeks from now? Probably not. So, make that space now.

Exactly. And Paul Blake, "My owners bought an actual cattle prod for me when I was promoted." There's a fun quote by I think it's Patton where or maybe it's Eisenhower of if you push a string, it goes nowhere. If you pull a string, it follows you. And that's something maybe to keep in mind as we go through this, as while herding cattle is fun, leading sheep is a lot easier.

So deep.

Uh, on that note, guys, we are actually going to have a live board. You probably saw it in the email. Let me go ahead and add that question. It has an upvote mechanism. So this is where we're going to put a lot of the questions. We're going to build the topics. I actually have a few people in our community right now that I'm gonna bring on stage with us at some point to help us answer some of these questions. Because again, as service managers, everyone's gonna do something a little bit differently, and it's learning how differently you can handle one problem that gives us more tools in our toolbox of soft skills and people management. And I think we have Jordan Silva and Dean Trimpelis possibly Wes Spencer. We'll see if he sticks around. We'll see if we can put him in the hot seat. But I look forward to bringing those guys on stage. So where are we starting with this, Todd?

So we're talking about keeping with the Valentine's theme. Let's talk about some things that you need to fall in love with. So I kind of alluded to this of the role of operations, your chief problem solver. Chief people person, chief people builder, process builder. And how do you do that? So we wanted to point out a few things that you need to fall in love with, really just to sort of underline the idea around what should you be focusing on. And this is something I see people struggle with a lot in this role, especially people that have come from a technical role, individual contributor, and are, you know, in a lot of cases unceremoniously promoted into a service manager role because they're either like the most tenured employee, or, you know, they're the most reliable person, kind of the right hand to the owner. And it's like, hey, I'm really busy. You seem good at this. How about you take over the team and figure— help them figure out how to do the rest of this. So I see people really often struggle with, you know, what, what are the things that I do need to focus on? And this is kind of a list of those things that are going to be important for you. So first, really easy. I think most people understand this, the tactics are sort of unique. I don't think we should dig too deep into what those exact kind of metrics are because it'll vary on different circumstances. But metrics of things to fall in love with is certainly one of them, right? So how are you measuring what you're trying to achieve in your organization? So if it's just subjectively, I think we're doing great, that doesn't really get you very far. If you're able to say, I think we're doing great and here's some data to really back up that feeling, then you're marrying that subjective and objective experience, which is really, really crucial. So however you're measuring metrics, you should be doing it absolutely understanding and trending to understand if you're getting better or worse at what you're trying to achieve as a team. Okay.

And that might actually be an interesting thing because one thing I've noticed in my years is we use that subjective and objective term so freely. And I, one thing that I've noticed in my own ability to teach people, sometimes we forget to just explain the very root concepts of those. Can you give me some examples of objective versus subjective management?

Yeah, so, um, uh, one I often sort of call out here is the subjective experience of, uh, being told as an individual contributor, I need you to do better. And it's just quote unquote better, like, what does better mean, right? Like, that's a subjective experience of, like, uh, whereas an objective experience is, uh, your target is supposed to be you know, an SLA response time of 80% and X number of tickets closed per day and X percentage of utilization. That's objective measures that doesn't really lie or have a different interpretation. And this is where people can kind of get into trouble is I have a feeling about things. I think that this is true. That's a subjective experience. Whereas the objective is there's, there's, there's sort of a rationale or there's a number that we can point to that is independent of our opinions or perspectives.

Right?

Because I may feel I'm working hard, but are you achieving the results that are expected? That's the difference between subjective and objective.

And I can tell you right now, we've all been in the predicament where someone uses a subjective statement to say, "Hey, you need to do this," or "You need to do that," or "I didn't like how you did that." And us as individuals, as contributors, we get upset. I mean, I remember back in the day, I would tell my Tier 2 engineers, just because I didn't have time, or I would be lazy with my analysis, right? Like, hey, we need to close more tickets. And you give them these very brief instructions. And what do they do? They ask the magic question of why, why, why? Because there's an intellectual ability to where if I'm going to be motivated by something, or I'm going to help you take care of a problem, I need to know the root cause, right? I need to be convinced that this is the right nature. And Well, and I know we have some conversations. I know one of the anonymous questions that got motivated or got upvoted the most was about motivating your employees. One of the easiest ways to motivate your employees is to elaborately and objectively explain what we are trying to accomplish. Start really getting black and white in communicating the goals that you are trying to march towards and allow them to contribute. To how they can accomplish those goals, right? I was going to write an entire LinkedIn thing about the subjectivity or the damningness that you can cause on your business by exaggeration or just not clearly stating the goals of the company or the department, because it's so easy for us to say everyone's networks suck and everyone's environments and none of our employees are happy. But it does nothing for us, right? There's no way for us to now contribute to the resolution of that problem.

Yeah, 100% agreed. And I think that lends really well to the next point of the people. Like, the, the people are how you get things done in an organization. And this is another one of those fundamental things about being a service manager or any type of operational leader in any business in particular. But, you know, we're talking specifically MSPs, is, uh, you know, how, how you're measured as a leader in an organization is the effect effectiveness of your team, not you as an individual. And that's again, one of these things that you really need to comprehend and internalize that the harder you work is not the measure of your performance. It's, it's the effectiveness and the contribution from the individuals. So your point, I think, Kyle, I absolutely agree with of being really diligent and clear about what the expectations are. When people's fingerprints are all over something, it makes it harder for them to sort of fight back against it. So draw them in and get them to contribute to that. That's a great way to lead with positivity, right? Like, we all agreed that this is important and we all agree what we're trying to achieve this. Like, I'm not standing here kind of whipping you for 99% utilization. We agreed this is what we're trying to achieve. And if we're not able to do that, let's openly talk about what's in the way. Let's remove those roadblocks together because we agreed this is important. So that's where you sort of lend from positivity. And I describe this as a service-based leadership mentality. Or it's an inverted pyramid, right? So you're— the CEO is basically at the bottom and trying to serve all the people up, uh, above them. And that's a really important sort of way to understand this, is how can I help you, how can I contribute to your success, not I need you to do these things. It's not dictatorial, it's you creating the environment and the platform for people to be successful around you.

Well, and I think there's also a— and I, I kind of put a post on LinkedIn today about this where listen to your team. If they know what the goals are, you do not have to be the answer person. If you ever read The Five Levels of Leadership by Jim Collins, he talks a lot about the level 3, level 4, and level 5 leader, where the level 3 leader is the person that starts to develop a team that contributes, and the level 4 leader is the one that now starts to create clear vision. But the level 5 leader actually steps back and becomes the dumbest in the room because they're able to leverage the genius and excellence from their team. And where a lot of us get into time management problems, especially for us that have been tier 3 engineer promoted to service manager, is we've always been expected to be the answer guy. But to be a successful service manager, I have to rely on my people and my results are the results of my people. So I can't individually lift the entire service department on my own shoulders. And what you find is as you dictate more and more and more, the motivation of your team actually goes down and down and down because they are unable to contribute to the solution, right? They're just being dictated to and say, do it my way or the highway. And I can tell you, for all of you as service managers, the last thing that you don't like is when your business owner or the CEO or your COO of your MSP tells you how to lead your department. So why do we then go and do it to our teams?

Yep. Agreed. All right. So finance. This is another area that is really important to fall in love with. And Kyle is absolutely in love with this. So Kyle, I think you can, you can let her rip on finance. Go ahead.

So yes, I, at this point guilty as being the CFO a little bit.

Wow.

I clicked the wrong button, so I don't know how to get you back on stage. Uh, there we go. Oh wow, man, pushing too many buttons. Um, so with that, Todd, really where I fell in love with the finances of an MSP was I was able to quickly use it as an engineering tool to a lot of the problems where I got misaligned with the owner of the MSP. Because what I found through a lot of conversation and mistakes was a lot of decisions that the owner of my MSP were making was because there was a financial consequence that they were becoming very insecure about. They had to be, and they lacked the vulnerability to say, hey Kyle, I don't want you to make that decision because payroll go up will go up and money will actually come out of my pocket. And for many of us, and I, I have the research to show, a lot of MSPs aren't making a lot of money, guys. We may see, oh, we're making $3, $4 million in revenue. But in a lot of cases, I think last year Service Leadership showed the average net profit was like 3 to 4%. So you got to think, that's where a lot of owners are paying themselves. And what I found was that if I was to obsess about the finances, is that I was able to now lend an alternate solution to the owner that I was operating with to say, hey, if I do these steps, it will cost this much money, and then that much money should save us this much money. And when then communicating on a wavelength where the owner would go, okay, so we're going to spend a little bit, right, one step back, but we're going to save a lot in the 3 or 4 months. So I'm going to be able to make more money, which will eventually pay off that deficit that allows me to get what I need as a service manager and allow them to not have money taken out of their own pockets, which is already not as much as we may feel as service managers that aren't involved in the finances. So I had to do a lot of research. I had to go learn how to read a P&L myself and balance sheet myself, and I had to start getting obsessed with Excel just to model, hey, if our revenue's here and we need to have a margin of this with our service product, what would that take? And I'm not gonna lie, guys, it, it, it was a painstaking process because no one ever teaches this to service managers. So when I started to take on my own MSP, it— the very first thing I taught all of my engineers was how we made money. I taught them how the MSP made money, what margins we expected, what being a service business, not a system administrator, and how those differed. And that way, if we ever had grossness about things like timesheets or charging a client too much or any of these topics, they already had the data to understand what the goals of the company work. And if they didn't like them, then they just didn't like the goals of the company. And that's an okay situation. If they don't like the goals of the company, right, I can help them find a job that they're going to like. But as a service business, we have to make money so that we can be paid fairly. We can have all the rad benefits. All of those things get consumed when you actually look at the business finances. And we can get super detailed. And if you're interested, put in the chat, we can do an entire— oh, again, I'm clicking the wrong buttons. I, I, we, we can do an entire Service Manager cohort session just on the finances of an MSP, and I can actually show you guys P&Ls of MSP and the decisions that I would help make based off of the service department and the margins they're taking. So if that's an interesting topic to you guys, let me know in chat and we can put that on the books.

Yeah, I think that's a great one, and this is, I think, a really, really important one. And I think also like to call out one of the things I see as a limitation around this is a lot of the owners are often quite cautious to share financial data with a new service manager. So I really encourage people to have sort of this conversation, at least to talk about percentages if they're— if they don't want to share sort of an open book with you. You know, Jack Stack, Great Game of Business, check that out. It's open book management style is also excellent. But if you're not sort of to that level, the percentages is a really important aspect because then at least you can have sort of intelligent conversations and it's not caught in sort of the making up stories between each other of like, oh, the owner's cheap, he won't, you know, get more staff. And it's like, well, I don't necessarily believe more staff is necessary because maybe efficiency is low or utilization is at 40%. So how can I justify adding more staff? Maybe, maybe we're working on too many useless things and it's a signal-to-noise ratio. We should do less and that would actually help us to be more efficient. But if you're explaining these things around our target margin is, say, you know, at least kind of 50%, right? Best in class would be up to 70%. That's not a target that everyone should be trying to achieve, but at least kind of shooting for that 40 to 50% as a sane margin for your business. That way, if you say like, okay, we can hire 2 more people at T3, but all of a sudden now our profitability, our margin, our gross margin on service drops to like 35%, 30%, right? Like, that's— we're getting to an uncomfortable territory that we're not willing to sort of make those decisions. So can we hire one and sort of figure some things out? Those are the types of conversations that you need to start to have. So you're having sort of these transparent discussions rather than just sort of, you know, a disagreement about what the reality actually looks like.

No, totally. And right, and going back to one of our questions about how to motivate employees, right? One of the quickest ways to demotivate them is not pay them, you know, standard living expenses or not giving them that inflation raise every year. And a lot of that comes because as service managers, we may spend more money than we are able to make as a company. So we need to be strategic enough to go, hey, if our costs will increase 5% so we can give employees raises, then either we need to increase our margin 5% or increase our pricing 5%. 5% in order to pay for those raises. So if we are not aware of this, that where we are in this entire journey, then there is no way that we can motivate our employees by giving them those fair raises and bonuses. And we'll get to bonuses in a different situation. But this is where going into that motivational state is we have to have a finger on the pulse or we're going to spend it all on, like you said, stupid tickets that really only improved maybe our client experience a half a percent, but it made us feel good as technical experts, right?

All right, so challenges. I, I've noted this one a few times. I don't know if we need to sort of get too deep on this, but like, just for me, it's quite simply the fact that, uh, I, I encounter a lot of people in management, and especially in a technical industry, that are really frustrated by the, the number of, uh, just sort of quite frankly, bullshit that they have to deal with day to day. And they get incredibly frustrated with the impediments in their road to sort of getting towards the end of the day. And quite frankly, like, this is a part of your job. Chief Problem Solver. However you do that, I think that's a process that you need to fall in love with and figure out like, yes, this is a challenge. Yes, this is a problem. What can I actually do about it? And I think maybe one of the foundational things about this is The Serenity Prayer is understanding the things that you have some level of control over is really, really important here. Right? So, coming back to finances, you know, you would like to make a particular decision for the business. You don't necessarily have full control over the books. So, is that a practical ask? Maybe, maybe not. But once that decision is made, you need to move on. Right? And just sort of grumbling in the background and, you know, potentially commiserating with staff around things that are or aren't happening is really, really destructive. Right? So you need to understand what are the things that I do have control over? You have control over the prioritization of your team's work. You have control over potentially some of the stack alignment within your client base. You have control certainly over your time. And I think that that is often misunderstood, is you have a lot more control over your time than you probably think. You just need to be proactive about it. And if you're finding that, you know, everyone's time is continually sucked away by team and Slack DMs and escalations, like those are your challenges to solve. Like, how do we reprioritize? How do we reengage conversation so that it's less pingy, right? We're creating space for these conversations to happen. We're creating an escalation process that doesn't involve everyone at every hour of the day. These are the challenges that you need to solve, and understanding the ones that you have some control over will help you to reduce a lot of that inherent stress level of just like, oh my God, there's just so much to do. It's like, okay, yes, there is. Pick a problem, work with the team to start solving forward on it.

Right.

And, you know, I really want to bring, I think, Jordan on. I think he would have a good finger on the pulse for this topic. So Jordan, I'm going to bring you on stage because I know that when you did RejectionCon, you did a great conversation about challenges and some of the things we need to level up on at MSPs as we're leading large teams. So I would love to hear your take on new service managers trying to deal with challenges.

Yeah, for sure. I think that, you know, I think a lot of people underestimate the influence they have. Like Todd was kind of talking about it. So you feel like because you're new, you don't really have— like, you can't unilaterally make decisions that impact the organization, but you can kind of be the end of chaos for your team. Like, if you have, you know, an owner who's maybe a little erratic or going out and doing all kinds of stuff that causes chaos, and that's usually what people are freaking out about, you often have the ability to slow that down and sort of not let the storm hit your team. You can absorb some of that and, and break it down into problems that they can actually solve and focus on goals that get us out of that problem long-term. And, you know, really just slow down some of the noise and say, okay, you know, we know there's a lot going on, but let's break it down. How can we fix this? How can we address this as a team? How can we kind of take these big— I mean, big problems like, hey, everybody feels overworked— and really examine why. And like you said, pick the things that you can influence influence, right? It's, it's, I think, probably one of the most important roles of a manager is sort of just being that, that umbrella, right, to shield everybody from the storm and say, okay, there's a lot going on out there, but, you know, in this team, here's how we're going to handle this stuff. Yup, we do have to increase gross margin, but I'm not going to yell at you to just say, go get me 8% more gross margin. I'm going to say, here's how we're going to tackle this. We're gonna, you know, we're each going to tackle one more ticket a day. We're each gonna, you know, try our best to make sure these problems never come back once we solve them. That way we're redoing work. We're going to, we're going to make these very tactical things for the teams to consume. And I mean, kind of, Kyle, what you were talking about earlier, I think that goes back to making people happy, is understanding that the work they're doing has a real long-term net impact and they're not just on this ticket treadmill, and they kind of see that they can make a difference with what's going on and then calling it out when it improves. Like, I think people are really bad at seeing subtle improvements over time. They're really good at seeing pain, like when something happens and it hurts, they're like, man, this sucks all of a sudden. But when the pain disappears, it kind of falls back to status quo real quick. So as a manager, you have to highlight that and say, hey, remember last quarter we were buried, everybody was really unhappy. I heard you all making jokes again today. You know, the meme count in Slack is up 10%. Like that means people are happier, you know.

So I would love for you, for Todd and Jordan, you guys to go over One of the questions that we have that got 7 upvotes. So I want to hear your guys' two takes on this, which is, I am getting interrupted constantly during my day. How do I balance trying to be available for my team while also making time to get my own tasks completed? Because Jordan, you're bringing up a lot of things that consume time, but I can't get a minute of my day to allow me to work on any of this crap, let alone go to the bathroom, let alone get my lunch. Let alone take a deep breath. You're saying go watch these videos and read this stuff and talk to my people, but I got a server down on aisle 3.

Yeah, I'll kick it off. I like this, like one of my favorite quotes are sort of littered around here, right? But the important aspect of this, I think, is one of the areas that I feel people really make a mistake in is not running regular one-on-ones on a weekly basis. This is your solve for this, and it's the dividend investment that reduces the pingy nature, right? And part of this is training the team. It's what I talked about before is like you're constantly DM'd, then train the team of like, we don't send each other direct messages. And I was talking to somebody about this the other day. Think of the human equivalent, like the real, the IRL equivalent of sort of DMing someone a question. In a lot of cases, like you literally walk into their office, like you're not just sort of like knock on the door, you walk straight into their office and you're like, Hey, when you're thinking about this, can you do this and do this thing? Like, we can chat about this later. And then you turn around and literally walk away. Like, you don't, you don't stick around for that conversation. It's a crazy way for us to try and engage with people. And I think where this comes from, honestly, is a lot of people just want to— they have something occur in their head, they need to ask someone something, so they'll write a quick DM and send it or post it in a Teams channel. And then everyone is sort of habituated to respond to that, right? Like, I hate You know, my, the little indicators of an unread message. I need to solve those and close those out. Right? So, we need to train each other of like, we don't just sort of ping each other whenever we're having a thought. We want to contain these things, put it on an agenda. This goes into our one-on-one agenda. This goes into our Teams meeting. We silence some of these, you know, channels, and we only look at them when we're doing some type of review. So, spending 30 minutes with your team members and having them consolidate a lot of these non-urgent but important questions into that agenda is a great solve for this, right? I think that, that is a big piece of this. And then the other piece of what we talked about is like you need to control your time and book meetings with yourself that you're not constantly overriding with something else. If you booked a client meeting and just didn't show up and told them, oh, sorry, you know, someone asked me to help them with this ticket. So, you know, I just didn't make that meeting. That's effectively what you're doing to yourself by not maintaining that. So some of my thoughts, Jordan.

No, I think that's spot on. But also, like, from a tactical perspective, one of the things I tell a lot of my leads to do is just say, I can help you in 15 minutes, or I can't, and just habitually tell people you can't help them right now, but you can if they put something on your schedule, if it's really urgent, or yeah, throw it on the issue list, right? A lot of shops are running EOS, like, hey, if this isn't urgent, throw it on the issue list. And also making sure you're doing that even for group chat, like group channels, because the way I try to explain is it's really unfair to make team decisions when not everybody is in a place to participate.

Participate.

So if you start going down this road of, hey, we need to standardize on something, and 4 people are busy on issues and they can't contribute to that conversation, you're really taking away the team's ability to, to actually put thought into something and to contribute their perspectives by arbitrarily picking a time to discuss it rather than doing it in the place and time where everybody agreed they're going to make decisions, which is our, our weekly team meetings or one-on-ones and things like that. But, you know, I think pushing back a little, but also empowering people to make mistakes sometimes. Like I go on vacation or I go to trips or conferences and like the last thing I tell my team usually when I leave is just do whatever makes the customer happy. I can deal with the rest when I get back if it's that critical, right? Like anything that makes a customer happy, like the downside of that is almost always financial and that's easily usually recoverable, right? Like I can get back and whatever they did, as long as they didn't really upset and ruin a relationship, most of the other stuff is pretty easily fixable. So empower your teams to just do stuff without you. Yeah, that gets rid of a lot of that.

And Jordan, I appreciate you hopping on. There's a great— I don't remember, I got to find the episode and I'll see. I was trying to look for it and it's a podcast called Founders Journal where they talk about asynchronous communication versus synchronous communication, where things like Slack and Teams, we think of that as asynchronous where I can just drop something and walk away. But a lot of times we use it as a synchronous communication tool and we type something and then we sit there and wait for an answer, right? And it almost becomes a longer period than it would just be to do a quick phone call. And the whole idea of the podcast is sometimes we have meetings when it could have just been a memo. Sometimes we have meetings when it could have just been put in an email or a Loom video, right? Because you're really dictating. You're not trying to have a collaboration or conversation. So we do these things that end up consuming so much of our time because we're not disciplined in owning our time. So kind of like when we started off the show, hey, add it to your calendar right now. If those one-on-ones are on your calendar and they don't have to be weekly, they can be biweekly. I see some communication going on in that chat, especially when you have larger teams, then it will happen. And if you just hop in the meeting and go, hey, do you have anything to talk about this week? Nope. That's fine. At least the time was dedicated. Now, yes, eventually getting to an agenda. I'm a big fan of having a leading mentality with one-on-ones where the team member brings to you their wins and losses from the previous week so that they are able to suggest how they can improve. And you hear a lot from that because a lot of people are afraid. They think they need to dictate the agenda, but you learn a lot if you have an employee come to a one-on-one on unprepared and they tell you they were great last week and you know a bunch of shit burn, right? That, that, that shows the tenacity and integrity that they have in their own work. And that says just as much as them being unprepared. So don't be afraid to have you only talk 20, 30% during a one-on-one and having your team talk to you during that one-on-one. And we can get into a lot of stuff like that, but Jordan, I appreciate you hopping on. I'm going to send you back to the week.

Awesome. Thanks, y'all. Jordan.

All right. So should we go to another question or keep the slide going?

I think we can probably skip past this. Like the— I think the process— people probably understand this. Like you need to develop some process. I'll say just a quick couple of words on this that you can't improve something that doesn't exist in the first place. So if you don't have a process to rely on, on how you do something, then that's a system that will never get better. Right? And I, I don't want people to overthink process and documentation because, uh, the worst SOP is one that, that takes a lot of time to invest and develop and doesn't get utilized. I see a lot of people in the industry looking for the perfect SOP to make their team better. That is not how this works. Okay? Like you need to focus on developing the people and then they can use the process to help them along. Right? So my adage is people, process, and technology in that order. Right? If you start with process thinking it'll, it'll fix all of your people problems, you are sorely going to be disappointed. So just have a process, but think of sort of minimum viable product, right? It can be bullet points to start with. As long as people follow that, then you can look for ability to iterate and improve that. So that's my thought on process. And then gray area, we've kind of hit on a bunch of times. I've just like, look, you're not going to know a lot of things and you don't need to. I think a lot of people in the technical industry have some level of self-identity where like we're considered magicians and geniuses and miracles by our friends and family because we happen to know technology. I don't know anything about cars. I find like being able to be like fix stuff around the house or fix a car by yourself, I find that magical. So it's not necessarily that we are sort of geniuses, but we've been told that all our lives and it becomes a bit of our identity. So when we get into a situation where we feel like we have a bit of imposter syndrome of like, I don't really know what I'm doing here. I don't really know what the answer is. We tend to try to bluff our way through it. And that's not necessary. Like what often one of the best answers you can give someone, especially when dealing with clients, but it's the same as if you're dealing with an owner or you're dealing with a staff member is, I don't know, let me get back to you. That's a great question. Let's do a little digging. I'll find out. And we, when we meet again, or I'll send you some, some info afterwards. That's a much, much better way to approach the gray area.

Yep. And you know, it's— we will always live in the gray area. Managing people is a gray area thing. But I do want to call something out because I see it going on in chat right now. I'm seeing a lot of tool conversation, a lot of tool conversation. Where do we keep all these topics that we discuss? And here's this tool and that tool and this tool. And guys, I gotta say, the tool doesn't matter. It is your discipline to manage your team. We can have little quick wins and quick places to put things. But if you are not using it as a way to consistently keep discipline in your organization and follow through, which is a massive trait that we all have to work on as service managers, that the tool doesn't matter. It's the behavior and the enforcement of that behavior that is going to take you from this level to the next level. Hell, you could use a spreadsheet, you could use sticky notes, you could tell your engineers carry around a notepad and a piece of paper. It's obviously making their life easier is important, But at the end of the day, spending money on a tool, like you said, Todd, isn't going to fix the problem. So yes, and I, I totally understand, Brian, the tool does make it easier, but at the end of the day, when we don't have the budget, that doesn't mean we just can't do it.

Yeah.

So I did want to have one conversation as one of the questions, and I don't know if it's on the slide deck, so let me pull that up. Let me get off my soapbox. Notebox on that moment. And let's see if we have a slide for it. We're gonna get things to not fall in love with. This troubleshooting question, and I want to bring in our buddy Dean to help with this because he is a mastermind when it comes to troubleshooting and process. And like we said, Todd, process and people and all of these things are important, but asking you this question, Dean, If— how can we improve the troubleshooting process for technarsh— technish— technarshians— technicians regardless of their experience level? Can troubleshooting skills be taught, or is this literally just process?

You could definitely teach troubleshooting skills. It's certainly easier to hire for them. I think a certain amount of emotional intelligence comes into it. You know, you have to remember at the end of the day that most technology in and of itself doesn't break anything. Anymore. We break it. And so your troubleshooting is largely around your ability to understand how other people think and how they will likely use or misuse technology, but also not apply your own bias to them. And that can be taught, absolutely. And, um, one of my favorite ways to do that is pick a framework. Like, uh, we used to have the OSI model on posters up everywhere in our office And anytime there was any issue— real quick, anyone—

model, just real quick, what is OSI model for the people that are not OG nerds?

I do not remember what the acronym stands for, but it is a 7-layer model starting at 1, which is the hardware layer, which is your cables, and ending at 7, which is this layer, the layer that we're all interfacing with. And it steps you through the fundamental elements of basically how data is transmitted and presented. And a framework like that is a really powerful troubleshooting tool because if I had a tech come to me and say, I can't figure out why the network is down, you know, I, in my mind, I'm like, well, did you check this and this and this? What are you doing? So you frame it around the OSI model. Layer 1, did you check all the cabling? Oh, well, it can't be the cabling. Well, did you check it?

No.

Let's go check it. Layer 2, you know, it can't, it can't possibly be the switching at the MAC address level that, you know, well, did you check it? No, let's go check it. Layer 3. Oh, it was Layer 3. Look at that. It was a routing issue. And it's very easy to teach someone to think that way. And what's nice about it is getting back to the EQ component that turns a frustrated technician who feels like they don't know something into someone who feels empowered to win. And when you make your team feel empowered to win, they build confidence and they flush that imposter syndrome nonsense out. And that projects forward to what the client sees. And instead of getting an unsure tech on the phone who's like, oh, well, I'm not sure, could you try this, could you try that, they can very, very authoritatively walk that user through, you know, we have tried X, Y, and Z, I would like you now to go do step Q and you will see this result. People love being told the result they're going to see from your troubleshooting suggestion. You look smart, authoritative, you win, and your clients are happy.

Yeah, thank you.

I agree. Like, I really like it.

I got a mug for this.

Read the manual. Uh, so I like this because, like, one of my— one of the things I, I sort of harp about, Dean, is very similar to this, is, uh, like, the, the troubleshooting experience that drove me the most crazy, uh, when I was doing service management is the people that are like, "The machine, the workstation's acting weird. I'm going to install the third, like, virus tool to try and figure out, like, there's something in there. There's got to be something in there." It's like, "No, like, there's, like, have you read event records? Have you looked at even the fundamentals of this?" Basically, right? So like overcomplicating that troubleshooting, I find, is an issue that is pervasive. Maybe a little less so now, but I think it's important, like, utilizing some industry frameworks, or having some common core troubleshooting steps that people agree to. And this is where, like, getting your team to contribute is really helpful. Like, this is a great subject for team meetings, right? Where you, you take someone who is particularly good at troubleshooting and have them step through their process. Like, pick a ticket, like, this is how I thought about it, these are the things that I checked. Everyone's like, oh, okay, I never thought of that, I'll make that a part of my process. Like, it becomes a collaborative learning, uh, and this is also another cool hack that you can do for team meetings is like ticket reviews of like, you know, this is— there was some of these issues, like, um, without explaining what happened, how would you guys approach this, right? And getting people to collaborate and share. And like, either they— like, the people that don't speak up in the room may learn something, or everyone's like, oh, interesting, okay, that's not what I would have expected this would be. Do we have SOPs for this when this happens, right? It can kind of spawn some of that, that more detailed information.

So real quick, gentlemen, I— there's a couple things in chat and one of the questions that I want to steer this towards, which Joe Wright puts, there's a lot of discussion regarding people, but the issue is we're having issues finding the good ones. And I want to pair this one of the questions that we have in Slido, which is, let me find it. How can we stop the triage help desk techs from spending too long on tickets for researching things? Because I think these kind of go hand in hand with finding the good people. And I could do a shameless plug for Empath here in what we're trying to solve. But beyond that, right, I think these, this kind of leads into being a manager. And are we always going to have the good people?

No, I would say this is where like the pair of people and process makes a, makes a big difference. So a process for this, what I suggest is like there's a 10, there's a 15 to 30 minute cap on triage, right? If you don't have a really good foundational understanding of what the problem is, then escalate it, right? And the people side of this is reinforcing that at a management level, right? So you have like a WIP, work in progress status, and the manager is kind of watching. Like if you have multiple tickets in WIP or there's a ticket that has been open for 45 minutes, then, you know, hey, like you tap them, you're like, what are you up to? Like, are you stuck on this? Or like, no, no, no, I just need 5 minutes. I know exactly I know exactly what this is like.

Okay, cool.

Right? Or if they're like, I'm Googling around, I think I can figure this out. Like, often they're trying to hero their way through this because they don't want to admit they don't know, right? Like, no, wrong approach. Escalate it. If you need some advice on how to fix that, go talk to the T2 and have them explain to you what they did offline some other time. Right? And just one other adage on this around, like, you're not going to have the best people, but that's why training matters, right? Path as a training approach and building these systems into the team. I often say like technical, technical skills are easier to teach than to teach someone not to be a jerk, right? Like you want to look for someone who has really good administrative skills, good people skills, they have an aptitude for learning. Those are the people that you want to look for, not someone who's a killer tech but is a total asshole, right? Dean, your thoughts?

Oh, okay, real quick, you got me on a soapbox. I'm going to cut Dean off because you said something that completely struck thing, uh, accord with me, which is, guys, when I was at Best Buy corporate and we were hiring for Geek Squad employees, we were hiring 1,200 employees a month. 1,200. And the one thing that you have to keep in mind when you're hiring that many people, and yes, we can make fun of Geek Squad all day long, but what other IT companies in the entire history of IT have had 1,200 locations and 15 employees per location, right? That is a mechanism of scale. And as you scale your departments, you need to be able to scale your people and recognize that I can't be picky and look for unicorns. I got to get someone from Starbucks to just basic level 1 troubleshooting and then nurture their way up. Because as MSPs, we are college football teams. We are not professional football teams. We are a place for people to get started. We are for a place to people to get Excel, but we're not hiring from Microsoft and trying to think that we're going to hire from Microsoft. It's just, it's setting yourselves up for failure. So you have to be able to manage your team and career path them so that you can go ahead and tackle these problems. Because if you don't, then yes, you're always going to be sitting there going, oh, we need another person. And the number one bottleneck to MSPs and why they don't grow is because of their people, not because of sales. I know many MSPs are actually very good at sales, but the service manager is always throwing their hands up and going, don't sell that new client. Tell them that that project won't start for 90 days. Tell them that we can't onboard their help desk for the next 45 days because we can't get the right people at the right time to do the right things. All right. Off my soapbox. Dean, your thoughts?

Well, real quick on that. So I started off in a very small MSP that was in a terrible location for finding the right people. And we grew that into an absolute monster of an MSP. In fact, not being able to hire and retain the best people forced us to become experts at figuring out how to allow anyone on the team to solve anything, which made us unstoppable. And kind of connecting back to what both Todd and Kyle were just saying, a lot of troubleshooting, you need to remember as the service manager, you're there for a result. And I know that we don't want to be that MSP that band-aids things, that just treats symptoms. But we also need to remember we're a for-profit IT department. And sometimes you just need to fast forward to the result. There's a service manager in this chat right now that used to work for me. And I remember once there was an end user problem on the computer he couldn't fix. So he just restored like an hour ago backup from Acronis and wiped the machine. It was just like problem solved. And at first I was like, what are you doing? You can't just etch a sketch, you know, solve the problem. And he was like, but I didn't know what was wrong and now it's not. And we're back to a known good state and the user can work. I'll figure out what happened later. And I was like, huh, that's genius. So just, just keep that in mind as a service manager. Yeah, you want to do troubleshooting, you want a process, but make sure you're not losing sight of the actual result that you're delivering. And if you do have tools or methods to arrive at that result in a safe and responsible way, don't forget that because that is kind of why we're here.

Yeah.

So, Dean, we are running out of time, but that was so well said. And I hope when we do our next one in April, you'll come and join us as well, Jordan. And then in the chat, if you want to be on the panel for the next one, either post a message in chat or send us an email. And we'll go ahead and get you in this so that we can actually have you, uh, join us and kind of respond to some of these topics. Because again, there's a lot of gray area in what we deal with. So having multiple opinions from multiple people that have done this, or even are new to it— if you're vulnerable and you want to come on stage and kind of voice your question, uh, this is, this is for us. This is more of a, a true forum. This is not something that's just Todd and Kyle talking too much. At a camera. So anywho, Dean, thank you for your time. So with that said, guys, what I would like to know— oh, bringing Todd, a couple things. So Todd, I'm gonna help promote him on this one. He actually has a pretty rad MSP Service Manager boot camp course over on his website. It's a pretty neat little course. How many lessons is it, Todd?

It's 4 modules.

Yeah, so it's 4 modules and it's, it's a, it's kind of like a crash course, right?

Yeah.

It's, I, I wanted to build a course that has all the fundamentals that you need to be successful without it taking kind of 8 weeks to complete, right? Like you can finish this in a week or 2 and it gives you all of the core fundamentals around, uh, what do you do as a service manager as the first module? Uh, how do you leverage data and KPIs as the second module? How do you manage people and breed a culture of success as the third. And then the fourth is because if once you start managing your team effectively, some may wash out either by choice or your choice. How do you hire to build a performance culture? So the hiring and onboarding aspect of it as well. And like I can say this true is true is everyone who's taken this course has loved it. Like the only refund I've ever given was someone who got very excited, signed up for the course and was a service manager for an auto dealer. And he's like, oh, wait a minute, this is not for me. Probably still would have been helpful, but yeah, like, like people love the course. So really, really encourage you guys to stand to take a stab at and try, uh, sign up. There's a— the first module is a free view, right? So you can watch the first module of the— or the first, uh, video in the course to see if you like it. So sign up.

Awesome. And then guys, we want your feedback because I know we're putting a month and a half, almost 2 months between this one and the next one, and we've even thought about changing up the format, having some breakouts so you guys can kind of do some role plays with other service managers. Managers in this group, and we're really open to making this— I don't want to say peer group, but a cohort. We're using this term purposefully because we're not going to be able to fly out and all hang out with each other. Maybe, maybe at some point, but we want to make this for you. We want— I, I really want to make this a resource that we can all leverage and grow from, just because of how gray our job is and how poor some of the education is. Now, shameless plug, we're going to be tackling this a lot inside of Empath with courses, but courses only cover so much because of all of the soft skills that you have to learn and be comfortable with, build out that resilience to just be able to dip, dodge, and weave. That if you're interested, please let us know in chat so that we, if we wanna do this monthly and we wanna make it 2 hours or 90 minutes and have breakouts and bring in other panels or just have single topics per session, just please give us that feedback because this is something that we can keep going. I mean, we're at 184 people that registered. That's how many service managers are looking for something like this. And right now, guys, we have the ability to stand up and get better together, and I want to support all of you in any way that we can make that happen.

Awesome.

So with that being said, um, any last things, Todd, before, uh, we go ahead and kick this off?

No, I think that, that covers it. Like let's, let's get stronger together. So make sure you reserve that time. And as Kyle said, if you want to sort of be a part of the panel and let us know if you have continued questions or areas of focus, let's, let's start to hit on those because, you know, we went through, I think, a lot of awesome content today. Like, I'm, I'm as jazzed up about this at the end of it as I was at the beginning, maybe even a little more. Like, this has gone really well. I think this has been great. But honestly, like, we, we didn't touch half the content, right? So there's still much more to do, right? This will be amazing. So really, really appreciate everyone being here and we'll get plenty more content for you to help you develop in your career.

And it was mentioned in chat, but I'll just say it now because Crowdcast is the platform we started with. All of these sessions are recorded inside of Crowdcast. So once we hit end session, you'll actually be able to go into Crowdcast and rewatch it. There's a good chance we're not going to put them all on YouTube or all on LinkedIn because we want to make this a personal thing where eventually you're able to share and be vulnerable. And at some point too, we may gate this and say, hey, 200 people's enough. Let's just lock it here for right now. Make some— right, make it a thing to where we can learn more about each other, especially being that Jeff is going to be the vulnerable one. He's already signed up for our next session. Our next session, we're going to focus a little bit more. We're going to actually hone in on professional services. What are projects versus recurring revenue? So, and then I know I saw a lot of people asking about finances, so we might make a P&L one. But again, let us all know. And then from there, we're going to go ahead and let everybody out on time. Let's make our CEOs happy that we weren't in here longer than an hour. And that being said, thank you everybody again. And I really mean that, as this was so cool, being vulnerable, right? I also didn't know how this was going to go. I didn't know if you guys were going to participate. I didn't know if you guys were going to show up. Up, but this has just been fan-fucking-tastic.

So guys, this time it was so fun. Yeah, yeah, this—

and maybe eventually we'll make a chat group with all of us. So that being said, guys, it's been a pleasure. Take care.