About two years ago we started noticing (in 1on1’s, surveys, etc.) a growing interest in the progression possibilities from the people in the Engineering Department. Up to that point we always handled professional development ad hoc: when somebody was standing out in their job they were promoted, given a raise, or offered training and mentoring to progress further in their role. After several years, we had grown from 50 to 190 people and this was not enough anymore, people wanted to know what was expected from their role, what was needed to progress, and what options they had.

We learned a while ago that when we face a challenge it rarely is something very specific to us and most of the time we find that many other companies faced similar challenges before. So we started looking around and we found about Progression Frameworks (PF). It looked like exactly what we needed.

What’s a Progression Framework?

A Progression Framework defines the possible roles in your organization as well as the skills and expectations for each of the roles. Usually, it defines different levels for a role and then expectations for each level related to different topics (communication, Impact, Leadership, Technical Mastery, etc.).

Why a Progression Framework?

In our case, the PF serves the following purposes:

• Provides people in our organization with clear expectations about their work.
• It's a tool for managers to facilitate the professional development of members of their team.
• Helps unify the roles and levels across the different teams in the organization.

The Individual Contributor Progression Framework

We decided to start by working on the role of the Individual Contributor (IC) in our Engineering Department. We define an IC as the professionals in our Department who doesn't have line management responsibilities and work as an individual but who contribute significantly to the goals and mission of the organization.

In our Department, this includes:

• Software Engineers (Backend, Frontend, DevOps, and any type of Fullstack).
• Software Development Engineers in Test (SDET).

We started working on it by defining it in a spreadsheet, it was a long process, for the first version we were inspired strongly by Progression Frameworks from other Tech Companies (check progression.fyi (opens new window)) and then we started modifying and adding our own skills and expectations. It went through several rounds of proposal and review from our Engineering Managers and after that, we tested it with some individual contributors from the department to check if we were missing something important.

By the beginning of 2021, the first version was ready and we started the first round of evaluation through all the engineering teams. The feedback was really good, and we got some modifications and improvements from the Engineering Managers. One of the bigger things was to define specific mastery sections for each of the specialties: Backend, Frontend, DevOps, and SDET. We worked on that in groups with the senior engineers for each specialty, and by Q3 2021 the Individual Contributor Progression Framework (ICPF) was ready for another round.

Our ICPF is now split into 5 different frameworks. A shared one that covers: Communication, Feedback, Influence, Impact, Leadership, and common Mastery. And 4 more PF’s covering the Mastery for each of the specialties: Backend, Frontend, DevOps, and SDET. Every Engineer fills the shared one and as many specialties as they want to be evaluated for.

Keeping a spreadsheet for every Engineer was very uncomfortable for our Engineering Managers, especially when a new version of the ICPF was published, so our most recent change has been moving it to a specific tool for Progression Frameworks: progressionapp.com (opens new window)

Also, this allowed us to publish it to share it with other companies who, like us, may be looking for some inspiration for their progression frameworks, check ours here:

mad.progressionapp.com (opens new window)

The evaluation process

The evaluation process for a person follows 3 steps:

1. The person starts by self-evaluating themselves for each skill choosing between working towards, meeting, or exceeding the skill level. They can also add examples where they demonstrated this.
2. The manager then, without being able to see the self-evaluation yet, starts the same process of evaluating the person. Choosing between working towards, meeting, or exceeding for each skill and adding examples or notes for each.
3. The third step is done together in a meeting, where they both can compare the evaluations, have conversations about each skill and agree on what is the level for that skill.

Finally, some things we try to keep in mind…

• A Progression Framework (PF) is a compass, not a GPS. It’s meant to provide you with a direction to follow but it’s not supposed to guide you in every little step, is not a mathematically precise model of reality.
• We don’t expect a person to meet each and every one of the expectations and skills in a level to consider them that level. We all have strengths and weaknesses.
• The PF levels can represent the full career of a person. Makes no sense to try to rush it.
• A PF is not a promotion checklist for a role, rather it’s designed to help people figure out what their impact could look like at the next level.
• Our Progression Frameworks exist in the context of Mad Collective and are tailored to our context and needs. Levels from previous work experiences may not be perfectly equivalent.
• A PF is a live document. It has to be reviewed periodically. The more it’s used the more it will improve and the more helpful it will be.

This has been our experience so far, we are very open to hear from other companies, collaborate and learn from each other, please feel free to contact us for help ideas and collaboration.