Due to the global talent shortage, a star MSP candidate has almost endless options for where they can work. Should you wish to have any chance of securing the best technicians, we’d like to make you aware of some incredibly common mistakes MSPs make when searching for talent. We’re talking about mistakes that send the very people you want most running elsewhere.
A job posting is often someone’s first introduction to your company and its culture, and first impressions are everything. With that said, do you know if it’s inviting the right type of person to envision themself finding success with your company? Are your postings all about your company, or are they also about what you provide your staff in regards to culture, mentoring, growth opportunities and, oh yes, compensation.
Must haves or wish lists?
MSPs tend to be way too specific and nit-picky when making job postings. They list numerous technologies they currently have deployed, and make it seem like if a candidate does not have extensive experience with those specific technologies, they need not apply. We’ve found that the best MSP job ads are really good at describing the type of character they wish to hire and the broad technological experience they should have. As well, these job posts explain that they are open for conversations with applicants who have transferable knowledge and experience, and seem like they will pick up new things quickly.
If you want your job ads to sound a bit more flexible…
Try writing something like: “Should have the ability to take the lead and take ownership with cloud infrastructure, networking and Windows server projects, drawing from past experience.”
Rather than: “Must have extensive experience with Amazon Workspaces (AWS), Cisco Meraki and Microsoft Azure AD.”
There are lots of talented people who can learn the specific platforms you use very quickly and you don’t want to alienate them.
Insisting on MSP experience
Insisting on MSP experience is a big mistake because you disqualify the majority of applicants who likely have the actual skills you need. It’s important to remember that an MSP is a business model within IT support rather than an industry itself. Most of the tasks that technicians do inside and outside of an MSP are similar to tasks performed in the greater IT support industry anyway. It’s true that the MSP business model leads to a faster paced and more diverse environment than say, an internal IT department in a large company, or a support division of a software company. But that doesn’t mean that the environment cannot be learned quickly.
The issue isn’t a candidate’s bank of knowledge. The issue is actually that very few MSPs invest their time in making a training program which prepares people for MSP work. If you did have such a program, and trained your new staff with the relevant information, as well as giving them clear expectations, you would find that some of your best hires are those who were not in the MSP space. You would also find that they quickly get excited about working for an MSP once they get a taste of it. Given the right chance, these people are thriving within 30-60 days.
We’ll focus more on training programs later in this article.
Not selling the company and its values and environment
Here are some questions to ask yourself (and some solutions):
Is your company a great place to work? A lot of MSPs aren’t. Also, why is your company going to be a better place to work than your competition? Remember, it’s a candidates’ market these days. They have more options than you do.
Do you have happy staff that have been with you for years? Consider including a testimonial.
Do you strive to create an environment where techs can rise through the ranks in your organization? Tell them about it.
Do you promise them an environment where the tasks they are doing are varied and help them develop a broad skill set? Give examples of task variation.
Are there core values that the management staff embody? Write them here.
Do you have a well-curated client list that has been purged of the clients who were causing friction? Talk about it.
Do you have ways of ensuring that your staff does not get stressed out? Make them feel like you care.
After posting a job ad, the applicants come in. In selecting the ideal candidates, MSPs often make several mistakes.
They rely too much on what’s written on the resume or CV
Anyone can put a bunch of industry buzzwords on their resume. The words Amazon AWS or Azure AD written down don’t tell you anything about what is going to happen when a new hire is actually put on the panels. Someone who has never used the technology in question might be able to foster a solution in no time, whereas some “ideal candidate” who copy/pasted the entire MSP stack on a document with their name on it will look like a deer in headlights. Whatever they write, take it all with a grain of salt and don’t disqualify those who don’t have your entire stack written under their name. Tech platform experience is in general transferable, and the most brilliant people learn fast.
Not enough testing of knowledge or research ability as part of the application process
A short, well-designed multiple choice test can quickly eliminate many people who have no business applying.
Here’s one we have used at Support Adventure:
Which of the following IS an operating system?
- Office 365
- Mac Pro
What was the first major release of an operating system in the family of technologies that Windows 10 belongs to?
- MS Dos
- Windows 7
- Windows NT 3.1
- Windows 95
Which of the following is NOT a networking related command on Windows 10 command prompt?
Make it clear that they can Google the answers. Those who know how to Google, or know the answers from their experience, will have no trouble with these. However, many others who apply might have trouble.
But before putting those who fail in the “no” column, you might want to take a second look at them. We have seen plenty of edge cases of people who really did know their stuff, but they were tricked by how easy the questions seemed and made mistakes as they breezed through them.
A lot of MSPs insist that applicants they “find interesting” from a resume take a psychological test before ever speaking to clients. However, we have found many psych tests to be less consequential in comparison to the actual real job-related tasks we give applicants. We have also found that some great applicants are put off by having to take such tests before talking to a human being. It seems too corporate and inhuman, and they don’t want to work with a company that treats them like that.
Not inviting candidates to introduce themselves on video
At Support Adventure, all applicants are requested to submit an intro video where we can see how they communicate verbally and visually. Screening candidates like this allows you to avoid awkward interviews with those who do not have the social or communication skills you want in your organization.
Mistakes MSPs make in interviews:
Interrogation style job interviews
This is a style of interview where the person interviewing focuses only on asking questions in an authoritative tone to ascertain whether or not the applicant is a good fit for their company. We have seen many company managers and owners who set this type of frame in the interview fail repeatedly at securing talent. They don’t quite understand that they are losing out in a competition with companies who take a more conversational and rapport-building approach to the interview process. The best interviews we see mix small talk, humor and unusual questions in a two-way information exchange which allows both the company and the candidate to become comfortable with the idea of working together. Those employing interrogation style interviews can expect to almost always fail in cases where a warmer approach is used to make a competing offer. Can you blame people for wanting to like and build a connection with the people they are going to be working with?
Too technical in nature and too much focused on individual technologies
Again, specific technical experience and what one can answer off the top of their head is NOT the ultimate skill that you should be looking for. Focusing too much on specific technologies and “right and wrong” answers is going to severely limit your pool.
Don’t you just want someone who can get stuff done? If so, why not include questions that elicit stories of how they’ve overcome challenges that required them to go above and beyond what was expected of them? Isn’t that the sort of person you want to hire?
You can also ask them to tell a story of how they learned to be proficient on a platform they became a master at. That will give you an idea of the intelligence they will deploy every time a new technology gets rolled out, or even a new version of a panel.
Overweighting the value of certifications
Certifications can tell you a lot about specific knowledge someone might have, however it does not actually tell you how serviceable that knowledge is for everyday MSP work. You must ensure that when asking about certifications, you ask them how they’ve applied any practical value of those certifications to real world scenarios. If you don’t do this, you might find that hiring based on certifications is practically meaningless.
Not describing the environment they are providing
A lot of MSPs are notoriously horrible places to work. The best technicians know this, as well as knowing how many options they have. If you’ve put in the work, listened to your team and researched industry best practices, you won’t have to worry about this as much. If you’ve created an environment which ensures that techs are productive, relaxed and stimulated, as well as team members having each other’s backs, now is your chance to brag about it.
Not describing specific KPIs
How is success judged in your organization? What will a candidate’s successful onboarding to your organization look like? And how do both you and a new hire know that they are doing their job correctly? Some companies just wing this part. Others have a system. Those with a system, which the candidate views as fair and well-defined, are likely going to impress more.
Not describing the training/onboarding procedure
Assuming you make an offer to a candidate and they accept it, what happens then? Do you just give them credentials and then let them rip, or is there a structure? Describe it so that they can envision exactly how committed your company is to getting them across the go line.
Not talking about growth opportunities
This is an industry where the best people have a lot of upward mobility. If you want to attract star technicians, ensure that this is one of your selling points. Great MSPs usually have two paths that fork at one point, with the person being asked to choose: do you want to be part of management or a supertech? Very few people can remain simultaneously focused on both. Ask them which of the two options they can better envision themselves becoming and be prepared to share any stories of people who have followed that path.
Not expressing values
Are you a premium MSP who gives great, personalized service? Tell candidates how you ensure that your service embodies that. For instance, do you only take on clients who take your advice and implement the technologies you recommend? If so, talk about how strong this has made your offerings. Do you want your company to be a place that doesn’t burn people out? Tell candidates how you do that.
This is where you get a chance to share what you stand for and emphasize why they should choose you over the other options out there.
Not selling the company as a great place to work
Further to the above point, how much do you love working at the company where you work? How great are your co-workers?
Some MSPs are toxic environments where staff blame and trash-talk each other, and many technicians have an “everyone sucks but me” attitude. Is this not you? It would be nice to describe how positive, supportive and pleasant working with your company is. If you can’t say that about your company, you might not be ready to attract the best talent before you clean out some of the toxic or incompetent characters you’ve allowed to fester in your ranks.
Common training mistakes:
Not having a trial period
Even if you do all of the above, you still don’t know what’s going to happen when the rubber hits the road. In your contract, it’s best to have a one month (or longer) probationary period where, if it’s not working for anyone at any point, they have the right to terminate without a notice period. After the probationary period, make it maximum one month’s notice. You don’t ever want bad situations to be prolonged as they will weaken your whole organization.
Not having a structured training plan
“Hey, just shadow Bob” is not a structured training plan. Bob may be great at his job, but how do you know if he’s a good teacher for trainees? How do you know that bad habits will not be transferred by him? How do you know Bob is prepared to give a training that will work for all different types of learners? You don’t. You’re just hoping it will work out.
Not having a well indexed body of standard operating procedures, standards, etc
If any of the following is true, you might want to add some more thought to things:
- “Pick up the phone and help the clients” is your ticket creation policy
- ”Write what you did in the notes” is your ticket note writing guide
- ”Write the others in Teams chat” is your escalation policy
- ”Update IT Glue” is your documentation policy
There are a lot of opportunities to improve this. The above may work for a small MSP, but should you plan to grow your business, more structure will be needed. It’s best to put one in place as soon as possible. We at Support Adventure can help.
Not having recorded materials
If every time you train a new staff member, someone has to explain everything all over again, you’re missing out on a huge opportunity to record that and pass it on to those you train. The best way is to give them recordings of a live person getting on-boarded and have the trainee keep notice of a) what they learned b) any questions that came up in their heads that didn’t get answered.
By doing this, you’ll be well on your way to having a consistent training plan that doesn’t eat up the time of existing staff members.
Not having real “go get it tasks”
The best technicians are “learn by doing” types. They’ll be incredibly bored with Connectwise University and other such vendor resources. You could provide a bare minimum of how you use Connectwise, your statuses and then some video walkthroughs of how your staff approach the toolkit.
Follow that up with giving them training tickets like:
-Log onto server CORPLAW-DC1 using Continuum RMM and take a screenshot of the server’s uptime
-Log onto the control panel for CORPLAW’s Firewall and take a screenshot of the exceptions
-Check CORPLAW’s email spam filter and copy and paste the subject of one message which has been correctly identified as spam
Those tasks will get them comfortable with the tools in a hands-on way, as well as allowing you to see how ready a new hire is to actually use the tools. You’ll also get a sense of their ability to research any feature they need to achieve what they will actually be doing on a daily basis.
Not having shadowing/mentoring with peers and management
Shadowing shouldn’t be the whole training program, but it should be part of it. After they’ve got the self-training resources you’ve created for the basics done and dusted, have them watch one of your masters do the work, and then have them switch places.
Assuming what all techs should do or know without defining it
The best techs will probably do what you would do in a lot of situations. It’s magic. However, as you grow your organization, the likelihood that everyone will do exactly what you would want them to do will diminish.
Instead, you should have as many guidelines as possible written down in a concise manner to guide techs on how to navigate business, security, data protection, emergencies and other situations. You must also develop procedures for escalating situations that you would want to weigh in on. Don’t just assume that a tech will have “common sense” and behave like you would. There are reasons you are the owner, executive or manager of a company. That’s hopefully because of your strong insights into a business model, and its system or structure. Apply those principles here and guide the organization with your wisdom.
Not checking ticket notes
If there’s one thing which should be a must for training new staff, it’s setting the bar on what good ticket notes and statuses look like, and reviewing compliance to those standards. This can be done by a dispatcher or service coordinator. They should have a checklist of what they’re looking for in terms of ticket notes, but a manager should also be looking at a new tech’s notes–at least in the first month.
Not following up with a new tech in a structured way after they’re across the go line
Once they’ve passed the trial, things don’t end there. Ensure that they are happy, that they’re following your standards and that they’re a functioning part of the team. Have monthly catch up calls with them where they are encouraged to share feedback on how their role makes them feel, what stresses them out and what they would suggest to make things better. This will allow you to harvest some great ideas, as well as ensure that they are content, productive and fitting into your team. Or, if things aren’t right, you can know before the damage is irreversible and somebody quits or gets fired.
We hope we’ve given you some ideas on how to attract and select the right people, make them excited about joining your team and bring them onboard to flourish. The success rate will never be 100% in an environment so complicated as an MSP, however we’ve given you a lot of tips and tricks to increase your success rate. We hope this helps!