I Didn't Know What I was Getting Myself Into

When I started my first job at an MSP, I had no idea what I was getting myself into. I was still somewhat new to the business world at the time and had not heard of the Managed Service Provider (MSP) business model. For the uninitiated, an MSP is essentially an outsourced IT department, generally for small to medium businesses that don't have their own IT team or wish to augment an existing team. For the client, an MSP is an easy way to put a team in place that provides end user support and can handle many if not all the businesses IT needs. From the perspective of working at the MSP though, there's often a sharp learning curve.

Drinking From the Fire Hose

On my first day, I was given a rundown of the tools and applications we used internally to communicate with one another, store data, and manage client devices. While I'd heard of many of the tools, some were things I'd not yet been introduced to yet and others were entirely new concepts. While I'd spent many years in school learning about tech and even done some side work, this MSP job was my first real experience in a proper team with defined standards, workflows, tools and processes.

When I accepted the job, I thought I'd be working at a call center taking password reset requests; I was sorely mistaken. Even being a first line technician, I was doing much more than I had initially expected. Detailed troubleshooting of difficult problems, remotely accessing client machines, creating and disabling user accounts, taking calls of course, and much much more. My first day on that team was about four hours of non-stop information overload about the business itself, followed by lunch, and then 4 hours of shadowing one of the help desk technicians. I remember poking around in Slack that first day and stumbling across an automation channel full of daily messages from various sources, all things that were happening silently keeping everything working properly. While I knew about automation and its importance and role in a business, seeing it in action in this way piqued my interest. So many of the things I've learned since then started in the same way, me being curious about how something works, teaching myself about it, and asking questions to find the answer.

Starting in the position, I knew I would have a lot to learn about processes, systems, workflows and much more, but what I hadn't expected was the intensity of onboarding at an MSP. Since an MSP augments or even replaces internal IT teams, I didn't have just one company worth of systems, team members, office politics, and business processes to learn, but around 30. The person I was shadowing was throwing around business names and acronyms left and right and it was truly a challenge to keep up with the sheer overload of information. While the company had a defined set of standards for clients, defining a 'stack' of tools is one thing, and getting tens of clients to adopt that stack is completely different. (Since I've been at this job, my colleagues and I have made significant strides in uniformity across client environments, but implementing change isn't easy and it takes time and money). Because of this, when I joined the team things were to put it nicely, disjointed, and this meant I had to absorb an absolute fire hose of information to get up to speed with the rest of the team.

The first two weeks in that position were filled with note taking, countless questions and a lot of time spent independently digging through documentation and client systems to get an idea of how things worked for each customer. While those two weeks were quite challenging and I left work at the end of each day feeling drained, putting in that effort early on proved utterly invaluable. At the end of those two weeks, I was done with formal training and was let loose to begin working tickets on my own.

Why the Fire Hose Isn't Always Bad

I could probably write an entire post about my first few weeks of working tickets solo, but the short version of the story was that my learning didn't stop when my formal training stopped. Instead, I dug my heels deep into the dirt for months on end and learned everything I could get my hands on. I worked hard to bring as many tickets as possible to resolution without asking for help or escalating the ticket and I spent any time between tickets learning about whatever I could. By the time I'd logged six months on the team, I knew an incredible amount of information not just about the way we did things internally, but about how each client operated both from a technical and interpersonal level. I knew that I needed to prove myself in my role in order to move up the food chain; digging in and drinking as much as I could from that fire hose of information allowed me to learn more than I ever had about IT before and set me on a path that would lead to me to quickly advancing my position in the company.