How to Build a Job Leveling Framework from Scratch

Most HR teams will eventually reach a point like this - a promotion dispute, a pay equity complaint or a new hire who wants to know why two employees with the same title are pulling in very different salaries. When that happens, the absence of a job leveling framework goes from a vague background concern to a legitimately urgent one. Titles start to drift, pay bands get applied differently depending on who's asking, and employees slowly lose faith in leadership when they can't get a straight answer about how advancement works.

Most HR teams delay it because the scope of it alone feels massive and the worry that it'll go wrong makes it easier to hold off even longer. But the costs still show up in hard ways over time - employees who leave because they can't see a path forward and managers who have no way to justify their compensation decisions when it comes up.

A well-built leveling framework does quite a bit more than arrange titles neatly on an org chart. When it's done right, it gives everyone in the company a shared language around growth - managers have a defensible basis for pay and promotion decisions, and employees finally get a picture of what advancement looks like and what it takes to get there.

Let's build a job leveling framework that sets your team up for success!

What Breaks Down Without a Level Framework

Without a leveling framework in place, a few areas start to slowly come apart - and the longer it goes unaddressed, the messier it gets.

Pay gaps are usually the first warning sign. With no structure to reference, compensation ends up being decided on a gut feel, on how well someone negotiates or on whoever made the most noise in the last budget meeting. After a while, two employees doing nearly identical work can end up with wildly different salaries and no one has an explanation for it.

Promotions can get messy fast when no one has defined what "senior" or "lead" even means at your company. Without a picture of that, every promotion conversation has a chance of turning into a debate - some managers push for their reports, others push back, and what could have been a quick call ends up turning political. Employees pick up on this. Over time, advancement starts to feel a bit too much like it depends on who you have in your corner.

And attrition starts to climb. Most employees won't make a dramatic exit - they'll just stop seeing a future at the company. Once they can no longer picture what the next two or three years might look like for them there, they're going to start looking elsewhere. A leveling framework addresses this and gives everyone (managers and employees alike) a shared language around growth, expectations and pay.

A manager gets asked by one of their employees why a colleague earns more (and without any pay framework to point to, there's no actual answer). It's not a comfortable position to be in, and it's the type of situation that can slowly chip away at trust. From what I've seen, these conversations almost never end well when there's no structure behind the decisions.

Organizations like Dropbox and Rent the Runway cared enough about this to publish their leveling frameworks publicly. A public framework is not a small move - it's a strong signal that this structure is worth doing right. With the "why" out of the way, the next section gets into how to actually build one.

Set the Standards Before the Titles

Before any names, titles or level labels get assigned to anything, the criteria need to come first. Of the whole framework-building process, this part is probably the most important one to get right - and it also happens to be the one that gets skipped the most.

The criteria are the building blocks of your framework - they give each level its shape and meaning, and each one defines what a person at that level owns, what they're responsible for and what they can take on without a second opinion.

The most common ones to cover are scope of reach, decision freedom, technical depth and leadership. Scope of reach is about whether their work touches just their own output, their immediate team or the wider company. Decision freedom is what they can call on their own versus what still needs sign-off. Technical depth is about how advanced or hard their work is. And leadership covers whether they lead others - and if so, at what scale.

When titles come first, the whole framework ends up built backward. Labels like "Senior Specialist" or "Lead Associate" carry plenty of baggage with them - everyone arrives with their own idea of what those words mean, and those ideas are almost never the same from one team to the next. Two managers can use the title "Senior Engineer" casually for months and walk away with wildly different pictures of what that person is supposed to do day-to-day. The title felt shared. But the meaning wasn't.

Once the criteria are set, every conversation about levels has a shared language to work from. The guessing goes away, the conversation stays grounded in something concrete and the titles that you eventually hand out actually mean something - instead of empty labels that each person reads a little differently.

How Many Levels Does Your Company Need

Most businesses land between four and six levels in their job framework, and it's not an accident. It's where it all works best as work grows across a normal organization, from entry-level contributors to senior contributors or early managers.

Drop below four levels, and you've compressed the entire growth path down to just a handful of milestones. Employees will hit a ceiling fast, with no place left for them to go - and it turns into a retention problem before long. A two- or three-level structure can look clean on paper. But it forces you to group together employees who are doing very different types of work, which gets messy fast for compensation and expectations.

On the other end, too many levels create a whole different type of problem. At eight, nine, or ten levels, the difference between each one gets so narrow that it's nearly impossible to explain what separates them. Promotions that are supposed to feel like a genuine milestone wind up feeling more like a paperwork update. Managers spend more time justifying level placements than coaching their team members and helping them grow.

One of the most common mistakes I see is building a structure for the company that you're hoping to become, instead of the one that you actually are. So get it right for where you are, and make sure that there's enough room to grow into it - so you won't have to tear everything down and start over.

Each Track Gets Its Own Role Card

With the right number of levels locked in for each track, the work is ready to start - the role cards are what bring those levels to life. "Leads projects" and "leads cross-functional projects with unclear scope and no direct authority over other contributors" are two very different roles. The second phrase tells you something concrete about the role. The first one could mean almost anything - and whoever reads it is going to interpret it any way they see fit.

A single card also can't pull double duty across every role in your organization. An engineering Level 3 and a design Level 3 are two very different jobs (even when they land at the same pay tier), and each track does need its own set of descriptions, ones written around the day-to-day work that employees in that track are expected to do.

A place to start is to look at what other businesses have already made public. Dropbox and Rent the Runway have leveling frameworks that are worth your time. Neither one will be a perfect fit for every company. But they give you a decent baseline to work from - and with something concrete in front of you, the whole process tends to move much faster than it would from a blank page.

The language on these cards can make or break the entire framework - it's the part I see go wrong more than any other. Vague phrases like "shows leadership" or "communicates well" are nearly worthless, because two different managers will read them in two different ways, and each description needs to be grounded enough that you can point to an example and say with genuine confidence, "yes, that fits this level" or "no, that's actually the next one up." Teams will spend weeks building out a framework and then fill the cards with language so soft that it falls apart the second a calibration conversation starts. Write for testability - each card needs to be grounded, written at the track level and worded in a way that leaves no room for misreading - that's what makes it worth having.

Pay and compensation bands are coming up next - but for now the focus stays on the behaviors.

Set Your Pay Bands With Market Data

With your leveling cards in place, the very next move is to connect each level to a pay band (and it's a step that's worth doing right from the start), not something to patch in later. Plenty of teams skip that step altogether. The whole leveling structure gets built out, leadership signs off on it, and it rolls out to the org - and only then does anybody start thinking about comp ranges.

That order of operations is painful, slow and expensive to unwind. Pay structures that get bolted on after the fact almost never map cleanly to the levels already in place, and at that point, you're stuck. Either you go back and rework the framework, or you live with a comp model that won't hold up the second it gets any actual pressure on it.

Before any final decisions get made, anchor your pay to your levels first. Tools like Radford, Mercer and Levels.fyi make that much easier.

A leader agrees to promote one of their direct reports to Senior Engineer, then walks over to HR and finds out that the pay range for that level doesn't come anywhere near what they already committed to. A broken promise is a trust problem and a retention issue - and it traces back to pay bands and levels that were designed in the wrong order.

Pay bands work best when they're built alongside your levels from the start - not patched in later as an afterthought. A well-integrated structure like this keeps your employees' trust steady, and it gives your finance team much less to argue about every time a comp conversation comes up.

The next section covers how this framework holds up against actual employees and actual roles - but that part comes later. For now, the focus stays on pay mapping. Validation is a separate step.

Run a Pilot Test With Real People

A job leveling framework that gets built in isolation (even a well-designed one) tends to fall apart the second it meets actual employees and actual managers. It's one of the most common failure points I run into, and it traces back to a skipped pressure-testing phase before launch.

A few focus groups or pilot review sessions where your managers actually put the framework to work on real employees can tell you quite a bit. Hand them a few employee profiles and have them assign levels based on your criteria. From there, get everyone in the same room and have them compare their answers.

Something else to watch for is quiet resistance. Managers who didn't feel included during the design phase don't usually complain out loud about it - they'll nod along in meetings and then just sidestep the whole framework the second it matters. A framework without genuine buy-in doesn't fall apart all at once - it just slowly drifts back toward the ad hoc leveling decisions that you were trying to get away from.

Make sure to get some feedback from these pilot sessions - and don't shy away from the uncomfortable parts of the conversation. A little pushback at this stage is much easier to manage than a full rollout that your team doesn't believe in - or that they don't use.

Make and Keep a Leveling Framework That Works

A framework is only as strong as how reliably it gets used. The hard work of defining those levels and putting everything in place is only the beginning - the bigger challenge from that point is making sure the whole system stays together and works the way it was meant to.

Documentation is always the right place to start. Every level, every criterion and every expectation needs to live somewhere that's accessible - not buried in a folder that no one ever opens. A well-organized and easy-to-reference document that any manager can pull up mid-conversation during a review or a promotion talk is worth more than even the most well-designed framework that only ever lives in one person's head.

Manager training deserves quite a bit more credit than it tends to get. Managers need to be able to apply whatever framework you give them with consistency across all kinds of different teams and situations. Without that shared foundation, the same framework can be read five very different ways by five different managers - that's right where fairness starts to break down.

The audit's the piece that most teams usually skip over. Put a schedule in place (at least annually) and actually follow through on it. New roles get added, the business changes its direction, and what made perfect sense 18 months ago might not line up with where the company is now. Levels will drift when no one is cross-checking them against recent promotions, new hires and structural changes. Give it a year without that check-in and the team will start to feel like something is off without being able to say what changed or when.

Standard check-ins are what keep a leveling framework honest. Without them, even the most solidly built system will start to drift over time, and once employees lose faith in the levels, it can take a long time to earn that back. A leveling framework is not a one-time project. It's a long-term commitment to fairness, and the maintenance side of it matters just as much as putting it all together.

Start With a Draft and Go From There

A little bit of nervousness about where to start is, well, normal. Most HR teams that have a framework started with a messy first draft and plenty of uncomfortable conversations - and what mattered was just that they started. Your framework will grow and change as your company does - it's a positive step, not a setback. The best move you can make this week is also the simplest one - write out your first set of leveling criteria (even if it's rough). You can always smooth it out later, and the first version doesn't need to be perfect.

From there, the harder part is how you keep the system honest over time. Written records, managers who enforce it the same way every time, and regular audits are what keep a framework from slowly falling apart a year or two later. Direct input from employees is also worth looking for - they'll see inconsistencies before leadership does. Whatever structure you put together now will only hold up for as long as the managers running it stay accountable to it. Without that accountability, even the best-designed systems tend to drift.

At HRDQStore, our Negotiating Style Profile was built specifically for this - it walks employees through their own negotiation style, explains why a flexible mindset gets better results than a rigid one and gives them the skills to manage those high-pressure conversations with more confidence. It's an easy tool, and it works whether your team is new to structured negotiation or just looking to sharpen what they already do.