A bonus program for your engineers and service delivery staff is one of the most important drivers of profitability, customer service and quality. Or at least it should be. I have talked to many MSP owners and there is universal agreement that a bonus program is important. And, unfortunately, there is also universal agreement that theirs falls short of its potential.
I learned the value of a technical bonus program early in my MSP ownership career. We had general profit sharing but no bonus program specifically for our engineers. We were averaging about 26 billable hours per week per tech. This is in the days before fixed price contracts where every lost hour meant lost revenue. They were doing the work, but they were just not documenting the hours. I spent two years encouraging, threatening, and exhaustively explaining the lost dollars associated with their poor documentation habits. All to no avail. And I had a principled resistance to paying them extra for extra hours. Shouldn’t they do the right thing simply because it is the right thing to do?
I finally admitted defeat and implemented a simple bonus program based on documented billable hours and, I am not kidding, the next week average billable hours went up 4 hours per week. And stayed there. I learned an important lesson. You cannot fight human nature; you must figure out how to work with it and turn it to your own advantage.
It is indisputable that bonus programs can motivate behavior change. But the best bonus programs motivate the right kinds of behavior change. You do not want to turn your engineers into lone wolf mercenaries. Quality, customer service and playing nicely with co-workers are extremely important, too.
Rewarding productivity is a given in any MSP bonus program, but there are additional metrics that should be included to promote well rounded behaviors. For this blog’s purposes, we’ll focus on engineers, but service delivery personnel and MSP operations people can also be effectively incented. (Note: For each individual bonus component, we used minimum, expected and exceeds goals along with associated escalating monetary rewards.)
- Productivity. This comes down to the hours that produce something useful for the MSP. In this day of fixed price agreements, useful hours are usually some combination of hours against agreements plus project development and project execution. Training can be included depending on your company’s view of training. The math must be done to adjust for PTO, internal support, and different expectations for on-site vs. remote work. The result is usually a goal of averaging X hours per week.
- Timely Documentation. Documenting in real time is critically important for several reasons:
- Hours worked are accurately captured so that staff and staffing can be effectively managed.
- Crucial details are captured to feed your knowledge base and to justify hours spent.
- It improves customer service by giving your account managers, and other workers, in the office the detail they need to immediately answer client questions on work performed.
- It smooths the transition of tickets between techs for escalations or when the original tech is not available.
- It reduces friction within the organization as both managers and engineers hate the constant nagging associated with tracking down late documentation.
- Customer service. Whether you use ticket-based surveys or broader quarterly/annual surveys, or both, incenting techs on CX scores is a good practice. And the more closely you can associate specific client CX scores with the engineers supporting those clients the better. This metric is typically achieving X level in whatever tool you use to measure CX.
- Managed Endpoint Security and Integrity. Whether you perform RMM in-house or out-source it, there is a client-side piece that must be paid attention to. Agents and endpoint apps sometimes fail or are missing, and backups often require troubleshooting. The same with server patches and the occasional workstation patch or Endpoint Protection (EPP) failures. Incenting engineers to fix known malfunctions, and discover new ones, can pay big dividends in crises prevention. By scoring quality of deployed and functioning services, thresholds can be set to encourage engineers to ensure vital protections are optimized and running effectively.
Frequency. Let’s turn our attention to how frequently a bonus program should be paid out. If the period is too short, the reward is small, and it makes it too easy to quit trying for any given period. Too long and the reward can appear too distant to change behavior in the short term.
From personal experience, we found quarterly to be the right period. It is short enough to allow changes each day to impact the overall result and keep an engineer’s attention, but long enough to provide a meaningful reward at the end.
And the Most Critical Factor. There is one final factor in a bonus program that, if not implemented, will cripple its ability to motivate behavior change. The program status for each tech must be available in real-time throughout the bonus period. Techs must be able to see their score for each metric, how much they have earned, how much they are leaving on the table, and what they must do to maximize their reward. Without this real-time availability the bonus will feel more like a random windfall and the direct association between their behavior and the reward is muddied.
If all this makes sense to you but the operational, data collection, and reporting requirements to produce these metrics seem out of reach, give us a call. We have you covered.
