At Progression we believe that it is vital that progression frameworks be considered a product not a project.
What do we mean by that? We mean that frameworks should not be a one and done process or project. They should be an iterative living document, a tool or product that you use, change, and improve as you and your business change.
Many people consider the process of creating progression frameworks to be a lengthy process of researching, writing, levelling, assessing and rewriting, until the framework is ready for a big roll out to the team. In fact we host on progression.fyi a series of frameworks with descriptions that describe this process.
The problem is that we know of many people whose perfect framework didn't work and so they're doing it again. Here & here for example.
We've seen this happen so frequently, that we believe it's inevitable that frameworks have to change. Teams grow, with new roles created. Roles change as responsibilities shift, or individuals want to take their role in new directions. Most importantly, you discover through using it that the framework wasn't as perfect as you thought to begin with.
If these changes happen and you've treated your framework as a project, something that was a big piece of work, with an end date, and for which you've had a big bang roll out, then to make changes you have to go through that process again.
However, if you set up your framework as a product, with the knowledge that it's going to change, and the intention that it should change, you can:
Roll it out and start finding value from it much faster, as it doesn't have to be perfect before you share it
Engage your team much earlier. You don't need to worry about differing opinions as you're looking for a first version (not a perfect version), and then you're going to test and iterate on it from there.
Iterate and improve on the framework based on implementation and testing rather than theoretical discussion.
Practically how do you do this?
Get a framework that's good enough, fast. Don't try to make it perfect. If in doubt use fewer skills rather than more as it's easier to add skills than take them away. Work with some of your team on it to ensure their buy in early. Check out our guidance on how to get started.
Brief your team that the framework will change over time and this is an MVP version. It's vital they take ownership of the framework through this process, and this initial set up is key.
Run a first round of check-ins against the framework. Frameworks by themselves don't work, they require conversations in order to be functional.
Receive feedback on the framework and what changes the team would like to see moving forward. This might include which skills that are included, the levels of the skill associated with each role, the positions themselves, or just the examples provided to help achieve a certain skill.