Implementing a career framework in a fast-growing organization is certainly a tricky process. We’re talking about something extremely sensitive: people’s competencies, and how those translate to a (possibly externally visible) seniority level. Furthermore, applying such a framework impacts every single engineer in the organization. So we needed to make sure we approached the initiative with the proper care and respect for everyone involved.

1. Getting started

The first step was to form a group of people that represented our existing engineering department, but who also could take a step back and help clearly establish our goals. We settled on a team of four: one individual contributor, two managers and myself. Two of these people had long tenures in the company, while two were more recent joiners. Everyone in the group had been working in engineering for at least five years.Luckily, there was no need to start completely from scratch. There’s a wealth of information about career frameworks we could readily draw from. These are the resources we found most valuable:

• Progression at Monzo
• Engineering Career Development at Etsy
• Building a technical career path at Spotify
• Engineering Career Development at Gitlab
• We got career progression wrong. At CharlyHR
• Why we re-designed our engineering career framework at CircleCI
• One Rubric Changed Box’ Engineering Performance

2. The writing

Before we could put our ideas on paper, we needed to align on what we felt were the most important qualities of a career framework. Everyone has their own biases and it’s important to try and get these on the table. In a sense, you are discussing where your organization is now and where you want it to be. In our case, we wanted to emphasize rigor, collaboration and a high bar for quality. We also wanted a clear path of growth for individual contributors to positions other than management – you shouldn’t need to become a manager to continue to grow.

Many companies have mission, vision and value statements to help guide some of this work and determine which skills and competencies to prioritize. For example, at WeTransfer inclusivity is an important value and one that had to be considered in all our decision-making.

Our framework identifies the following areas of competency for individual contributors:

• Architecture
• Code
• Collaboration
• Community
• Delivery
• Hiring
• Leadership
• Operations
• Security
• Usability

And the following areas of competency for engineering managers:

• Leadership
• Team building
• Coaching
• Technical excellence
• Delivery

To give people enough room for growth, we defined eight levels of individual contributors, from intern to principal engineer. For managers, we defined five levels, from engineering manager to chief technology officer (CTO).

The writing itself was done in numerous iterations. We also experimented with different ways to present the framework, from excel sheets and exported PDFs to building an entire separate website. The framework had to be easy to find, easy to digest and easy to maintain, so in the end we settled on Notion – our internal wiki. Notion offered a good interface for the framework plus it’s a tool we’re all familiar with.

Once we finished our first complete draft we decided to expand beyond our initial group and get broader feedback.

3. Alignment and approval

We shared our first draft of the framework with a broader set of engineers, our HR team, and our internal works council. Sharing our draft early helped us address any key information we’d overlooked and brought to light some of the sensitivities that come with introducing a framework like this.

Next we sent out a request-for-comments (RFC) to the entire engineering department. We’ve worked hard to build an RFC-culture and all engineers had two weeks to provide their feedback to the framework, plus their proposed methods of implementation. The added benefit of sharing this freely and upfront meant engineers had some time to get comfortable with the levelling process that was coming.

The final step was to get formal approval from the works council. The majority of our engineers are based in the Netherlands, and important changes impacting these employees must legally be approved by the works council first.

4. Initial roll-out

When the framework was finalized, approved and published on Notion, the last crucial step was to apply it to all current staff. We realized this was going to be the trickiest part of implementing the framework, and one we really needed to get right. We wanted people to feel valued, but we also wanted to set a high bar. We wanted to steer toward a set of competencies we feel WeTransfer needs for its next stage of growth, with a strong emphasis on collaboration and quality.

We needed to apply a ‘level’ to about 60 engineers across several locations and a handful of managers. To minimize bias and ensure the framework was applied consistently across all managers and their reports, we created a levelling committee.

Our levelling committee consists of the CTO, two of our most senior engineering managers, and a representative from HR. This small group oversees the initial levelling as well as future promotions in the framework.

To establish and ensure fair levelling, we organized a session with all managers to align everyone’s interpretations of the competencies we’d outlined. Each manager then applied levels to their team members and fed back to the levelling committee. The levelling committee then went back and forth between managers to iron out inconsistencies and ensure a fair and balanced application of the framework.

If you think this sounds like a lot of work, you’re right – it was. But it was an important step in getting it right.

We want this framework to inspire people to grow further, instead of leaving them feeling misunderstood and undervalued. We wanted to make sure we were diligent and had a solid narrative to back up each and every level of growth.

Inevitably our initial levelling revealed some discrepancies in salary. So while we worked on the framework our HR team conducted some salary benchmarking. We projected their findings onto the framework, giving us a salary band for each level we’d established. This helped us identify pay gaps we could then address, and showed us where people were either overpaid or under appreciated.

5. Living the framework

The work of creating a career framework inspired a few follow up initiatives that are either planned or already underway: embedding the career framework in how we do performance management, and having the framework inform our recruitment process are the two most important ones.

We were able to produce our career framework relatively quickly because of the material that was available online, so we feel it’s our duty to give back what we’ve learned and add our own two cents as well. We hope that publishing our process and final framework will inspire others to create frameworks of their own, and follow through when the going gets tough.