Software Engineering levels are a mess.
Every company decides what their levels are, what they mean, what they're called, what the pay scales are, and they're all different. But what if they weren't?
Why do we even need levels?
Some companies, like Netflix and Valve, have decided to forgo levels and inflated titles in favor of deliberate flattening. This often goes along with a flattening of organization structure as well. Both decisions have pros and cons. I can't effectively argue for flattening, so I wont waste keystrokes on that (yet). Feel free to provide reasoning for that in the comments. Instead, lets look at why you might want levels...- Levels provide a path of advancement, communicating expectations and milestones for career growth.
- Levels codify seniority, a way to for management to communicate and grant authority.
- Levels promote fairness of pay, mapping capabilities, responsibilities, and experience to compensation.
- Levels allow for rationalizing the hiring of higher paid, more experienced employees, without disgruntling existing employees or getting push back from finance.
- Levels make it easier to scale up by codifying management policies.
- Levels allow applicants to self-select into a desired band of responsibility and pay, increasing attractiveness of job postings to experienced candidates.
- Levels provide a reward mechanism for social recognition through titles and implied respect.
When should you institute levels?
Putting aside deliberately flat organizations, many startups and small companies also lack levels, simply because they aren't big enough to need to stratify or just haven't gotten around to it yet.
Any one of the above reasons to have levels might drive you to start talking about them with your team. In my experience, when company size exceeds Dunbar's number (between 100 and 250) the social relationships within the company start to break down and you start needing much more process and policy to hold the company together. The next point of inflection comes when a single department exceeds Dunbar's number. So if your engineering department reaches 100+ you might start thinking seriously about levels, if you haven't instituted them already.
The critical point comes when your employees start asking "Why should I care what this person thinks? I don't know them. I don't work with them regularly. I don't know their experience or specialty." Now you might counter that with "You should trust that your company hired smart people." But that's not a very satisfying answer, especially if you don't know their boss either.
Really, it comes down to communication. Levels communicate several things. If you institute levels you communicate those things explicitly so that you don't need to communicate them implicitly or one-on-one any more.
How many levels is enough?
There's no one right answer to this question. As with most engineering questions, the answer is "It depends."
One of the oldest example of levels is seen in the guild system of artisans or merchants. Guilds helped originate the idea of lifetime progression from apprentice to journeyman to master to grandmaster. These levels allowed guild members to demand recognition and increased compensation from their peers and their customers.
Guilds were eventually largely supplanted by corporations, but the meme of levels hasn't gone away. In some ways, the idea of artisan levels even overlaps somewhat with concepts like The American Dream, which revolves around the availability and achievement of upward social mobility. If each level grants increased compensation and recognition, then advancing through the levels also advances one socially. Of course, engineering levels wont span the same gamut, from pauper to titan of industry, but it does express a subset, perhaps just within the middle and upper middle classes.
Interestingly, most modern leveling rubrics define a lot more than just the four levels used by the guild system. A fascinating resource is levels.fyi. Given that data, it seems the majority of represented companies have between 5 and 9 distinct software engineering levels. For example, Google's has 9 software engineer levels while California has 5 programmer analyst levels. Both of these are popular examples to emulate based on a history of successful operation and logical separations.
What level are managers?
One thing that's called out in California's levels, that isn't as obvious from Google's, is the qualification of "supervisor", which usually means direct management. Despite the clarity in the official series tho, the implementation of matrix management often confuses the topic. Google's, on the other hand, focuses on technical leadership, with management being a tangential concept. You might have to be at least an T5 (senior) to manage other people, but you might also be an T8 (principal) with no direct reports.
Having worked under both types of regimes, I think it makes more sense for management to either be an attribute that modifies your level, or a separate leveling series that branches from and overlaps with the independent contributors, rather than trying to fit both into the same leveling series. The biggest reason for this is that management is effectively a completely different skill set than programming. Both roles eventually get into politics and heavy communication at higher tiers, but they often require distinctly different personalities, talents, experience, and goals.
Are levels the same as titles?
Again, it depends. Titles are hard.
The more interesting question is perhaps whether titles should indicate role or just level. If you're on the Platform Team and you're a Senior Engineer, does that make you a Senior Platform Engineer? What if you're new to platforms but not to engineering?
This complexity has lead to a situation where many tech companies let you make up your own title, or put whatever you want on your business card. This isn't really a solution tho, especially if you're using levels to help communicate. Substituting a user chosen title probably communicates something else, generating confusion rather than alignment and clarity.
My suggestion? Compound titles. Being a "Senior Engineer on the Platform Team" communicates a lot more effectively than "Senior Platform Engineer", unless for some reason you have so many Platform Engineers that they get their own leveling series. Plus, with compound titles, you can easily indicate that you're a manager or supervisor if you don't have a distinct leveling series for that.
Another branch that is sometimes implemented is a separate leveling series for architects. This is more controversial and less common, but as with management, system architecture spanning multiple projects and teams and domains often requires different personalities, talents, experience, and goals than programming or design of individual components and smaller scale systems.
What might standard levels look like?
These levels probably aren't perfect, but they're probably a good place to start from, and iterate on if you decide they don't match your needs exactly.
For reference, guild levels are mapped to every other level. This is because the guild levels are well defined historical ideas that help communicate without needing to define them every time you use them.
- Intern
- Associate (Apprentice)
- Senior Associate
- Staff (Journeyman)
- Senior Staff
- Principal (Master)
- Senior Principal
- Fellow (Grandmaster)
- Senior Fellow
The target of these levels was originally software engineers, but it turns out they're applicable to a variety of positions, like designers, analysts, hardware engineers, technical sales, etc.
Who is junior?
No one likes being called junior. You could get away with calling an intern junior, but you might as well just call them an intern. It's more descriptive and less derogatory. Likewise, you don't need to call anyone entry if everyone above them is qualified by seniority.
What is an associate?
Retail companies, especially in high fashion, often call their entry level of floor sales people Sales Associates. This almost ubiquitous usage just isn't worth conflicting with.
An associate is someone who is connected with the organization or has subordinate membership. The connotation of being connected to but not necessarily a part of the organization may not be entirely accurate when used for Full Time Employees (FTEs), but it does at least imply at or near entry level.
If the word itself is contentious, one option is just to leave it out, without affecting the leveling. For example, T2 could be "Software Engineer" while T3 is "Senior Software Engineer".
Who is senior?
Some people really don't like the deflation of the "senior" qualifier common to the tech industry. Senior when discussing age usually means over 65 years, the relative peak of life, rather than something describing 20-somethings. But when you have more than a few levels, it's often hard to find English qualifiers to express seniority.
Some companies use Senior as the level above staff. Some companies use Senior as the second level above no distinct title. For my proposal, I used Senior as the "tock" to the guild level's "tick". This way Senior gets a distinct meaning as a sub-qualifier and doesn't need to be put on the same scale relative to the primary qualifiers of Associate, Staff, Principal, and Fellow.
Another benefit of making Senior a sub-qualifier is that you sidestep the problem of whether Senior is above or below Staff, which often confuses people.
Who is a lead?
Tech Lead or Lead is often used as a level, but in my experience it tends to imply leading a team of peers. If you have more or less leads than teams then who's leading each team? Lead is too tightly coupled with the organization structure and roles. So it's easier just to leave it out of the levels.
Why not distinguished?
The problem with using "Distinguished" as a level is that it implies that one stands out from the crowd. It's hard to go further than being distinguished. It doesn't make sense for Senior to modify Distinguished either, because they are both adjectives. So either Distinguished needs to be at the top or it needs to be a third modifier above Senior, which puts it too low. What exactly would a Distinguished Associate be? It sounds more important than a Staff member. So that's not going to work.
The other problem that Google ran into is that they had to add more levels as time went on. The top when they instituted levels wasn't enough. For example, they eventually needed to add Senior Fellow to give Jeff Dean a new title in 2013. So putting Distinguished at top makes an artificial cap you might need to expand past.
Why not partner?
I don't want to answer every objection here, but there's definitely some places, like Microsoft, that use Partner as an alternative to Fellow or at least above Principal. I left it out for a few reasons. First, partner is often used to describe external individuals or companies that are being collaborated with for integration or supply or sales, and having it be a title might be too ambiguous. Second, law firms and banks often use Partner to describe partial owners of a private firm, but this conflicts with ownership through public stock and can be confusing when a private company goes public.
How do I implement this?
Another hard question! I'm gonna call this out of scope of this article, otherwise I'll never finish. ;) But there's definitely more to do that I will leave as an exercise for the reader and maybe explore in a future post:
- What responsibilities does each level have?
- What are the pay scales for each level?
- What experience or knowledge is required for each level?
- How does leveling affect who you report to?
- How do you re-level people when instituting levels?
