Benchmarking Software Engineering Job Levels by Company Size

What is the optimal number of Individual Contributor (IC) levels in your job architecture design? 

‍

Facebook/Meta has 7 IC levels for software engineers. Meanwhile, Microsoft has 13 IC levels for software engineers.

‍

This raises the question–what is the optimal number of IC levels?

‍

First, let’s look at some market data. And then let’s consider some pros and cons of the two approaches in this Microsoft vs Meta IC level comparison.

Software Engineering Job Levels by Company Size

How many IC job levels do most companies in the market utilize today?

‍

Our team analyzed the number of IC levels within the Software Engineering job ladder across 1,033 Pave customers. A key note: only levels with employees currently in-seat today were counted in the analysis.

‍

So, what is the standard number of engineering levels? Two key findings emerged:

‍

1. ~5-7 IC levels is the norm. We found that by the time companies get to ~200+ employees, they tend to leverage ~5-7 IC levels for software engineering. Smaller companies (< 200 employees) tend to leverage a couple or few IC levels as they grow into a more robust job architecture.
   
   
2. The “double level” Microsoft system is an outlier. While there are certainly some companies in Pave’s dataset more aligned with Microsoft’s 12+ IC levels system, these companies are exceptions to the norm.

‍

Individual Contributor (IC) Software Engineering Job Levels by Company Size

‍

Pros & Cons of the Two Approaches

In this Microsoft vs Meta IC level comparison, both approaches to job architecture design have pros and cons.

‍

Pros to the Microsoft-style Architecture with 12+ IC Levels:

‍

• Theoretically, you get to promote employees roughly twice as frequently. This can increase an employee’s perception of their career momentum and perhaps act as a retentive force.

‍

Pros to the Standard Architecture with 6-7 IC Levels:

‍

• This is the market-standard architecture and thus is more congruent with how existing compensation benchmarking datasets are structured (Pave, Radford, etc.). This likely yields more seamless market pricing exercises for your compensation team. Also, there’s less of a learning curve for candidates, employees, and comp program administrators.

‍

• The size of each promotion award in a system with fewer levels (and promotions) is likely larger than in the Microsoft-style system. Which raises the final question…

‍

What matters more from a retentive standpoint—the frequency of recognition, or the magnitude of an award each time an employee is recognized? 

‍