Why

The good thing about levels, is the transparency. When it’s clear to people what’s expected of them, stress goes down. It’s much easier to give frequent feedback with reference. “Remember that expectation from the list? I think you can improve in it by doing this and that”. With frequent feedback and low stress levels, productivity goes up. Aspiring to progress towards the next level can encourage managers to be more mindful about careers when allocating people to certain projects or tasks.

At Apegroup we’ve had a few more reason for introducing levels: at a Peakon survey employees asked to have a clear growth ladder; we needed a baseline for our hiring ads; we needed a baseline for our compensation process; and we needed to allow different pricing for our clients, based on the experience of the team that will develop their next needle-moving product.

Risk

But introducing levels can be a harmful process, risky to the team’s moral and hence productivity, and to the retention of the team members. Most companies our size (we have about 30 engineers), don’t have levels.

We believed that by working with the team and giving people control, we can enjoy the benefits of the change without suffering from damage.

How

I have created and led this process together with our tech directors team. We agreed to follow these steps:

1. The TD forum create a draft of detailed expectations from each level.
2. The process is communicated in a team meeting, including why, what and how.
3. The draft is shared in a 1:1 meeting with each team member. In the meeting suggestions are added to the draft. It’s also allowed to add suggestions offline.
4. The draft is finalised in the tech directors forum.
5. Each team member pitches in a 1:1 meeting about the level they think they’re at.
6. The level for each person is finalised by the tech directors forum.
7. A 1:1 meeting with the tech director and department head is conducted in case there is a disagreement.
8. Personal growth plans are created for employees who are interested, towards the next levels.

What

In this post, you can find the list of expectations that we’ve defined for each level. We used Monday.com as the tool to document and discuss the expectations at.

Execution

1: Creating a draft of detailed expectations from each level

We are four tech directors and one department head, coming from very different backgrounds. Nonetheless, the discussions we’ve had during the creation of the draft were very constructive and strengthened our forum.

It took us about 3 weeks to create the draft, we started with 3-hour meeting where we individually filled each category for about 15 minutes, and then went through what everyone wrote together and discussed. Then we’ve had a few more 1-1.5 hour meetings to complete the draft for all levels.

2: Sharing the draft in 1:1 meetings and add suggestions

This happened after the head of department explained about the process to the entire department. In my 1:1s, I shared my screen and just read the Monday board where we created the draft, one row after the other. In some of them we’ve had elaboration inside the ticket, so I opened the ticket and read the elaboration. If people had questions or suggestions, I added them to the board with a [Suggestion] label.

My colleague is managing more people than me (I manage 9 people and it was challenging to manage to speak with all of them in one week, but I did it). I recommended him to have that meeting in 1:2. He chose pair of people similar in level and style. We got some feedback, saying that it’s a nice process. We didn’t get any feedback from anyone in the team that it’s problematic, nor noticed a drop in velocity or motivation at the time of the process.

3: Finalising the draft

It took us about 3 hours to go through the few suggestions and finalise the draft.

4: Individual pitches

The state of mind that I’ve had when taking those meetings, is to come up with additional examples for people that they might have forgotten, and encourage them that they actually meet some criterion, and to identify and discuss with them what we can do to give them the right opportunities.

So for example, if someone said: “I don’t feed into the dev-ops tasks”, we discussed how such behaviour can look like in their current tasks. If they said “I didn’t choose stack” I noted that I need to give them the opportunity in the future instead of choosing for them. I was able to learn a lot about the past of people from the stories and to allocate them to tasks with a better fit in the future.

I found that the individual process of searching for examples per criterion, which we asked all employees to do, was more fruitful than just presenting the list of criteria and going through it with each one of them.

I did ask for clarifications sometimes, when they said “we” or spoke too generally and I wanted to understand if they were doing something themselves.

5: Finalising the level for each person

It took us about 20 minutes per person, and we used presentations with this template:

• Pitching for: Z
• X greens, y orange, z red for this level (in my slides I added the table of criterion and examples for each person, for the level they pitched for. Green is strong examples, orange is something they didn’t get too many opportunities to experience, red — didn’t get/take at all opportunities to experience).
• Hired as x, y years ago (it matters because giving people a level below the level they entered the organisation is something that we wanted to try to avoid, if possible).
• People that perform similarly (we wanted to highlight potential risk of people working together and feeling that they perform similarly, and then receiving different levels).
• Opportunities needed (yes, this was a big part of this process — to make sure people advance to our organisation’s max capability).
• Action items (always good to have action items. They were for example, to make sure we open a slack channel for code reviews, following one of the discussions).
• Next level — for people who did not jump a level this time, so that we can have a goal for 2021 that will motivate them to grow in the growth areas that we define together.

The discussions were interesting. I was able to collect “360” feedback for people. I didn’t give it immediately, but had 1:1s with the tech directors who gave feedback to get the details right. For some people, someone had an experience were they didn’t do well, and then someone else said that they actually had a more positive experience exactly in this context, so we were able to adjust our collective appreciation for our developers.

Sometimes people had comments that could impact the level of a person but were not related to any criterion in our list. In those cases we tried to see if we need to modify the list, and we ended up not taking into account the comments and sticking to the list.

6: Escalation in case of a disagreement

We didn’t need to decline anyone’s level, and I think one of the reasons is that the criteria were detailed enough so people couldn’t really work around them but had to pitch for the right level.

7: Building personal growth plans for employees who are interested, towards the next levels

The format of the plans was as follows:

• Level: Y
• Goal: Advance to a X during 2021.
• Feedback (Only things that came up during the discussion on the level).
• Identified work areas by you: from the discussions we’ve had when they pitched.
• 6 months Plan: recommendations for tasks, books, courses, what to highlight in meetings.

Summary

The principles that guided us in this process is transparency and collaboration with the team. We managed to avoid hurting the productivity while creating a framework for growth in the team and clear expectations. After publishing this story, I was referred by Karni Wolf to a similar process done by CircleCI. You can read about it here.