How to build a clear and transparent process for supporting career progression.
The role of the software engineer is common in tech companies, but progression upwards from this position is shrouded in misconceptions.
It’s often assumed that the only level up from a senior software engineer role is lead engineer, followed by engineering manager. But this path might not be appealing to those who don’t aspire to become people managers or lead teams, and who are better suited to become senior individual contributors (ICs). As a result, engineers might feel limited, and start exploring opportunities elsewhere.
We both noticed this problem at our company, Secret Escapes, where Nikos is our head of engineering, and Laura is an HR business partner. Earlier this year, we noticed our turnover was higher than we’d have liked, so we went back to basics and looked at what the data was telling us (particularly exit interviews) and spoke to our teams too. The number one thing that jumped out was that people were leaving, or thinking of leaving, because of a perceived lack of career progression.
We knew that there were opportunities for people internally, but as we reflected and talked to people, we could see that these opportunities were not clearly defined or visible, which was what people really wanted and needed. They wanted to be able to see how to build and grow their career within the organization.
Moreover, a lack of clear expectations at every level was making conversations about performance and promotions challenging, as different people had different interpretations of a role and subjective views on performance against the role requirements.
It was becoming increasingly obvious that we needed a more structured process. So, we started working together to create a transparent, structured, and relevant framework for professional development.
We’re now several months into rolling out the new process, and we’ve learned a lot about what works and what doesn’t. Here we’re sharing how we created the framework, what it looks like now, and our practical tips for anyone on a similar journey.
Creating a career progression framework
When we started scoping out the framework, we set out with a handful of key objectives:
- Support our teammates’ growth ambition by making roles and level expectations explicit. Offer them direction to build an exciting and long career path within the organization.
- Remove the subjectivity and stress from performance conversations.
- Define guidelines for optimal squad composition (e.g. a squad should have at least one Level X Engineer) and identification of skill gaps.
- Improve the effectiveness of our hiring process by aligning the assessment criteria with role/level expectations.
- Make salary conversations and decisions more transparent and objective.
Based on these goals, we defined the core building blocks for our new framework: a two-track career ladder, a matrix that detailed the competencies for each level, and an assessment process for leveling up.
The career ladder
Our career ladder is a simple representation of possible growth options for an engineer, with each step representing a different level, for example, L3 Senior Software Engineer II.
In line with the tech industry norm, we settled on two tracks: individual contributor (IC) and engineering manager (EM). We agreed that lateral moves would be possible. By doing this, we hope to encourage people to try out management as they could see a clear way back if it wasn’t for them.
The career matrix
For each track, we identified a list of competencies that we expect our teammates to demonstrate. For ICs, this includes concepts like coding and testing, design and architecture, and delivery, but also leadership, communication, collaboration, and others. Meanwhile, engineering managers competencies include organizational planning, hiring, coaching and mentoring, and more.
For each competence, we listed a number of example behaviors. The list isn’t exhaustive and team members can suggest alternative examples based on their own experience in the company.
We gathered all this information into a matrix-like format using a simple spreadsheet. This way, anyone can see what is expected at their level, and also understand the expectations of the levels above.
Career assessments and leveling up
When we started thinking about assessments, we wanted to avoid the perception of the set of competencies as a checklist. A simple yes or no assessment wouldn’t have encouraged consistent and regular demonstrations of the competencies. So instead, we use a rating method based on a frequency range of never, sometimes, often, and always.
Assessments are done both by the individual (self-assessment) and another person who is best placed to provide meaningful input (external assessment). This person is typically a team lead, or someone who works closely with the individual. Managers are also involved in the process to calibrate the scores and ensure consistency and fairness.
Once the assessment is complete, then the employee and their manager work together on building a personal development plan (PDP) with short, medium, and long-term SMART goals. The purpose of this is to provide focus and direction for the individual in their effort to level up.
Leveling-up is the official recognition that an employee has been performing a level above their current one consistently for a period of time, typically six months. If someone is underperforming, we don’t level them down but work with them to get them to where they should be.
Rolling out the framework
Once we had the technical framework and the core principles, we were ready to roll it out. We had two key priorities:
- How can we integrate the framework into other processes and benefits we have across the organization?
- How can we make it specific to our engineering teams but also generic enough that we could use something similar in other departments across the business?
To achieve these goals, we made the process super simple and created a continuous cycle for team members to work through. Here’s a visualization of the cycle, which we shared with participating team members:
We were already supporting learning with a designated budget and personal development time, so we integrated these benefits into the career progression process. We also supported managers and employees through the process by creating simple guides on the following topics:
- How to assess as a peer/manager/yourself
- How to create a development plan
- How to support the development of your team
We also offered training and one-to-one support, and created a development planning resource for people to use.
Lessons learned along the way
We’ve been applying the framework over the last few months and have learned a few valuable lessons so far:
- Involving team members early in the design process, especially around competencies, was a wise decision that helped avoid later misunderstandings and hiccups. Some team members volunteered to do a dry run of parts of the framework in its early stages which resulted in valuable feedback.
- The assessment method isn’t suitable for all competencies. Some can only be demonstrated infrequently, because there are limited opportunities or they take too much effort. We’ll review this once we complete a full cycle for everyone.
- Collecting supporting evidence can be a tedious task for teammates and managers, especially during the initial leveling step. From now on, we encourage people to use brag documents to record accomplishments that could be used as evidence.
- Expressing competencies and example behaviors in a generic form helped us increase the applicability of the framework. However, some effort is required by managers in assisting team members interpret the example behaviors for their unique specializations. We expect these teething problems to go away as we get more familiar with the framework.
- Making the two tracks explicit was definitely an improvement on people’s awareness of options but it didn’t work for all cases. One individual who could be a great (and our first) staff engineer also enjoys the management duties of their current role. In future, we’ll aim to identify these cases sooner to see if we can accommodate their needs with a modified version of the ladder.
- We should have been more pragmatic with time. Every step in the process from planning to rollout took longer than expected, as we had to deal with trade-offs in our decision-making as well as people’s availability in helping out or using the framework. Give yourselves enough time!
What’s next?
In the spirit of everything we’ve done so far, we want to focus on getting the basics right first. This means making sure the framework is integrated and providing a clear and transparent process to support career progression.
Looking ahead, we plan to run a survey with our engineering team to check that the framework has fulfilled our expectations. We’re also excited to be working on using the framework to support hiring, by introducing the framework to successful candidates before they start with us. Finally, we’re hoping to make the career development framework public so other organizations can benefit from it. Watch this space!
Creating a career progression framework takes serious investment from both engineering and HR, but it’s all worth it to see the positive impact on engineers. It’s so important to show people that you value them and want to support their growth within your business. If you’re starting out on a similar journey, good luck!
