Designing a growth framework for your engineering team

What considerations should you be making when marking out the career paths for your engineers?

In my last article, I talked about the importance of setting expectations early. As leads, if we don’t make expectations explicit to the team, they will still exist implicitly; not discussing expectations will only result in a mismatch. Some of the most important areas to align on expectations include performance, career pathing, and growth. A growth framework creates a common understanding of levels within a role and what’s required for an engineer to advance in their career. I’ll share with you my learnings from developing one for individual contributors (with a lot of support from all across Rasa, of course!).

What does a growth framework look like?

A growth framework documents the expectations of team members in various competency areas. For example, senior engineers are expected to understand technical and business tradeoffs and help mentor newer engineers. Some go more in-depth and give a level for a team member in each skill area. For example, a senior engineer could be at Level III for product acumen and Level II for mentorship. A lot of frameworks document example behaviors and projects in each area and at each level to provide more clarity. Check out progression.fyi for some examples.

The need for a growth framework arises as your organization scales. This article by Smruti Patel details when such a ladder starts to be useful and why.

The goals of a growth framework

It is impossible to create a perfect framework. People have various skill sets, and it is challenging to fully represent the value and contributions they bring. But, I believe the growth framework should strive to achieve the following goals.

Align expectations

The lead should set expectations on the requirements for a role or a title so the teammate can receive clear feedback about where they are in their career and their contribution level. They could start a conversation if they disagree with the assessment, consequently creating alignment.

Align incentives

As the framework levels advance, they should increasingly reflect the impact the company needs and wants from their teams. When folks progress in their careers, they should be rewarded for making the best decisions and creating the highest impact on the business.

Mitigate bias

When a lead discusses levels with a report, the lead needs to prepare sound evidence to back up their judgment. Also, leads can compare and calibrate their evaluations with other leads based on the framework. Hence, the process aims to mitigate bias. 

However, this is not entirely immune. It’s easy to fall into the trap of confirmation bias, where the lead will only include examples that support their presumptions.

Plan career growth

A growth framework should highlight the areas in which an individual contributor can progress and step up. This allows team members to see what their potential career paths could look like. It turns career conversations from ‘titles’ to ‘skill sets’ and ‘competencies’.

The lead can lean on the framework to plan the next steps for a teammate’s growth with them. At the same time, having an overview of the team members’ growth needs helps the lead provide each teammate with the right opportunity at the right time, as well as distributing these opportunities fairly.

To support an engineer that wants to progress into management, the lead can work together with them to identify the competency areas that are especially important for the role: for example mentorship, core collaboration skills, and prioritization. This steers the conversation from ‘I want to become a manager’ to ‘What are the necessary skills I need to acquire before becoming a manager?’ The lead can then sketch out stretch assignments that will ease the engineer into the role, like mentoring a new hire, and leave out less relevant opportunities, like a multi-month architecture challenge to others. 

Help with calibrating compensation

Managers may want to tie the growth framework with compensation bands. Within the company, if two people have similar levels in the framework, they should also be paid similarly. This works towards closing the gender pay gap.

Having the levels also allows managers to compare these expectations across the industry. A ‘senior’ title could mean very different things in different companies. Doing the comparisons ensure that the team gets paid fairly in the market. Levels.fyi is a good resource to get started.

Things to consider when developing a growth framework

Fair recognition across skill sets

The framework can serve as an abstraction layer to articulate the skills needed rather than the technology or programming language used. The expectation of designing long-lasting software won’t change, while the technology and frameworks behind it can change year to year. This allows us to set similar expectations for engineers across the technical stack.

One of the goals of a growth framework is to mitigate bias and bring about equity. You want it to equally recognize skill sets across the technical stack. If you come from a full-stack engineering background, you’re probably biased towards the problems you understand best. So reach out to industry engineers to outline what a UI/UX engineer’s growth trajectory can look like to fill in your knowledge gaps. You can also work with other engineering managers to ensure that examples from different stacks are well-represented and calibrated at each level. 

The same goes for the diversity of strengths. One of the goals of a growth framework is to align incentives. In a well-performing team, there is usually a good balance of folks who are great at executing, influencing, relationship building, and strategic thinking (I borrowed some CliftonStrengths terminology here). Map out example career paths where people with different strengths can excel.

Diversity, equity, and inclusion (DEI) should take the front seat

You want to design a framework that helps the company become more diverse and inclusive. On one hand, you should be recognizing the work that employees do to push forward DEI: educating themselves to practice allyship, bringing on candidates who make your teams more diverse, and taking a leading role in your company’s DEI group to advise the company’s DEI strategy. 

On the other hand, you want to be establishing a baseline for DEI: to contribute positively to a safe and inclusive team environment. Everyone should meet the baseline to work at your organization. Also, the more senior someone is, the bigger the scope of influence they have, and the more commitment to DEI is expected from them. 

Apart from weaving DEI elements into the growth framework, you want to design a framework that accommodates various needs. In the case of parents, you should make sure the framework rewards folks’ output and not their constant availability in the day. Considering neurodivergent folks, you could expect some of their competency profiles to show distinct strengths and weaknesses. So an approach could be to set promotion criteria around people’s strengths. Instead of requiring people to get to a certain level for all areas, you could only set a few baseline requirements and focus on people’s strengths and what they are achieving with them instead. 

Success in the lens of stakeholders

Dev teams work in collaboration with stakeholders like Product, Sales, Marketing, and clients. You can solicit feedback from different parties to ensure that you are aligning the right incentives to help the company, not just the team, to become successful. For example, consider the original phrasing of the ‘Product acumen’ area: ‘continuously evaluates proposed product solutions with respect to better alternatives unknown to product management.’ I got feedback from Product in my organization that this is not entirely accurate. Their primary responsibility is to determine the users’ pain points and describe the problems. However, it is a collective responsibility between Product, Design, and Engineering to come up with solutions. 

Things to avoid

Having a growth framework can potentially solve many problems in an organization. On the flip side, it can also bring about nasty surprises. I’ll share with you some pitfalls I have seen and mistakes I have made with growth frameworks.

False proxies of competency

As competency levels become more advanced, writing the level descriptions gets increasingly challenging, mostly because the work itself is less predictable. One solution is to link the competency with the scope. For example, you would expect someone to be able to design small systems at Level I, medium-sized systems at Level II, and large-sized systems at Level III. You would expect someone to be able to complete tasks in a project at Level I, scope out medium-sized projects at Level II, and lead large-sized projects at Level III. However, solely relying on scope violates the goal of aligning individual and company incentives. To grow their career, teammates ask to be placed in big projects. Then, who is left to tackle these small projects critical to the business, which still needed to be finished with delicacy and quality?

Another solution is to evaluate the competency with the sphere of influence. For example, you would expect someone to follow the team’s process at Level I, create processes for the team at Level II, and organize cross-team processes at Level III. You would expect someone to interact positively with their teammates at Level I, be able to resolve conflicts at Level II, and be able to resolve cross-team conflicts at Level III. When people interpret this shallowly, they will fill the organization with these cross-team processes that slow the teams down. People might get rewarded for resolving simple conflicts just because they are with another team.

Going back to the root of the problem, the difficulty of specifying expectations for more senior roles is that it all depends on the situation the team member is in. From there, we decide which impact they are expected to create. For senior roles, I designed the expectations for folks based on these scenarios: turnaround, accelerated growth, and sustaining success (borrowing terminologies from The First 90 Days by Michael Watkins). A turnaround situation is when the team does not perform, fails to hit their goals often, or when there are significant strategy changes. An accelerated growth situation is when a product hits Product Market Fit, and the company needs to scale up fast in a short period. A sustaining success situation is when the company steadily grows and optimizes for long-term success. In a sustaining success situation, the team might need more processes to streamline workflows. In a turnaround situation, the team might need to revisit and tear down the original processes. The growth framework should award a person’s ability to identify and solve problems with the appropriate solutions.

It is not to say that evaluating people’s work scope and the sphere of influence is entirely ineffective. Instead of solely relying on them as a proxy to competency, I suggest also looking into people’s technical breadth, technical depth, and the business impact they bring about. Introducing these criteria along with the scope and the influence better equips us to avoid the ‘false-proxy’ pitfall.

One last thing

Introducing and iterating on a growth framework is a significant organizational change. It requires your teams’ and other stakeholders’ buy-in and deliberate change management to succeed. Check out this topic in my other article here if you are interested to know more.

Conclusion

Designing a growth framework requires thorough considerations: fair recognition across skill sets, championing diversity, equity & inclusion, meeting stakeholders’ success criteria, and avoiding the ‘false proxy’ pitfall. But when done right, a growth framework can help you and your organization become more transparent, bring the best out of the team, and support your team’s growth. Good luck with drafting your framework!