Building the cornerstone of your people-stack: the job level framework (a guide)

One of the most popular things HR pro's are most excited to to ask me about, is job level frameworks.

How to build them, how to scale them, how many levels, how many tracks. Everything.

And it makes sense. They form the bedrock for so many things:

• Compensation

• Performance

• Headcount planning, the list goes on.

But it's one of those topics that can quickly become a little overcomplicated, which just makes it cumbersome. And in a startup, cumbersome can kill your company.

For example, it can be all too easy for a job level framework to have:

• Too much granular detail,

• Levels the business doesn't use, and

• Unclear (or un-real) comparisons between levels.

So it's important to get it right, and often the earlier you can build one, the easier it makes many of the things I mention above.

So where do you start and how do you get to the promised land of a job level framework?

Well you could sample from the many places that give frameworks away for free, such as:

• Here,

• Here, and

• Here.

But for me, adopting someone else's framework might be good for a rolling start in building your own, but often feels a bit off. Kind of like wearing someone else's shoes. It was designed for them, not you.

Side note: I've done this before, and blindly applied a job level framework from another company to my own. It was an abysmal flop.
Our people didn't see themselves in the framework, and they rejected it outright. I walked away with my tail between my legs and had to try again. So learn from my mistakes.

How do you build your own?

(ps: I'm not going to go into why you need one/how they're used, I'll assume you're already all across that)

Any formal 'job level building' process will tell you that you need position descriptions. But let's be real, you're in a startup, you probably won't have them (I gotchu).

Instead, we're doing this with a bit of feel and a lot of consultation with the people who know those roles best: your leaders.

Job Families

I like to start with job families (a group of roles that are functionally similar) because comparing roles is easier when they're functionally similar. Start by identifying each group of roles (a job family).

Normally you can do this simply by looking at you discrete departments. But not always. In most SaaS companies, this won't be too hard. It will be families like: Engineering, Product, Design, Customer Support, Sales, Marketing, Finance, People, and maybe Legal. The usual suspects.

• A good rule of thumb: if the primary purpose, core skills, and success measures of the work change, you’re dealing with a different job family. If they stay the same, you’re not

Job Levels

Once you've made a list of all the 'job families', we're going to go family by family and dive into roles.

Let's say we're focusing on the People team first. We're going to do this:

• Write out each unique title on a post it note:

  • Bear in mind that you may have roles that are called different things but do the same thing.

  • You may also have roles called the same thing, but are totally different.... welcome to startup land!

• Group roles in order of seniority

  • You may end up with something like:

• Next is where the consultation piece comes in. You should be querying the head of that department (or their leaders) on every aspect of the order. Things like:

  • Are the HRBP and TA really similar in size/shape of role?

    • Or would one be higher/lower than the other? Why?

  • Are you likely to need levels between these roles in the near future (next 6-months)?

    • Where would they sit relative to existing roles?

Do this for each job family independently, because we need to do something else before we 'stitch' these job family's levels together into one big framework.

Job Traits

Here's where things might feel a bit backwards, but you'll see why I think this order works instead of tackling it first.

While building the general 'order' for roles within job families, you want to keep an ear out for the kind of language leaders use when describing roles, and in particular, articulating what differentiates them. These are what are called 'job traits'.

Job traits are a set of descriptors that defines the elements of your roles. It's what will help us distinguish your most junior role from your most senior, and everything in between. These are like the DNA of roles at your company, and give you a clear set of levels that allow you to be consistent in how they're applied (important for making sure this process is fair)

Crucially, this is also where you're going to distinguish what makes a role an 'Individual Contributor / Professional', or a 'Manager / Leader'. That is, where the primary focus of the role is on delivering impact through one's own work vs through the work of others.

Here's also where you may spend some time on a bit of a time-suck question, which is 'what is a manager?'
I say this because, in my experience, simply having a direct report doesn't always mean you're a manager. So it pays to agree as a business when someone is a manager vs just has a bit of responsibility for the work of others (but it isn't their primary focus).

Create a list of the common descriptors you hear, and when they differ (for example for a leader role vs a professional role, or different roles at different levels).

This might result in traits like 'responsibility', 'impact', or 'autonomy', and they should eventually be defined at each level of your framework.

You will find AI of great help in a step like this.

Bring it Together

We're on the home stretch!

By now we should effectively have a set of mini job levels for each job family. Our final focus is bringing it together into one company-wide job level framework (which is important for a lot of reasons, most of all, looking and feeling like one company, so don't miss this step!).

Here, you should use the job family with the most levels, and see whether the others match up with the other job family levels by using the traits.

In practice, it might look something like this.

In this really simple example, we can see that Finance have the smaller org, and that we've evaluated Head of HR and Head of Finance to be of a similar size/level, based on the job traits.

The same goes for the Accountant being similar to HRBP + TA. Finance doesn't have any other roles, so there is nothing in level 1 for them right now (although might be in the future).

OK but what about tracks?

Something that is common to engineering forward businesses (like SaaS) is creating a pathway for professionals/individual contributors, that allows them to progress without having to take on managerial/leadership responsibility. Thus we go from the more traditional job level framework like this:

To something that caters a little more to this modern setup:

And that's it 🎉 by now, you should have a job level framework that represents your entire organisation, and the people within it.

You can now use this to harmonise titles across the business, set salary ranges, and use in headcount forecasting (Finance will love you!).

What do you think?

Is there anything you'd add to further make your framework more effective? Or questions you have about a step in the process?

I'd love to hear from you in the comments.