Starting your progression framework is a task that, for many, can feel overwhelming. There are so many moving parts, so many different problems to solve. How do you get started?
I've spent the last 18 months learning how different design, product and engineering teams think about progression, and build the frameworks that match their needs.
From open-source frameworks to barely comprehensible competency maps I can tell you – you can read and read and never get to the end of the advice, ideas and opinions when it comes to putting this together.
So I'm going to try to list a few of the simple tips and things to know as you get going on this journey.
For the designers reading this, you'll notice that a lot of this is effectively describing a design process. You'll have challenges around scope, building vs buying and defining problems to solve. Just like design!
OK, hold onto your butts, and off we go!
1. Know why you're building a progression framework
This may seem like a silly thing to say, but not knowing exactly what problem you want to solve is the easiest path to half finishing your framework before second guessing yourself and giving up.
This will be one of several plates you have spinning so keeping it focused on that first win will stop you getting overwhelmed by the size of it all.
There are several reasons why it can be useful to have a progression framework. Very much like hiring, it would be lovely to solve all of them in one fell swoop but chances are there are one or two that will be 'urgent' for the team. Focus on the one problem you need to solve first.
- The team is asking for clarity. People are leaving and it's unclear why. When you're asked about what people need to do to demonstrate growth, you don't have a good answer.
- You have one or several team members who need some help understanding why they're not being promoted/paid more/running the team. Describing your expectations on gray will make it feel less like just your opinion.
- You have multiple managers (including first timers) on your team and you want to ensure their expectations are aligned, and that you're supporting their every-day management efforts
- You need to quickly grow your team, or improve the quality of the team. A progression framework will give you the wiggle room to fit more people in while managing the expectations of your existing folks.
- The HR or people team is putting pressure on you to do it, otherwise they will. And you don't want that.
2. See this as an ongoing product, not a one-off project
We've spent the last several decades learning about lean methodology, just-in-time and avoiding 'big bang' launches in favour of agile and constant iteration.
Your progression framework is no different.
One 'big bang' launch with the assumption that you'll no longer need to put any effort in afterwards misses out on the vital weekly and quarterly process that you'll need to run once it's there.
So it's important to think actively about questions like:
- How will you use this in 1:1s?
- How do you expect team members to engage with it for goal-setting, peer reviews etc.?
- How do you want to use it as part of hiring?
- How much time will I and other managers need to dedicate to ensuring this works ongoing? What rituals are needed to support it?
This detail will be the difference between success and failure – and spending months on a framework that then fails is not what anyone wants.
3. Involve your team
It may seem like the sensible thing to do is to lock yourself in a room, hash out every word, drink a lot of gin and then launch it to wild acclaim and complete agreement when it's perfect.
The problem with that is that (a) your opinion about what 'good' looks like alone might not be shared by the team, and (b) creating it will leave a vacuum of 'it's coming soon' while you go through all the pain solo. People will become more frustrated and you will get demoralised by the size of the task.
Every time I've seen a manager empower their team to help write the content and hash out the structure, it results in a quicker, better outcome with less risk of organ rejection. Getting team members involved early and often is the way to go.
4. Build for your team size
It's very tempting to look at complex frameworks like Medium's Snowflake as a small team and look to set that up when you only have a handful of folks using it. Equally you may be running a large team craving simplicity and go for a linear framework (like Buzzfeed's design framework) when you should be offering your team more optionality and opportunities to grow in a variety of ways.
As a general rule, if you're small enough to require every person on your team to be good at a very specific set of skills (e.g., Javacript, or UI design) it makes most sense to go for a simple linear framework.
If you're big or fast-growing enough that hiring and building (lots of) good people is more important than everyone having specific skills, it's worth exploring a more 'choose your own adventure' approach with a variety of paths to take to the same levels of seniority.
The latter is more complicated, so buyer beware! Progression supports either of course 😉.
5. Make it actionable
This final point is hugely important for helping anyone on your team to be able to read and change their behaviour based on your framework, without having to constantly clarify with you what that means.
High-level simple frameworks seem great: everyone can understand them at a glance, and they don't take much time to create. But they can easily fall apart when used as part of levelling and goal-setting because they're so open to interpretation.
The difference between "Has conceptual familiarity with information architecture, multi-step and cross-platform flows" and "You've produced several cross-platform multi-step flows for live projects" is that the latter gives your report very clear instructions of what you expect them to do.
While there's a risk of box-ticking that you'll still have to manage with this level of granularity, and you'll still need to adapt these goals per team, it anchors expectations, avoiding that awkward conversation six months later when they think they're a principal and you think they're junior.
