TL;DR
- The core decision: whether to choose a levelling approach that sorts the people you already have, or one that describes the work so clearly that a person at level four can read it and know what level five would ask of them.
- When doing nothing is right: when headcount is under roughly thirty, turnover is low, and a single manager can hold every reporting line's actual scope in their head without help.
- What has to be true for this to work: the level descriptions have to read like job descriptions for the next level up, not like trophies for the level the person is already at.
- How the options split: by whether they answer "what is this person paid for", "what does this person do", or "what would have to be true for the next move", and most frameworks only do one of the three.
- Decision rule: if you can't read a level aloud, in plain words, to the person who is one rung below it, and have them nod, you don't have a framework yet.
- Outcome to expect: a structure that a manager can use in a one-to-one, that a candidate can use in an interview, and that your finance partner can use to defend a pay decision without flinching.
The Conversation You Are Already Avoiding
A director walks into your office. She closes the door. She has been here for four years, has run the integration of two acquisitions, and now manages a team of nine across three countries. Her skip-level told her in passing that she is "solidly a senior manager", and she has come to ask what she would have to do to be a director. Not for the money, or not only for the money. For the next role. For the thing on her CV. For the conversation she will have with her mother at Christmas.
You open the levelling document. It has six tiers, two ladders, a matrix of competencies and a points-factor grid that someone built three reorganisations ago. You find her current level. There's a paragraph of behaviours. There's no next paragraph that describes the level above. There's a salary band. There's a job title. There's nothing on the page that tells either of you what she would have to be doing, in her actual job, that she isn't doing now.
So you say "let's come back to this" and she leaves. The door clicks shut. You're alone with the document. The real issue isn't whether she should be a director. The real issue is that you can't answer her, because your levelling framework was built to put people in the right cell, not to describe the work, and the gap between those two jobs is showing in every conversation you've tried to avoid this quarter.
Best tools for HR Strategy
When You Do Not Actually Need to Act Yet
There's a version of this problem where the right answer is to do nothing, and a content site that won't say so is selling you something. Four honest stages, from genuine fine through real risk.
Stage one, the current setup is genuinely fine. A team of thirty, all in one location, with one HR business partner who knows every line manager's actual scope because she sits in the stand-ups. Titles are short, mostly one of three, and people understand them. Pay decisions happen in a room, with the founder in the room, and the room is small enough that the founder remembers everyone's first name. Levelling, in this company, is gossip, and gossip works because it's fast, it's personal, and it isn't yet wrong. A framework here would add ceremony to a thing that's already working.
Stage two, friction, not failure. A company of one hundred and fifty has outgrown the founder's memory. Titles still work in most places. They fail in two: the new manager in the second office, and the senior individual contributor whose title is "Principal" while the manager two desks over is a "Director" and they have roughly the same scope. Pay is now decided by who asked last, and the HR business partner is rebuilding every offer on a spreadsheet. This is the moment to introduce a structure, but only the parts of it that solve the friction, which is titles, the next-rung picture, and a way to compare two roles in different functions. Skip the points-factor grid.
Stage three, real risk. A company of four hundred has nine business units, three countries of operation, and a leadership team that has been hiring above the existing levels because the levels didn't exist. A senior engineer in one unit is paid more than a director in another, and both of them are right according to local market data. The CEO is about to chair a pay-equity review, and the HR team has nothing to show her except a folder of offer letters. A framework is now urgent, and the cost of doing nothing is starting to look like exposure, not just awkwardness.
Stage four, the edge case. A company has had a framework for years, has re-validated it once, and now the work has changed more than the framework. Most of the level descriptions still describe a job that the job no longer is. AI has eaten half of what level four used to own, and the framework has not caught up. This is its own kind of doing nothing, and it's the stage most often missed because the paper looks fine. Treat the absence of recent re-validation as the same signal as the absence of a framework at all.
The Five Questions You Are Asking at Eleven Pm
Why am I the one doing this, and not the compensation team? Because you're the one who will be in the room when the question gets asked. Compensation can build the bands. You have to defend them. If you can't defend a level to the face of the person who is on it, the band doesn't save you.
Do I need a framework at all, or do I just need better titles? Titles are the smallest useful version of a framework, and they're also a framework. If three titles and a one-page description of each will solve your problem, that's your answer. Most of the resistance you're feeling is about the rest of it, which is bands, and which you don't yet need.
Will the framework survive the next reorganisation? A framework that's bolted to today's org chart won't. A framework that describes the work rather than the box on the page will, because the work is more stable than the boxes. Test any level description by asking whether it would still be true if you deleted two layers of management and flattened the rest.
How do I get buy-in from the leadership team when they don't feel the problem? You don't, not yet. You show them the conversation at the top of this article, the one you've been avoiding, and you ask them how many of those conversations they have had this quarter. Buy-in follows the count, not the pitch.
What is the smallest framework that would let me sleep at night? Write the answer down before you ask the question. The smallest defensible framework is one document that describes four or five levels in plain words, with one rung of "what the next level looks like" for each, and a clear owner. Anything beyond that's a project, not a framework.
Three Honest Categories the Approaches Split Into
Levelling approaches don't exist on a spectrum. They answer different questions, and they fail in different ways when the wrong question gets asked.
Category one, what is this person paid for. This is the compensation-led family, which includes points-factor job evaluation, market-anchored bands, and most of what an external survey provider sells. The unit of analysis is the job. The output is a score, a band, or a slot in a benchmark file. It's right when the question you're answering is mostly about pay, and it's precise about pay in a way that other categories aren't. It fails the moment a person asks "what would I have to do to move". The job evaluation doesn't care what you do tomorrow. It cares what the role is worth today.
Category two, what does this person do. This is the job-family family, which includes broad-banded structures built around role profiles rather than scores, and competency matrices anchored to observable behaviour. The unit of analysis is the work, described in plain words. The output is a profile, or a matrix, that a hiring manager can use. It's right when the question is mostly about clarity of expectation, and when managers actually have the time to read the profile. It fails when the descriptions are written by people who don't do the work, and so describe an idealised version of it that nobody recognises.
Category three, what would have to be true for the next move. This is the smallest family, and the one most frameworks don't bother with. The unit of analysis is the next rung. The output is a paragraph, for each current level, describing what the same person would have to be doing to justify the next one. It's right when the conversations at the top of this article are the conversations you keep having, because those conversations only end when this kind of description exists. It fails when it's written as a wish list, full of vague scope language, instead of a specific description of what changes in the work.
Five Diagnostic Questions You Can Answer Tonight
One, can you name, off the top of your head, what your level four does that your level three doesn't? If yes, your framework is probably doing some work. If no, you've titles in a spreadsheet.
Two, can a hiring manager in another country take your level three profile and use it to write a job ad without phoning you? If yes, the description is concrete enough. If no, the description is too abstract, or it's too long, or both.
Three, when you compare two roles in different functions at the same level, can you explain to both role holders why they're at the same level? If yes, your levels describe something real. If no, your levels are a fiction the comp team has agreed to.
Four, does each level description include a paragraph for the level above? If yes, your framework can answer the question your director came to ask. If no, you're going to keep avoiding that conversation.
Five, can you name three people in the last year who you would have levelled differently under a clean framework? If yes, you already know your framework is wrong about someone, and that someone is the person you're about to lose.
Six Levelling Approaches, Reviewed
Titles alone with no underlying structure
What it is: a short list of titles, agreed by the leadership team and applied by hiring managers, with no document beneath them. Why it earns a place: it's the smallest useful structure, and it works until it doesn't. Where it falls short: the moment two functions use the same title for different scope, or the same scope under different titles, the titles stop meaning anything and the conversation in your office starts happening weekly. The weakness isn't that titles are informal; it's that titles carry scope by accident, and the accident stops being benign past a certain headcount.
Dual ladder separating individual contributor and management tracks
What it is: two parallel sets of levels, one for managers and one for individual contributors, with an explicit point of equivalence between them. Why it earns a place: it acknowledges that scope grows on two axes, and that promoting a great engineer into a bad manager is a known failure mode. Where it falls short: the equivalence point is always a fiction, and the moment a senior IC's scope crosses the manager at the same rung, you have to either invent a new rung above for one of them or admit the ladders have re-merged. The ladder also tends to assume that the management track is the more valuable one, which it usually isn't, and which the ladder's structure quietly encodes.
Points-factor job evaluation
What it is: a scheme that scores each role on a fixed set of factors and produces a numeric total, which then maps to a band. Why it earns a place: it produces consistency across functions in a way that nothing else does, and it's the only approach that defends itself well to a finance partner who wants to know why two roles are in the same band. Where it falls short: the factors are chosen by the scheme, not by your work, and so a role that's unusual in your company scores oddly because the scheme has never met your company. The numeric output also feels more objective than it's, which makes the conversations at promotion time harder, not easier.
Market-anchored bands built from external pricing
What it is: bands built from what the market pays for roles of similar shape, with your own internal logic overlaid. Why it earns a place: it grounds the conversation in something other than internal politics, and it's the only approach that has a clean answer to "why is this band where it's". Where it falls short: market data describes what other companies pay for roles like yours, not what your company actually needs from this role, and the gap between those two things is where the awkward conversations live. Anchoring also does nothing for the question of what the next rung looks like, which is the question your director came to ask.
Broadbanding with few wide levels
What it is: a small number of wide bands, each containing a lot of internal variation. Why it earns a place: it's permissive, it tolerates growth inside a band, and it gives managers room to recognise contribution without re-levelling someone every quarter. Where it falls short: broadbanding trades clarity for flexibility, and the moment an employee asks why a peer at the same level is paid more, the band is too wide to answer the question without an internal sub-level that you've not built. Broadbanding also tends to drift, because nothing inside the band is fixed, and after two years the band means whatever the loudest manager says it means.
Competency matrix describing observable behaviour at each level
What it is: a grid with levels on one axis and competencies on the other, with each cell describing an observable behaviour. Why it earns a place: it's the closest any framework comes to the "what would have to be true" question, because each cell is a behaviour, and behaviours can be observed. Where it falls short: most matrices are written by people who don't do the work, and so the behaviours describe an idealised version of the job that the person in the job doesn't recognise. The matrix also tends to be long, and a long matrix is a matrix nobody reads, which is a matrix nobody uses.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Single office, founder knows everyone, low turnover | Under thirty | None | None yet | Stay where you are; revisit at the next hire outside the founder's memory |
| Titles working in most places, breaking in two | Fifty to one hundred and fifty | Titles only | Same title, different scope, in two places | Add a one-page description per title with one paragraph for the title above |
| Multiple units, multiple countries, no shared structure | Two hundred to four hundred | None or stale | Pay-equity conversations without a common yardstick | Dual ladder with three rungs per track, anchored to role profiles not points |
| Existing framework, descriptions written for a job that has changed | Any size | Framework in place but untouched for years | Level descriptions describe work that no longer exists | Re-write the level descriptions from the work outward, keep the structure |
| Hiring above the levels because the levels do not exist | One hundred to three hundred | None | New hires arriving at levels you cannot explain to existing staff | Build four levels max, from the bottom up, and publish them internally before you use them in offers |
| Heavy compliance pressure, finance wants a defensible structure | Three hundred plus | Some structure, partial | Pay decisions under scrutiny without a defendable structure | Points-factor for pay, competency matrix for the next-rung question, kept as two separate documents |
| Acquired two companies, three legacy structures in play | Variable | Three competing structures | Three titles for the same scope, three scopes for the same title | Pick the structure that describes the work best, retire the rest, and accept the conversation that follows |
| Engineering-led organisation, IC ladder matters more than manager ladder | Variable | Flat, IC-heavy | Senior engineers leaving because the next rung is management | Dual ladder with explicit IC rungs above the manager ladder, not parallel to it |
Writing a Level Description Someone Can Self-Assess Against
The single biggest difference between a description that sorts people and one that tells them what to do next is whether the description is written in the voice of the assessor or the voice of the role. A description written in the voice of the assessor sounds like a set of criteria a panel would tick. A description written in the voice of the role sounds like a job description for the next rung. People can self-assess against the second. They can't against the first, and a framework that doesn't let people self-assess against it's a framework that does all the work in promotion conversations, which means all the work lands on you.
| Element | Weak version | Usable version | Question it must answer |
|---|---|---|---|
| Scope of role | "Operates with significant autonomy" | "Owns the quarterly plan for a product area, including the cases where the plan is wrong" | What does this person actually decide? |
| Impact | "Drives business outcomes" | "Their work is visible in a specific metric, and they are named in the review of that metric" | Where does this person's work show up if it goes well? |
| Next rung | "Demonstrates strategic capability" | "Is the person the CEO calls when this metric moves the wrong way" | What would change about what this person does? |
| Behaviour | "Collaborates effectively" | "Disagrees with the head of sales in writing, in a room, and the disagreement changes the plan" | What does this person do that the level below does not? |
| Judgment | "Uses sound judgment" | "Has made at least one decision in the last year that the rest of the leadership team was wrong about, and can describe what they saw that we did not" | What does this person see that the level below does not? |
The Re-Levelling Nobody Budgets For
You have built the framework. You have written the descriptions. You have tested them on a vacancy and they worked. Now you have to apply them to the people who already work for you, and this is the moment most projects fail, because the framework is going to say that some of your people are in the wrong place.
| Existing person | What the framework says | The conversation you have to have |
|---|---|---|
| Long-tenured manager, scope has shrunk | Below their current level | Acknowledge the change, agree a path back, give it a timeframe in writing |
| Recent hire brought in above the structure | Outside the levels on the high side | Either retire the existing rungs above theirs or carve an exception, in writing, with an expiry date |
| High performer in a small function | Above the level the structure assigns | Either widen the function until the scope fits the level, or accept that the level is wrong for this person |
| Solid performer, framework puts them at the rung they have always been at | Confirmed in place | The easiest conversation, and the one most worth having in writing, because it pre-empts the next one |
| Person whose title was a promotion in everything but scope | Above their actual work | The hardest conversation. The framework has to win, the title has to change, and the change has to be handled as a project, not a conversation |
The re-levelling is a project. It has a plan, a sequence, a comms plan, a way of handling the exceptions, and a deadline. Without it, the framework is a document you wrote, not a structure you're running. With it, the framework is the structure. The cost of skipping it's that you end up running two structures, the formal one and the actual one, and the actual one is the one that costs you people.
What to Put in Writing
Written records are what turn a good decision into a defensible one, and this is the section most teams skip.
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| The framework document itself, with each level written in plain words | Head of People, or equivalent | At decision, before any promotion is run against it | The "but our framework says" conversation that nobody can have because the framework is a rumour |
| A one-page summary per level, suitable for an employee to read | Head of People | At decision, updated when the framework is re-validated | The "I never knew that was the bar" conversation at promotion time |
| The decision record, in plain English, of why this framework was chosen over the others considered | Head of People, signed off by the leadership team | At decision | The "why did we pick this one" question two years later when the leader who picked it has moved on |
| The re-levelling plan, including who is in scope, the sequence, and the exceptions | Head of People, signed off by the leadership team | Before re-levelling starts | The drift where two structures run side by side |
| The exceptions register, with each exception, its reason, and its expiry date | Head of People | At the moment each exception is granted | The exceptions becoming permanent, which is how frameworks die |
| The re-validation calendar, with the next review date and the trigger for an off-cycle review | Head of People | At decision | The framework describing work that no longer exists |
| The communication to employees, written as if a person will read it | Head of People, reviewed by legal locally | Before publication | The employee finding out about the framework from a manager who read it once |
| The manager briefing pack, with worked examples of how to use the framework in a one-to-one | Head of People, delivered through line managers | At launch | The manager who applies the framework inconsistently, which is the manager who breaks it |
Questions to Ask Before You Commit
On the work, not the document. Ask your team: "Describe, in your own words, what a person at level three does that a person at level two doesn't." If the answers agree, you're ready. If they don't, you've not finished the description.
A bad answer sounds like: "It depends on the function" or "the matrix says".
On the next rung. Ask: "What would a person at level three have to start doing, in their actual job, to justify level four?" If your team can describe the change, the framework works. If they describe a wish list, the framework is decorative.
A bad answer sounds like: "More of the same, at a higher level" or "strategic thinking".
On exceptions. Ask: "How many people in the last reorganisation did we hire above the structure, and how many of them are still with us?" If the number is high and the retention is low, the structure is being treated as a suggestion, and the next framework will be treated the same way.
A bad answer sounds like: "We always make exceptions for hard-to-fill roles" with no register.
On the existing population. Ask: "If we applied this framework tomorrow, who would be in the wrong place, and what is the plan?" If the answer is "we'll cross that bridge", the framework is going to be a problem, not a solution.
A bad answer sounds like: "We don't think anyone would be in the wrong place", which means no one has done the work.
On the re-validation. Ask: "When was the last time this framework was tested against the actual work, and what changed?" If the answer is silence, the framework is a museum piece.
A bad answer sounds like: "We refresh it every few years" with no calendar.
On the conversation at the top of this article. Ask: "How many times in the last quarter did a manager come to you to ask why someone is at the level they're at?" If the answer is more than a handful, the framework is failing the test it exists to pass.
A bad answer sounds like: "That's a people problem, not a framework problem."
What Getting This Wrong Actually Costs
The first cost is the one you can feel, which is the time you spend in the conversations you can't have. But you're not the only person who pays. So does the director in your office, who leaves not because she was refused the promotion but because no one could tell her what the promotion would require. So does the senior engineer in a different office, who is paid less than a peer at the same title and has stopped asking why. So does the manager who is about to hire above the levels because the levels don't yet describe the work, and who will then spend two years explaining that hire to everyone they manage.
So the second cost is the pipeline. The people you wanted to keep are the ones who can read a level description and tell, instantly, whether it was written for them or about them. They're also the ones who will leave first when the description is clearly not for them. The framework that can't be explained in a room is the framework that loses the people you most wanted to keep, and you won't see the loss on any report. You will see it in the quiet quarter when the senior team turns over and you can't remember who you were trying to keep.
The third cost is the one that arrives two reorganisations later, when someone rebuilds the framework from scratch because the last one was unreadable, and the people who lived through the last one are quietly certain that this one will go the same way. So the question isn't whether you can afford to build a framework. The question is whether you can afford to build one that nobody can defend, and then to build another one after that.
When You Are Ready to Go Further
If you've read this far, you're past the stage where a definition would have helped, and you're at the stage where the next thing you need is a way to test the approaches against each other on your own situation. HROpsLab publishes independent comparison work on the decision points that sit underneath HR operations: levelling, job architecture, the moments where the structure meets the people. We are a review publication. We sell nothing, we supply nothing, and we don't advise. We publish what we find, and we publish the reasoning so you can rerun it on your own numbers.
If you want to see how the approaches we've reviewed here compare on the questions you actually have to answer, the comparison work on the site is built to be read alongside a decision like this one. We don't sell you a framework. We help you see which one is closest to the shape of your problem, so that when you go into the room with it, you go in with your own conclusion rather than a vendor's pitch.
Frequently Asked Questions
What is a job architecture, and how does it relate to levelling?
A job architecture is the family of roles in your organisation grouped by function and ranked by level. Levelling is the part of the architecture that decides what makes one role a four and another a five, and what the next rung looks like. The architecture is the map. The levelling is the contour lines. You can have one without the other, but the architecture without levelling is a phonebook, and the levelling without an architecture is a set of ladders propped against nothing.
How many levels should a company have?
The honest answer is the smallest number that lets you describe the work. For most companies under five hundred, that's four or five rungs in a single ladder, or three per track in a dual ladder. For larger companies, it's more, but only because the work is more varied, not because more rungs is better. Every rung you add is a rung you have to write a description for, defend in a promotion conversation, and re-validate next year. If a rung doesn't earn its place by describing a real change in the work, it's a rung you don't need.
When should we introduce levelling?
When the founder's memory is no longer reliable, which is usually somewhere between thirty and eighty people, depending on how concentrated the workforce is. The signal isn't headcount. The signal is the first time a manager can't explain to a candidate, in plain words, why the role they're being offered is at the level it's at. That's the moment a description would have helped, and that's the moment to write one.
Should we publish levels to employees?
Yes, with a one-page summary per level that a person can read in two. The version to publish isn't the matrix and not the points-factor grid. The version to publish is the plain-words description of what the role does and what the next rung would ask of it. Employees who can read it use it to plan their next move, which is the conversation you want them to have. Employees who can't read it will make up their own version, which is the conversation you don't want them to have.
How do we handle someone who is over-levelled under the new framework?
In writing, with a plan, with a timeframe, and with a path back. The conversation isn't optional, because the framework has to win, but the path back is part of the framework, not an exception to it. Most over-levelling is scope that has shrunk, not performance that has fallen, and the framework should be able to describe what would have to change for the level to be right again. The hardest case is the person whose title was the promotion and whose work never caught up; that conversation is a project, not a one-to-one, and it has to be resourced as one.
What is the difference between a level and a title?
A title is a word on a business card. A level is a description of the work. The same title can exist at different levels in different functions, and the same level can carry different titles in different functions. If your level and your title say the same thing, one of them is redundant. The level is the one you keep, because the level is the one that describes the work, and the work is the thing that doesn't change when the reorganisation lands.
How do levels relate to pay bands?
The level describes the work. The band describes the pay for the work. They're related but not identical, because the market for a role at a given level can move without the level moving, and a role at a given level can be more or less critical to your strategy without the level changing. The right relationship is that the level is the input to the band, not the output of it, and the band is rebuilt from market data on a different cadence from the level. Where this falls down is when the band drives the level rather than the other way around, and the framework becomes a way of justifying pay rather than describing work.
How often should we revisit the framework?
At minimum, once a year, and off-cycle whenever the work has changed in a way the framework can't describe. The annual review doesn't have to be a rebuild. It can be a confirmation, with a written record that the descriptions still fit the work. The off-cycle review is triggered by a specific change, usually a new function, a new technology, or a reorganisation that has shifted scope. The framework that has not been re-validated in two years is a framework that's being run on trust, and trust is what you've when you don't have a framework.
HROpsLab is an independent review publication for HR operations decisions. We test what works, publish how we tested it, and stay out of the sale.
