Subscribe
Share
Share
Embed
Today I'm excited to bring you a really insightful conversation with Brian Largent. Brian brings nearly two decades of experience running an MSP that specializes in co-managed IT services, particularly in complex and regulated industries like healthcare and manufacturing.
In this episode, Brian and I get into the nitty-gritty of co-managed IT. What it means, why it's not just for large enterprises, and how his team lives and breathes this model for clients, unexpectedly in rural markets.
We dive into the real challenges and opportunities of working alongside internal IT teams, what makes for a successful partnership, and some lessons learned from both our journeys in the MSP space.
Whether you're an MSP looking to branch into co-managed services or looking to improve your co-managed offering, you'll get a ton of actionable insights from this conversation.
This episode is brought to you by Opsleader Pro. A place for MSP owners and managers to get the systems and tools they need to build a stable and growing MSP. Part group coaching, part peer group, everything you need to run a successful MSP.
Evolved Radio Podcast: Interviews with technology experts, industry thought leaders, business leaders and other interesting minds. Exploring the evolution of business and technology.
Thank you. Thanks for having me. Great to have you. So if you
could maybe start us off, we're going to be talking about co managed
and just to set some context here, if you could
give a bit of background on your company.
How. Long you've been in business and other operating notes.
Sure. We are been in business about 18 years. I
started as an infrastructure person, IT manager, IT director,
worked at a bunch of different companies. And
in my early days, when I first started getting into computers, in my
early 20s and I'm 52 now, to put that in perspective,
I got a computer, I loved it. I got addicted to
computers and upgrading them back in the 86 days
and we used to go dumpster diving, pull computers out of dumpsters and build
home networks. And when ebay became a thing, I buy
network switching and stuff and I just started building networks. It just became like a
passion for me to do that and parlayed that over time into working
in IT and did that for many years and then started
my company, like I said, about 18 years ago. And the impetus for our company
was I had several friends that were doctors and they were telling us about
this HIPAA thing and he said, hey, we're charts or paper? Charts. I mean,
we need to get this EMR system and we got to get all this electronics
and we don't have any idea how to do that. Can you help us with
that? And I went and read big chunk of the omnibus rule and it's like,
oh yeah, this is just enterprise IT being foisted upon small practices in
the name of efficiency and safety.
Efficiency, exactly. Yeah. The more portable your
data is, the more secure it is somehow. But anyway, that's all other
podcasts right there. But so that kind of got us
started and we had a couple of medical clients early on and a couple of
manufacturing clients and just kept growing and growing, shrinking, growing,
shrinking, failing and succeeding off and on, trying to go out of business every
couple of years and failing to go out of business.
And it kind of got us where we're at today. So we're right now we're
at nine employees. We're out of Tulsa, Oklahoma. We primarily
work in regulated industries. Healthcare was our primary. We've since
shifted to do a little cmmc, a
little dod, some manufacturing. And I love to tell
people whenever I go to talk to prospects is, you
know, we take care of everyone from hospital clients all the way down to we
have a hair salon. You know, it's people that like the way
we serve our clients and they're willing to pay a fair price to get the
really rapid response and the knowledge that we bring to the table. So that's
my long worded response to a simple question. That's perfect.
All right, so the predominant delivery model that you guys run,
well, maybe it isn't predominant. You can, you can sort of fill that in if
you like. But a big section of your business is co managed, which
is not typical for a lot of organizations unless they're working
in enterprise or at least sort of large mid sized organizations.
So maybe if you can spend on that a little bit. I'm curious sort of
how that happened and why you view that as an important model for how you
guys are deploying delivering for your clients. Sure. We got
into it originally, of course we're in healthcare and
when Covid really ramped up, there was a lot of funds pushed into rural
healthcare. And as those funds got pushed into rural healthcare, they started
looking for companies that could help them with securing their
environments and to do all these different things. And that was, we did
have co managed before that, but that was what really kind of got us more
into the co managed is trying to really serve these rural healthcare clients.
And so, you know, we came in, did, we started
doing assessments for hospitals, started with risk assessments, partnered with a couple
of different risk assessment groups external that had the
tool set that we used to be able to do those and started presenting the
findings and figured out that they, you
know, I shouldn't even say we figured out. You kind of know rural hospitals, they
don't have the local talent to really manage their
infrastructure. And Todd, you've been in the MSP space for a very
long time and you understand just how important it is to
touch a bunch of networks and to work in a lot of environments. That's where
your skill grows. If you are working in a rural hospital and you've got
five hyper V guests on a physical host,
you're stagnant. You're going to be, you can't not be stagnant now you can be
getting certifications, but you're not touching enough environments and enough different
infrastructure to really get a well rounded understanding. And so
as an msp, we kind of parlayed that into hey, we touch a lot of
environments, we touch a lot of rural hospitals. We can take our experience and
knowledge number one and try to keep your costs down because they don't have a
lot of money. Right. The COVID funds dried up really quick. They didn't last
very long. And hospitals oftentimes, especially rural hospitals,
work on Grants so they don't have, they don't know if they're going to be
able to pay your bill two years down the road. So we came in
and we tried to work around their funding cycles, the way they function, to
give them at least the minimum necessary security they
needed for their environment and the amount of support that's timely that
they needed for their environment. That was kind of the impetus and it's where we've
been mostly along the way with some shifting into more trying to
coach our clients on how to manage their internal infrastructure teams
as well as how to use those teams in conjunction with us. That's, that's a
bigger topic I'm sure we'll get into as we go. Absolutely. So many, so many
threads to pull on there. Yes. Maybe to start with the first one that
I think is bang on is I always talk about co
managed the model like the value
that you're often bringing is either subject matter, expertise on a
particular technology or as you kind of stated like breadth of
knowledge and you know, two parts is I often tell people like
the value of getting started in your, in your career
in an MSP is dramatically different than working
in other environments for exactly that reason. You know, when people are sort
of like pulled away from an MSP potentially, you know, they hear
the siren song of X amount of dollars and, and you
know, simplicity and not you know, low stress of going into
corporate it. It's like well you better like what you're doing in that
job because that's all you're going to be doing for the next seven years. Right.
So that to me is a huge, huge benefit of working in this environment
and as you say like bringing that, that level of knowledge and
experience to, to those customers is huge because
as even a mid sized organization to be able to hire
a team with the relevant knowledge to cover all of your infrastructure
and then be able to scale and grow with it is kind of an impractical
ask. Right. So I think that this is a huge value that I think is
really understated by a lot of MSPs that
they have this capability of understanding sort of trends and
environment and can lend that to an internal team not as a
replacement but absolutely as an augmentation.
Absolutely. And you kind of help them overcome the
bureaucracy too. Right. I as a third party
can say what needs to be said, whereas the internal IT guy whose
job is on the line is going to be far less prone to say what
needs to be said. It's like you know, our, we've got when give you a
good example. We got Windows 10 computers. We've got a night
a hospital that has 500 computers, let's say rural
hospital, and they're all Windows 10. Well, we all know that's end of life in
October of this year. But the guy that's managing that's like, well, you
know, I could, I could hack together and make these work. There's like some things
we can do to maybe make them run Windows 11. And we
come in and we look at them and said, oh, those are over, you know,
you know, they're at 5 years old, they're
Windows 10. We don't want a hacked solution. You have a hospital, people's
lives. I can say those things and not worry about it. Because
honestly, if you fire me, there's someone else lining up to be told the truth.
If you don't want to tell the truth, if you don't want me to tell
the truth. I'm not your, I'm not the guy you want to work with as
a consultant. I often say you pay me for my opinion, whether or not you
like it or not. Exactly. Exactly.
But we do get to cut through that bureaucracy of these
hospitals and other. Any large organization has bureaucracy.
Years ago we did work for an organization. I'm not going to name
them, but everyone was related in this rural hospital.
And I say everyone. I mean like every
doctor's kid worked in the hospital. And it was like, no wonder you guys are
a mess. Everyone is worried about the hierarchy of how things operate
here. And so we were able to come in and say, you got to re
cable the hospital. You're running non plenum cable in a plenum
airspace. You're doing, you know, all these things that you're doing that
are bad. You need to fix them. And they were able to
say, you know what if we pay you to do it? We're not stepping on
anyone's toes. We're not. You know, it's just easier to have you guys
do that work. And so that was been a real nice segue for us to
cut through the bureaucracy, tell them what they need to do and then they can
save face with their internal departments and let us handle it. Yeah,
so the other one that you touched on there, I think that's, that's super important
and we'll probably spend a bit of time on this is sort of
the, the relationship between internal IT and
external party. Especially in a co managed like there's a delicate dance that
happens there and maybe we'll Start with sort of like the getting to know
you phase, where like you show up as an external party and internals
like, oh God, the consultants are here. I'm going to lose my job. I have
to look, you know, like I know what I'm doing and, you
know, potentially sort of cause a bunch of fud and undermine the
consultant so that they don't end up replacing my job. So, I mean,
I'm sure you see sort of that, that, that tension that exists
there. How do you guys address that when you're first started making your way into
an environment? You know, it's interesting because sometimes you're brought
in to do exactly that. I mean, right. They know they've got a problem
and you're actually being brought in to clean house for them. It does happen.
More than anything. It's having a candid discussion with the person who's bringing you
in. Oftentimes the CFO's over it. And hospitals and other
organizations. I'm sure you've seen that. I don't know why they think that. Well, it's
a cost because it's a cost. A lot of money.
Usually the CFO is bringing you in, and sometimes the CFO doesn't have
an understanding why he's bringing you in. He just thinks things aren't getting done. But
he's also clamped down on the internal. It's where they can't spend money and
do the things. And he doesn't trust that they're giving him good advice. I would
say the majority of the time when I come into an organization, what we
find is they're not spending money in the right areas
and that I have to have a candid conversation with the cfo. It's like, I
can't solve your spending problem, that you won't spend money. I can't
solve that. What I can tell you is this is how much IT costs
per person. And I can go back to the.
I'm going to forget the name of them just because now I'm talking, but I
can go back to some of the studies that are out there on how much
it costs per employee in a rural hospital or any hospital
setting to provide them with IT services, security. And it's not a small
number. I remember at one time it was like $7,500 per employee per
year to provide them with the IT services and security and everything that they
need. And so I can go back and I can talk
about that. And what I try to do is I try to say, in your
industry, this is how much support someone needs. And I like to point to like
Gary Pica and Peakonomics and he talks about, you know, the
average amount of support and maintenance that a person will need within an
organization. And I walk through that with them and I say if this
is true. And I believe it to be true because I work with lots of
organizations. If this is true, your problem is you're not spending
enough money in the right areas. And it's usually the right areas, right?
It's not, you're not spending enough money. It's like I'm going to bounce
around here. So I'm going to give you another great example and I'm sure you've
seen this as well. You go to a hospital and they've got a
hundred thousand dollar storage array with 100 employees
and you're like why do you have that? Well, the IT guy told
us we needed it and he brought in a consultant. The consultant said that's going
to save everything and make us all very, very efficient. And I'm like
no, you could do all that on a nice server for
maybe $20,000 and have some virtual hosts
and tell me what you're even running on that and you find out that
it's, it's really doing nothing. But someone sold him a bright shiny object. The
IT guy that worked there wanted to play with it because he likes toys and
now he has no budget to do, you know, Zero Trust or
edr, the real things that they need. And what's funny, in
those situations, the IT guy is wrong. You know, he's, he's
either not skilled and trained enough to know what are the things that are most
important to the organization or he's misguiding them to get the toys he wants to
play with. Right. So anyway, I'm sorry, I'm kind of bouncing around
a bunch of places. That's great because like, like all of these threads are things
that I can, I can pick up because like I have all of these experience
like for those that like don't know like from, from listeners and perspective
is like, like I'm immersed in the MSP environment but like
my, my original and sort of where bread and butter where I
grew up in it was enterprise and mid market. Right. So like I worked,
I oversaw multimillion dollar co managed
teams embedded in some of the largest oil companies in Canada,
the largest airlines, all of that stuff. Right. So this is all very,
very familiar to me. So the other
thread that you noted here I think is this interesting aspect of
enough or not enough, right? Like where that internal IT person
is setting a budget and trying to manage sometimes to the best
of their ability, but other times like they are just building their own personal
playground. And yep, it's incredible the number of times that you see
this where there is sort of that misguided application of technology. You come in
there, you're like, what is all this gear for? And you can really like get
an idea like they don't know what they're spending money on. The guy is just
sort of building stuff as a, as a hobby to like play with things and
have that environment. But you also see the opposite where there's some
guy who is like, who he is like trying to save them every
dollar that they can and undermining the business. Same time it's like,
oh well you know, I was able to keep this thing together and you know,
I got this, this cheap server off of ebay and all
this stuff. Right. It's like neither of these are a good option
basically. Right. Like don't overspend to, to, to your other
point about sort of budgetary numbers, a good one to sort
of reference with people that I find is, is an industry standard number
is your IT costs. Your technology spend for
a business should be 4 to 6% of total budget. And like for
a lot of people when they do that back of the napkin number, they're like,
holy crap, that's a lot of money relative to what they're currently spending.
And they're like, yeah, like you guys are probably underspending on technology.
And I think it's an interesting aspect that you raise as well is like maybe
they're not actually underspending, they're just spending in the wrong places relative to
what their actual business needs are. And this is exactly what we're talking about of
like bringing that consultative angle to these conversations rather than just being
beholden to. We have this one guy, he's the tech expert. He kind of tells
us what to do. We don't know if he's right or he's wrong. We can't
judge that. And that's a really sensitive position for a business to be in.
Well, I love the three legged
stool. Good, fast or cheap, you can only choose two. Right. And so
in that case, what we find a lot of the times is organizations
and I'm talking about even just MSPs, we start to go toward cheap because that's
easier to sell on. Right? Well, I'm the cheapest. And then you claim to be
good and fast, but you're really Just the cheapest. Well, when you do that
long enough, you end up where you don't have the bandwidth to truly
provide the service that you claim to be selling. And then
you implode. Hospitals, specifically, they have more or less a fixed
income, Medicaid, Medicare, all those kind of tell them what they can reimburse for, especially
rural hospitals. And so when you go to them and you say you need to
spend up to 4%, the hospital looks at you, say, I want a fixed budget.
I cannot, I do not have the ability to do that. And,
and so we then have to do is help shape them to look at, well,
where is your money going? You know, and I hate to say it because
I've done this before and it never goes over well, so I have to be
careful not to do it. Is I'm like, okay, well where can you make more
money? What can you do? You guys got to think outside the
box instead of thinking inside the box. What can you do? And there's things like
critical access, hospitals, there's ways that you can shape
up your hospital to do different things. There's grants that you can go after.
And so they have to sometimes be able to get the things that they really
need. They've got to go find those opportunities. We try to help them find them
as well. There's third parties that you can work with just watching,
like Microsoft ran a big thing about a year ago for rural
hospitals and other hospitals, I think all hospitals where you could get real big
discounts on their solutions for a period of time. But
that's a hard discussion. It doesn't always go over well, especially when you're talking to
the CFO and you're telling him he needs to do more to bring more money
in so he can meet the minimum security standards they need to protect
their environment. So you got it. That's really. You got to really kid glove
that. But when I go back to the good, faster, cheap,
you can only choose two. In my msp, we
started out trying to be all things to all people. And then we
decided we wanted to be good and fast and we knew we couldn't be cheap,
but we had to be appropriately priced. And that's a learning thing.
That's something you can't just go out there and say, and I'm sure you see
this all the time in discussion groups and people will have out there, how much
should I charge? Oh, wait, no, that's not a real question. That's. You can't even.
There's nowhere to start with that. You know, it's, it's. Well, I used to make
80,000 a year when I did help desk. So I just want to make,
you know, $40 an hour, $50 an hour, and be independent. Like that's not going
to float you very long. So. But being good,
fast and cheap, if you are too cheap, you cannot scale
into delivering those services that you need to. And the same is true of all
of your clients. And so when we talk about co managed, I'm trying to bring
this back around. When we talk about co managed, when you get into a client
and you walk through the facility and you see that it's a
bit of a shambles. You know, the building hasn't been updated in
50 years. You know, people are using very old
equipment. When you walk through, you've got to make a decision right then
of can I accept them, give them just the minimum
service and just walk away from knowing that they're not going to be in good
shape. Can I make that work or can I shape them into the company
I need them to be to make our services and all that we want
to do with them work? Well, the MSP coaches, a lot
of them will say walk away when they're like that unless they're all in.
And I don't agree with that. I believe that there's always value in
every opportunity. You've got to be smart and wise enough to be able to
find the value. But do your risk calculation to make sure you're not creating
too much risk for yourself. And we've done a pretty good job on that in
the last few years, so. But not everyone's a good fit. No,
agreed. And I think that is a really important aspect because I agree with you
that the absolutes that get floated
in the industry around best practices are a little dangerous. Right,
Agree. I think that lends to an interesting question of do you believe
that there is sort of a rural discount that happens,
that if you're in a smaller regional market that automatically you need
to price lower? Do you believe that that's true?
I do not. Well, so I'm a firm believer that
your price is your price is your price, that you put your effort and your
time into figuring out what a good price and that you can deliver good service.
We used to get asked all the time and it used to frustrate me to
no end with nonprofits. They'd say, well, we are a
nonprofit. We don't have a lot of money. Can you give us a discount? And
the answer is yes, but I can Also discount the quality of the service you're
going to get from me. And you don't want that. If I'm having to make
a decision when we're really busy, the company that's paying me, you know,
$220 an hour or the nonprofit that I'm charging $60
an hour and I write off half of their bill half the time you're going
to get pushed out of the way. So do you need good support or do
you not? And so I never discount any prices. I will
discount the service. In other words, I'll say here's 20 things in
our standard stack. You are in a. And I always,
I always quantify. So you're not in a regulated industry. You don't.
If you get compromised. Here's your risk assessment. We talk about
a recovery point objective, recovery time objective. How long can you live
without your data? How long can you. How much data can you afford to lose?
And if those are really long times, if someone says I can be down for
a week and I can lose a week of data, we can recreate all that.
We've got paper that we do a lot of stuff in. I can still serve
you. Maybe I roll out EDR to your endpoints and I give you
a help desk service co managed with your team because they don't have
enough people to do that that might be a good fit for you or you've
got a help desk person or two or three and they don't
have the breadth of knowledge to manage the infrastructure. So we manage your Azure environment.
You. So the answer to that is
we never discount. Like I don't have a product that's $5 and I go to
a rural community, I make it 250 never. I have a product that's $5.
I have another products that's $5. Another, you know, all these different products priced
differently. I remove products and I remove what we're giving the
client and to get their price down and I educate them on
you're losing this. Here's why I feel like this is viable for you
and then you can sign the agreement. Now I will tell you, and
I'm sure you've seen this, all of our insurance companies
serving MSPs are scared stiff, right? They literally
the one we were using, which is a great company, we switched recently because I've
got a partnership with National Insurance Company we're working
with but they've all sent me these documents saying,
do you have proof that your customers refuse all these
security controls that you recommend? Right. So they want me to create that,
that plausible deniability. And I get it, I understand where they're
coming from. So what we've done is when we do quotes for a new
customer or renewal, we list all of our security controls, we use
quoter as our quoting system and on there when we do, our security
controls are listed and it's everything from a NIST baseline, like an actual
project in there to each product, like
keeper security. Things that we don't mandate but we do recommend. So
when they go sign it, they can check the box to add it or not.
That's my plausible deniability. And so that gives me a
degree of safety that my customers have rejected the
controls and the recommendations and it's even called recommendation recommended add
ons so that I can then sell them what they want
but have a degree of security myself. So that's interesting because like
I wanted to ask, like, are there base minimums? Like what disqualifies a customer
customer? Where you meet with someone, you're like, I could probably help you but I
choose not to. And if it's not necessarily price, like
is there sort of values judgments there or like just
the interactions, the vibe that you get from them, how like what are some circumstances
where you're, you met with a customer who you probably could have helped but chose
not to because of risk or value alignment or whatever that was that that
sort of rubric was. You know, it's interesting about, like I said,
about a year or two ago, we started to stop saying no as
much. We spent a year where I rejected about a million dollars in revenue for
our company because they didn't want to go on full service. They didn't want everything
in our stack. And after that I had a come to
Jesus moment with myself and my sales team and my infrastructure guys
and I said we got to find a way to serve these people.
This is ridiculous. It's because I bought into the Kool Aid of the
full msp all or nothing.
Everyone's got to buy everything. And they do. They the people that are marketing that
sell you on fear, right? If they don't buy everything and something happens,
you're going to be liable, right? If they don't have
EDR with Sock and they get compromised, you're going to be liable.
So I bought into that and I don't disagree that
that's the best way to go. My clients that are on our full service are
the best relationships I have. They value what we do.
We charge enough that I can give them very Fast response, very
fast resolution. But we've got to say
yes to more companies, especially if you have an economic downturn.
The MSPs, in my opinion, that are full service are going to take a beating
if we have an economic downturn. Because everyone that has a laptop and
says they can do it for $80 an hour is going to get
your business. I mean, it happens. So how do we serve those
people? How do we keep that cost down and give them the value
that they need? And we came up with a minimum subset of security
controls and services and they're pretty inexpensive. But I
will say this. There's never going to be a time that I'm going to go
to a company and say, for example, if you wanted to go
on our lowest Tier and it's $300 a month, it's not going to include support,
right? It cannot. And so
that $300 a month, how much labor is actually in managing that
agreement? We're a connectwise shop. We use a lot of different tool sets to do
a lot of things to make our lives a little more efficient. But in that
agreement, how much labor do I have to put into invoicing you? Are you
arguing about your bill? Do I think you're gonna argue about your bill? Are you
super cheap or do you get it now? Here's the way I look at that.
We had a client about a year ago that bought into one of our agreements
at that low tier. And every month was I don't know where my hours are
going. Cause we were doing a block agreement for them. I don't know where my
hours are going, I don't know what I'm paying for. And that
agreement, we don't have that agreement anymore. I'm going to give you a. Let's see,
I'm trying to figure out how I bounce around so much.
The agreement we had for them was when our first attempt at doing not
full stack and it was here's a bunch of security controls
and you buy so many hours per month they expire after 90 days. Just kind
of a typical block agreement where they carry over and expire after 90 days if
you don't use them. And what we were doing is, we were saying here is
your security stack at say 50% markup on, on
the agent cost. And when you need us, we're gonna do
work and we're gonna deduct it from those hours, say five hours a month or
something. But if your security agent flags for a virus, we're also
gonna deduct from Those five hours. Well they had so many problems in their networks
they didn't wanna fix anything. Cause they were cheap that they were using up all
those hours with us doing maintenance, trying to hammer away to get Windows patches
to apply to systems that were messed up and so on. And he
came to me and said I don't know what I'm paying for, we're gonna go
with someone else. And they went with someone else that was just a cut rate
provider. And that's fine. That's actually the. And so
we learned from that. We said okay, there's no way we can do a block
agreement where we're actually covering those base services. So our
base always includes support on whatever those agents are, be it
edr, what have you. And so if we're going to do a low cost,
it's got to include the support in the agent fee. And then they don't have
that question. And then we do what we call retainer where they put so much
money down in a block. We're not doing monthlies anymore. They have to have a
minimum block of retainer and then we deduct from the retainer. And that's only for
reactive. Now reactive is we're monitoring, we may notify
them that they had an incident that we could not remediate. Like
saying using Sentinel 1. We couldn't remediate it remotely. We notify them and say
do you want us to remote into the computer and fix it or do you
want us to roll someone on site? They say yes, that is them doing
reactive. Right. They're saying yes, go take care of this. Then we built from it.
So sorry. Yeah, okay,
cool. So let's, let's roll back to the
internal IT relationship. The other aspect of this is,
and you kind of, you noted this a little earlier and I see this
as a really prominent problem where. And I think we talked about
this earlier when we connected that the standard
applied to an external consultant versus an internal IT
person could not be more different. And it's
incredibly frustrating for an effort for a consultant at an msp.
You want to sort of expand on your experience with this?
Yes, we trying to figure out where to
start on that. I want to be very cautious. I don't want to throw any
of my clients under the bus on that.
I have yet to go and do work for a
customer in any industry that we do co
managed where they manage by the numbers
and that's it's mind because people will be in these companies, you know, 15,
20 years. They started Help Desk and now they're the CIO
or they're the IT director. And I think what it comes down
to is the impetus to manage by numbers in the, in the
infrastructure side. Private sector is not really
there because the people over you just want to know things are being work. They're
working, right. And when they don't work, everyone accept that you have problems
in the MSP space. We don't accept that because problems mean we
lose money. Especially on all inclusive agreements. Right. We need as few problems as
possible. We need to make things work and they should just function.
So the difficulty for us is we manage by the numbers. We
are attraction EOS shop. We've probably got
100 KPIs that we track between project team,
help desk and so on and we run like that.
And so what I try to do now, and this is
relatively new in the last year, is I try to take how we operate and
when we meet with a co managed company, I talk to them, I show them
like we use Stretti for managing our traction. I'll pull up our internal
Stretti and I will show them the metrics we manage our help desk team by.
And I'll say look, it's important to manage how many tickets are they getting
done, what is their average billable for? For a client that's not
billable but it's productivity. Right? You gotta be at least 80%
billable is what we call it. They have to be 80% productive working on
things that move the company forward. And you
gotta have how much time on ticket, you know all these things. I know you
do all the training on all this so this is nothing new for you but
you gotta have those things and does your system support generating
those numbers? And nobody does. Most of them are still using email for a
ticketing system or they're using spiceworks.
Spiceworks a good tool but you're not going to get those KPIs. You can't manage
your team by numbers unless you have a tool that does it. Streamline it
for ConnectWise is not. It's got its problems but we
can get all those numbers right and we can then help them manage their
team. That's like pulling teeth. That's hard to do. We're still trying to
figure out how to get our clients, our co managed clients to start to run
their business by the numbers. I bought. I'm sure you know Bob
Coppage, I've got all his books
and I'm trying to go through his going, okay, what, what can I garner from
Bob, to, to really help me get this,
this message to them, to manage by numbers so we can match our numbers to
their numbers and help them really make sure they're being productive. Yeah, I
like that approach of it being educational. Right. Because, like, and to your point of,
like, not throwing people under the bus, I don't think any of this is malicious.
Like, I think this is just sort of a misunderstanding and sort of a
lack of context of how to apply those systems and frameworks
to, to an existing business. Right? Because you meet
with a lot of, you know, say it's CFO that's overseeing IT and
they know that the person does work. They see them support
staff and fix the printer when it's broken. Beyond that, they don't really have a
good context for how they spend their day because for whatever reason,
it is still sort of this mysterious, magical thing in a business and people are
just like, oh, I don't know, they do all that fancy work over there. There's
geniuses. And I don't get it yet. When they engage
with, with a, with a provider, my issue that I tend to
see is, like, there's a different gear that they kick into in
wanting to hold you accountable when they're not necessarily setting those same
expectations of accountability to, in the internal it. And I see that as
incredibly unfair. It's like, I can tell you, like, like there's
a lot more we could get out of this internal IT person if you were
applying the same rigor that you're trying to apply to us. We're
compliant with this. Yet you've never had these internal conversations
with that. That person. And that's not always the case. Like, I'm not saying
that internal IT people aren't useful, they
absolutely are, but they're also not getting the same level
of training and context and support that you would get as a person in an
msp. We run our businesses in a very particular way,
and a hospital or a logistics firm or something runs their
business in a very particular way. They don't run it the same way that they
run the rest of their business. That's the gap. And what I find
fascinating is just that that piece of, you know, hey, I can help you
to be able to apply these things the same way. And I think, like, to
that point, like, the education around that of, like, this is what it looks like,
what good it looks like, and how this can actually be run like a business
and that if you can get them on board for that education, that's fantastic. And
hopefully that is enough and that works. But what we tend to see in a
lot of these situations as well is like we're doing all the ticketing. We
pass a ticket to the internal staff to pick up and carry on and then
they just go and do some things. They don't necessarily manage the ticket, but then
that's our fault because they don't see whether or not it was closed,
so and so complained. And you're like, you go and look at the queue for
the internal IT guy and they have like 10 tickets to stacked up over the
last three weeks that haven't been, haven't been closed out. You're like,
there's only so much I can do. Like it's your staff, like, how do you
manage that tension between the expectations of you
overseeing it. But then, you know, sometimes, and I will stress
sometimes having that internal IT staff, not necessarily sort of
living up to the standard that everyone else is. Setting,
it's really tough. I will say this, I have failed at this at times.
I don't know how many CFOs I've offended. It's quite a few.
I think what they have to understand is the difference between IT
and your finance department. You'd said earlier,
you said that they need to run the IT like they run the finance or
run the other departments. I agree to that to a
point, but I think there's like a nuance to that.
So if we talk about a finance team, and I've never managed a finance team,
but I just kind of watched the this, right? You've got mostly
professionals, college educated people that have, you know, finance
degrees, CPAs, all the way down to maybe some clerks and people that
do things. But if I'm a CFO and an invoice doesn't
go out, that person failed. There's my metric, right? If I'm
a CFO and the. The entire network is down, what is my
metric? Because my IT guy just says, oh, it was
an update. Oh, it was outside our. He doesn't know. He can't go
and say, just like an invoice, hey, why aren't you invoicing? And
that person says, well, you know, I forgot to
generate. Okay, now you're in trouble. But the IT guy gets so much.
I love the term plausible deniability. He gets so much plausible deniability
because no one knows. And the worst part about that, and do you
remember back, it's probably been 15 years ago now. 10, 15 years
ago, everyone had viruses on every computer and it was never anyone's fault.
It was like you'd go into companies and they'd have 20 toolbars, you know, those
malware toolbars. And they were like, can you stop
this? And I was like, yeah, fire your employees, turn your computers
off. No one accepted responsibility.
And so we had 10, 15 years of managers. And these are,
you know, your CFOs are not usually spring chickens, right? You know, 60,
even 70 years old. And they have ingrained in their mind that
computers have problems. That's to be expected. We're going to have
system outages, we're going to have all these issues. And I just need to have
something to take to the board and tell them this is what happened, the guys
are working on, shouldn't happen again or what have you.
That's not acceptable. You and I know that because we run companies that go out
of business if we make that acceptable. Right? So for us, we have to do
an after action review. We have to go through and figure out why was there
an outage, who failed at their job. How are we going to put safeguards
in place to prevent those things from happening again? But I think that
the problem, the biggest problem is leadership, especially in the
world with CFOs have been trained over years of
time that problems just happen and that's just
the way it is. And they don't understand it. And these are very smart
people, right? They could be it. I always say this about my, my guys
ever start griping about a client, be it a doctor or a
professional. And I said, they can do your job better than you if they chose
to do it. That's not their job. That's why they're paying us to do it.
There's no doctor out there that can't be a good, great IT guy. I mean,
they can, they can store knowledge. Do not talk bad about those
guys. They're very smart. Your, your job. He's paying you to do
the things that are not worth his time. If he's billing 500 an hour and
he's paying you 160 an hour, he's smart.
If he doesn't know how to open Chrome, that's your
problem, not his. And he's paying us to do that and that's great. Love it.
So. Respecting the customer
and like the position that they have in, in the relationship that you're in. Right.
And you make a point that I think had not occurred to me, but I
think is really insightful that like, especially in finance, like
the level of professionalism as a baseline is so much higher than
IT because in a lot of circumstances like especially like internal
IT people they're not even necessarily formally trained,
right? Like maybe they went to college but a lot of them are just hobbyists
that got into IT and ended up with some skills and got a job.
So I think that distinction is actually really important
base expectations. And I think again why an MSP
can play such a pivotal role in this is they can bring that level of
professionalism and validation to the IT department because it
doesn't inherently exist with the person who has just been
tinkering with computers for the last 20 years and knows what they know
but you know, can't necessarily explain that doesn't to the business doesn't really have
systems to be able to manage those things. So it is a bit opaque.
I think that's a huge level of value that we can bring as an external
provider around like you said, like here's how we run our business, here's how
we're able to judge good quality, whether or not people are productive. Like
this is how I would like to see things work in your environment. And then
it really just becomes a question of whether or not the person that
you're working with in a co managed environment or like who steps up who is
actually willing to sort of like work in a more professional fashion versus you
know, the hobbyists. That was like oh well this isn't as much fun anymore,
right? I don't have my personal playground because these guys are calling
bullshit on occasion. Right? That's it.
We do run into that, you know. You know, it's.
You'd mentioned earlier, you said something about how do I deal
with the people who maybe think I'm trying to take their job. Right.
And those guys who have made it their personal playground. I
tend to tell the people before I go into any kind of co managed environment
is I'll say look, if you don't have a good solid
system if you're bringing us in because you don't trust your guys, just expect
they're all going to quit. And when they quit I can help you build a
good culture. But it's going to be around numbers, it's going to be around the
way we operate ourselves. I honestly yet to have
anyone take me up on that. I've had, I have customers now
that that have good internal it but I'm still
working to try to get them to use our numbers to those teams and to
use the right systems to manage those teams. Some we're seeing some
improvement along the way. I wish it was Better than it is,
honestly. But we're still working on that. I'm actually,
I'm writing a, trying to write a book as I have time
of how to use what we do as an msp. So I came from infrastructure.
You came from infrastructure. When you work in an MSP that is really
efficient and you figured out your numbers and it's starting to really click.
That works in an enterprise. I mean it really, you talk about
running an enterprise, it. I wish I could go back to my previous enterprise
jobs with all of my knowledge and put these systems in place for
those organizations. I mean just. It would be amazing. It would be, it would
be just fantastic. So I'm trying to get a good
book together of what I've learned from the enterprise. Going from that
to running an MSP and trying to rewrite that back to the enterprise
of you need to do this. And then once you do this, you
decide what your strengths and your weaknesses are and then you can go and analyze.
Do I bring in a help desk team to outsource? Do I bring in an
infrastructure team to outsource? If you're rural, if you're in a community that
doesn't have a lot of highly skilled people, you should not be outsourcing
your help. That or your, yeah, your help desk, maybe you can get those guys.
But outsource your infrastructure and if you're in a large community that
has lots of smart IT guys, well,
maybe you need to outsource your help desk and keep your. Anyway you
get, I'm jumbling it up. That's exactly the conversation that I would have with
organizations when I met with them. When it was obvious it was a co managed
situation. I said, look, your team can be good at support
or projects, probably not both at the same time. So which role do you
want us to play? And then that I would often have that conversation with
the internal staff saying like, look, we're going to take all the back end the
projects, the complicated stuff and you guys can continue to work on supporting the
users like you're good at it. You have subject matter expertise on, you know,
the vendor software that you guys use, the isms of all of the
stuff that goes on. You have good relationships with the staff and now you're gonna
have time to focus on those things and not like leaving projects on the, on
the vine to die. We'll go and take care of those things and make you
guys look like rock stars or the opposite of like you guys
understand sort of the direction of the company. You can work on the projects, we'll
take all the BS of dealing with the user so they're not distracting you all
day from the projects that you should be working on. And that sets up a
much more sort of like a more clarity in the situation of
like, I'm not coming here to take everything, I don't actually don't want it. Like,
it may not work for us and for these reasons. So, you know, here's
how we're going to split division of duties so that both of us can look
good. Right. And I think that's. That's a helpful way to sort of position things.
And generally pretty true, right? Like, maybe there
are certain circumstances, especially back in the day when we were more var centric,
that we didn't really want help Desk. Right. That was not what we did.
And NMSP is different. Like, hopefully we're better at both of these
now, but internally there's just not again,
that breadth of knowledge and exposure to all the relevant technologies to
be good at project delivery. Right. Like, you're good with systems, you maybe understand the
network, but, you know, could you deploy a complex VLAN
structure with a VoIP installation? Right. Like, yeah,
that's probably beyond what you've been exposed to. Right. So it's perfectly
reasonable that there is an external party that you can rely on to be
like, yeah, I don't know how to do that. You guys go ahead and do
that and like, maybe you can give me some training. So I'm up on it
and I can kind of support the end users once you're done, right?
Yeah, absolutely. It's. Speaking of that training, that's something we
do quite a bit. We actually have a prospect we're
talking to right now. They've got a very tight budget, they
are investing heavily in growth
and they've got, they're currently with a large national MSP
and the price is not. It's cost prohibitive for them to be able to
grow. And so we looked at it and we said, well, everything they're offering you,
we think you should have. You know, we think that that's all viable,
but we understand where you're at, so you have to make a risk calculation. And
we helped them make the risk calculation and they decided that they were able to
tolerate more risk for less cost and so we were able to give them that
solution. It's.
I apologize. I'm kind of getting myself derailed on this stop.
I forget where I was even going. I had a point there and I've lost
it. So you got an edit right there. Just mark that point.
I do have, I have one thing I wanted to bring up and you
might want to ask the question, but the thing that I want to bring up
is how you work with your co
managed client on an ongoing basis. Like how do
you communicate, how often do you communicate, what do you talk about? And I'd like
to, if you want to ask me that question, I've got some pretty good input
that we've learned and struggled with. Okay.
So one of the things we tend to struggle with is how to sort
of best engage. We kind of talked about, you know, the importance of the
relationship with the business owner is obvious there.
I think the importance of the relationship with the internal staff is actually
really pivotal as well. And we kind of touched on why this is important to
be able to set up that relationship so that it's healthy and not adversarial.
What are sort of the systems and processes that you guys utilize to make sure
that you're connecting at the right level at the business side, but also on the
technical side so that your, the relationship stays healthy.
That's a great question. It's one that we didn't do very well on a
couple of occasions and we've had to learn to do it better.
I'll give you what we did wrong initially. So we didn't have a
good cadence of meeting and we didn't have a good,
we weren't using smart goals like to scope out projects. We kind
of went in, said, hey, we can really help you guys a lot. You got
all these things that we identified through our discovery that need to be done. We
need to build those into projects. And we left a little too
much up to the client to determine when we met and what we talked about
and so on. And time goes by and things aren't moving and they're not
moving and they're not moving. Well, like you said earlier, we can get blamed for
that. Right? They have a pro, they should have a project system they should be
tracking and if things aren't moving, they should be communicating to us to move them
themselves if they're a large, I'm talking large co managed
organization. But they don't. But yet they're taking
the helm and we're let, we're, we're abdicating that
role of making sure things are moving forward. So what
happens in that? We didn't start with that as our intention, but you get
comfortable, you start to build maybe some relationships. They've told you some of
their struggles in the organization You've empathized and you're trying
to be kind and not call them out and not push them too hard. And
the next thing you know, you're just the same problem they already had. You're just
the outsourced problem. You're not making sure those things are moving.
So in that case, what we end up doing, we had a meeting
where we regrouped with the client, we talked about it and said, hey, here's the
deal. We have a project management system. We track everything we're doing in
there. Let's track everything you're doing in our meetings. And
we're going to start, we're going to go through every project, we're going to set
smart goals for them. We're going to agree to the timelines and everything. We're going
to track it all in our system. And so we shifted. We created an actual
meeting agenda that we follow for every meeting, which should have started that way.
Honestly, we should. It's silly. We didn't, but it was just so easy to segue
in, okay, tell me your problems, let's start solving them. Or here's our
list. We actually had a whole list of stuff and, and you tell us what
your priorities are and they shifted constantly. So we sat down, we got everything into
smart goals. We got to where we had an
agenda and then every week we have a meeting and we walk through
that agenda and we walk through every project and we literally bring up for
us, it's connectwise. We bring up the project with all the phases and everything in
it and we talk about who's doing what, you know, are they on
track, off track and so on. And we work through it that way. Now
that has been a game changer because now every meeting we have, it's,
you know, you said you would do this. Here's where we've got it. You said
it'd be done by this day. It didn't get done. And we're tracking that now.
And we're starting to create reports on the things that are not getting done that
we were given timelines to do. Now that doesn't push the
organization to fix their internal problems and start to manage
properly, but it does protect you as the provider. And
it's kind of like, you know, either they're going to start
exactly. And they'll either get on board or eventually
they'll have to start changing their processes. But it can't be you
letting them run the way it says. The takeaway from that is
when you do co managed, you have to make sure things are moving forward. And
if they're not, you have to make sure you're documenting what the roadblocks are,
and it cannot be your team. So make sure you've got a
strategy, a plan, a meeting cadence, an agenda for it, and
that everything you're doing has been crammed into those smart goals.
I think that's really insightful and super important. I will underline this because
I think this is a make or break for people working in these
environments. You have to bring the professionalism. Just because the client
isn't setting that standard or demanding it, or in some cases even
participating, that doesn't matter. It's still incumbent on you to
set that tone and to try and make sure that those, those
systems and processes are bought into over time, even to some
degree. Right. Like maybe some clients just don't get on board with all of the
things and the practices that you would like to have. But having some of those
systems in place makes you look more professional and hopefully sort of
gets them to buy in over time and improves that relationship for sure. No, I
think that's super, super helpful. Yeah, I,
from experience, you can get that lulled into.
I'm. We're trying to meet them where they're at, and that's.
You don't do that. You're not meeting them where they're at. You're elevating
them to operate efficiently and appropriately
for the way you need to function, to protect yourself and to make sure they're
moving forward. And if they're not, you have to be able to show that to
leadership. Because I guarantee you, I know this
is cynical, but it's true. I guarantee you behind the scenes, things that aren't
moving are your fault. Whether your fault or not, they're your
fault as far as the organization is concerned. Right. We used
to, years ago, we didn't do tbrs or qbrs or anything with our
clients. And we would lose a client and it would just. We had this problem
and no one ever fixed it. And we go, look, no ticket never got put
in, you know, never saw it at all. And it was, you know,
this printer wouldn't print well internally. Everyone
knew that that had been submitted a dozen times and we just never got it
done. And they were frustrated and no one ever said anything until they turn
with us. Now we do the TBRs and it's okay. We walk around.
Susie. Hey. Anything going on that you need resolved? Yeah, that printer
hasn't worked for a couple of weeks now. Well, has anyone put a Ticket in.
No, they haven't. Okay, well, I'm gonna go fix it right now. We're gonna get
it taken care of. Right? That's, that's what's always happening
in the background. Every customer you ever had, whether it's co manager,
otherwise, you've got to get those things out in the air and
you've got a document when they're happening, when they're not happening. And you've got to
be communicating those to the right people. Like, I'll give you a good example.
If I have a weekly cadence call with the
IT team that is constantly missing meetings or
constantly failing to meet goals, I can't just do that forever.
I've got to have a regroup meeting with leadership to talk about, okay, here's the
issues. And you've got to be emotionally detached enough, which
is hard for me because I get really invested in these things, but you got
to be emotionally detached enough to say, here's the fact.
Excuse me, here's the facts. We had this project, we
budgeted 120 hours. We were going to start on this date, finish
on this date. We are at 160 hours. You guys
are paying us to go to meetings that no one shows up at. We don't
want that for you. You got to figure out how to get your
team to fit in the system that they agree to, and they agreed to it.
So what are you going to do to make that happen? Do you want us
to just keep going the way we are, or do you want to try to
fix it? And it starts to get them to say, what are we going to
do different? And my goal is, hopefully they're going to come to us and say,
yes, you guys have a plan. We get it. We're going to try to figure
out how to fix our systems. Do you have any ideas how we can do
that? Well, yes, I do. Hopefully we
haven't got there yet on these, but we're still working toward that.
And I think that's, that's what people need to recognize is that this is all
a process. And it's sort of an evolution of, of the relationship and
the systems that you can, you can instill, but you have to try to just
sort of say, the clients, they, they don't do this. Like they're not interested. It's
like, well, if you accept that, then, you know, the, the outcomes
are going to be pretty predictable as like, the relationship just doesn't flourish and they
don't see the value, and you probably get, get broken out. Right so,
yeah, but, but as an entrepreneur, not as an IT guy or a
technician, as an entrepreneur, did you make money while it was lasting? Did you
deliver service and value while it was lasting? Can you feel good about it even
when they left? And if the answer is yes, you still won. And that's, that's
one of the things that always, you know, in the different peer groups that I'm
in, there are some people that are really adamant, never do co managed. Co managed
is awful. There's no money in it. The truth is if you do a co
managed project and it lasts a year and you made money and you
managed it appropriately, you didn't, you didn't have a lot of problems and they
decide not to use you after that, you made money, it worked. But, you know,
you got it. You got to make sure that it makes sense and you're making
money. Just because something doesn't last forever doesn't mean it failed. Yeah,
agreed. No. Well, this has been great, Brian. Really appreciate your
insights. For anybody who wants to get into CO managed more,
I think there's a lot of opportunity that's going to flourish in the future and
I don't think people should be afraid. I think it works really well. You just
have to recognize like it is different and you have to be aware of these
things. So I think this has been really helpful in framing some of those things.
So really appreciate your time and have an awesome one. All
right, thank you. Take care, Todd.