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?

Exponential Improvement Is The New Growth

Here's a sneak peak at a future S.A.T. analogy. Fill in the blank.

Velocity : Acceleration : Jerk :: Growth : Continuous Improvement : _________

We'll get to the answer, but first a history lesson!

Buckminster liked to make up new words. "Ephemeralization" was his from the 1930's. The classic definition of ephemeralization is "doing more with less", but it's more precisely the observation that things happen more quickly and easily over time, requiring less resources. The easier things become, the faster they become easier. The cheaper things become, the faster they become cheaper. Generally this is attributed to the adoption of scientific management, as exemplified in early industrialization (especially by Henry Ford).

Gerald Hawkins in the 1980's described the idea that each stage of change had an inflection point where a paradigm shift ('mindsteps', as he called them) occurred, advancing the rate of change forward. He also observed that the rate of paradigm shifts was increasing. Change was accelerating.

In 1986, Masaaki Imai popularized "Kaizen", the idea of continuous improvement in business management. Ideally improvement doesn't need to be limited to discrete (continual)  jumps based on scheduled analysis after designated periods of time (iterations), but could instead be driven by slack in the system to allow (continuous) improvements every day. The acceleration of change requires faster measurement and analysis, but with built-in slack the workers on the factory floor can do it better than managers at a distance.

In 2010, David Anderson documented "Kanban", a method of software development that integrates Agile concepts with Japanese Kaizen improvement techniques. The practices and policies Anderson describes are great management techniques based on years of experience and an evolution of Agile methodology. His primary focus is on work in progress limits to create slack, but the real power comes from empowering workers with information and constant feedback so that they can use the slack for continuous improvement.

So with the implementation of continuous improvement in Japanese factories (like Toyota) and later Silicon Valley software developers (like Google), managers found themselves with less management to do because they'd empowered their employees to do their job for them. Many people have been confused by this, thinking that managers are now obsolete in an organization of continuous improvement (like Valve software), but the truth is simply that managers need to level up, the same way factory workers replaced by automation had to become educated to produce, maintain, and improve automation. Managers won't manage people in the future, they'll manage their own empowerment of people.

Managers don't just provide feedback any more. They empower employees to provide and receive feedback. Just like employees need feedback to improve, management needs feedback to improve as well. If you really want to get better at getting better you need to level up again. "It's much less about 'What kind of knowledge advantage do I have right now?' but 'How fast am I creating new knowledge?'."

This is where executives come in. The new job of executives isn't to manage the managers any more or even just to manage external expectations, but to empower the managers to manage themselves. Empowered managers get better at empowering workers to get better, inovating on innovation. As we've seen on the previous level, old style executives are becoming obsolete, even a liability. They need to educate themselves and raise to the challenge of faster change, to manage the empowerment of managers. They need to not just set a culture, but grow a culture of change. Business doesn't just need to evolve; it needs to improve its ability to evolve.

Back to the analogy...

Velocity is position over time. Acceleration is velocity over time. Jerk is acceleration over time. Growth is improvement of state over time (the new role of workers). Continuous Improvement is positive growth over time (the new role of managers). So Exponential Improvement is faster continuous improvement over time (the new role of executives).  Jerk is the third time-derivative of position. Exponential Change is the third time-derivative of state. Exponential Improvement is positive Exponential Change.

No, this doesn't mean future executives will all be jerks, but they might need to be good at calculus. The executive needs to enable Exponential Improvement, and the easiest way to do that is to derive it from the employee improvement metrics over time. They'll have to analyze metrics and behavior to figure out how to improve exponentially. They'll have to identify synergistic ways to empower managers that increase their rate of empowerment.

To be fair, Continuous Improvement will get you a long way. Most organizations haven't even figured out that yet, but they will. And the more that figure it out, the faster the movement will grow. But if you really want to succeed in the future you can't stop there. You have to get better at getting better at getting better.

Future Shock is no longer in the future, it's now. Change is and will be. Change is continuous and accelerating and decentralized. This isn't a revolution; revolutions end. Businesses that didn't change are already dead. Businesses that aren't changing fast enough are dying. The new race is how fast you can innovate. It's a race you can't conclusively win; you can only win now and survive until you win again. Growth is slowing down. To grow linearly you'll need to improve exponentially.

Stop watching the world improve and start participating in making it improve faster.

Technology in Education

This article (linked in the title) from the NY Times reports on the selective happenings of some students and how they are affected by the general trend towards increased computer use and constant connectivity. The author tries to stay objective in the reporting, but the picture painted is one of change and the difficulties educators have adapting to that change.

While technology may be difficult to adapt to it is not a fad. One of the educators quoted seems to compare advancing tech to rock and roll. Not only does this date the speaker but it also indicates a misunderstanding of technology in general. Rock and roll was and continues to be a category of a narrow section of consumable media. At most one could classify it as a lifestyle. But technology is a much wider empowerment of all lifestyles (save those that reject it).

It's plainly obvious that educators are seeking ways to use technology to better reach students. While this is a worthwhile goal, perhaps it might be more useful to invest in improving motivation, curiosity, and useful curiculum.

As seen in the article, many students are motivated by trade skills like video and audio editing, useful skills that students can easily identify as applicable to their future. I'm not implying that all schools should be trade schools, but the world that values renaissance men and women has past. As technology advances the volume of availible skills and information increases dramatically. Many large corporations spend millions categorizing information and educating their work force. As information explodes it becomes increasingly difficult for one person to know enough about general topics to be any more knowledgable than a search engine. Knowing facts becomes less and less important. Facts can be categorized and searched. Yet schools continue to rely heavily on memorizing things that can be easily looked up on any student's wireless device. It's no wonder students don't like learning algebra or Latin. The modern world simply doesn't need EVERY student to be able to do these things.

At university they used to like to tell us they were teaching us how to learn. Why did it have to wait until university? Why wouldn't I know how to learn before that? We need to teach kids how to learn much earlier. Then we can concentrate on teach skills, not just knowledge.