A managed services firm hires a network security engineer to replace a resignation. The candidate asks for more than the person who has been there three years and handles the same client. The owner says yes, because the client needs the cover. Six weeks later, the older engineer finds out.
This is the most common pay problem in managed services. Offers are made one at a time, in a hurry, with no shared grid. The fix is not complicated, but it needs to be written down. Here is how to build it.
Start with grades that describe work
Titles such as engineer, senior engineer and lead are too loose. Write each grade as a short paragraph on what the person does without help. At the entry grade, an engineer follows runbooks, handles known alerts and escalates the rest. At the middle grades, they diagnose new faults, change configurations under review and speak to the client. At the senior grades, they design, mentor, own client escalations and set standards.
Keep the number of grades small. Four to six grades per family is common, but your size and spread of work decide. Separate families for infrastructure, security and service desk usually make sense, since the skills and market rates differ.
Build the ranges
- 1
List roles and map them to grades
Take every current role and place it in a family and grade using the written definitions. Do not use pay as the test.
- 2
Gather market data
Use a benchmarking source, salary surveys and what offers you have won or lost in recent months. Treat any single data point with care. Compensation benchmarking is a service GullyHR provides if you want help here.
- 3
Set a range per grade
A minimum, a midpoint and a maximum. The midpoint is where a fully competent person in that grade should sit. The decision on where to set midpoints against the market is yours and depends on your margin and your hiring pressure.
- 4
Place each person
Locate every engineer inside their range based on skill depth, performance and tenure. Flag anyone below the minimum or above the maximum for a decision.
- 5
Cost the gaps
Add up what it costs to bring those below the range up to it, and decide on a timeline. Do it in stages if cash is tight, but tell people the plan.
- 6
Write the offer rule
New offers go inside the range for the grade. Anything above the midpoint needs a named approver and a note on why.
Pay components that suit managed services
Fixed pay should cover the work the person does in normal hours. Add separate components for things that vary: night shift allowance, on-call availability, weekend or festival duty, and certification premiums for skills a client contract needs. Naming each component makes it easy to explain and easy to stop when the duty ends.
Be careful with certification pay. Pay a premium while the certified skill is used on a client account, and review it when the contract ends or the market shifts. Link the premium to a certificate that is current, not one that lapsed years ago.
Promotions and increments
A promotion should follow evidence that the person already works at the next grade, not the length of time in the seat. Ask for examples: incidents handled alone, a design reviewed, a junior coached. Increments inside a grade can follow a simple matrix of performance and position in range, so that people lower in the range move faster. The post on pay grades and fair increments in IT infrastructure and managed services covers increments in more depth.
Family and grade name, for example Security Engineer, Grade 3.
Scope: the kinds of client accounts and systems the person can work on.
Independence: what they can decide alone and what needs review.
Incidents: the severity of incident they can lead.
Skills expected: named areas, with levels, not tool lists.
Behaviours: documentation, handover quality, client communication.
Typical experience: a guide, not a rule.
Pay range: minimum, midpoint, maximum (to be filled by the company).
Allowances that may apply: night, on-call, certification.Keep offers and existing staff in line
Before each offer, compare it with the people already in that grade. If the new hire will sit above a current engineer, ask whether the grade is right, whether the current engineer needs a correction, or whether the premium is truly temporary. Quiet corrections early cost less than a resignation later. Hiring pace and offer logic are linked, as the post on hiring cloud and DevOps engineers explains.
What to tell the team
You do not have to publish every salary. You should publish the grade definitions, the fact that ranges exist, and the process for moving between grades. When someone asks why a colleague earns more, you can point to grade, scope and position in range. That answer works only if the grid is real.
For the wider set of people practices in this kind of firm, the managed service providers page is a good map.
