Areas to think about when introducing a progression framework

I’ve been involved in a couple of progression frameworks. In my last role I led a group where we redeveloped the Engineering framework, and now in my new role I’m building on some already great work done to help get our first Engineering version done, before I kick off our Enginering Manager framework in December.

From both processes I’ve learnt a lot about dos and don’ts. In the rest of this post you’ll find some key lessons I’ve learnt to date, along with a set of questions to ask when you next think about creating or updating a framework. If I learn more into the future I’ll try to update this as an evolving resource.

🔧 A progression framework is a tool that helps everyone have shared expectations

But first off, what even is a progression framework? In short, it’s a career pathway for people, which gives some structure around what they’re expected to be doing at different levels of seniority.

Progression frameworks can help a manager and managee have a shared vocabulary to talk about what a person’s great at, and what they need to do to be promoted. It can help individuals decide on goals and areas of development. It can also be used before someone’s even started; checking whether they’re capable of operating at the specific level that you’re missing in the team. And of course… it’s a way to aim for fairness of pay, and make promotions more transparent.

Many companies now see them as an invaluable tool, and you can find some great examples at progression.fyi (although please note that the Monzo framework on here is not the most current, and I don’t recommend copying it for reasons that will hopefully become clear in this post!).

⚖️ Progression frameworks can also lead to inequality, frustration, and dysfunction

Despite best intentions, getting it wrong can have damaging consequences. Tons of companies are sharing how they made their framework, but not many companies seem to be sharing what isn’t working about their frameworks, or how they’re evolving them over time. I’d like to add a bit of this into the mix, so that others can learn from it.

In my previous role, over the first year(ish) the framework was in place, it became clear that it wasn’t working as well as it needed to be. We found ourselves starting to introduce sticking plasters, whilst also initially not fully realising the damage of sleepwalking into some practices that were never intended.

The balance between specificity and ambiguity didn’t turn out as planned

The progression framework had always been described internally as “a compass, not a GPS”, meaning that it was intended to guide your sense of direction without overly specifying how you get there or being fully exhaustive. More “I’m headed East” than “it’s 50m to a river, which you’ll keep on your left and follow until you reach a fork in the path”.

Over time, we’d found that this original intention hadn’t always played out like we thought. Despite best intentions both managers' and engineers' use of the framework became quite checklisty, which led people to get hung up on wording and semantics. Some behaviours, such as “Proactively seeks feedback from the people around them” were straightforward and easy to ‘tick off’, but other behaviours (“Delivers large well-defined tasks” - what’s ‘large’?; “Leads the refactoring of complex parts of the system” - what’s ‘complex’?) left a lot to interpretation. Not all behaviours were of equal importance, but in being presented equally people would seek to demonstrate lots of ‘easy wins’ and then feel upset if they weren’t seen as adequately performing at a level.

On the flipside, the problem with a checklist (whether intentional or unintentional), is that things that fall outside don’t end up mattering, no matter how good they are. This can lead to people with other strengths or differences feeling disenfranchised because those strengths don’t map to anything, but can also lead to people feeling like they have to be a certain personality type, or do only set things to succeed. It can lead to a narrow view of what good looks like, and have people working for themselves rather than for the greater good.

Additionally, there were a number of inputs that weren’t documented at all, but which formed part of implicit managerial expectations. These were things like controlling weaknesses (i.e. someone wouldn’t be promoted to a higher level if they were demonstrating certain more negative behaviours), but these expectations weren’t adequately covered in the wording of positive behaviours they related to. Other, very specific examples sometimes cropped up in promotion meetings, memorably “would you put them in a room with a Regulator?”.

Not everyone had great confidence in what the levels meant

Engineers and Managers alike were having to parse all of the individual behaviours and mentally tick them off before being able to decide “this person Is a level X engineer”. With such an extensive list this was laborious, and it hindered new people or those who weren’t intimately familiar with it from having a strong mental model of levels.

Assessing someone’s level could be bureaucratic, or even combative

Partly because of this need for some clarity, and partly because of the accidental move towards checklisting, some people found promotions processes a painful and lengthy experience typically underpinned by a “levelling exercise” - an enormous spreadsheet containing every behaviour, that scored against a very specific view of what good looked like. This practice was accidental; it was born out of one individual manager’s interaction with a particular report, but others found it useful and it became a de facto part of the process, despite not actually being needed for a promotion. It also led to some cases of friction and nitpicking (“my manager thinks I’m a 6 but I think I’m a 7 on this item”).

It didn’t reflect a rapidly scaling variety of roles

As we’d scaled the situations of engineers had become very different. The original web framework was written for a single team that focused on one internal system, for example “Modifies and improves code outside of the developer abstractions” where the abstractions in question were a very specific part of our codebase which other web engineers didn’t touch. It wasn’t just at discipline-level though. As another example, Platform engineers began to raise that it was much easier to demonstrate behaviours in a Product team, and felt at a disadvantage.

We originally started an activity to revise and extend the behaviours on the framework to better reflect people’s situations. This got a little bit stuck - whilst many behaviours could be improved, we found that other opportunities lay in rethinking the structure of the framework itself.

Engineers who didn’t want to be tech leads weren’t well catered for

Another thing that became clear was that we needed more clearly defined support for people who wanted to stay truly on the individual contributor path, as well as those who wanted to explore technical leadership whilst staying hands-on.

The intention was to have a separate framework for both engineers and engineering managers (management was a career branch, not a promotion), but day-to-day many people around the business wore the Tech Lead “hat” at both team or Collective (tribe) level. This gave them opportunities to demonstrate more typical ‘leadership’ behaviours. Progression to Senior level required a lot of evidence of team leadership, and we realised that the framework wasn’t great for talented engineers who didn’t necessarily want to go down that route.

It gave an incomplete picture of progression

We didn’t have as many people on the most senior levels of the framework, and partly because of that the original framework felt very vague and undefined to people who were looking to progress to or through Staff levels. This made it hard for both engineers and managers to build a convincing case for promotion, or to understand exactly what expectations were.

Most importantly… both engineers and EMs were becoming unhappy

People didn’t feel that they could get promoted if they didn’t fit the mold, or had strengths that weren’t recognised. Antipatterns emerged in that individuals wanted to move teams to tick off behaviours. People would focus more on themselves as an individual rather than what teams or the business needed. Despite having a set of behaviours called “Impact”, this didn’t really reflect the outcomes and impact we’d want to encourage. We also began to have inclusivity concerns, around realising that the framework didn’t necessarily think about topics like neurodiversity, part-time workers, or a variety of other considerations.

In short… it needed to change.

🏗 Common considerations to set yourself up well

Both through the redevelopment of the above mentioned framework, and creating a new one in my new role, I’ve got a set of recommendations for you to think about. The following are intended as prompts and light guidance rather than aiming to give you all of the answers. Everyone’s situation and needs are slightly different, but by asking yourself these questions and following the suggestions you’ll hopefully avoid some of the pitfalls that you could otherwise have faced!

1. Before you get started in earnest

Make a call on ownership and involvement

First off, you’ll want to think about who’s responsible for, or involved in creating a framework. Will this be worked on by one person, be ‘top-down’, and introduced without opportunity for amendment? Will it be a collaborative effort, where without consensus it won’t happen? Or somewhere in between?

Personally I’ve had good results from one person leading, with an initial small group to work on different aspects of the problem. Once there’s a rough initial version, opening this up for wider feedback, whilst also reserving the right for the leader/core group to make final decisions seems to work well. This has helped to answer questions, clarify wording, and get buy-in along the way.

User research leads to better outcomes

I hope that you wouldn’t build a product without understanding the needs and problems to solve, and I’d strongly suggest that you do a bit of the same with your framework. With the redevelopment project, I created a survey for engineers and for managers.

The survey sent out to engineers was fairly straightforward. They’re busy folks, and we wanted to get to the heart of important elements but didn’t want them to have to invest lots of time in responding. We primarily asked about:

• Their situation, including their level, and whether they agreed with that assessment
• How they relate to the framework, and how they’ve found using it
• What they found useful
• Suggestions for change

A lot of the questions were designed to give us qualitative feedback, because we wanted to get a sense of people’s sentiments as much as gathering the data itself.

The EM survey was longer. Engineering Managers are busy too, but as a group we knew that they were particularly invested and would definitely have views, so would be happy spending a bit more time to answer. We asked this group about:

• Their situation (how long they’d been at the company etc)
• Sentiment about the framework
• Situations they’d used the framework
• How they’d describe levels/sub-levels in their own words (to see how well people were aligned)
• Tools they used alongside the framework itself
• Their likes and dislikes
• Times when they felt it had worked well, and when it hadn’t
• The future! What they thought we’d need a framework for as the business evolved

2. Deciding on structural aspects

A framework is a combination of several elements

With the redevelopment project, we’d realised through the earlier initiative that just redoing the wording of behaviours wouldn’t cut it. Instead, rather than be too constrained by our previous thinking, we questioned everything. We split the framework into three main areas to address: the structure, the behaviours that slot in, and the tools and resources to use alongside it.

In that case, impact became the primary focus for progression. This was intended to reward the outcomes and value someone was bringing to their team and the company through their work, and aimed to discourage people ‘ticking off’ behaviours to no end.

I’d recommend that you think about these three topics, specifically around what should and shouldn’t be part of the core framework. Following on, you’ll also need to think carefully about associated processes, some of which are outlined below.

Don’t require people to parse long lists of behaviours

From experience I’ve seen that a written description helps people to get a quick understanding, and helps make the overall content a lot more easily accessible. This should ideally be part of the framework itself, as keeping it separate can lead to it getting lost, or by only being considered by some (leading to inconsistencies).

Define how levels relate to job titles

I’m firmly on the side of job titles being important, especially to folks from groups underrepresented in tech, and this is a really important element you’ll need to decide on. Some places use numbered/lettered grades for level (both internally and externally), whilst others just use titles. Whatever you decide, consider your wording carefully.

Does it align with the rest of the industry’s general expectations (i.e. are you pitching your Senior levels at a place that’s generally accepted?). Also think about the terms that you’re using - for example in my new role I wanted to consult people about the proposed term “Junior engineer”. Using wording that doesn’t resonate, or that people don’t want to be associated with can lead to outcomes like pushing hard for promotion before they’re really ready.

Decide on level consistency across the business

Most companies tend to start with progression frameworks being created for different types of roles individually, rather than trying to do everything all at once. Regardless, it can be useful to think whether you want to have consistency of levels - for example does your Director of Engineering role have similar expectations in terms of the impact they should have, or the scale of problems to solve as a Director of Product does? Your situation may vary, but in my experience having more consistency helps to combat feelings of unfairness, and helps people across the business understand progression and seniority in a standardised way.

Your business and the nature of roles may make this easy, or not. For the engineering framework I’m currently working on, I’ve spoken to our Chief of Staff about some non-engineering roles around the business that have very different titles, where concepts like Lead or Senior don’t match to the norm in the engineering world.

Should you include roles that don’t exist yet?

I spoke recently to a colleague whose trust was eroded in a previous role because of a very senior level that existed on a framework, but which was unobtainable in reality. There are pros and cons here. If you don’t show people the paths that are available, they may not see a long term future for themself at your company. But also, you don’t want to paint a false picture.

Personally I’m a fan of setting out a clear picture of the full career track, whilst also making it very clear why you may not have a need for certain roles at present, and when they would come in. With my work on our current framework, there’s a hypothetical path to CTO, but this is extremely unlikely. If someone was stretching for this we’d also likely interview against external candidates. By making this clear it can give someone a sense of career direction, without giving them false optimism.

3. Thinking about the framework’s content

Balancing specificity and ambiguity

Your situation may mean that you want an incredibly specific set of behaviours; ultimately a formula to plug in values and spit out a definitive answer for how senior someone is, and whether they should be promoted.

Personally, whilst I appreciate that at first glance this kind of approach can seem like it’ll bring simple clarity and complete fairness, I’d caution you to discuss your needs here carefully.

As you saw from the issues at the start of this post, a very specific set of behaviours may not work for everyone, especially as a business grows. It can also lead to a very homogenous view of what good looks like; not allowing for different strengths, interests, or paths. Some of this homogeneity may actively discriminate against certain groups, leading to them being disenfranchised. It can be time consuming and lead to quibbles over ratings, and it doesn’t do anything to eliminate biases over those ratings themselves. In short, your seemingly totally fair decision-making tool may ultimately be being filled with a ton of biases and blockers.

In my experience, I’d encourage you to think about having fewer behaviours which clearly reflect the essentials for what good looks like at each level, and allow someone to easily comprehend the type of outcome that’s valued. It should also leave plenty of room for celebrating and rewarding other strengths where appropriate, easily allowing someone to judge what kind of level they relate to.

With engineering in mind, personally I’m a big fan of creating a single engineering framework rather than overly-specific discipline specific ones. Your situation may vary, but again, I’ve found success in stripping back rather than trying to cover all of the bases.

Consider whether your frameworks allow for different ‘shapes’ of people (e.g. T/M-shaped)

Relating to both your decisions on specificity vs ambiguity, and also whether you’re going to have standardised levels across the entire business is this - what happens if someone does a job, or has strengths that place them outside of their framework?

Depending on your needs you may want to consider approaches like paring back even further; simply having a business-wide set of very limited and generalised behaviours (although this will likely cause ‘shadow frameworks’ for each discipline to spring up as individual guidance anyway). You could also consider a ‘major and minor’ approach, where someone majors in the role they’re most focused on (e.g. engineering), but can still pick up ‘credit’ from skills in other areas (e.g. design). Again, personally I recommend having a strong core, and a framework that allows people to get credit for strengths that fall outside.

Remember inclusivity isn’t baked in by default

One of the key messages I want to hit home here is this: one of the goals of a progression framework can be fairness, but simply by having a framework that doesn’t make your workplace fair. How it’s applied, how people are judged, and whether some folks are worse off than others will depend on the work you do around the edges.

For example, have you stopped to consider whether decisions you’ve made are actively hurting some groups? If you have a requirement to demonstrate behaviours for 6 months before being promoted to the next level, how does that work if someone has taken a month off, if they work part-time, or if they were an excelling but furloughed? If you have requirements around verbal communication, presentation, or challenge, how does this work for someone where English isn’t their primary language, introverts, or people with anxiety disorders? If you require consistency, but someone struggles with mental health, or as a parent with kids who’re being home-schooled?

Undertaking some consequence scanning activities, having a diverse team of people creating your framework, and getting honest input into who this doesn’t work for as much as who it does work for can help to mitigate some of the potential issues.

Decide and communicate weightings

If you’re splitting your framework into different behaviour types (technical skill, communication, leadership) as is common with many examples in the wild, you should decide whether these are all equal. If it’s not possible for someone to progress without certain elements, you should make this clear.

For example, maybe to be considered for a certain level, an engineer must be able to demonstrate an appropriate level of technical skill. No matter how high their communication was, they wouldn’t be promoted if they couldn’t write code beyond the basics. However, also be mindful of clearly stating your expectations about balance too - in this situation you could be encouraging “the brilliant jerk” (a talented engineer who treats others poorly), by not also setting out clear expectations around behaviours which tie into your overall company values.

Give visibility to your implicit expectations

Where there are explicit expectations, you should make sure that you’re shining a light on any implicit ones too. As an example, in both frameworks I’ve worked on so far, I’ve made the recommendation to include guidance around typical times to progress through each level. Everyone’s different, and there will always be people who race through or take longer. The wording should be sensitive to counter this (nobody wants to feel like they’re slower than average!), but a shared understanding can help set some expectations (that you may not race to Senior within a year of starting a career!), and also help identify when things aren’t going well (if someone hasn’t progressed beyond junior in 5 years, what’s going on?).

Tied into this, it can be useful to have a discussion and set down some thoughts over where you expect everyone to get to. If everyone you hire should be capable of reaching Principal Engineer, that could require a very different strategy for hiring and ongoing coaching than if you’re happy for people to not want to reach Senior level.

4. Wider processes and decision making

Think about how the levels on your framework relate to reward

This one’s likely to take you more time than you think. You’ll need to decide on your initial numbers, ideally doing some benchmarking externally to inform this. I’d recommend thinking about a range for each level rather than it being a single figure. Having a range gives people scope to keep getting a pay rise when they’re making progress, even if they haven’t quite reached the next level.

You should also think about whether all levels are equal in this respect. Depending on how you structure your levels you may want to have equal leaps (e.g. each level means a £10k increase), or you may have bands where the range is wider than others. For more senior levels people are likely to take much longer to progress (if they do at all), so be sure to take this into consideration.

If you’re bringing in a framework from scratch, unless you’re lucky you’re also likely to have people which don’t fit the model, either being over-paid or under-paid. The under-paids are initially easy - everyone likes getting a pay rise! - but you may also face some questions around why they were being underpaid before (and even if not, you should ask some hard questions of yourself as to whether you’ve baked inequality and/or bias into your business). People who are over-paid according to your new model are more of a challenge. In very extreme cases where someone is hugely out you may need to have a tough conversation, or decide to continue knowing that you have known inequality. You may decide to keep people at their salary until their actual level ‘catches up’, but for some this may take a long time (without getting any financial recognition), or for others it may not happen. There’s no one right approach here, but be mindful that whatever your situation, you’ll need to plan your communication very carefully.

And finally on this point, if you employ freelancers or contractors you’ll need to make some decisions here too. Will you only hire people whose rates fit into your ranges? Will you treat them separately? Remember that being freelance comes with an entirely different approach to pay and benefits, but that your full time employees could feel put out if they find out day rates without knowing the full context of why these can often be higher than a base salary.

Work with the wider business on usage overlaps

You’ll also need to clearly define how the progression framework works with wider company processes, such as promotions, setting salary for new joiners, or assessing performance. Try to avoid a situation where your framework leads you down a fragmented path where you’re doing everything in different ways to the rest of the business.

Some of the areas you’ll need to think about include expectations about what it means to have ‘done’ behaviours on your framework, which ideally should be consistent with how the rest of the business judges this. Does someone need to provide particular evidence? Should the manager or managee do this? Is there a particular timescale needed? Having a framework alone doesn’t make for success, and you’ll likely need to consider your performance, promotions, and reward processes at the same time.

Have a process for keeping it up to date

Finally, your framework ideally should be able to flex as you need it, and grow as your business subtly changes over time. You’ll need to think about topics like who checks whether it’s still fit for purpose, and if not updates it on an ongoing basis. Is it the same as the initial core group? How do you approve changes as a business? How frequently does it get reviewed? Do you want to set known warnings, or trigger points for things you know will break? (e.g. if you’ve written it to be very specific for Product teams, adding a Platform team could mean a rethink)

Another area to consider, particularly if you’re creating a framework for a high-growth startup: as you scale, people’s roles and responsibilities can also grow very fast! What it means to be a Head of Design, or a Senior Engineer at a 20 person company is typically very different to the need when the company’s reached 200 people. If this growth happens in a short amount of time it can lead to people feeling like the path they were sold wasn’t the one they ended up on (e.g. being told “do this and you’ll be promoted”, meeting that, then being told “the scope of this role is bigger now, now do THIS and then you’ll be promoted”. This is an exceedingly important consideration to bake into your plans and processes if this is likely to happen.

5. How you communicate matters

Plan your communications and training carefully

The first time an engineer sees an engineering framework, they’ll be thinking about where they fall in. The first time an engineering manager sees it, they’ll be thinking about how well they can place their people, and whether they’ll be judged for getting it ‘wrong’.

As I mentioned above, I’m a big fan of consulting and involving those who’ll be using a framework. Particularly when you’re moving from 0 to 1; if you currently have a flat hierarchy with no levels but are bringing in something, you need to make people feel 1. Like they understand and have come on the journey 2. That they can feed in and make it as accurate and reflective of possible, and 3. That they feel safe with the end result.

Hopefully you’ve created something that speaks for itself without needing a whole ‘shadow framework’ of guidance, but you should also regardless expect to introduce the framework, what it’s for, and help people understand how it should be used. Overcommunication can be key here!

Bear in mind that communication isn’t just for the people here now. You should also think about how to help newcomers understand as they join, and how you’ll stay calibrated as a group into the future.

Decide how much you want to, and the impact of sharing with others

A progression framework can be a valuable thing to share externally. It can give potential hires a sense of what you value and how they fit in, but it can also help other companies up their game too! You may want to think about the format your framework lives in, the process for (technically) updating it, how you communicate changes externally, and whether additional context (like a blog post) is needed.

Certain companies approach this in very different ways: The Financial Times built a microsite and an API! Clearleft make use of Trello and Progression App. Rent the Runway’s hugely influential career ladder is simply a spreadsheet. Monzo’s old framework is on a public-facing website, but the new one was simply an internal document for speed (despite wanting it to be made public).

In terms of impact, think about the future. If your progression framework lives in a website, but the structure changes so much that the site needs a chunk of developer time that can’t get prioritised, is that ok? What happens if someone external gets the wrong impression from a behaviour on your framework because they don’t have context, and doesn’t apply for a role? Could you be encouraging others to adopt very specific elements of your framework, which could do harm in other settings? Again, doing some consequences scanning could help here.

Frameworks in an age of uncertainty and financial pressures

And finally, I wanted to touch on something that isn’t easy to think about, but which can have a huge impact on people’s lives: what happens to your framework when a pandemic hits, when the company experiences financial pressures, or when other situations bring instability to your employer or the business as a whole?

This one’s for you I’m afraid, without knowing your situation I can’t give great advice, but I would encourage you to think about the following types of scenarios:

🤔 Has your work or business priorities fundamentally changed, and does the framework still reflect the needs accurately? For example, perhaps your framework for ‘normal times’ stresses quality and consideration above all else, but your business has shifted into a mode where it accepts more risk, and values speed and nimbleness even if it could cause some incidents.

🤔 If some of your staff are being harder hit than others, revisit whether your framework and processes are being as inclusive as they can. For example, if previous high performers are struggling because of COVID bereavement, family situation, or stress, is it fair to run a performance assessment as usual? For those who thrive on ongoing development, is it fair to withhold this source of feedback and motivation?

🤔 If you can’t afford pay rises, is it more fair to stop promotions for everyone, or should you continue to recognise progression in other ways? What would stopping promotions mean to a person who’s demonstrated their capabilities for months at a higher level, without reward? What does it mean to a person who’s on the lower end of the pay spectrum, vs the upper? Are there potential groups who’ll be more disadvantaged than others? What will changes or pauses for an indefinite time period do to staff morale, retention, and manager/managee relationships?

🤔 Again, I’m a big fan here of using data to understand impact, consulting as widely as is appropriate, aiming to think about different consequences, and communicating appropriately. Sometimes hard choices need to be made, but there are better or worse ways to bring people on that journey. Thinking about these kind of questions can help you lean towards the former.

🔜 New frameworks coming soon!

I’ll never claim to be able to create a flawless and entirely perfect progression framework, but I like to think that considering the topics I’ve outlined here can help to set you up better than if you don’t.

Our Farewill engineering framework is going through final amends and we still need to decide how best to share it, but my goal is for it to be made public (along with related info like updating our job adverts to have visibility over salary ranges) soon. Whilst I can’t take full credit (the majority was already in place before I started, and I’ve mostly contributed by asking the kinds of questions in this post), I’m proud of where we’ve got to, and I’m excited to start using it. Up next will be our Engineering Management framework, which I’ve set us an ambitious target for and will hope to also be sharing soon!

Thanks to Chad Greiter on Unsplash for the header photo