7 Surprising Insights From the Top Engineering Career Frameworks
We set out on a quest to create the most comprehensive engineering career framework in the industry. Our first step was to find and analyze the top frameworks that engineering leaders spent months building. We surfaced 17 engineering career frameworks from companies like Dropbox, Etsy, and Square, and synthesized our findings into a unified framework. Then, we sent this framework to dozens of experts to get their opinions and refine the final product. Here’s what we learned along the way.
Most frameworks have the same common themes
One of the core jobs of a career framework is to break down all the skills that are required in a software engineering career, across levels. Over 70 skills are used across companies (more on this below), so multiple levels of grouping are used to help navigate them. Most companies have a very similar approach that involves grouping skills into 4 high-level themes:
- Technical (aka technical mastery, domain expertise, craftsmanship, knowledge)
- Impact (aka ownership, delivery, execution, or ‘get s*** done’)
- Collaboration (aka communication, feedback, teamwork)
- Leadership (aka influence, management, organizational)
Some companies choose to break down their skills differently or combine two of these themes together, but the majority of teams use these themes.
Leadership and collaboration skills dominate the frameworks
This may not be a surprise to anyone who has tried to progress in the software engineering field: most frameworks put a far greater emphasis on collaboration and leadership skills than technical skills. This is usually clear when you look at a framework at a glance, and our in-depth research confirms it. In our comprehensive framework, only 1/4 to 1/3 of the skills are considered technical.
The average framework has 50–75 skills, not 8–10
Blog posts about engineering skills often say there are 10 or 12 essential engineering skills. Many job descriptions usually list out 8–10 skills. But based on our research, the average engineering framework has many more skills than that: the true number is at least 50 per company. In order to be comprehensive, we aggregated the list of skills across companies; we ultimately identified 75 individual skills that are required of most software engineers.
Some frameworks do try to shorten the list, relying on more generic terms and skill categories like ‘teamwork’ or ‘reliability’ to stand in for a long list of component skills. They do this to make the framework more understandable and less overwhelming, but it’s not optimal for learning. Identifying granular skills is the most effective way to learn and to make progress in your career.
A framework should evolve over time, and it’s usually easier to add something than it is to take something away.
But, shorter and smaller frameworks can still be valuable
Many companies publish highly detailed frameworks complete with verbose value descriptions and long lists of behavioral examples and expectations. This is not the only way to make a framework. We encountered numerous teams and companies that use concise frameworks and see good results with them. Finding the right level of detail for your team’s framework requires examining your challenges, goals, and priorities. Smaller companies, with fewer specialized teams, usually have simpler frameworks. A framework should evolve over time, and it’s usually easier to add something than it is to take something away.
If you introduce a framework in response to a problem, you’ve waited too long
Because frameworks are often thought of as highly detailed and precise documents, companies tend to invest a lot of time and energy in creating them. In turn, many companies put off the process of creating one for a long time. A very typical situation is that a company will create a framework as a reaction to an engineer asking a difficult question about their title or their role expectations. In this case, the company has waited too long to clearly communicate with their engineering team about role expectations and they’re likely to lose some talented engineers who see more career progression opportunities elsewhere.
Build on top of existing company values
Frameworks that suffer from complexity and obscurity don’t get used. In pursuit of perfection and novelty, engineering frameworks tend to introduce lots of new concepts and terminology with their framework. One easy way to boost the memorability, understandability, and thus the likelihood of success of a departmental framework is to make an effort to re-use existing company terminology. If your organization has already articulated company values or if the HR team has already defined a leveling system or compensation structure, those existing systems should be embraced and referenced throughout a framework, with department-specific skills, expectations, and levels layered on.
existing systems should be embraced and referenced throughout a framework, with department-specific skills, expectations, and levels layered on.
Participation is key to buy-in and adoption
A framework is only valuable if it’s used by individuals on the team to think about career progression and to drive productive growth discussions. Getting team members to actually adopt a framework for regular use is a challenge. One common reason why frameworks aren’t adopted is that individual engineers feel that the framework doesn’t actually map to the things they are asked to do in their day-to-day jobs. Companies that make an effort to include a broad group of engineers in the creation process, and investigate how they work and what examples of excellence look like, see stronger adoption. Furthermore, engineering organizations that have a transparent and simple process for updating a framework, or at least giving feedback on a framework, also see stronger adoption.
Thanks to the dozens of engineers, leaders, and career experts that we talked to in the course of this effort. You can view (and fork) our comprehensive framework here: https://practicahq.com/leveling-frameworks/engineering
