Having determined which positions we are including in our frameworks in Part One of this series, and which skills to include in Part Two, the final stage in building a framework is determining which levels of skills are required for each position. We've done the x-axis, and the y-axis, now we need to fill in the middle!
This final step is where you create the skill expectations for each role, where you determine what each role across your team requires in practice.
As with all the previous stages, do this in consultation with your team.
We’re going to start with the most common approach to this exercise. Then we’ll look at what the limitations of this approach are, and the options we can take to mitigate these limitations.
The basic approach to assigning skills levels, is to have them map directly to the levels of hierarchy.
In the example below, a level 1 Associate Designer (PD1) has a set of level 1 skill levels, and a level 5 Principal Designer (PD5) has a set of level 5 skill levels.
The linear skills to positions approach each skill growing through five levels of organisational hierarchy
This approach is fine, and it is common. It is simple to understand, and, in particular if you've built in a spreadsheet beforehand, it's almost certainly what you have already. In particular for small teams/organisations it will work well, so don't be scared of it.
There are some problems with this approach that you might run into.
Growing the number of levels in your organisation or team is easier, more common and more necessary than growing the number of levels each skill contains.
Organisational hierarchy will and should change. You need to make sure that everyone in the organisation has somewhere to go. It’s relatively easy to add two more levels of hierarchy, you’re just creating new positions.
However, skills, once they are written, take someone from beginner to expert, across a set number of levels. Once written, the beginner and expert requirements at the top and bottom are established, so to add new levels, they have to fit within the middle. Adding meaningful steps within what already exists is tough, as they were written to cover all levels.
And you definitely don't want your skills framework to prevent you adding organisational hierarchy where it's needed.
Don't worry. There are solutions.
Are there skills that can 'top out' before the higher levels of the organisation?
If you have 7 levels of organisational hierarchy and 5 levels of skill hierarchy, could some skills grow between levels 1-5, but by the time you're at level 5 in the organisation you should be an expert? This would leave levels 5, 6 & 7 having the same skill level.
Core, basic skills such as Communication or Initiative might fit this for example.
Similarly, are there skills that don't need to start until a higher level?
Are there skills that lower levels don’t require at all? Could Strategic Vision start at level 4 heading leading up to the very top? Presuming it's not something an entry level role need think about.
If those don’t work. Does each move up the hierarchy require upskilling of every skill?
If you need to add a role between Associate Software Designer and Software Designer, (maybe Senior Associate), could you split the skill development between the two? Half the skill levels increase between Associate and Senior Associate, and half between Senior Associate and Designer? That way you can add organisational hierarchy without adding skill levels.
If you must rewrite the skills.
Keep bottom level and top level where they are, and start again with the middle levels. Find more granular definitions of the impact someone must have, or the level of influence that skill encompasses.
As with the rest of the framework building process, you won't get this right first time.
So make your best effort, get started, have conversations around the framework, and iterate based on the feedback from those conversations.