One of the biggest things I’ve gained from working in an MSP environment is the variety.
I’m not talking about having a few different applications to support. I’m talking about moving between different customer environments, different technologies, different ways of working and completely different problems, sometimes within the same day.
I’ve worked across Microsoft 365, Entra ID, Intune, Active Directory, Exchange Online, SharePoint, Teams, endpoint management and a whole range of business applications. I’ve also spent a fair amount of time on-site with customers, dealing with everything from user issues and device rebuilds to larger pieces of work such as Windows 11 migrations.
That variety can be challenging, but I think it has had a big influence on how I work.
You can’t assume every environment works the same way#
One of the things you quickly learn in an MSP is that knowing one environment doesn’t mean you know the next one.
You might be very comfortable working in one customer’s Microsoft 365 environment, then find yourself dealing with a completely different setup somewhere else. The same technology might be there, but the configuration, policies, processes and expectations can be different.
That means I’ve had to become comfortable with not immediately knowing the answer.
I don’t think there’s anything wrong with saying, “I don’t know yet.”
The important part is what happens next.
I can look at the information available, understand the environment I’m actually working in and start investigating from there. I’ve found that much more useful than trying to make a familiar solution fit a situation where it doesn’t quite belong.
It’s also made me more comfortable picking up things I’ve not dealt with before. I don’t need to know everything about an environment before I can start understanding a problem.
The variety of work has been a big part of my experience#
My day-to-day work isn’t just one type of support.
There are the Microsoft issues you’d expect, such as authentication problems, licensing, Conditional Access, Exchange Online, Teams and SharePoint. There are endpoint issues involving Intune, compliance and device configuration. Then there are the things that don’t fit neatly into one category.
I’ve built and rebuilt PCs, provisioned tablets, dealt with printers, worked through VPN issues and supported users on-site. I’ve investigated issues using sign-in activity, device state, logs and policy behaviour, and I’ve had plenty of occasions where the first description of a problem hasn’t really told me what the underlying issue is.
That range has been useful because it means I’m constantly having to work out what kind of problem I’m actually dealing with before deciding how to approach it.
Being on-site has taught me a lot as well#
One of the parts of my role that I particularly enjoy is customer site work.
I’ve regularly been trusted to act as the lead engineer on-site, sometimes as the only engineer there, which means the responsibility is slightly different from sitting behind a service desk.
You’re not just working through a queue of tickets.
You have to look at what is happening around you.
You might arrive with a list of planned work and then have users coming to you with issues that weren’t on the list. You have to work out what needs attention first, what you can resolve yourself and what needs to be passed back to another team.
Being there also gives you information that isn’t always obvious from a ticket.
You can see how people are actually using the technology. You can ask questions directly. You can sometimes spot that what looked like an individual issue is actually part of something wider.
I’ve found that particularly useful because it gives me a much better understanding of the difference between the technical problem and the experience of the person dealing with it.
The Windows 11 migration was a good example#
One of the larger pieces of work I’ve supported was a Windows 11 migration involving more than 200 users.
My involvement included readiness checks, on-site support, floor-walking, triage and escalation.
On paper, a migration like that is obviously a technical exercise. There are devices to prepare, compatibility to consider and issues to resolve.
In reality, there’s a lot more going on.
You’re dealing with users who need to be able to work. You’re dealing with different devices and different problems. Some issues can be resolved immediately, while others need to be investigated or escalated.
That experience reinforced something I’ve noticed throughout my time in IT: the technical work is only part of delivering something successfully.
You also need communication, coordination and a good understanding of what needs to happen next.
You start to notice where processes don’t quite work#
Working across different customer environments has also made me much more aware of documentation and processes.
You can have a process that looks perfectly reasonable when you read it.
Then you actually have to use it.
That’s when you sometimes find that a step no longer applies, something isn’t documented properly or there is a dependency that nobody has written down.
I’ve experienced this directly through working on JML documentation.
Some of the existing documentation contained legacy steps that no longer reflected the environment, including old Citrix and Google administration activities. Reviewing that meant looking at what the process was supposed to achieve and then bringing the documentation back into line with what actually needed to happen.
I found that work more interesting than I probably would have expected when I first moved into IT.
It isn’t particularly glamorous work.
Nobody is going to get excited about updating a process document.
But when the documentation is wrong, it creates problems for the person trying to follow it. Fixing that can make the process easier and more consistent for everyone who uses it afterwards.
Escalation has become part of the job#
Working in an MSP also means you’re often working as part of a much bigger chain of support.
There are plenty of problems where I can investigate a long way but ultimately need another team to take it further.
I’ve become quite conscious of the quality of those handovers.
If I escalate something with:
User can’t access application. Please investigate.
I’ve probably not done enough.
If I’ve included what the user was trying to do, what I’ve tested, what the logs show, what I’ve ruled out and what I think the next team needs to look at, that’s a much more useful escalation.
I’m still learning here, but I’ve found that taking the time to structure an escalation properly can save someone else from starting the same investigation all over again.
For me, that’s still part of taking ownership of the issue, even if I don’t own the final fix.
Working across customers has changed how I troubleshoot#
I think this is probably the biggest technical lesson I’ve taken from MSP work.
You can’t always rely on the answer you’ve used before.
You have to understand the environment in front of you.
That has made me more comfortable starting with evidence.
If something isn’t working, I want to know what the device is reporting. If it’s an authentication issue, I want to know what the sign-in logs show. If it’s a Conditional Access problem, I want to understand which policy is actually affecting the request.
The same applies to more straightforward support issues.
What has changed?
What works?
What doesn’t?
Is it one user or several?
Is it one device or several?
What has already been tried?
Those questions sound simple, but they’re useful because they stop me jumping too far ahead.
It has also changed how I think about service management#
This is probably where my recent ITIL learning has connected most with my day-to-day experience.
Working in an MSP means you’re constantly seeing the relationship between people, technology, processes and the services they’re trying to deliver.
A technical issue might be the immediate problem, but the reason it takes so long to resolve might be something else.
It could be missing information.
It could be an unclear process.
It could be a poor handover.
It could be something waiting on another team.
It could be documentation that hasn’t been updated.
Once you start looking at those things, you begin to see that good IT support isn’t just about knowing how to fix technology.
It’s also about understanding how the work gets done.
That’s one of the reasons I’ve enjoyed studying service management alongside my support role. I’m seeing examples of the concepts in the work I’m already doing, rather than learning them in isolation.
MSP work can be busy, but that’s part of the value#
There are definitely days when the variety is the difficult part.
You can be working through one issue and suddenly have something completely different land in front of you. Priorities change, customers need different things and sometimes you have to switch between technical investigation, customer communication and practical work very quickly.
But I’ve found that useful.
It has forced me to become more adaptable and comfortable working things out as I go, without losing sight of the fact that the work still needs to be done properly.
I’ve gained experience across a much broader range of technology and environments than I would probably have seen working in just one organisation.
More importantly, I’ve started to understand that good support isn’t simply about how quickly you can find a technical fix.
It’s about understanding the problem, taking responsibility for what you can control, communicating properly, documenting what matters and recognising when something needs to be improved rather than simply fixed again.
That’s probably the biggest thing working in an MSP has taught me. That’s probably the biggest thing I’ve taken from it.