Earlier this year we started using new versions of our progression frameworks for individual contributors and managers. The changes came from a desire to simplify the framework and make it easier to use for both individual contributors and their managers across the engineering department.

In this article I’ll share five principles that became apparent during the process. These may be helpful if you’re thinking about introducing a progression framework or making improvements to an existing framework. It’s not an exhaustive list!

Principle 1: Agree what your framework is for!

This might sound obvious but it’s important to make sure everyone is clear on the purpose of the progression framework before starting to write. Our framework has three main purposes:

1. Evaluate staff performance against expectations for their role and level. We do this twice a year in line with the rest of the company.
2. Help staff progress in their role and advance to the next level by identifying skills and behaviours to develop.
3. Help hiring managers identify the right level when making job offers.

This is what we had to keep in mind when designing our framework.

Principle 2: Leave the implementation details in the role profile

The previous version of our framework included detailed examples that were relevant to some roles but not others. This meant managers had to do some translation of the language for their teams, and it was a big deal to make changes to the framework document that everyone used.

We realised taking those details out of the progression framework and putting them into role profiles would make the framework more inclusive across engineering and make it easier to delegate describing the nitty gritty to individual teams. Here’s a made up example:

Software Engineer	Data Scientist
Technologies	Technologies
Ruby on Rails MySQL…	Python Amazon SageMaker…

	Junior	Senior
Technical skills	Learns the tech for their role	Demonstrates expertise in the tech for their role

Principle 3: Include the smallest number of independent skills and behaviours

Five or six years ago I was involved in writing an earlier iteration of the progression framework with a few other managers. We got started by trying to think of an exhaustive list of all the different things that engineers of different levels might be expected to do. This might seem like a sensible approach but stopping there can create problems:

• “Box ticking” on the part of both staff being evaluated and their managers. Want to be a senior data scientist? You’d better run an A/B test next year!
• “Overlap” between skills or behaviours. If several areas of the framework can be evidenced by completing one kind of task, are they really adding anything?

This sort of incentivisation is neither helpful for the individual nor the organisation and generates unnecessary admin.

In the latest version of the framework we distilled things down to the smallest possible list of distinct skills and behaviours without over specifying the details. This helped reduce box ticking and the associated admin overhead, and encouraged more active and creative conversations between individuals and their managers.

Principle 4: Use simple, accessible, inclusive language

Let’s make up another example of two skills described at two levels:

	Junior	Senior
Programming	Is a beginner at writing code	Is an expert at writing code
Documentation	Is a beginner at documentation	Is an exemplary writer

When can one become an expert at programming? Who gets to decide? Are people with English as a second language more or less likely to feel like they can be an exemplary writer?

Now let’s make some tweaks to emphasise demonstration of a skill rather than a declaration:

	Junior	Senior
Programming	Learns to write code	Demonstrates expertise in writing code
Documentation	Records their work	Records complex issues clearly and concisely

By using “expertise” rather than “expert” we’ve shifted the onus toward demonstration of a skill rather than an arbitrary bar to be crossed. We have simply explained that we value clear and concise writing instead of asking for “exemplary” writing without any definition.

Principle 5: Ensure opportunity to demonstrate skills

Past versions of our framework included examples that related to responding to production incidents and involvement in the hiring process. While these are important skills, not everyone will have the opportunity to demonstrate them at a given time. We actively avoid production incidents and sometimes we don’t have any open roles.

In these cases it’s worth thinking about the real skill that we’re looking for. Responding to production incidents might be an example of demonstrating leadership and hiring might be an example of building high performing teams. There are more ways to develop and demonstrate leadership than just responding to incidents, and helping with team building goes beyond just hiring.

If you need to explicitly call out that software engineers are expected to respond to incidents or help with interviews then this can be done in the role profile, recalling principle 2.

Summary

Creating and maintaining a good progression framework takes significant time and effort. By following a few simple principles it’s possible to create a simple, fair framework that’s easy to use and easy to update over time:

1. Agree what your framework is for!
2. Leave the implementation details in the role profile
3. Include the smallest number of independent skills and behaviours
4. Use simple, accessible, inclusive language
5. Ensure opportunity to demonstrate skills