Recently, we implemented a career ladder for software engineers to define the growth path by using a competency framework similar to what CircleCI uses. Before, we only had abstract titles that gave no information about responsibilities and didn't define clear expectations. Every engineer was handling their growth and expectations with their manager. We now have a career path for software engineers.
During the implementation, I directly worked on implementing the career framework in our team and moderated sessions between the engineers and the manager. Here are my observations and thoughts on the career frameworks.
Engineers Get a Chair on The Table
The career frameworks are growth tools for engineers, not producers of hierarchy. Without it, engineers never get a chair on the table, and the power accumulates on the managers. It helps to disperse authority, align expectations from titles to generate new opportunities. Once the power is spread between different roles, organizations and individuals both see a huge uplift. Achieving this uplift is only possible by approaching the ladder as a growth tool and fairly evaluating everyone.
The career ladders help engineers comprehend where they are and what they lack precisely for the next level.
Dropbox recently published their career framework, and they have a variety of roles covered. If the career framework is comprehensive enough like Dropbox's, it covers various roles and applies to many different disciplines such as engineering management, software architecture, and security. Although many companies won't have many positions covered like Dropbox, having the minimal framework still benefits everyone, especially people in their early careers.
Personal Growth in All Levels
Junior and mid-level engineers usually cannot perceive how they can grow and what they should learn. The framework assists them with options and opportunities and identifies which skills need attention to plan their growth.
On the upper levels of the ladder, staff and principal engineers can understand the scope of their work to prioritize their projects more efficiently. I often encounter principal and staff engineers having trouble describing their impact while preparing for performance reviews. The framework provides a basis for discussion about their responsibilities and influence on the company.
Regardless of the level, all engineers use the framework in performance reviews. Since it defines the minimum expectations, engineers get help to prepare for the review and the promotion case. However, the framework shouldn't be the only criteria in performance reviews and promotions.
At the same time, career frameworks help look at what others are doing and in which scope they work. If there is a chance for peers of the engineer to evaluate the engineer using the framework, the framework gives better results because there are skills that the manager might fail to assess fairly. Evaluating peers also helps engineers, especially juniors, understand other engineers' actions and mimic them to learn new stuff for reaching the next level.
Of course, everything comes with trade-offs. These are the good sides of the career frameworks and the most substantial reasons to implement them. Now, let's take a look at the bad sides.
How Much Time Does It Take To Implement?
The framework takes a lot of time. If you want to develop one or even adopt one of them, it takes a lot of time and energy to evaluate everyone from scratch. Especially in the beginning, it's a significant investment, and many people find it difficult to separate a time for it.
The company's leadership group isn't the only one who creates the framework and evaluates everyone. Depending on how you implement it, almost everyone spends time on it. We asked two peers to assess an engineer's competency so that the manager's point of view wouldn't be limited, and we catch hidden gems. Although we told peers not to spend more than thirty minutes, it is still an investment. Depending on how you make this investment, your gain will differ.
Not Every Skill Is Measurable
Some skills listed in the framework will have a vague meaning. Some companies define them as precisely as possible, albeit the skills themselves are difficult to specify and level, especially soft ones. For example, being an effective communicator has different meanings in different cultures. Finding what does effective communicator mean is the real challenge.
Be Aware Of The Cultural Differencs
The managers' skills and communication impact the evaluation a lot. The difference between people's cultural backgrounds makes the precise assessment difficult. While low-context cultures (e.g., the American and German) can communicate their evaluations explicitly with examples, people from high-context cultures (e.g., Indian and Turkish) and people who use a holistic approach (e.g., East Asian) to present an idea walk around to explain what their self-evaluation. If the manager isn't aware of these differences, the discussions are highly likely to create dissatisfaction.
Imposter Syndrome is Real
Before we finish the bad part, there is one more point. The imposter syndrome is real. If the managers are not careful, they can easily fall into the trap of lower evaluation because of engineers having an imposter syndrome. It's also possible that bad managers can use this to their advantage. We've seen that some engineers tend to evaluate their competencies lower than their actual level. It is tricky to put the finger on this issue during the evaluation discussions. However, once identified, we've seen that concrete examples convince the engineer.
There are other trivial bad points that I won't mention in detail because they are not very common. Let's move on to the ugly.
It's Getting Ugly: Promotions
Promotions. As exciting as personal growth is for everyone, governing promotions is difficult. It usually involves many people for decision, and many factors affect the judgment. The ugliest part is that when people grow their skills and become ready for the next level, there may not be an available seat.
The company strategy, size, and growth define how many staff+ engineers will be in the company. Although the goal is to grow engineers into staff-level engineers and give them a seat, not everyone can and should be a staff engineer. Even though some people may have the necessary skills to level up, it might not happen and therefore losing the engineer becomes inevitable.
Creating the career framework brings the responsibility to level people correctly. When there isn't any career ladder defined, people don't expect to be levelled correctly. But the mechanism itself creates the expectation. When this expectation is not managed correctly, it will cause a lot of headaches.
The expectations will also be present about the opportunities. When engineers wish to climb the engineering career ladder, they will expect to get opportunities from the above level to learn and operate on the next level. Managers need to seek out, find and delegate these opportunities to engineers. However, these opportunities are rare. The more an engineer climbs the ladder, the fewer chances they will get.
Difficulty: The Team Impacts The Promotion
In some teams, such as automation and platform teams, the day-to-day work brings these opportunities because it includes working across teams (one of the main requirements for staff-level engineers). On the other side, in product (or feature) teams, these opportunities are usually absent. This situation results in more engineers from platform or automation teams getting promoted to staff levels. In contrast, product or feature engineers are less levelled up just because they don't face the challenges every day, though they may handle them when given a chance.
Unfair challenges lead to unfair evaluations and promotions. Doing fair evaluation is difficult because of not only lacking opportunities but also different interpretations of the framework. Strategies such as involving another manager or director in the assessment can create a consistent evaluation across teams. However, adding these people will generate a bottleneck and result in a higher evaluation time.
Providing the framework and ladder to engineers shines the light on only one part of the career ladder. The other parts, such as becoming a software architect, team lead, engineering manager, and technical product manager, are usually unclear. For example, while Dropbox defines multiple tracks, CircleCI has only one framework for all engineers. Of course, satisfying everyone is impossible. However, once you start implementing a framework for the software engineering track, the others should follow as soon as possible because people have different career goals.
After talking about opportunities, evaluations, levelling, and promotions, skipping the salaries would be inappropriate. Although I like having specific salary ranges for each level, there are trade-offs for all approaches. The good side of aligning compensation levels with the career ladder is that it helps underrepresented groups close the pay gap and make managers' lives easier. However, the salary levels also limit engineers' compensation when they reach the top in their title but are not ready to level up. This whole process can quickly get ugly when the interests start conflicting.
The career frameworks are helpful, but how you approach it and your implementation strategy defines how useful or a burden it will be. If the approach focuses on defining only levels and creating a hierarchy for better decision-making, you will probably form a promotion competition. If you don't make the process clear and transparent, you will break the trust when people struggle with promotions.
If you are getting into implementing the framework, don't get stuck in the advantages. Be aware of the flaws of the framework, and don't try to overachieve it at once. Build it step by step. Try the framework with one team, collect feedback, improve it and slowly expand to other groups.