Managing pay and reward through a growth framework

Are your engineers on the correct salary? How do you know?

At Attest, a high-growth startup in London, we found it incredibly difficult to fairly and accurately quantify how much an engineer should be paid and when to offer progression. We wanted a better way than the traditional and often biased methods seen elsewhere. I have gone through the process of creating a growth framework for our engineers and took it further to be the basis of all our salary and progression decisions. In fact, with the model we created, you can calculate someone’s salary from their individual growth framework alone.

The journey began with a set of problems we wanted to solve, which can be represented in the following questions we found ourselves asking.

• How can I quantify my own, or someone else’s skills and value within my organization?
• How do I know what is needed to progress to the next level?
• How can I accurately and fairly pay my team members? Who gets promoted? Who doesn’t?
• Is this candidate right for the job? What level of seniority do they come in at, and how do they compare to the rest of the team?

What is a growth framework?

A growth framework is a tool that can be used to create clear definitions of role expectations, graduated by seniority, and categorized by skills and business impact. 

Why is a growth framework the solution?

The questions we were asking ourselves stem from a common cause: the lack of ability to quantify what we value at Attest and how to measure that.

We found that if we were able to put data at the heart of every decision, we would be empowered to solve these challenges.

This mantra is exactly what a growth framework embodies. It allows you to measure what matters to your organization and make better, more informed decisions.

Growth frameworks not only give a view of the expectations at a given level and whether these are met, but it also shows what is expected to reach the next level.

By looking at the expectations beyond the current level, growth frameworks can build focus areas and objectives to help get there. This gives engineers a compass on how to progress within the organization.

So about a year ago, we embarked on a journey to create a growth framework from scratch. Not an easy task! Where do you start? How do you define what matters to you?

How did we do it?

We started simple, by getting everyone in a room to answer the following question on post-it notes: what have you been up to in the past couple of weeks?

From these tasks (which included both small, everyday practices and larger projects), we explored how our engineers were spending their time, which activities were being done on a frequent or infrequent basis, and which activities did we value and want to see more of.

This created a natural grouping of tasks into similar categories, in our case we found that tasks fell into three different types of skill:

• Tasks that expressed an engineer’s attitude.
• Tasks that showed an engineer’s ability.
• Tasks that documented an engineer’s action.

This gave us the three core sections of our framework, that we call our three A’s; attitudes, abilities, and actions.

The Three As

The next step is to fill each of these with the expectations you’d have of engineers in each area. As a starting point, we filled these with the relevant tasks on our post-it notes.

I highly recommend, when building a growth framework, to embrace the ‘ship fast, ship often’ mantra. Build the framework and the expectations within it collectively as a team. Get feedback and iterate.

This requires trust from the engineers that it will affect; it’s important to make it clear that everyone has the opportunity to input, that all views are considered, and disputes are worked out as a team. Importantly for us, the framework acts as a guideline. It’s not necessarily the definitive input into our decisions when it doesn’t make sense to do so, and this is something we made clear from the beginning.

In our first two months, we updated the framework nearly every day. This produced a framework that encompassed everyone’s views and values, whilst developing buy-in and ownership.

Levels

Not all engineers will be at the same point in their careers, and expectations of them will differ depending on an engineer’s experience and capability. This needs to be taken into account when building a growth framework.

Traditionally it’s common to see roles expressed as Junior, Mid, and Senior. We found that this didn’t work for us as titles like ‘junior’ can be disempowering for those that have them. And we felt this did not accurately portray the impact and value that all our team members have. So instead we opted to use a levels system that ranged from 1 to 6.

Graduating our expectations through levels 1 to 6 provided a greater level of precision and granularity. Our goals became more short term as a result, which meant progress could be measured more effectively.

The Code action levels 1 to 6

How did we apply it to the team?

Our process at Attest starts with an informal chat between a team member and their engineering manager, where they discuss which level fits the engineer best based on their current abilities and actions. Usually, a level is achieved if you’re meeting around 80% of the expectations and have been doing so for a couple of quarters; we acknowledge that you can’t be expected to meet every benchmark at each level. But this is not designed to be a tick box exercise. We consider other inputs and adjust the criteria where it makes sense to do so.

We also ask for feedback from our peers to help understand where our own perception of what we do differs from what they think. This helps us measure against and maintain a consistent yardstick across the team.

This self-reflection and peer review cycle happens every three months and we produce a view that looks something like this.

A rewarding journey 

Salary and remuneration is often a controversial topic, but we all deserve to have transparency and fairness in the way our pay rises and promotions are handled. 

Where there is an opaque and subjective process, or a lack of a personally-tailored guide on how to progress, you are often met with the following:

Pay reviews are too infrequent. In an environment where engineers are building their skill set and experience rapidly, why wait a whole year or six months to recognize that? One of the most noticeable effects of this will be the demotivation of existing team members, leading to attrition; usually to competing hiring companies who at the time of hiring will inherently offer a more up-to-date reflection of where candidates pay should really be.

Salary increases can be awarded at the mercy of how loudly you or your manager shouts. If there is no clear and transparent way of determining your growth & development and how this links to pay, you’ll end up relying on your communication and negotiation skills to barter for a pay rise. Perhaps you’ll need to put together a dossier of evidence, or your manager will need to build a business case and sell the idea to other managers; either way, this is neither enjoyable nor fair to do. This can also penalize minorities or less confident individuals who find it difficult to shout about their worth.

Fortunately, with a growth framework, you already have a mechanism for quantifying an individual’s growth and development. The next step is to directly translate its output into a reward.

Numbers and pay are for illustration only

If we look at the levels in the example above, including the levels cut off by the screenshot, we can work out that the overall level is 4.3. This is the average of all individual levels within the framework.

The overall average level of 4.3 means this individual would be paid exactly 0.3 (or 30%) into our level 4 pay band. This number can change every time we go through the review process, where we gather peer feedback on these levels, meaning if the overall level goes up, so will their pay.

We’ve found the benefits of this novel approach to reach further than expected.

Having such a calculated and well-understood process unlocks the ability to have more frequent pay reviews. We do this every three months. This allows improvements and adjustments to happen sooner, to iterate quicker, while facilitating smaller and more attainable goals for individuals.

Such a methodical and quantifiable process brings inherent fairness. This fairness helps with challenges such as the gender pay gap, which is less likely to arise. Our colleagues peer review our frameworks, providing a more objective approach. On top of this, all our pay bands are published internally, further increasing transparency.

The result is a truly agile reward process, one that is fair, consistent, and enjoyed by the whole team.

You can see our own engineering growth framework at Attest here!