Professional Blog

For more from me about work, business, technology, kubernetes, and more, check out my medium profile: https://medium.com/@KarlKFI

Standard Engineering Levels

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...

1. Levels provide a path of advancement, communicating expectations and milestones for career growth.
2. Levels codify seniority, a way to for management to communicate and grant authority.
3. Levels promote fairness of pay, mapping capabilities, responsibilities, and experience to compensation.
4. Levels allow for rationalizing the hiring of higher paid, more experienced employees, without disgruntling existing employees or getting push back from finance.
5. Levels make it easier to scale up by codifying management policies.
6. Levels allow applicants to self-select into a desired band of responsibility and pay, increasing attractiveness of job postings to experienced candidates.
7. 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. 

1. Intern
2. Associate (Apprentice)
3. Senior Associate
4. Staff (Journeyman)
5. Senior Staff
6. Principal (Master)
7. Senior Principal
8. Fellow (Grandmaster)
9. 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?

The Role of the Software Architect

An architect's role is to provide technical vision, coordinate direction across teams/components, and counterbalance short term thinking.

— Karl Isenberg (@KarlKFI) July 7, 2017

What's in a Name?

Collaboration improves when the roles of individual team members are clearly defined and well understood.

— Tammy Erickson April 05, 2012

I recently switched roles, from distributed systems engineer to distributed systems architect. I've been doing professional software development for about ten years. I remember telling my boss five years ago that my five year plan was to be a software architect. Guess that worked out! (Now what!?)

Looking back, it's obvious that I'm much better equipped for the position than I was five years ago. But the role itself also seems to have changed over time, as the tech world has evolved to integrate agile tendencies. So as I approached the new position, I found myself needing to repeatedly answer the same questions. Here are some of my notes.

What is a "Software Architect"?

An architect is an engineer who empowers other engineers as a force multiplier.

An architect focuses on the big picture of the system as a holistic product, rather than owning individual components.

An architect drives consensus between tech leads and product managers, rather than making or dictating critical decisions.

An architect promotes flexibility by identifying potential interface points and presenting engineers with options to reduce the cost of change, balancing short-term tactics and long-term strategy.

An architect is a specialist with strengths in diagramming, documenting, communicating, information architecture, and system design.

What is a "Distributed Systems Architect"?

The title itself doesn't seem to have a commonly accepted definition. So let's build one from similar titles.

A systems architect defines the architecture of computerized systems to fulfill specified requirements. Such definitions include the design and specification of components, component interactions, interfaces, technologies, resources, and dependencies.

— Wikipedia - Systems architect

A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages to achieve a common goal. Significant characteristics of distributed systems include: concurrency of components, lack of a global clock, and independent failure of components.

— Wikipedia - Distributed computing

Therefore, a distributed systems architect is a systems architect who defines the architecture of distributed systems, with special focus on communication and coordination between components.

Increasing Complexity

Whether you call yourself a software architect, a systems architect, or a distributed systems architect, the computing landscape continues to evolve with or without you. A few things specifically have changed in the last decade or two that make these roles harder than they used to be.

1) The demand for high availability and intolerance of down time has caused components that used to be simple to be replaced by distributed systems. Likewise, previously distributed systems became systems of systems. With multi-layer systems it's no longer appropriate to rely on legacy architectural design patterns, like a single API layer or a single communication bus.

2) The demand for agility and larger development teams has mutated service-oriented architecture into microservice architecture. This mode of development pushes even more glue code out of the individual components and into the platform or infrastructure layers, increasing their complexity. Deploying and managing a sufficiently large system of microservices increasingly requires a container or application platform above and beyond the scope of modern infrastructure platforms.

3) The demand for hyperscale (the ability to quickly scale up and down without re-architecting) often calls for the architect to design a dynamic system that considers dramatic change over time normal to system operation. The ability to survive a flash crowd of users (aka the slashdot effect) caused by social media is increasingly required by even the most mundane of business domains. Preparation for this and similar phenomenon happens largely at the system level.

4) The demand for open source software creates proprietary systems that aren't completely controlled by their developers. Unlike proprietary components, where one company is in charge of development, open source components can be both easier to change (with a fork or local modification) and harder to persist change (merging changes upstream often requires politics, persuasion, and modification). Partial control of the architecture of a system is nothing new, but partial control over individual components (specifically their APIs and communication patterns) increases demand for intermediary translation, proxy, and caching services. These ancillary components are often tightly coupled with one component to allow loose coupling with another, but tight coupling in a microservice environment often requires new deployment and management patterns, like sidecars and pods.

Musings

Not all software engineers will or should aspire to be software architects. Architecture is a specialization of the engineering track for people who enjoy abstract thinking, are good at and enjoy documentation and diagramming, have the ability to be political and drive consensus, and have demonstrated a solid grasp on prior art and the competitive landscape.

An architect may or may not also be an engineering manager or tech lead, depending on how much focus on architecture is required or desired. Since being hands off of code tends to erode peer confidence and personal skill set, it is desirable that an architect continue to be partly involved in programming efforts, either through tool, component, or ecosystem development.

The bigger an architecture team gets, the more they tend to lose touch with the every day life of the engineers they're supposed to be supporting. However, the more engineers an architect has to support, the less time they will have to stay hands on with code. So a balance must be struck such that architects retain respect and skill yet also spend enough time on architecture to actually provide the benefit of a higher level perspective. It's a fine balance.

Ontological Evolution

The idea of a distinct architect role has in recent past become somewhat contentious among software engineering agile practitioners. The more senior a thought worker, the less they want to be told what to do. But at the same time, modern development patterns are pushing complexity out of individual components with well defined teams into the between space. Plus each component may have a life of its own: independent release cycles, independent versioning, multiple interface/protocol paradigms, independent motivations, and external contributors. Someone has to align these components and the teams that develop them, to unify them into a single cohesive system. So just as engineering practice has evolved, so must architecture practice evolve from controlling and managing technical vision to leading the direction of its evolution. And since collaboration is easier with clearly defined roles, hopefully this new definition can help point the way.


(Revised on 2017-07-13 to expound on the increasing complexity of systems and the increasing demand for architectural design.)