Working out framework parameters

Why do I need to set parameters?

While your framework build and rollout project might be led by one individual (the Project Lead), there’ll be a group of people working to build out content tailored by team and function.

Of course it depends on the size of your organisation, but we typically see groups formed of the Project Lead, HR Business Partners and Function Leads, plus the managers and team members actually using the frameworks day-to-day. That’s a lot of people. So it’s important you establish some parameters at the start of the project.

By working out your framework parameters you can:

• Drive content consistency across your organisation

• Make the build more manageable and straightforward for HRBPs and Function Leads

• Set guardrails that help builders avoid common pitfalls and mistakes

• Facilitate internal mobility — employees can easily compare and contrast

• Create a one-size-fits-all rollout plan and resources.

Now let’s take a look at each of the parameters you’ll need to define:

Teams and tracks

Define teams within your organisation, and the tracks within each team

What’s the difference between a team and a track?

Your organisation is made up of teams — engineering, marketing, product and finance to name a few. Each of those teams should have their own framework within Progression.

Within each team, you can add tracks. Tracks break teams down into sections, making it easier to identify the different progression pathways available within a team, both vertical and lateral.

Most commonly, a team is broken down into two tracks — Individual Contributor (IC) and Management — but it might also be split into disciplines, particularly for larger teams. Where there’s only two or three positions within a team you might only have one track — that’s fine too!

Positions within a track increase in seniority depending on where they sit — seniority increases from left to right.

Admins can add tracks as teams grow, or move a track into a different team entirely.

Actions:

1. Make a list of the teams in your organisation

2. Decide how you want to approach tracks — if you take the more generic IC/management track route, you can add these, or you can ask the HRBP and/or Function Lead to create discipline-specific tracks

3. Assign an HRBP and/or Function Lead to each team.

Positions

Define position naming conventions and levelling, and decide whether you’ll include salaries in the framework

How do I decide the position naming convention?

The naming of positions can be approached in three ways:

1. The explicit approach

Positions match all job titles within a team exactly and/or drill down into disciplines within a team, for example Senior Frontend Engineer and Senior Backend Engineer.

Pros: It’s easier for employees to understand exactly what’s expected of them in their job right now or a position they’d like to move into because the skills within their position are tailored more closely to it.

Cons: It can take much longer to build out the positions with skills tailored specifically to job titles, and the number of skills within the framework can become bloated and unmanageable. The team will also need more tracks to accommodate the different disciplines included.

2. The abstract approach

Positions are kept generic, for example Associate Software Engineer, Mid-level Software Engineer, Senior Software Engineer.

Pros: You’ll create fewer positions and skills because they apply to more job titles. That means you’ll be able to rollout your framework sooner, and updating content will be more manageable because there’s less of it. This is especially useful for larger organisations with more positions.

Cons: Your framework will lack the nuance of each job within a team, and it can be harder for employees to gauge what’s expected of them in their job right now or a position they’re looking to move into.

3. The numbered approach

Instead of job titles, numbers are used to denote the seniority of a position within a team, for example SWE1, SWE2, SWE3.

Pros: Opting to number your positions can really help where job titles are inconsistent (eg. Engineering Lead and a Head of Marketing). Assigning employees numbered positions doesn’t impact their job titles but makes their level clear, so it’s easy for them to compare their position against another in the organisation (and you don’t have to embark on the mammoth task of retitling everyone!)

Cons: It’s not always immediately clear which job titles correlate to which positions.

No matter the approach, your position naming convention should be consistent across your organisation.

How do I establish a levelling structure across the organisation?

Establishing a new levelling structure across your organisation is outside the scope of this manual and the six week onboarding process. Let your Onboarding Lead know if you need support in this area though — we can recommend consultants able to help.

Will we include salary data within Progression?

Make a decision on whether you want to share salaries in Progression

You have the option to include salary bands within positions in Progression, and the option to break salary bands down by location. Salary bands aren’t compulsory, but it’s a good idea to decide upfront whether you want the positions within your organisation to include them.

Actions:

1. Decide position naming convention

2. Decide whether you want salary bands to be visible in all positions

Categories

Define skill categories

All the skills in your frameworks sit within a category. Categories help distinguish between different groups of skills, and can help determine who in your organisation is responsible for which skills. They’re also useful for managing skills, providing a snapshot of the different skill types in a framework.

How many categories should the framework have?

While there’s no limit to the number of categories a framework could have, we strongly recommend limiting it to three or four. Any more than that, and your framework can become confusing.

What categories should the framework have?

Skills can be grouped in the following ways:

1. Domain-specific

Also known as craft or hard skills, these are the technical skills needed to do a job. Domain-specific skills include Copywriting, Data Analysis and Testing.

2. Core

Also known as human or soft skills, these are the transferable skills generally required of everyone within the organisation. Core skills include Communication, Organisation and Problem-solving. Often, skills linked to an organisation’s values are grouped in the Core category.

3. Leadership

Leadership skills include Giving Feedback and Stakeholder Management. More specific management skills, like Developing Others and Hiring and Org Design also fall under this category.

While it doesn’t matter what you decide to call your categories, their definition should be clear and they should be used across all frameworks within your organisation.

Actions:

1. Decide category names and definitions

Skills

Decide how many skills each position within your organisation will have

How many skills should a position have?

Every position within a framework is made up of skills. These skills give employees the clarity they need to understand what’s expected of them in their job and how they can progress, and form the criteria for managers to track, evidence and support growth.

While there’s no limit to the number of skills a position could have, we strongly recommend anything from eight to 12, 12 being optimal.

Here’s why:

• Your employees have a finite bandwidth — if their position has too many skills there’s simply no way for them to keep them all front of mind

• The more skills a position has the more likely the employee will feel overwhelmed at the prospect of growing them all — this’ll ultimately lead to disengagement

• Frameworks with more than 12 skills can feel unwieldy and bloated, and it can be harder for managers to have impactful, focused conversations with their reports

• Positions with targeted, well-constructed and up-to-date skills unlock the career clarity employees so desperately need — the fewer the skills your frameworks include, the easier it will be for HRBPs and/or Function Leads to ensure their quality.

• The fewer skills you commit to building at the start, the quicker you’ll be able to rollout and start iterating based on real world usage — remember, these skills aren’t set in stone, you can always edit, swap out and add more skills later.

All skills will fall under a category — depending on the position you might have an even split between categories, but you might also see skills more heavily weighted to a category depending on the job type. For example, in an IC track, there may be more domain-specific skills and fewer leadership ones, with the balance shifting with the level of seniority.

Actions:

1. Decide how many skills each position will have, and ensure this is consistently adopted across the organisation

Read next: Building your framework