This is the number one question that people ask Progression. And no wonder. With very limited research you can find public progression frameworks available with more than forty skills, and ones with just five. Forty instinctively seems a lot, but how can you define a role with just five?!
Start from the end of the process. The skills that you're expecting team members to develop for progression must be realistic, or no-one will engage with the framework.
How many skills do you think it is reasonable for your team members to focus on at any one time? Two, three, maybe four over a six month period?
How long would you expect a team member to grow all of the defined skills in their role? One year? Two years? If they can work on three skills every six months, and you want them to upskill their entire role in a year, then the framework should have no more than six skills within it. If you think they can tackle four every six months, and two years for a full role upskill, then sixteen skills is the limit.
If you have too many skills in your framework, your team will be overwhelmed, won't be able to engage with it, and will become demotivated.
"But there are some skills they need that will develop naturally and they won't need to focus on, but it's important we're aware of what's going on"
There's definitely some mileage in this. But, firstly, will your team understand, without getting overwhelmed, that some skills are 'essential to work on' and others are 'not essential but worth monitoring'? And secondly, if they're going to develop naturally... Haven't you answered your own question as to whether its necessary to track through a progression framework...?
If you're trying to provide progression opportunities for your team, then you need to provide the number of skills required to guide this progression. And not any more.
Some skills that are used in roles won't be defined on the framework. But that is expected and necessary.
Based on talking to hundreds of teams, we know that 8-12 skills is the sweet spot between granularity of role definition and engagement with the framework.
If you find that despite your good intentions you still have 20+ skills in the framework, another way to think about it is:
If someone didn't have this skill, would they not be doing their job?
A framework should be a product not a project, so it's going to change. Roll something out, and iterate over time. It's much harder to remove skills than add them, so start with the minimum you can have, and let your team add in the skills they want to track against. Check out our quick start series for a template in how to begin.