The why

There are multiple reasons to introduce a progression framework, but if you ask me, these are a few of the ones that make it worth spending time on defining one for a company:

Raises, promotions, and / or salaries are arbitrary

In some teams, there is no apparent reason why someone earns more than someone else. The reasons can vary from “this person knows a lot about our tool as he was here from day 1” to “this was their salary at their previous job, and we needed the profile, so we matched or raised the salary”. Promotions risk being based on “it’s been a while since this person got a raise or promotion” or even on being liked by their direct manager. New hires can receive reward packages that don’t match the rest of the team. As the team grows, this can lead to frustration when people discover there is no apparent reason why a particular colleague earns more than they do, while they have the impression they bring more value.

Make hiring decisions

When interviewing candidates, there are numerous things that can influence the final decision. What kind of profile are you looking for? Someone who can raise the bar and coach others, or someone you are happy to invest in but can already contribute early on? And what is the correct salary for that profile? Finally, what if the candidate is asking for a higher salary? Will you match their demand, or will you send the offer you had in mind with the risk of them saying no? And if you chose for option 1, will you give the entire team a raise to make sure it all adds up?

Bring clarity to the team on expectations, and growth

Am I performing as is expected of me? And what do I need to do to get a promotion or a raise? It’s often unclear. People want to grow for various reasons, but are unsure what they need to do to reach a higher level or to grow toward a certain role. By giving clear and concrete descriptions of the expected behaviour and contributions at each level, you create alignment and clarity.

The what

The matrix

A progression framework tries to answer some of these issues by clearly explaining what is expected. In short, the progression framework is a matrix where each “row” defines what we will call a “level” from here onwards. For that level, each column defines what is expected within a certain area. The idea is that, to be assessed at a certain level, you have to consistently show the behaviour mentioned in the framework. If you start showing glimpses of the level above, it means you’re on your way to levelling up. It’s OK if you aren’t quite consistent in some areas. That merely means it’s maybe not your strength, or it tells you where you can still grow.

Individual contributors and managers

It’s recommended that, as of a certain level, you split the framework up into two parallel tracks: the individual contributor track and the manager track. The level where you start doing this is often the minimum level for the managers you have on the team. Let’s say that, to become a manager of a team, you have to outgrow level 4 and reach level 5. In that case, that’s where you start splitting up the tracks. That way, you emphasize that you don’t have to become a manager to grow. Additionally, it means that the fact that you don’t like managing others won’t stop you from growing within the company.

The how

Building a progression framework is not an easy task and not one you want to take lightly. You may have to adapt to the levels and areas the company defined. These areas are typically, but not always, linked to the company values. It’s not unlikely that some areas are hard to link the qualities you value in engineers, just as there will be qualities that you care greatly about that are difficult to link to the areas the company defined. That’s where you get creative. Don’t give in at this point.

You may also struggle to match the skills that you expect from a manager to the areas defined by the company. Either get creative again or have a discussion with the management team to adjust the areas of the framework.

The next sections explain the process we took to build our framework. This is by no means the “right” or “only” way to build a progression framework. Here, we also had a team of engineering managers that helped build it. This will not always be the case.

Find inspiration

You can find several examples on progression.fyi. The site collects frameworks shared by a lot of start- & scale-ups. We started by collecting numerous quotes and examples taken from these and added some more that we thought of while reading through these quotes. These would be quotes like “you are the buddy to new joiners and help them get onboarded” or “you write out technical initiatives and gather data to back them, so they can be prioritized”.

Storming

We wrote all these examples and quotes on stickies (we used Mural, but there are plenty of tools that will do the trick) and had the team put them in the right area and at the right level. Go over them individually and put comments on stickies where you disagree on. Timebox this, don’t let this drag on.

Area by area

We then went over it area by area. We had discussions on examples where we disagreed on the level and came up with some other examples or quotes. This helps in making sure that this gradually progresses as you raise a level, within that area. You’ll also have discussions where you feel an expression or example doesn’t belong in that area. You can still move it at that point.

Having a meeting with some key team members on each of these areas will create hefty discussions. Aim to create clarity. We got stuck on stickies. The magic started happening when we would prepare the meetings by writing out what was on the stickies in a narrative. This would create plenty of clear discussions where it became obvious that things didn’t add up or were unclear or maybe too opinionated. The result became a narrative for each level within that area in a ubiquitous language that left little ambiguity or room for interpretation.

Pivot! Pivot!

When you’re through, transpose the whole thing. This way, you have a document that describes for each level what is expected from a person on that level for each area. We moved some things around in between the areas and noticed that for some levels we discussed things like security issues or coaching, and for others, we didn’t, and more. We saw some things coming back in several areas, but in fact, that’s quite OK. It means it all ties in nicely.

It doesn’t have to be perfect

There will be moments where you feel that things are still unclear, or you are not addressing the great behaviour that some people on the team show. Or you don’t have clear descriptions on the highest levels in your framework, but you don’t have anyone near that level anyway. Having the framework shared with the team is more important than having it pixel perfect. I’m sure it’s already an improvement over what’s there today.

Share and collect feedback.

Time to share it with the broader team and ask for feedback. There will be feedback on things that are unclear or where they feel the expectations are unfair. You’ll have to adapt your document a few times or will have to dismiss their feedback and explain why. Some people on the team may not agree, but at least they were heard at that point.

Using it

Once you finalized the framework (or as close as you can get today, at least), use it throughout the day. Especially if you are in a management position, this will be something you can refer too often: You can talk about growth in one-on-ones, discuss where the team member is still falling short and figure out how to grow in that area. You can use it in hiring interviews, trying to find questions that relate to the different areas, so you can get a view of where this person is level-wise within that area. This can help to decide what level this candidate would come in at and what would be a reasonable offer for them. If you want to promote a member of your team, find examples that show that this person is already behaving at a higher level than they are on today.