Most organisations treat job evaluation as a project with a finish line. You evaluate the roles, assign the grades, file the outputs and move on. Job done.
But the moment you complete a job evaluation, you've created one of the most useful datasets in your organisation, and most HR teams never go back to look at it properly.
After working with teams across different industries on job grading, I keep seeing the same pattern. The evaluation gets done, grades get communicated, and then the spreadsheet or the software sits largely untouched until someone challenges a decision or a restructure forces a revisit.
That's a design problem as much as an HR one. If the tools make the data hard to see, nobody goes back to it. Here's what HR teams should be getting from their job evaluation data, and what that means for anyone designing the software they use.
-
01
The factor scores tell a richer story than the grade
In an analytical job evaluation, each role is scored across several factors, such as knowledge, complexity, impact and communication. The final grade is a summary of those scores combined, but the individual scores show where a role's weight actually sits.
If knowledge scores across a department all cluster at the top end, the grade structure may not be wide enough to reflect real differences in role complexity. If impact scores are high but autonomy scores are low, you have roles carrying significant responsibility without the authority to match, which is often where you find your most frustrated employees.
For product teamsDon't let the grade be the only output. Make factor scores easy to see and compare across a team or department, not buried inside each role's record.
-
02
Grade distribution should reflect strategy, not a textbook pyramid
How roles spread across the grade levels has no single right shape. A technology company leaning heavily on AI might deliberately have more senior, specialist roles than a traditional service organisation. The question is whether the shape reflects the organisation's actual strategy and operating model.
For product teamsShow the shape of the whole structure at a glance, so teams can judge it against what they intended rather than against a generic ideal.
-
03
A surprising shape can reveal grade inflation or title creep
Too many roles clustering in the middle can be a sign of grade inflation creeping in over time. A top-heavy structure that doesn't match the business model might point to title creep. The distribution itself isn't the problem or the solution. It's a prompt to ask whether the grades are telling the story you think they are.
For product teamsHelp people notice drift. How the distribution changes between evaluation rounds is often more telling than a single snapshot.
-
04
The gaps between grades expose compression and cliffs
The distance between grades matters as much as the distribution across them. Grades too close together cause compression: roles of genuinely different complexity sitting at the same level, which undermines the point of grading. Gaps too wide create cliffs: big jumps in pay or expectations that make progression feel unreachable and can create equal pay exposure at the boundaries.
For product teamsShow the distance between grades, not just the grade labels, so compression and cliffs are visible before they become pay problems.
-
05
Inflated grades throw off market benchmarking
Benchmarking against inflated grades produces salary recommendations that are off before you've even started. Anyone preparing for market benchmarking should check their grades first.
For product teamsBuild a sense check between evaluation and benchmarking, so questionable grades are caught before they feed into salary recommendations.
-
06
Outlier roles are where job evaluation earns its value
Every job evaluation surfaces outliers: roles that score unusually high or low relative to their current grade or pay level. A role that evaluates well above its pay grade is a flight risk waiting to happen. One that evaluates below it may be a role where expectations have drifted well beyond the original job design.
Neither is a problem the grade creates. The grade just makes visible what was already there. Ignoring outliers doesn't make them go away. It means managing them without the data to back your decisions.
For product teamsSurface outliers without being asked. If finding them depends on someone exporting a spreadsheet, they won't get found.
-
07
Career frameworks and grades should tell the same story
Once there are solid grades, they should connect to salary bands, career frameworks, succession planning and pay equity analysis. If a career framework says someone can progress from Level 2 to Level 3 by taking on certain responsibilities, the evaluation data should confirm that Level 3 roles actually score differently from Level 2 roles. If they don't, the framework and the grading structure are telling employees two different things.
For product teamsConnect evaluation data to the frameworks it should validate, and let people see the whole structure in one view.
“When we built the cross-tab report in PAYgrade, it was because we kept hearing the same thing from HR teams: they had the evaluation data but no easy way to see it all together. Being able to map every role across grades and departments in one view changes the conversation completely. You stop looking at individual decisions and start seeing the structure.”
Paul Hajduk · Co-creator of the PAYgrade framework -
08
A documented basis for grading is becoming a requirement
EU member states were required to bring the EU Pay Transparency Directive into national law by June 2026. Being able to demonstrate an objective, documented basis for how roles are graded and paid is no longer just good practice. It's becoming a requirement.
For product teamsTreat the audit trail as a feature. Who scored what, when and why should be recorded by default, not pieced together when someone asks.
-
09
Job evaluation only works if it stays live
Roles evolve, structures change, and a framework that was accurate two years ago can drift without anyone noticing. The organisations that get the most from job evaluation treat it as a living reference point. New roles are evaluated against the existing framework instead of guessed. Roles that change significantly are reassessed. When pay decisions are challenged, there's something concrete to point to.
For product teamsMake evaluating a new or changed role part of normal work, not a separate project. If it feels like a project, it gets put off.
Questions to ask of your HR software
- Can you see factor scores across a whole team or department, not just role by role?
- Can you see the shape of your grade distribution, and how it has changed?
- Are the gaps between grades visible, or only the grade labels?
- Does it point out roles scoring well above or below their current pay?
- Can you check your career framework levels against the evaluation data?
- Is there a clear record of who evaluated each role, when and why?
The bottom line
Job evaluation data is telling organisations things about their structure, their pay positioning and their career frameworks. Whether anyone listens depends a lot on whether the tools make it easy to.
That's the lesson I keep coming back to as a designer in this space. The value of job evaluation sits in the data, and good product design is what gets people to look at it.