Without a strong sense of progression, your team is at risk of losing motivation and looking for opportunities elsewhere. Here's how CharlieHR fixed these problems by building a career progression framework.
In the previous article, Ben Gateley wrote about how we had failed to give the Charlie team a meaningful sense of progression – and how it risked demotivating the company, harming our hiring process and even pushing people towards leaving the business.
Eventually, Ben, Rob (our CEO) and I came to the conclusion that if we were serious about solving this problem, we had to build a career progression framework.
This is how we did it.
What is a career progression framework?
In its most basic form, a career progression framework is something which:
- Defines the possible roles and titles across your business
- Shows which roles each team member can progress to
- Explains what someone has to do to progress to each role
An effective career progression framework offers your team clarity, and gives them a sense of meaningful progression. It stops them feeling like they’ve stagnated – and the subsequent risk of them being demotivated, or looking for progression opportunities at other companies. Finally – and most importantly to Ben, Rob & me – it shows them that you’re invested in their personal development, something we have always strived to do at Charlie.
Before you start
Throughout this entire process, the best and most important decision we made was to commit to this as a major project. This was an opportunity to build a foundational piece of Charlie culture, not something that we’d have to rebuild in a year’s time. We wanted this to sit alongside things like our Holiday Policy and our High Performance Behaviours as moments where we had put in the work, and got it right.
Here’s what “committing” looked like:
- Giving someone total ownership of the project, for whom it could be their number-one priority.
- Understanding that this was going to take time. In the end, this was my main project for a month, and involved a good chunk of Rob & Ben’s time.
- Contracting Alistair Fraser of The People Collective. Our initial instinct was that we could do everything internally – but Alistair’s expertise and experience ended up being vital. Without his help, I’d probably have spent double the amount of time on this.
There was one other crucial realisation in the planning stages: we couldn’t and shouldn’t build from scratch.
Countless bigger, richer and more experienced companies have done this before us – and many of them have made their progression frameworks public. We took a lot of inspiration from Monzo and Buffer, and spent many hours browsing through the incredible collection of public progression frameworks at progression.fyi.
How do you create a progression framework that works for everyone?
At a basic level, a progression system turns your career into a series of levels, and provides rules for how you move from one level to the next.
There’s a wide variety of jobs at Charlie, from content marketers to back-end engineers. So how do you build a system that works for them all?
One answer would be to do everything on a granular, micro-level. Build discrete progression systems for each team, all with a different number of levels and unique rules about how and when you progressed.
We decided pretty early on that we were not going to do this. Here’s why:
- This was already a major project. Creating unique structures for every job role at Charlie would turn it into a gigantic one.
- This would also require a lot of liaising with team leads, taking up their time.
- We’d need dozens of meetings to make sure everyone in the business understood each individual system.
Instead, we chose to build a much broader system: one where everyone would have the same number of levels – and the same rules for how to move from one level to the next. This would mean a focus on behaviour and values, rather than job specifics.
As this framework evolves over time, we'll add more granularity around specific skillsets – but the expectations of each level will always remain consistent.
The second question: how do “levels” work?
We had two main goals in mind which shaped the number of levels we had and how they were structured.
Goal one: Solve the “individual contributor” (IC) vs “people manager” conflict.
Ben discussed this in the last article, but in short: not everyone wants to be promoted into managerial roles – some people want to focus in on honing a specific skillset to perfection. A perfect example is Jørgen, our senior product designer. His coding and design skills make him hugely important to Charlie – but he’s not particularly interested in managing people. Businesses need Jørgens – but if the only progression you’re offering them is moving them into people management, they’ll pack up and move elsewhere.
To fix this we built the system to give an explicit choice between these roles. The levelling system starts junior employees off as ICs, but as they progress, the path splits. At this point, they’re given the choice between continuing as an IC, or moving into people management.
Goal two: create a nuanced, tangible sense of progression.
Our old system was pretty traditional. We divided most roles up into “junior”, “mid-level”, “senior” and “Head of.” This simply wasn’t detailed enough to give people a feeling of progression. The most glaring example was the “developer” title, which sat between junior developer and senior developer. People felt stuck in this role, with no real idea of when or how they would progress to senior developer.
We realised our new system needed to offer a larger number of levels. We looked over a lot of frameworks that had chosen to do this – most chose six or seven levels of progression. We chose to go with six.
The result was this barebones framework:
But even with six levels, we still worried about people feeling like they’d lost momentum. We wanted our system to cover a lifetime of progression. A level 1 person is just starting out, while a Level 6 is absolutely at the top of their game – so the jump between each level marks a major progression in someone’s career. To avoid this feeling intimidating, and people feeling “stuck” in a level, we added sub-levels. These give a stronger feeling of day-to-day, month-to-month progression, and work like this:
How does someone move from one level to the next?
We had our structure of levels and sub-levels. Now we needed to work out what the rules were for progressing from one level to a level above.
This meant defining a set of expectations for each level. Since we were building a general structure to work across the entire business, these had to be broad enough to apply universally.
We broke these expectations up into three areas, which we felt applied to everyone in the business, regardless of their specific role:
- Communication & Leadership
Then we went about deciding what we expected at each goal. This was no easy task – remember, this system is designed to cover a lifetime of progression. Each level had to have a set of expectations that represented a major bump in someone’s personal and professional development.
It was slow, strenuous and expensive work – but we're really proud of the end result. In fact, we've decided to make it public, so if you're building a career progression system for your own business, you can save some time and money by building off the work we've done. Just click the image below to access the full spreadsheet of our expectations for all levels of Individual Contributor and People Manager:
Building a compensation calculator
This was the most daunting part. We needed our levelling system to tell us not just someone’s seniority – but also exactly how much they should be paid.
We knew that – if we wanted to hire and retain people – we’d have to be paying at least “market rate”. But “market rate” is hardly an exact number. It varies constantly, and different people and companies have wildly different ideas about what it is for a given role. Making things harder, while a place like Glassdoor can give you an average number for a junior developer, you’ll never find benchmark data for an “IC4 software developer” – since that’s a classification unique to Charlie.
Our solution was to sift through various websites (primarily LinkedIn, Glassdoor, Indeed and a couple of other jobs boards), reach out to people we knew at other businesses, and look at Charlie’s current salaries. Throwing all this info together, we built up benchmarks for what you’d pay a junior, entry-level hire, and what you’d pay a director – for every job at Charlie. We slotted the junior salary in at Level 1, and the director-level salary at Level 6 – and filled in the blanks.
In terms of experience, the jump from a level 1 to a level 2 – while nothing to sniff at – is much smaller than the jump from a level 5 to a level 6. Each step is larger than the last, and we wanted the salaries paid at each level to reflect that, so we added a multiplier effect – each time you go up a level, your salary increases by a larger percentage, making each jump larger than the last.
Creating meaningful titles
We had a set of levels, a list of expectations for each level, and salaries linked to each level. Now we just had to give all the levels names.
This task was an optional one. We could have left everyone with the basic IC/Manager numbers – adding titles to each level was just icing on the cake. But we decided to do this for a couple of reasons:
- A number alone doesn’t communicate someone’s role and responsibility particularly clearly – especially to people outside the business. If you say “I’m an IC5 software developer at CharlieHR”, nobody’s going to know what you mean.
- Simply changing a number isn’t a particularly satisfying reward for progressing to the next level. Getting an entirely new title feels weightier.
Here’s a list of all the basic job functions at Charlie:
- Content marketing
- HR advice
- Customer success
- Data analysis
- Product design
- Product management
- Customer operations
- Business development
- Software development
Each job was given its own set of titles, for all IC and manager levels, creating a result like this:
This took a long time. A chief concern was fairness – particularly between the IC and managerial pathways. We wanted the framework to demonstrate that we valued managers and ICs equally. If the titles felt unbalanced between the two pathways, we were undermining all our work.
For example - the highest position on the managerial path for software developers has the title “Director of Engineering”. That sounds super important - so how do you create a corresponding title for the IC alternative? How do you communicate that an IC software developer is as important as a Director of Engineering, but doesn’t have people management responsibilities?
In the end, we decided on “Principal Software Developer” - which conveys a high level of seniority, but doesn’t imply any management commitments. We then repeated this process for dozens of other roles.
Eventually, we got there. Here’s every possible title (for now!) at CharlieHR.
Note: these are potential roles. Many of them are currently unfilled at Charlie, and we don't expect to fill them all any time soon. This is a roadmap for progression, not a prescription for what the business should look like.
Fitting everyone in
Everything up until this point had been theoretical. Now we had to see if it would work in practice.
We assessed the entire team using the progression framework, working out what level they would be – and which title and salary they’d get as a result.
This was a pretty intimidating prospect – what if there were discrepancies? What if the framework told us that someone was being underpaid or overpaid? What if we assessed someone in a senior position, and they weren’t hitting the expectations the framework listed for them?
Fortunately, while there were discrepancies, they were pretty minor: a couple of people were being paid less than the framework suggested they should be, and a couple were being paid a bit more.
For those being underpaid, this was a great opportunity for us to make up for a failing on our part: we’d been undervaluing their work.
For those being overpaid, we committed to not lowering anyone’s salary, instead giving them a smaller bump in pay at their next promotion, bringing them back into line with the framework.
But that part would come later on – since for now, everything was between me, Ben and Rob. We hadn’t even rolled any of this out to managers yet. Everyone knew that we were working on a progression framework – but nothing more than that – and explaining it to them was as big a task as creating it. In the next post, we’ll talk about how to successfully roll out a project like this.