5 Reasons Why Top Engineers Quit MSPs (and How to Keep them)

A lot has been written about why engineers leave their jobs. Let’s face it: training people and then having them leave is expensive. A quick online search yield results like “work where you are celebrated, not just tolerated.” and “don’t pick a job; pick a boss.” and “people don’t leave jobs, they leave toxic cultures.” “Enable them to do work they enjoy, help them play to their strengths, and carve a path for career development that accommodates personal priorities.”

None of this is new. Little of this is limited to engineers. Intrigued by the differences between bosses I had early in my career (back then it was high school principals in public education), I conducted the research for my Master’s Thesis to determine who was the most responsible for teacher burnout. Some might say it’s the students. Others might say it’s the parents. Government intervention, particularly as it relates to funding, is believed to be the root cause by some. But the conclusion drawn from the data was that the building’s principal administrator – regardless of building grade level, size of the educational district, or the socioeconomic status of the community it was in – was largely responsible for setting building culture and, therefore, the most responsible for teacher burnout.

Think of the difference to teachers between a principal who would tape footprints outside of classroom doors to “encourage” us to stand in the halls between classes, and the principal who told my class he was so happy with my teaching he would stand on his head for them if he knew how. Sounds like “work where you are celebrated,” doesn’t it?

My career has taken an interesting trajectory, from classroom education to educational administration; to corporate IT; to healthcare IT (both hospitals and physician practices); to real estate IT, agricultural IT, county government, and manufacturing. My managerial strengths have often been utilized more than my IT strengths. And for 12 of those years, I was employed by an MSP, first managing engineers in a branch office, then at corporate headquarters and managing large-scale projects for our customers. What I learned and experienced early in my career has proven to be true regardless of where I’ve worked: the boss makes the difference.

Running an MSP is an especially challenging pursuit. To make a profit providing 24/7 IT support, one must run an efficient model. But to sell 24/7 IT support, must one be open to all industries? All IT? Finding the customer balance is hard. Finding and keeping engineers to staff an MSP is even harder.

Perhaps you offer a tiered support model, one that divides customer needs into Tier 1, 2 and 3 support, where Tier 1 handles password resets and other routine matters and Tier 3 is working on server and other back end system needs. Sure, you can help them play to their strengths and provide a professional development plan that allows engineers to move up through the ranks, but how do you keep them once they reach Tier 3? Ask. Yes, it’s that simple.

Ask. Remember this from above: “carve a path for career development that accommodates personal priorities.” One of the questions I asked of my engineers was this: “In 2 – 5 years, do you see yourself still primarily with your hands on the IT devices? Do you see yourself managing other people? Or something else?” This helped me understand the mentoring opportunities I could provide, ones that developed their career and accommodated their personal and professional priorities while keeping them happy with our company. Invest not only in the growth of your company but in the growth of your engineers.

Interested in Certifications Relevant to your IT Staff for training and growth opportunities?

Kris Hughes, Senior Content Marketing Manager at ProjectManager.com, advises managers to “recognize what motivates each of their team members as individuals, and adapt their management style accordingly to ensure each person on the team is staying engaged and will be provided with sufficient challenges and opportunity to keep them on the team for the longer haul.”

I call this “employment equity.” Think of the diversity of your engineers. If your goal is to buy each of them a bicycle, do you buy the exact same bike for all of them? That would be equality. Or do you buy the bike that fits each of them and their needs (size, style, adaptive structure, etc.)? This is equity.

Let’s debunk a few myths:

• Key engineers don’t leave companies because they have a bad job. If they like the company, they’ll find a different job in the same company.
• Key engineers don’t leave companies for more money. The “more money” part is the result of leaving, not the reason for leaving.

Instead, key engineers leave companies for one main reason and one reason alone: they have a bad boss (interchangeable with a manager or corporate leader) and there is no indication the company is going to do anything to change that. This usually breaks down to 5 different situations. Let me explain.

5 Reasons Why Good Engineers Quit MSPs

1. A bad boss has less experience or less subject matter expertise than the key engineer yet insists the job must be done his/her way. Instead, trust in the knowledge of the professional you’ve hired. It’s okay to ask on what experience the engineer is basing his/her solution. It’s okay to ask how often the engineer has solved this particular problem or built this particular system, and what s/he learned along the way. After all, you’ve either hired them for their experience elsewhere or hired them without experience and have trained them. But it is ultimately your trust and guidance that will deliver results, not imposing your solution.
2. A bad boss doesn’t set expectations for how the job should be done, yet – even if the key engineer completes the job successfully – questions why the job wasn’t done differently (i.e.., his/her way). What can you do? Stay in touch with what your employees are thinking. Trust in their past successes. You don’t have to agree with the methodology, but you do have to listen with an open mind and be able to admit there may be more than one way to achieve the goal.
3. A bad boss believes collaboration is overrated and, instead, develops policies and project plans without input from the key engineer. How often have you implemented a policy or proposed a project plan and felt frustrated at the lack of buy-in from your engineers? Skip the frustration. Engage them in the beginning; help them believe in their own talents and abilities. Meet them halfway.
4. A bad boss assigns hiring pay based on how desperate s/he thinks the (now) key engineer is to be hired and awards raise, or bonuses, based on the likelihood the key engineer will leave. When an engineer feels underpaid, s/he equates this with being undervalued. In today’s IT market, many will seek compensation elsewhere. And they’ll get it. But they didn’t leave the job for more money; the engineer left the job because s/he felt undervalued.
5. A bad boss exhibits no willingness to change…while pushing the key engineer to accomplish more (if only engineers would work more efficiently!) so the company can grow. And as for the ideas shared by key engineers? A bad boss simply dismisses them. If employees don’t believe their contributions are valid, they will wonder why you hired them instead of simply hiring someone who thinks like you. Validation goes a long way. Respect and value their ideas.

Wrap-Up

Can a bad boss be fixed? Perhaps. But the key engineer has already started looking for another job. Timing is critical. The logical, analytical, perceptive engineer (who has been underestimated by the boss) is watching how the company handles the bad boss and begins to take a closer look at the other bosses, perhaps only to discover the company really doesn’t want to change. So, the key engineer will accept a job offer that is a better fit at a company where, if he’s done his homework, his greatest challenge won’t be a bad boss. And chances are, he’ll also make more money.

Hopefully, you don’t end up here, but If you find yourself in this situation, check out our article on what to do when you lose a key engineer.

What about you? What has your experience been? How do you keep your engineers happy? We’d love to hear about it in the comments section below!