At Attest, we’ve got a growth framework in place for all of our engineers – and it’s become a core part of how we work. In this blog, we’ll share our journey to creating our growth framework, and what it means in practice.
But first, what’s a growth framework and why did we contemplate a framework in the first place? 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?
These questions 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. That’s a value we live by at Attest – it’s in our product and our strategies, and it’s embedded in our culture.
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.
So about a year ago, we embarked on a journey to create a growth framework from scratch. That’s no easy task, so where do you start, and how do you define what matters to you?
We started simple – by getting everyone in a room and asking: “What have you been up to in the past couple of weeks?” We encouraged post-it notes for tasks of all sizes, from small daily tasks to bigger, more time-consuming projects.
From these tasks, we explored how our engineers are spending their time, which activities are done on a frequent or infrequent basis, and which of these 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 parts of our framework, that we call our three A’s: attitudes, abilities, and actions.
At this point, each of the three A’s had a whole bunch of tasks associated with them, which could be separated further. For example, in the action skill we found multiple tasks that represented coding, design & architecture, testing, and so on.
By this end of this process, our growth framework formed into three sections.
The next step, of course, is to fill each of these with the expectations you’d expect from engineers in each area. As a starting point, we filled these with the relevant tasks on our post-it notes.
Ship fast, ship often.
I highly recommend, when building a growth framework, to embrace the “ship fast, ship often” mantra. Build the framework and the expectations within 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 be, 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 encompasses everyone’s views and values, whilst developing buy-in and ownership.
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 – we use seniority levels to set increasingly high expectations of our engineers as they progress through each action or ability.
Like us at this point in the journey, this can be the perfect opportunity to make a decision on how to represent seniority scales in the framework and in your team or organization.
Traditionally, it’s common to see this expressed as junior, mid, and senior. We found that those levels didn’t work for us for two reasons and instead we opted for using levels 1 to 6 instead. The reasons for this were:
Graduating our expectations through levels 1 to 6 provides a greater level of precision and granularity. Our goals become more short term as a result and progress can be measured more effectively.
Titles like ‘junior’ can be disempowering for those that have them. We felt this did not accurately portray the impact and value that all of our team members have.
Having a growth framework is great – but how do we apply it to our engineers?
Our process at Attest starts with an informal chat between a team member and engineering manager, discussing tentatively which level fits best to each ability and action. We do this by looking at the expectations and gauging if most of those have been achieved on a regular basis.
Usually, a level is achieved if you’re meeting around 80% of the expectations and have been doing so for a couple of quarters, acknowledging that you can’t be expected to do all the things at each level. 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 our peers. 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.
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, and taking into account feedback from peers, we build focus areas and objectives to help get there. This gives our engineers a compass on how to progress at Attest.
That’s all for now! Watch this space for the next article in this series, where I’ll focus on how our framework became a core part of our pay & reward process.
If you’d like to chat about growth frameworks or anything else, feel free to connect and drop me a message.
When folks read about our engineering culture, we’re often asked about open roles. We’re always on the look-out for exceptional talent, whether designers, engineers, product or otherwise. Please take a look at our open roles, or if you don’t see anything suitable there, feel free to email us at firstname.lastname@example.org to let us know you’d be interested in future roles; we’d love to have you on board!