How to Scale Your MSP Service Desk: The "Pod" Structure & Remote Teams

Is your service desk breaking under its own weight as you try to scale beyond 10 employees?

When an MSP is small, the "everyone helps everyone" model works perfectly. You shout across the office, grab a ticket, and solve the problem. But as you grow, that lack of structure turns into chaos. Tickets fall through the cracks, accountability disappears, and your best engineers get burned out trying to support every single client at once.

In this episode of the How to MSP Podcast, Andrew Moore talks with Jon Katz, COO of LISS Technologies. They discuss the painful but necessary transition from a high-cost New York City office to a highly efficient remote workforce. Jon reveals the "Rule of 8" for management, why generalists fail at scale, and how to implement a "Pod" structure that keeps your team accountable and your clients happy.

What You Will Learn in This Episode

[05:37] Going Remote: How to transition from a physical office to a remote workforce without losing control.

[16:18] The "Agile" Huddle: Replacing over-the-shoulder management with daily stand-ups and strict KPIs.

[25:14] The "Pod" Structure: Why you need 1 Team Lead for every 4-6 engineers to maintain quality

[27:50] Client Assignment: How to assign specific clients to specific pods so they always deal with engineers who know their environment.

[30:11] The Specialist Problem: Why you must move away from "Jack of All Trades" hiring as you scale.

Resources Mentioned

Guest: Jon Katz (LISS Technologies)

Company: LISS Technologies

Deep Dive: The "Pod" Model (And Why You Need It)

One of the biggest challenges discussed in this episode is the "breaking point" that occurs when an MSP service desk hits about 10–12 people. At this size, a single Service Manager can no longer effectively manage every ticket and every engineer.

Jon Katz introduces the solution LISS Technologies implemented: The Pod Structure.

Instead of having a giant pool of 20 technicians grabbing tickets at random, you break the service desk down into smaller, self-contained units (Pods) of 4–6 engineers.

  1. Dedicated Clients: Each Pod is assigned a specific group of clients. This ensures the engineers actually know the client's network, VIPs, and recurring issues.

  2. Dedicated Leadership: Each Pod has a Team Lead. This gives engineers a direct line of support for escalations without bottling up the Service Manager.

  3. Accountability: It is much easier to track the performance of a 5-person team than a 50-person department.

By implementing this structure, you recreate the "small MSP feel" (intimacy and knowledge) while maintaining the "large MSP scale" (resources and coverage).

Related Reading

Once you have your service desk structure optimized, you need to ensure your account managers are bringing in the right kind of work for them. Check out our guide on Building an Account Management Process (That Doesn't Suck) to align your sales and service delivery.

  • Jon Katz (00:08)

    it's very easy when you're looking at time per ticket, tickets taken per day, ⁓ burn rate, and you can see where the deficiencies are. And then it's about, again, accountability, making sure that the team lead is reaching out and finding out why. There could be some personal reason why something's going on. Maybe that engineer is a little burnt out. Maybe they need a day off, you know, it's something as simple as that. ⁓

    Maybe they're just not following the process and they're not showing their stuff. Maybe their time per ticket is too high because they're not following that escalation path or that collaboration path.

    Andrew Moore (00:39)

    That was John Katz, COO of LIST Technologies from the great state of New York. John is in charge of global operations and strategic initiatives. John's been 25 years in the technology space where he's been a systems engineer, a VoIP engineer, and he's also been a consultant. John is excited today to share with us

    how his service desk works remotely and how the pod structure he's implemented has helped his MSP be super successful.

    Andrew Moore (01:09)

    All right, we are live with John Katz from LISS out of New York City. Good morning, John. How are you?

    Jon Katz (01:21)

    Doing well, Andrew, how are you today?

    Andrew Moore (01:23)

    Fantastic. Where does the podcast find you this fine morning?

    Jon Katz (01:27)

    Sure, I'm in our Roslyn office, which is the old my father's place, a music venue. So, yeah.

    Andrew Moore (01:33)

    That's cool. That's cool. like,

    what kind of music did they play there?

    Jon Katz (01:37)

    Everything from the Ramones to I believe Madonna was here. ⁓ The police, a bunch of ⁓ different bands came through here. ⁓ It was actually a lot of history in the building. It was a car dealership, a bowling alley, a music venue. It was a lot of cool things. Now it's a cool IT company.

    Andrew Moore (01:41)

    What?

    That's awesome. That's so, ⁓ like Springsteen too. Nice. I love, I'm one of those people that I love The Boss. I've never seen him live, but I really like Springsteen. But I'm probably one of those people that I really like Born to Run.

    Jon Katz (02:06)

    He was here. Yeah. Yeah.

    Andrew Moore (02:21)

    more than I like all of his, and I might probably get in a lot of trouble for that, but I love Born to Run, but then some of his other stuff, I like it, but I don't love it, but I love Born to Run. So, for what that's

    Jon Katz (02:32)

    Yeah,

    people either love or hate him. When I hear like this time of year, the Christmas stuff comes up, I don't like it. I'm not a fan. I'm not a fan. But yeah, it's hard to not like him, but people either love him or hate him. Yeah.

    Andrew Moore (02:35)

    Yeah.

    Yeah, not a fan, huh?

    Yeah.

    Yeah. Well, the live stuff

    I've heard, which is really I've heard some of the live stuff on East street radio, on Sirius and stuff. like I've heard ⁓ people describe a Springsteen concert as like pure joy. And like I've listened to the live stuff and there's songs on there that I don't know. But I'm like, damn, that sounds like a throw down. Like it sounds like it would be a lot of fun to see him live, even if you don't know the music. So I get it.

    Jon Katz (03:10)

    That's fair. Cool. Yeah.

    Andrew Moore (03:11)

    I can see that. So

    John, we know each other from TBG. So we were in the Taylor Business Group together in the operations, like the COOs group. So why don't you talk a little bit just real quick about what you do at LISS, where you came from, how you got here, what's been going on with you ⁓ from a career standpoint.

    Jon Katz (03:30)

    Sure, man, I've always been in technology. I mean, I was, I'll start back with when I was 13, 14 years old, my mom was the first cell phone store in New York. So I got to hang out in the back and burn dams and like program phones and like watch all these, you know, back then you had to open up the transceivers and like literally program these things. so, you know, that was my background back then.

    Like a lot of others, I got into gaming in the mid 90s. And obviously you have to have the latest, greatest upgrading machines and having LAN parties and stuff like that. So that's what got me into computers. But yeah, man, I'm an audio engineer. I was an audio engineer by trade. So kind of always in that technical realm. In 99, I started with a partner out of necessity for

    some ⁓ of our clients back then, just break fix stuff and mostly in Long Island and Manhattan. And I had a met up with the LISS group back in 2006, actually installed the phone in the owner's car. And that's how we met. ⁓ And actually his dad was a...

    Andrew Moore (04:46)

    It says a lot, you

    installed a phone into a car. That was back in the day.

    Jon Katz (04:50)

    Yeah, they're big

    50. Yeah, when I first started doing installs, mean, transceivers were 50 pounds. We had to run six gauge wires to the trunk just to power the things. ⁓ But yeah, so my mom was the first cell phone store in New York. My stepdad was one of the first beeper stores in New York. So that's how they met. ⁓ But the owner of LISS which is the current owner's, ⁓ one of the current owner's father, ⁓ he used to buy his beepers through Neil.

    And ⁓ when they had phones to install, I would install the phones. And that's how we all met. And from 2006, I left for a few years. know, grass isn't always greener. Came back ⁓ and ⁓ been here since.

    Andrew Moore (05:37)

    So I want to talk to you today for a couple of minutes ⁓ while I got you about remote work and how you built your team. Because right now, from when I first met you in TBG and when we first got to know each other, your teams were

    all working in an office in downtown New York, or maybe there was a satellite office. But from what I remember, there was a very expensive piece of real estate that you had to maintain. ⁓ This was like pre pandemic. ⁓ And I remember when we would talk in our in our group meetings, we would have these conversations about when they were measuring our MSPs against your MSP, you would always get somebody would take out the stick and they would beat you about

    cost per employee, right? Like overhead costs, stuff like that. And you would be like, listen, like I, I have an office in New York, like I'm hiring people in New York. What do you want me to do? So I know that over time you started to figure out how to maybe make some changes to, to continue to create a consistent service quality, but also like lower your costs. And that came with bringing remote people onto the team. Right. Because it,

    Jon Katz (06:37)

    Yeah.

    Andrew Moore (06:53)

    You've only so many people you can hire in the city of New York, right? For your first problem. then all the other challenges. So like, can you just elaborate a little bit on like kind of where you guys were and like what drove you to start trying to figure out how to find talent outside of, you know, the big apple.

    Jon Katz (07:01)

    Yeah.

    Yeah, absolutely. So I know our first meeting together, by the way, that was, I looked it up before that was back in early 2018. So we know each other quite a while now. One of the things that.

    Andrew Moore (07:20)

    You drove

    us around and you drove us around after we had had too many drinks and you took us to In-N-Out Burger when we were in San Francisco. That was awesome. It was one of my favorites.

    Jon Katz (07:24)

    In and out. That's right. That was my first time I saw animal

    style fries, by the way. Yeah. Yeah. So one of the things that the whole group said to me was, why don't you guys have interns or first line support? Because for me, it's always about L2 and up. That's all we want to hire.

    Andrew Moore (07:34)

    Yeah, good stuff. That was good stuff.

    Jon Katz (07:51)

    And my answer back then was, was similar what you were talking about. Like our cost per seat is just too much to bring in an intern or something like that. Cause they cost a real estate and overhead. just, it doesn't work. ⁓ And yeah, the, the other thing about New York is it's a very competitive market. So trying to get all of your talent from this local area is, is hard. So I would say in, in right around there, right about that 2018 mark.

    We started looking for remote employees. Didn't always go great. We didn't have a structure in place. We didn't have the visibility to ⁓ see what these engineers were necessarily working on or doing. We didn't have any accountability for remote employees or anything like that. So I think what we ended up doing was shortly after we started moving into a pod kind of a model where ⁓

    we're able to have a certain set of engineers, a certain set of escalations and team leads to look over just a smaller group. That way your accountability is shrinking down to under eight people. And I think that that was the biggest thing. When we first met, I believe we had like maybe 12 to 15 direct reports and I just, it doesn't work. Anything over eight starts getting rough.

    Andrew Moore (09:13)

    So that's an interesting point. You've been in a situation where, and I mean this with all ⁓ the accolades that comes with this because you've been successful in overcoming them, you've had challenges that you've had to overcome. You've made mistakes. What mistakes?

    Do you see other MSPs make when it comes to dealing with remote work and trying to find how that balance works and just like, what did you overcome? What challenges did you have to overcome? Like what advice can you give to people on like starting to build a remote team?

    Jon Katz (09:50)

    Yeah, so that's a great question. I can tell you, you guys beat us up pretty bad that first Taylor meeting. And like you always do, you challenged us as well.

    But I would say again, the first thing is structure, right? You need to, you need to make sure that you have the team in place to oversee remote workers. And what I mean by that is you need to have someone that's sitting there and their job is to literally look at throughput for remote engineers. ⁓ It's also hiring the right people because working from your home all day, every day without the social interaction with, you know, the person right next to you, it's not for everybody. So.

    That's something as simple as discussing that during the hiring process. Like have you worked remotely before? Do you see yourself being able to work remotely in a scenario where you don't have a coworker next to you all the time? Some of the things that we do is we make sure that we have a huddle every day. We need to make sure that we're in contact with that every day. Andrew, one of the things that you always said to me was like have a best friend at work. That's really hard when you're remote.

    So again, making sure that your team lead or wherever you have overseeing that pod or that group of remote engineers, ⁓ they become friends because you need to have that person that you can reach out to and talk to all day. Sitting in solitude is rough, it really is. So I would say that that's probably the biggest thing.

    Andrew Moore (11:16)

    So if you're, there's a couple of things that come to mind. want to touch on it. So it's a two part question. One is if you're not big enough to break into pods, right? Like you only have four or five people, but you, know, you want to start higher remotely. Can you do this without having multiple pods? I guess. And so when you talk about pods, how do you, how do you see that? The other is where in the hell do you find these people?

    Jon Katz (11:44)

    Ha ha.

    Andrew Moore (11:45)

    Right?

    Where, how do you find remote people and like, how does that work? Right? So guess that's two things I'd like to, to dig into a little bit there.

    Jon Katz (11:54)

    Yeah, that's a great question. I would say if you're, if you're not small enough to have a full, let's say remote pod, ⁓ my suggestion would be a tag team. So you have one person who you see has some leadership skills on the, on the team that you could potentially offer a growth path to eventually be a team lead, have them start tag teaming, you know, have them start looking at, at what a remote engineer is, is working on, you know, having them check in through the day. ⁓ That's

    potentially how you can work. We were lucky enough to have ⁓ enough people to start breaking out into pods when we started doing this. And then we worked with one single recruiter. I, you know, we like it.

    Andrew Moore (12:37)

    You can name drop if

    you want, unless you don't want to, but it's fine if you do.

    Jon Katz (12:40)

    No,

    we work with Apollo staffing. What we found was in the beginning, we were working with multiple recruiters, but it is so much easier to work with a single recruiter. If you need to have a backfill, it's always from the same person. ⁓ We're at the point now with Apollo where we could just say, hey, we have this opening. ⁓ Here's the job description, and they know what we're looking for.

    to try to get that relationship and try to hone down skill sets and really just trying to get across what we're looking for to multiple recruiters was so hard. So again, we've standardized with Apollo Staffing. They've been fantastic for us. We do about 10 placements a year, 10 to 12 placements a year with them. ⁓ Obviously we're growing. So ⁓ we haven't stopped hiring since Andrew, since we met.

    I think one of the first things that we said and the reason why we started looking outside of New York was we couldn't hire fast enough.

    Andrew Moore (13:37)

    Yeah.

    I'm interested though, before we kind of dig into core processes and whatnot, the structure of the pod, it's something that I teach in my training and coaching, which is this ability to not really be able to manage more than eight to 10 people at any given time. I just, I feel like...

    that's a really core KPI that as a company begins to grow, when you have 10, 15, 20 direct reports, that's a problem, right? Because I believe that to your point, which I think we're gonna drop into here in a second, I wanna touch on is, if you wanna be able to manage remote workers, there's a level of accountability, interaction, oversight.

    Jon Katz (14:12)

    Yeah.

    Andrew Moore (14:29)

    that is different than if you can stand in a service center and listen to what everybody's doing and walk around and check on them. I think you could maybe make the argument that you could manage 15 or more people, ⁓ maybe not well, but better in an environment where you're physically there with them. But if you're dealing with remote workers, that eight to one ratio really makes a lot of sense.

    Jon Katz (14:54)

    It does. It does. Yeah. I mean, for us, the, especially in the beginning, what we said was, okay, if we had four engineers to every about one escalation, you know, that that's a decent ratio. If we can get five to two, that's a great ratio. ⁓ have a team lead on top of them. If someone's out that day, everybody shifts down. So if you have an escalation out, that team lead turns into an escalation for the day. If you have a first line support engineer that's out your

    escalation slides into that slot. ⁓ So as long as you can be fluid with it, I think a smaller pod certainly works. Obviously, when you start getting a little larger, when you can have maybe seven people in a pod with two or three escalations, now you're at that kind of 10 to one-ish ratio, where I think that works out really well for accountability and sustainability too, because at a certain point, like,

    it gets hard to manage and to do the one-on-ones. And that's another thing, like it's super important to get one-on-ones in there. Make sure you have smart goals and, you know, the ability for your engineers to grow and get those on a board and talk about it. ⁓ But yeah, weekly one-on-ones are huge. You know, and then when you start saying, hey, now you need to have 12 or 15 one-on-ones in a week, starts getting very time consuming.

    Andrew Moore (16:15)

    Right.

    So I want to get into a little bit about what works and how the processes go. And something I do want to talk about here is you used the word throughput before, which I'm a huge fan of throughput and work manifest or artifacts. Whatever you want to call them, whether that's a ticket or project, just moving work through the system. And then you talked about the pods and the one-on-ones. How do you make sure that you are

    telling the team in the field exactly what you expect from them and then using the one-on-one to reinforce that. Like, you dealing with, like, when you talk about throughput, is it number of tickets? Is it amount of time on tickets? like, like kind of generally, what are you doing to try to keep your, client satisfaction scores high and maintain your SLA's? Like, what are you doing there with these remote team members?

    Jon Katz (17:09)

    Sure.

    So it's always a balance, right? So we want to see, first and foremost, we want to give our engineers the ability to learn and grow. So to throw any situation at an engineer, think is wonderful for them to be able to grow. You know, can't pigeonhole and expect them to grow. But that being said, there has to be some type of a constraint there where, again, you can't have a client waiting for three hours because you have a junior engineer working on something.

    So what we do is we have time limits internally where we say, hey, there's no clear path to resolution after this amount of time, ⁓ collaborate with the peer. And that certainly helps with remote workers as well, where we used to have the ability to overhear or listen in an office, someone pops their head up and hears something, it's not there anymore. So again, collaborating with a peer. And that could be your team lead, that could be someone else on your team, that could be...

    Andrew Moore (17:55)

    Yeah.

    Jon Katz (18:05)

    It be me, it doesn't matter with anybody. So I would say that that's certainly important.

    So as far as some of the KPIs, ⁓ obviously, I know we used to not be a huge fan of tracking utilization, but ⁓ we do track utilization. And what we see is utilization is time in the system. used to be much harder to track this. Now that we've moved PSAs, it's so much easier. ⁓ You know, I spend a lot of my career telling everybody, put your time in, put your time in, put your time in. Now that we've moved PSAs, it's like, don't touch time. The PSA does it for you.

    But we look at utilization, we look at time per ticket, tickets per day, escalation rate. You know, it starts painting a picture. If you have a, you know, I'll use some KPIs here. So if you have an engineer that's about a half hour per ticket and their utilization is above 80%, well, you could do the math. You're seeing 12 tickets a day easy. But when you start...

    Andrew Moore (19:02)

    Yeah.

    Jon Katz (19:04)

    you know, when you start reverse engineering, an engineer that's underperforming, ⁓ it's very easy when you're looking at time per ticket, tickets taken per day, ⁓ burn rate, and you can see where the deficiencies are. And then it's about, again, accountability, making sure that the team lead is reaching out and finding out why. There could be some personal reason why something's going on. Maybe that engineer is a little burnt out. Maybe they need a day off, you know, it's something as simple as that. ⁓

    Maybe they're just not following the process and they're not showing their stuff. Maybe their time per ticket is too high because they're not following that escalation path or that collaboration path.

    Andrew Moore (19:40)

    Are you also, one of the things that we started was, ⁓ at this epiphany, ⁓ cause they used to work in restaurants, right? So at this epiphany of like open and closed shift routines, the goal is to have whoever comes in to make sure that they do a certain thing in the morning, every morning before they get ready to work. And then at the end of the day, they're doing something similar and then we would use the one-on-ones to.

    kind of verify, you know, Hey, are you doing, how well are we doing this week on staying on top of stuff? Have you guys integrated any of that into what you're currently doing or are the one-on-ones enough? Like just cause I know you guys are at scale. You're a much larger MSP. So I'm just curious how that was working out for you all. If you do it.

    Jon Katz (20:20)

    Yeah,

    our engineers know what they're supposed to do in the morning. I mean, it's when you first come in, it's checking any of your waiting internals, it's checking any of your open tickets, and then it's getting on the desk and grabbing those new tickets. We do have lists for our team leads, ⁓ just things that you're supposed to do through the day. Coordinators have their lists again. Hey, every hour you have to check this, you know, twice a day you have to check that. ⁓ We're in the middle of ⁓

    coming up with our, we're actually almost done with our AI shift reporting now, which is cool. So what we're doing is we're

    having the system pre search and present that with AI summaries to the team leads with anything that may need eyes on it. So, and then because of, you know, what's the ticket notes and what's in that ticket AI can potentially suggest next steps. So an example would be like we had an overnight shift that

    You know, it's a P1 that came in. There's a, you know, no internet at this location. And the ticket note says something about having a dispatcher first thing in the morning. AI will know that that was a P1. There was a last note was in there. It's still open. We could read through the notes, see what's going on and suggest that we need to dispatch first thing. And it's going to summarize that and present it to our team leads.

    Andrew Moore (21:37)

    That's pretty cool. Like not going to lie. Yeah, that's hot. That's hot shit. So, ⁓ for the one-on-ones that you do, are you sitting down with the team members and providing them their list of like KPIs? Like look chief, like looks like this week you only closed, you know,

    Jon Katz (21:39)

    We're getting there, We're getting there. Yeah.

    Andrew Moore (21:56)

    six tickets on two days, like what's going on? Like, are you going through that process with them or is it, is it the one-on-one more of like touchy feely? Like how does it work?

    Jon Katz (22:06)

    Yes. ⁓ Yeah, so basically ⁓ we do this in Planner. And the Planner basically has a bunch of different columns. And one of the columns is KPIs. We touch on KPIs in these one-on-ones. ⁓ Another column is engineer feedback. So what kind of feedback do you have for your manager and the team? Another column is manager feedback. We have a potential issues column where, hey, you missed a callback or you missed this.

    this something or a thing that gets put in that column. And then what we have is our long term goals as well. Again, we don't want people to stagnate here. even as in the beginning where, you know, during the interview process, one of the questions that I always ask when I'm on an interview is, you know, where do you want to be? You know, if we had any position here open today, you know, what do you want to do? And the same thing is where do you want to be in a few years? You know, let's make sure that we could at least get that path in front of you.

    Andrew Moore (23:03)

    So every service desk has got a different kind of model. I'm just trying to make sure I get in front of the naysayers out there that are going to be like, well, that just won't work for me. How do you guys take tickets? Do you guys allow clients to call in directly? Do you take just tickets through a portal? So I guess my question is more about if you're building out pods and you're creating structure around that,

    There is people are going to have excuses as to about well I have to have a bunch of people answering the phones or I have to have this or I have to have that like what do you say to that like what do you say to about like hey we've done it this way and this works for us and you know

    Jon Katz (23:38)

    Yeah,

    listen, everything works different for every company. ⁓ I could tell you what works. What wasn't working for us was multiple intake methods and our inability to prioritize based on the actual issue or real priority. So we used to have the ability to open from a web form. You can call in and have a live answer where you're sitting there and in a call queue and ⁓ an email in. But the problem becomes when you have all these different intake methods.

    It gets very hard to prioritize. So what we did was we went to a callback only help desk. We do have a live answer with the integration into the PSA to open the ticket on behalf of that end user. If it's a P1, yes, you get passed off directly to an engineer. And what's nice now is that engineer can answer the phone because they're not sitting there in a call queue and always on the phone. I think it creates more of a relaxed environment for the help desk, as relaxed as a hectic help desk could be.

    Andrew Moore (24:36)

    That's what to say.

    Jon Katz (24:37)

    ⁓ a little more relaxed environment where you're not sitting there with the phone ringing off the hook while you're trying to fix something. All of a sudden a P1 comes in, you're able to focus. The tickets are being opened for you. You're not answering the phone. Give me one second while I open this and start working on it. It's a little less chaotic. ⁓ We sent a survey out right after we did this about six months in and all but one client said that our response time has increased. ⁓ So I think that the

    And we did this way back in around that same time, that 2018, 2019 time frame.

    Andrew Moore (25:14)

    let's talk a little bit about where you guys are at when it comes to scalability and, working to like, when you get to the point where you want to put another pod together, like, how does that look for you? Like you were talking about, well, you get to a certain size, like what's the minimum number of people you're to put into a pod?

    right? So that you can maintain integrity. Like how does that look for you? obviously we know what the max level is, but when do people know it's time to create a new pod? I guess.

    Jon Katz (25:46)

    So we knew it was time to create a new pod when we got to that breaking point with accountability. When we got to that 12, 15 direct reports, we had to break the team up. It also helps too, because now you're putting two more, when you break into a pod, you're putting two more positions in. And these are two more positions that you can potentially move somebody into. So it's another hop or another progression.

    for an engineer that wants to potentially step into management, right? So what we're able to do now is say, hey, I would say minimum four to six people in a pod. And that would be having a, with a team lead on top. And the reason why is because again, you need the ability to be fluid in that pod. So again, four engineers, two escalations and a team lead. I would say in my mindset would be as small as I would end up going.

    Andrew Moore (26:41)

    Are you assigning clients to the pod or is the pod like, how does the pod actually operate so that you can maintain some level of capacity planning or whatnot,

    Jon Katz (26:52)

    Yeah, that's a great question. So until now we've basically had pods for accountability purposes, not for client breakdown or technical breakdown or, you know, specific skill sets. ⁓ But we're actually in the middle of moving over now to splitting the company in half and then assigning pods based on the company. And the reason why is because as you start growing, you know, one of the, again, one of our struggles is a client saying, Hey, we,

    when we call in, we've gotten three different engineers that we've never talked to before. Over here, it's funny, we always say it was so much easier when we were just four five guys in a room. Everybody knew everything that was going on at every client. So that's one of the things that we certainly, it's one of our challenges over here. So we have basically four pods that are gonna come down into

    into two separate sides of the company. And we're starting with splitting the company in half.

    Andrew Moore (27:50)

    And so when you, when you talk about that, you're talking about just splitting the client base between two different groups of, of engineering pods and then potentially account management, like inside sales. Like, so how does the, how does the service pod interact with the, we'll call it the strategic and or, ⁓ revenue generating revenue retention part of your company? Like how does that work?

    Jon Katz (28:02)

    Yeah, that's correct.

    Sure.

    So it's a great question. When we started looking at how we're going to split the pods up or the clients up, at first we said, you know, we have technical account managers here and that's who, ⁓ those are our VCTOs, those are our strategic planners, those who are having those meetings on those QBRs with our, the SBRs with our clients. We said, that would be great if we can just split them up by, you know, by TAM.

    ⁓ The problem is that it didn't work. We said, okay, let's try this by ticket volume. Sure. So we split everything down by ticket volume and it didn't work because you have complexity differences. And we said, okay, let's take a step back. Let's just take a look at how many hours are spent for each of these clients against these tickets. And then let's split this up by how much work is actually being done at those clients every month.

    So that's where we're at now is we've got the splits down pretty well. looking at probably two months down the road, we're going to make the split ⁓ and we're doing it based on the amount of time being spent on the clients.

    move one client over here, it shifts the amount of time. And we're trying to keep these relatively even. And again, being able to not go too far, kind of virtually splitting the company in half. ⁓ If someone's out that day, two people, three people are out that day, it's not going to be that hard to maintain. And we'll still have different boards and views where, you know,

    Andrew Moore (29:27)

    Thank you.

    Jon Katz (29:49)

    If one side of the company, these pods are light and the other pods are getting slammed, we can have people move between. But that's stuff that we haven't figured out yet.

    Andrew Moore (29:59)

    Yeah. No, I mean, it sounds like it's, to me, it sounds like it's the natural evolution of going into pods is that there needs to be some level I would call the specialization within the pod.

    what goes on in those service pods is going to have to be directly translated effectively to the account management team. And I think one of the challenges that I've seen is how do you make sure that an account manager who has clients in multiple pods,

    is able to keep a pulse on what's going on without having to interrupt the lead of each of those pods in order to understand how their accounts are being impacted or what needs to happen. Have you figured that out or is that why you're making this change? Are you using AI to potentially look at maybe giving them service notes? Here's a list of stuff that you're, how are you addressing that potential issue?

    Jon Katz (30:51)

    Yeah, that's a great question. We haven't crossed that bridge yet. ⁓ Again, we're in the process of doing this. We're still a couple of months out.

    But no, we haven't crossed that bridge yet. We haven't. Maybe on episode 14 I could be back and.

    Andrew Moore (31:03)

    You're like, let me tell you about this thing that happened that maybe I should have asked you more questions about. ⁓ It's a thing that I've seen in other MSPs only just because like, I mean, you how account managers are and rightfully so they're like, I want to know what's going on with my accounts. so, yeah. And so it, what winds up being, I think difficult is if you're an account manager and you need to have a scheduled meeting on a regular basis with five different.

    Jon Katz (31:20)

    Of course, they have to.

    Andrew Moore (31:32)

    know, pod leads versus maybe I would have it with one or two so I can find out what's going on with my accounts. It's a, it's a thing that winds up becoming time consuming for both because then you have to assume that lead on the pod has to now have a meeting with every single account manager as well. And so it begins to take up a bunch of extra time for everybody that may not be productive.

    Jon Katz (31:54)

    could tell you that we do meet a lot. ⁓ You know, maybe too much, right? So we have an account manager meeting every morning. ⁓ Basically that goes over just the pulse of the professional services team, what projects are going. We have all the leads in the company along with the account managers in that meeting. We break out those meetings into department meetings. Those department meetings break out into pod huddles.

    So anything discussed on our 9 a.m. Call ⁓ does trickle down to everybody in the company. ⁓ And I think that that's probably one of the things that we haven't talked about with remote employees is the importance of meeting and the importance of ⁓ really getting communication out to the entire company.

    Andrew Moore (32:47)

    I would say though that like, I do want to touch on that because that's, I'm glad you brought it up when it comes to remote work and pods and building out that structure. One of the things that I thought was really important that never really occurred to me until we focused on it was how your meetings need to be purposeful and deliberate because you used to be able to get away with a lot of just drive by and you were all in an office.

    Jon Katz (33:05)

    Yeah. Yeah.

    Andrew Moore (33:12)

    And so it did feel like there was a lot of extra meetings. Can you talk about like the challenges that you guys have seen with that? Like, and how that has worked and maybe some places where you've found some relief in how you put that together or philosophy.

    Jon Katz (33:24)

    Yeah, I think it's, it's

    sure. I would say that it's,

    quicker, more agile meetings. ⁓ Again, to the point, like have an agenda. This is what we talk about. This is who runs the meeting and move on. Like you can't sit there all day. You have too many people in these meetings. It costs the company too much. There's other crap going on. Like your shit's going crazy and you're sitting, everybody's sitting in a meeting, especially in that first AM meeting. You have every team lead in there. You have all your department heads in a single meeting. Like you need to be in and out. It has to be agile.

    ⁓ Yeah, you know me, I ramble a little bit. So sometimes some of these meetings go on and get off subject and stuff like that. But again, the cadence is there. It's got to have an agenda. It's got to be quick. It's got to be agile. Get the points across and then get out and break out into your other huddles.

    Andrew Moore (34:19)

    One of the things that I really like to tell my clients is I like having specific purpose driven meetings for things that become that used to be interrupted. Right. And I'll bring up an example. ⁓ I would have people that would swing by my office and they would say, hey, you got a minute? Sure. And they'd say, hey, I got this thing going on with this client. I need some advice on it. And I would say, I would love to help you.

    I'm always here for you. However, I'm going to ask you a very simple question. Will this hold until our meeting on Wednesday? And if they sit there and they go, well, you know what, actually, yeah, I don't need an answer right this second. I will hold. I was like, OK, cool. Let's talk about it on Wednesday. I would say more than half of the time on Wednesday, I'd be like, that thing you came by my office, like, no, I figured it out. It's fine. I'm like, cool. So like, you actually like,

    Jon Katz (35:07)

    Yeah. Push

    Andrew Moore (35:11)

    went out and figured it out on your own and now it's solved. Yeah. Right. So I love purposeful meetings and I like to have cadence meetings like that so that I can try to drive to having a more productive meeting. However, I will say that that can sometimes backfire. And so my question to you is if you saturate some of these purposeful meetings with too many, like one-off tasks, how do you track it? How do you manage it? Like, how do you keep your meetings on track? Like, how do you keep those meetings specific?

    Jon Katz (35:13)

    And learned. Yeah.

    So I can think of one, I guess what would be considered an L10 that we have every week that just goes off the rails. We have it scheduled for a half hour. It's typically an hour, hour and half meeting because we're jamming too much into it. ⁓ We've tried to go from planner to planner pro so we can add some more cool stuff in there and it's not working. ⁓ I could tell you our daily meeting more often, right? So again, that.

    that huddle, the huddles are quick, they're agile, they're purposeful, they're in and out and you move on with your day. Those meetings go so well. ⁓ This other meeting that I'm referencing, it it drags and you have so many people in there that are just, they don't need to be hearing half of the stuff that's going on in that meeting. but what I think what we're going to do is that's actually a team ⁓ that we're going to break up into smaller teams.

    and try to do the same thing. that's going to break out into three separate smaller teams.

    Andrew Moore (36:38)

    Yeah.

    That's great. Like I think, I think that that answer is actually fantastic for people who are wondering where to start, which is like not everybody has to be in every meeting, ⁓ as much as they want to be. think, ⁓ obviously you get politics involved in some companies are like, well, that person was in this meeting and now they're not, and they're to be upset. And, know, I mean, I guess you got to break some eggs, but, ⁓ yeah. ⁓

    Jon Katz (37:04)

    Yeah, absolutely. Yeah. Now again,

    I'm all about the small, agile, purposeful, quick meetings. ⁓ We're all busy. Like we need to just get to the point and get out.

    Andrew Moore (37:16)

    Yeah, no, I love that. I love that. So it kind of wrapping up here, I want to we're going to we're going to get to our questions in just a second. But what ⁓ the I'm going to surprise you here because I didn't actually prepare you for this question. ⁓ What is the one thing that I think ⁓ you want everybody to walk away from here knowing ⁓ before they take this journey of starting to build out more,

    specific and purpose driven teams, whether that's a pod or that's a more refined service center, where you can create accountability, where remote work becomes possible. what do you want people to walk away from? Because they're like, I don't know where to start this journey, or I've started it, and it sucks, and I don't like it, and I can't get my hands around it. if we were in our peer group, and you had to grab somebody, you know, over drinks the first night, and they were like, John, you seem to have your shit together. Like, I'm stumbling here. what the fuck do I do? what would you tell them?

    Jon Katz (38:08)

    That's a good question. It really depends. A smaller company, would say if you can find

    subject matter expert, that there's a deficiency in your company and you're having a hard time trying to backfill or fill a position, start looking remotely. I mean, it's super easy to get someone that's in a higher level seat because typically they're more seasoned in the industry, potentially don't need as much of managerial oversight. Maybe that kind of tag team that I was talking about before may work. ⁓ But yeah, those.

    those higher level positions I feel like are easier to fill remote. ⁓ And that could be a good starting point, right? ⁓ I would say the hardest thing for us is managing our first line support remotely. So it's much easier to manage a seasoned L2, L3 engineer remote than it is a first line support.

    Andrew Moore (39:06)

    And with the first line support, do you feel like the reason it's more difficult is just because the volume of work that they have to do or the inability to track that work or like where is it a chicken or the egg thing? Like, do you hire the person before you lay out the ability to track the KPIs or do you start tracking the KPIs first and then hire the people like what, what has worked for you and what would you, what advice would you give?

    Jon Katz (39:30)

    So I would say it comes down to process. think there's more procedures on the help desk when you're talking about a first line support engineer, right? They have to remember so many different things. It's hard to train them and track them and monitor and see what they're doing all day where if you hire a remote project engineer and you hand them a project and you kind of show them the project structure or your professional services team, it's much easier to manage and maintain that at arm's length than it is an L2 engineer.

    excuse me, a first line support engineer.

    Andrew Moore (40:02)

    Awesome. Awesome. Well, I have really enjoyed the conversation, but we're not done yet. I'm going to ask you some questions. All right. So these are, these are fun. ⁓ okay. What is the best book you ever read that helped you in business?

    Jon Katz (40:10)

    Cool, cool, I'm excited.

    I don't have a book that I can mention. What I can tell you is that I do read a lot of online content and follow subject matter experts and rely on our peer groups to continue to learn and grow. ⁓ I just really just rely heavily on other peers in the industry. And you're one of those peers, Andrew. And I know you for seven years now and we've...

    Andrew Moore (40:42)

    well that was, that's nice.

    Jon Katz (40:45)

    know, have text conversations back and forth, just kind of thinking out loud and being able to learn and grow together.

    Andrew Moore (40:48)

    Yeah.

    Well, I appreciate that. And I, and I'll say this about, um, you're one of the more engineering minds, I, and I mean that with the most respect possible, because when you're building an operations team and you're building processes, I believe it takes somebody who's got foresight into engineering and mechanics and stuff to look at something in the way that you look at it as a structural system, like almost visually where you're like,

    If I put this piece here and I put this piece here, what does that do to this other output? Like, and it's been fascinating to watch how your mind works because it's not always the same as mine. Cause I look at it more academically and you're very like structural when you're, when you're building out your processes. So it's been really interesting to, to understand how you've applied your backstory.

    right of being just like you're very hands on when it comes to this sort of stuff. it's been the application of that has been fun to watch, right? It's been really cool.

    Jon Katz (41:49)

    Awesome.

    bouncing stuff off of you because we think differently is awesome, really.

    Andrew Moore (41:53)

    Yeah, yeah. And it's funny

    because like mostly today we've actually agreed on a lot of stuff. ⁓ There have been times where we've actually just cursed at each other for like 30 minutes because like, yeah, like you're fucking wrong. Like, well, you're wrong. And then eventually we're like, we're both probably wrong, but we'll find a middle ground. Yeah. Okay. So speaking of, I've just used some fun language. What's your favorite curse word?

    Jon Katz (42:02)

    Absolutely, like this.

    Yeah, yeah, we'll find a middle ground somewhere. Yep.

    Man, this is a hard one. I'm going to go with a straight up generic fuck and not the noun fuck, not the adjective, not the verb, but like you can use it so many different ways, man. You can use it as a prefix, right? Fuck, man. can use it as a, but my favorite way is like an inter fix, right? I live in the town Massapiqua, it's Massafuckingpiqua. That's how fuck is an inter fix. But dude, you could say it everywhere. You can replace any word with it. could be.

    Andrew Moore (42:35)

    Yeah.

    you

    Jon Katz (42:50)

    Any type of word, it's fun, man. Fuck.

    Andrew Moore (42:53)

    I like that's why if I had to pick one, I use it as like seasoning in my language. Like it can be, it doesn't have to be biting and rude. can just be sprinkled in like pepper or oregano. it's, yeah, no, I love that. Okay, this was my favorite question for you. What is your favorite band and why? Cause you're a music guy. So I'm excited.

    Jon Katz (42:59)

    Sure.

    Absolutely.

    Yeah. So I could say the first band that really just took me on a journey and opened up so many different avenues is Pink Floyd, man. That's like my one, if I had to listen to a single band for the rest of my life and like, that's so hard to say. I would listen to Floyd. I mean, you look at their real early Sid Barrett stuff and it's very different than

    when Gilmore joined the band and at the very end before they, not the very end, because that was all Gilmore, but you heard the fighting within the band came out in the music, like the struggles of the overpowering bass trying to be that front man. But again, they take you on a journey. It's more of an experience and a feeling than it is anything. And I love Floyd.

    Andrew Moore (44:14)

    Honestly, like, that's not the first time I've heard that on the podcast. So we've now got a couple of solid votes for Floyd. So I did, I did, I kind of expected that because I know that you're a huge David Gilmore guy, but I am. all right. I love that.

    Jon Katz (44:20)

    Okay.

    Awesome. Awesome.

    yeah. yeah. I wasn't

    always either, you know, like as I get older, I like Gilmore more. I really do. Yeah.

    Andrew Moore (44:35)

    Yeah. Yeah. Yeah.

    Well, and I think I watched, ⁓ there was this really great documentary about the, guess they call them the marketing team that kind of built up around Floyd. If you have a chance to watch it. ⁓ and I'm terrible cause I should remember the name of it, but it was amazing because of how like it wasn't just the music with Floyd, but like all the things that went with it, like the development of the art around their album covers and like, cause up to that point,

    Jon Katz (45:02)

    yeah.

    Andrew Moore (45:04)

    albums were just the pictures of the guys in the band like doing something silly or like standing in a field or whatever and they were like yeah no we're gonna we're gonna go ahead and do like a floating pig or we're gonna be like yeah we're gonna we're gonna create a prism right of light through a triangle like i mean it was just like weird shit that they would do

    Jon Katz (45:22)

    I mean, look at metal,

    that's an ear. No one really knows that. When you look at the album cover, you don't even know what it is. Now all of sudden you realize it's an ear. It's kind of weird. Yeah.

    Andrew Moore (45:30)

    Yeah.

    Yeah, yeah, it's

    really cool. All of it came together for them and they came in the right time, so dig it. ⁓ Okay, so you please don't name names, right? But what is the worst client meeting or sales meeting that you were ever at? just an absolute train wreck. You were there and you were just like, this was awful.

    Jon Katz (45:39)

    absolutely.

    Early in my career, I used to use the mute button religiously. I was angry. I was not as laid back and chill as I am now. ⁓ Man, I'm going to name two things. One of them was a vendor. It was Red Hat, and they were trying to sell us their virtualization solution. It wasn't a client call, but

    Andrew Moore (46:06)

    Yeah.

    Jon Katz (46:18)

    I'm sitting there with our CTO and we're in our old conference room and I just remember like explaining our private cloud and what we're doing there and like he kept like not understanding and like pushing this one piece, one piece, one piece and I hit the fucking mute button and I was like, this guy doesn't fucking listen. And then like there was this long pause and all of sudden he's like, I'm sorry you feel that way. Me and Chris looked at each other.

    Andrew Moore (46:45)

    Hahaha!

    Jon Katz (46:47)

    I left the room cracking up. don't know how he stayed in there, but he ended up finishing that call. ⁓ And then I have another, yeah, you know, I probably shouldn't mention the other call, but it's very similar. We have our own VoIP company and we were testing phones for a company and we were beta testing a handset and the mute button didn't work with the headset connected.

    Andrew Moore (46:57)

    That's amazing.

    Yes.

    Jon Katz (47:17)

    And I had said something, needless to say, we lost the client. ⁓ But it was, ⁓ again, early in my career, just, I didn't have the restraint that I have now. I was a little uptight. was angry. was, why don't they understand? So I hit the mute button, I said something stupid and regretfully said something stupid. ⁓ And we ended up losing the client over it. ⁓ But yeah, that's beta testing a handset.

    mute button didn't work with the headset.

    Andrew Moore (47:48)

    That's the, those are amazing. And I've never heard those before. And so that's fantastic. ⁓ I love that. I love that shit. so if, if I were to, ⁓ if I were to try to schedule another podcast with somebody that totally kicks ass in this, in this industry that has a very unique opinion, it was great at what they do. ⁓ what person, not necessarily a group, like what person would you recommend in the MSP space?

    Jon Katz (47:55)

    Yeah.

    I would recommend,

    I know right off the bat, man, we've been working closely with them lately. ⁓ It's our halo consultant, Connor and his team. Connor specifically made us think very different about ⁓ our tool set and how we use our tools. Renata Solutions, they're fantastic. I would say Connor over there, if you can get him on this podcast, he's awesome, he really is.

    Andrew Moore (48:38)

    ⁓ I can't tell you what an honor it is to have a chance to speak with you today. This has been absolutely fantastic. you're one of my favorite people on the planet, not just in MSP. So, ⁓ you and I have spent many a late night catching up about like life and, ⁓ our jobs. So I just thanks like you're, you're a completely kick-ass human being and a great friend and a wonderful dad and

    ⁓ husband and I just look up to you a lot and so I just want to say thanks for being on the show.

    Jon Katz (49:10)

    Andrew, likewise, man. I mean, you've used all the words that I could possibly potentially say back to you, but bro, you're the man. I appreciate you thinking about me to come into here and to chat with you. And it's always a pleasure, it really is. ⁓ I know we haven't seen each other in person in a while. ⁓ We gotta plan something. It's been like a year.

    Andrew Moore (49:28)

    It's yeah,

    I know, know we'll, we'll, we'll this, this, this year, 2026 is the year we'll get together. We'll get like, need to get, I need to get up to New York at some point. So maybe that's just what we'll do. I'll just go.

    Jon Katz (49:36)

    Sounds good,

    I

    think that's the last time I saw you. When we said when to see Billy Joel. Yeah, one of his last shows. Yeah. Yeah.

    Andrew Moore (49:44)

    We did go to see Billy Joel and that was awesome. I know. like, it was like last minute and we totally got tickets

    and I was shocked and it was completely incredible. And we sang piano man and New York state of mind with 30,000 other people and it was awesome. So it's tough. All right, man. Well, take care of yourself.

    Jon Katz (49:59)

    Yeah, yeah, it was awesome.

    You too. Much appreciated again, Andrew. Thank you.

    Andrew Moore (50:05)

    Thanks, buddy.

    Andrew Moore (50:07)

    Well, that's it for the How to MSP podcast. We'd like to thank our special guest, John Katz. We'd also like to invite you to subscribe to the show on Apple, Spotify, or your favorite podcasting service. If you're watching us on YouTube, like, smash the subscribe button. Every like and subscription helps us find new listeners. Thanks, and we'll see you in a couple of weeks.

    Description text goes here

Next
Next

How to Build an MSP Account Management Process (That Doesn't Suck)