Building engineering progression - Part II: Core
Examples, tips & pitfalls while building effective engineering progression framework for your organization.
This is the second of three parts of articles describing the journey we made at VirtusLab while creating an updated version of the engineering framework.
This time, there are two major sections here:
Analysis of most common structures of engineering progression framework in real-world organizations (starting from section Choose a structure for your progression)
Tips & Pitfalls to have in mind while building framework (starting from section Things to consider when detailing your engineering progression)
In the first installment, I covered the case for building engineering progression and the groundwork. In this article, we switch to the nitty-gritty details of creating an engineering progression and its release.
Wait. You skipped the first article? Here’s a quick reminder of what I mean when referring to an engineering progression framework:
An engineering progression is a career ladder for engineering roles within a given organization. From a high-level perspective, it is a roadmap for an engineering career designed to help both engineers and their managers navigate their career paths over the years. From a low-level perspective, it covers a set of required skills and expectations to be met at a given level of seniority. In addition, it more or less directly indicates the engineer's salary.
Choose a structure for your progression
Let's begin by picking a basic form for your engineering progression. But where to start? How about taking a look a progression.fyi, where you'll see many different progressions, each drawn from a real organization. If you are building an engineering progression for your organization, I strongly recommend you browse through the examples on that webpage.
Engineering progressions typically fall into a small handful of distinct forms. Different organizations, of course, emphasize different aspects of how engineers work or how their culture works (which I covered in the first part of this article series, in the section Things to be clear on before building your engineering progression). What's less obvious is that the most appropriate structure for you will be a function of several parameters related to your organization. Most likely, the key parameters will be:
The size of your engineering organization
Role diversity of your engineering organization (number of various roles e.g. application engineer, data engineering, technical project manager, etc).
What does this look like in practice? Let’s look at a few typical approaches.
A simple approach
In a small, relatively homogeneous engineering organization with mostly one type of role, perhaps the simplest approach is the one Basecamp / 37signals used in 2017.
It focuses on just one type of role - programmer. Each seniority-level description consists of just a few bullet points. When the junior role is dissected, it contains these basic elements:
Scope of work: “Works primarily on tightly scoped, routine problems.”
Skills/capabilities: “Basic language features are mastered, but some advanced structures may still be unfamiliar.”
Length of experience: “Usually less than 2 years of experience being a professional programmer in the specific domain.”
I've noticed that adding explicit years of experience is controversial for some people. Personally, I think it is a good idea, and will cover the pros and cons in the Years of experience vs. speed of climb section later in this article.
All in all, this structure is simple, and that is its greatest strength. In fact, I'd go so far as to say that, in my experience, this is the way to go for most companies that are:
Relatively small (say up to even 50 people); especially if they have mostly similar roles
Building their first engineering progression framework (because it is likely to provide the best bang for the buck).
It is also simple from the perspective of particular ladder levels. It is a straight path, with fairly obvious stages, without any branches.
It is no coincidence that I used this approach when I was building an engineering progression framework, circa 2012. This was for a small consulting firm that I co-founded. We had about 10-15 engineers back then, and we needed something simple. We also used something very similar at VirtusLab between 2015-2020. In retrospect, I see the framework we built had a ton of problems, but we’ll get to that in a moment.
There are also other notable, well-structured examples of this approach - for instance, Monzo’s Engineering Progression Framework v3. This one has more levels - and now they aren’t universally as obvious as the previous example. This requires some additional Monzo context-specific information - which they do provide with the basic split into Impact, Technical Skills, and Behaviors categories.
It is clearly more complicated than the simpler approaches used above, but it seems very well justified - at the time of this writing, Monzo had likely more than 200-300 engineers on board. This leads to a full-blown competency-based approach, which will be discussed next.
Competency-based approach
The competency-based approach is effective, although more complex. As long as you capture the characteristics and culture of your engineering organization accurately, it can work quite well.
As an organization grows, the limitations of the simple approach become apparent.
As an organization grows, it becomes more fragmented and siloed (unless leadership consciously and relentlessly counters this drift). This is a phenomenon that may be all too familiar to anyone working in a growing organization.
At VirtusLab, noticing the lack of consistency in how engineers were being evaluated, we created a quick experiment.
I wrote a list of artificial engineer profiles. The role descriptions consisted of general characteristics, strong/weak points, some indication of recent accomplishments, and a general indication of previous work experience.
I showed this list to 10 managers and team leaders and asked them to match these synthetic profiles to the seniority levels seen in our existing engineering progression framework.
The results left much to be desired. We had good alignment for some profiles. We also found that for others - about half of them - we had discrepancies for the same profile ranging from Junior+ (advanced Junior) to Staff- (early Staff). The experiment’s results made us realize it was time to raise our game and modernize the engineering progression framework.
At this point, we were clear we needed to bring in more fairness and consistency, and help managers and engineers with career guidance.
What we'd experienced is what often happens in organizations as they grow, briefly:
More managers/leaders appear in the organization. Direct lines of communication become less effective and the need for more concrete guidelines arises.
The organization becomes more diverse in terms of its engineering roles.
These are challenges that the simple engineering progression can be adapted to meet:
Split the general expectations into separate, more quantifiable characteristics or competencies.
Add multiple parallel engineering progression ladders.
This typically leads us to what I’d call a competency matrix (sometimes called a rubric). My favorite example is the CircleCI progression. It is very well thought through.
The basic elements in this progression are:
Seniority levels (e.g. “E3 Senior Engineer”)
Scope of work (called “scaling of competencies” in the CircleCI progression)
Competencies (e.g. “Debugging”).
In this progression, the competencies and seniority levels work together intuitively. The scope of work scales from an individual task (for a junior or associate engineer), to teamwork (for senior engineers), to the entire organization (for principal engineers).
The competencies are also grouped into categories. For CircleCI these are:
Technical skills
Delivery
Feedback/communication/collaboration
Leadership
Strategic impact.
Five in total. While these categories are specific to CircleCI, when you look at a number of organizations, patterns emerge. For example, in our second approach to engineering progress at VirtusLab, we developed three categories: Engineering, Delivery, and Teamwork. Another example is Dropbox, which uses: 🏆 Results (a variation of Delivery), 🌟 Direction, 🌈 Culture, 🌳 Talent (all closely related to Teamwork), and 🦉 Craft (a variation of Technical Skills).
The most surprising finding for some, however, is that hard technical skills typically represent only a small fraction of the total expected competencies. This is interesting in the context of recurring online debate about whether soft or hard skills are more important for software engineers. Here’s my take, based on my experience with hundreds of engineers I’ve managed over the course of my career:
Hard skills are required and are key conditions for promotion in the first part of the engineering career.
Soft skills start to play an enabling role in the later stages, from senior engineer onward. They won't guarantee advancement on their own, but a lack of them will severely limit further development.
Don't get me wrong. Not paying attention to soft skills (collaboration, communication, etc.) will be detrimental to an engineering career at any level. However, you want to pay a significant amount of attention to this for the more senior engineers. On the one hand, your seniors, staff, and principal engineers set the tone for the entire organization (by orders of magnitude more than juniors). On the other hand, most senior positions require strong leadership skills (which in turn require good soft skills), even if they appear to be individual contributor roles.
I covered this in the Leadership Management vs Engineering section of the first article in the series. It is almost impossible to perform well in Staff and above engineering roles without well-developed soft skills.
Returning to the explicit split of competencies in the progression framework - even Basecamp (now 37signals) has begun to use separate competencies in their engineering progression circa 2018.
While it is definitely not the case that EVERY organization will eventually move in this direction, it is pretty typical for many growing organizations. I'd say when you have +100 engineers in your organization (and thus likely between 10 and 20 teams), the need for such a change will be apparent.
In addition, most growing organizations dealing with complex technology products quickly build more diverse roles. While they may initially have front-end and back-end engineers, they will eventually introduce designers, cloud engineers, data analysts, or ops. Whereas you can probably handle a fair share of traditional engineering (e.g. backend/frontend) with a single engineering path, it might not be feasible anymore to do that for all types of engineering roles (e.g. designers, ops).
Sure, you can create a very general progression, but I would argue that its usefulness quickly diminishes if it becomes too general. Since one of the purposes of an engineering progression is to establish consistency across the organization, it must, by definition, be tangible enough to be understood similarly by engineers and managers throughout the organization.
One thing to keep in mind is the increased effort required when moving from a simple progression to a more complex one, complete with explicit competencies and different career paths. The division into different specializations (career ladders) effectively multiplies the work you need to do to create and optimize the progression. In addition, explicit competencies require a deep understanding of the specifics of your organization and its evolutionary path.
While a simple engineering progression could be written almost overnight by a founder (well, the first draft, at least), a more complex version with a competency matrix and multiple career ladders will most likely require a working group active for many weeks. This is not easy work. There are several reasons why:
You need to break the work down into discrete, concrete competencies/characteristics.
You need to provide concrete descriptions of the competencies at different ladder levels.
You need to cover multiple roles, some of which may be less familiar to you (most engineering leaders have experience with some parts of the engineering work; but how many have the work experience with all the roles in the organization?)
By the time you are ready to build a complex engineering progression, your engineering organization will likely have many practice areas with their respective leaders or role models. It will be critical during the rollout phase to have their buy-in. Getting them (or someone from their sphere of influence) involved early on will definitely help.
Make sure you plan accordingly!
Optionality and trajectories
One of the problems that typically arises with competency matrices is that they assume that everyone within a given career ladder is the same. That is, there are specific requirements for each competency for an individual to be at that level. And it's worth noting that CircleCI relies on no less than 28 different competencies to define whether an individual is at a given level.
I have found this approach too prescriptive for larger, more diverse organizations. It's even unrealistic for smaller organizations, but not as obviously as in a larger organization. You are bound to end up with many engineers who not only meet certain requirements, but far exceed them while falling short in others.
A more liberating example is the progression used by Medium. They have done a great job of describing how it works in this series of articles. Basically, they have four different areas (Build, Execute, Support, Strengthen), each of which contains multiple competencies. You can see them here. Achieving milestones in these competencies gives you a specific number of points, and there is a specific threshold of points you must achieve to be promoted. How the engineer earns these points (which track they choose) is entirely up to them!
This is an extreme example of codified choice, but it is far from unique. Another example is used by a company very close to me - and now part of VirtusLab - SoftwareMill. You can read more about their "badge-based engineering progression" here.
Above, you can see an extract from SoftwareMill’s engineering progression. Here’s a note on how to decode it:
J1, J2, M1, S1, E1 - these are engineering levels (Junior, Mid, Senior, Expert)
7B, 9S, 2G - these represent specific badges. They fall into three types: Bronze (B), Silver (S), and Gold (G), each being more difficult to earn than the previous one.
Badges are related to achievements in specific competencies. For instance, knowledge sharing, architecture, production maintenance, etc.
Competencies are segregated into three groups: Technical (hard skills), People and Development (soft skills), and Organizational.
As you can see, the progression framework allows for considerable flexibility, but it also imposes some constraints. For example, to advance from S1 to S2, you must earn 9 silver badges, 5 of which must be in the technical category.
In my opinion, some flexibility in the progression framework is desirable. This is especially true at higher levels. Staff+ is where most people's careers start to diverge according to their different strengths. But be aware of the trade-off - this is another level of complexity you bring to the table.
I think you want to allow some flexibility, but at some point, you have to split into separate career paths. In the case of Flatiron, Cat Miller says they eventually decided to split engineering after the E5-E6 level into two paths: the Principal Track and the Architect Track. I think this is a reasonable compromise.
All right, we have covered the most typical structures used for engineering progression frameworks. Now let's discuss the key aspects to consider, tips from experience, and typical gotchas.
Things to consider when detailing your engineering progression
Now, let's move away from the high-level structure and zoom in on the details and key considerations to keep in mind when building the framework.
Picking competencies to add to your matrix
Whatever type of engineering framework you're working on, you need to think about competencies and attitudes - whether you show them implicitly (as with a simple approach) or explicitly (a competency matrix). Either way, you need to be clear about what set of skills and attitudes is required for a given role and level.
For any non-trivial job like software engineering, we quickly conclude that there are many skills and attitudes to consider. I'd say it's worth spending some time identifying the most important ones. In my experience, it is difficult to narrow it down significantly below 10. On the other hand, more than 20 can be overwhelming. The CircleCI example used earlier contains 27 different competencies. In my opinion – even though it may work great for CircleCI – it might be too many.
Keep in mind that distilling them into the engineering progression framework is just step one - the easy part! Then you need to get all engineers and managers to understand them well and use them regularly for performance reviews and 1:1s. Depending on the nature of your organization, you’ll spend different amounts of time on these activities, but keep in mind that if it’s too complex or time-consuming, it’s likely that only a few people will do it well, and everyone else will just treat it as another company bullshit they need to get through.
The obvious trick is to group them into some logical buckets. This is backed by science - grouping helps you remember more. In our context, it helps managers and engineers remember the competencies relevant to the organization and their careers.
A balanced, manageable number, 10-20, will also help you be concrete when applying it to a variety of different roles. For example, at VirtusLab we've found that we can use the same skill set for backend application engineers and frontend engineers, even if they specialize in different technologies, from Scala to Java to Typescript. However, we concluded that Data Engineering would require a modified skills matrix. Designers would also get a different matrix.
Avoiding low-level concepts, such as knowledge of specific tools or frameworks, is the key to achieving broad applicability while still being tangible and useful. We concluded that, even if we wanted to separate frontend from backend paths, we wouldn’t focus on tools and frameworks because they change too often from project to project. Instead, we divided technology competencies into high-level skills: writing code, maintenance/production, technology landscape expertise, architecture, and DevOps. I’m sure the exact breakdown is pretty much specific to us, but it shows the level of granularity.
The key here is that it doesn’t make sense to get too specific (e.g. talking about the particular programming language, framework or methodology) because it changes over time and from team to team. Also, it sounds a bit too dogmatic and counterproductive to focus your engineering culture on particular tools. On the other hand, being too general doesn’t make too much sense either - remember that the main goal is to build consistency across the organization. Being too general won’t help. Pick the competencies that are relevant to your organization. If observability or security is relevant to most engineers in your organization, it should be part of the rubric. Not every organization emphasizes these aspects for every engineering team - especially with a siloed dev vs. ops culture. For example, we chose "maintenance and production readiness," which includes security, observability, diagnostics, etc.
We also found that for different engineering roles (Ops, data engineering, application development), even if we create separate career ladders and competency matrices, the competency matrix really only differs in terms of the hard skills. Delivery and teamwork remain largely the same. This is not unusual, as these categories are more tied to company culture and organization and, thus are likely to be more common across disciplines. One exception is purely management roles, but that’s a different story, probably a separate career ladder and perhaps a topic for another article.
The bottom line is:
Do your homework: verify the competencies that are relevant to your organization (as opposed to copying them from other hot companies)
Keep the number of competencies in check (< 20)
Group competencies into logical buckets that help people keep track
Don’t be overly specific, especially with technologies, or too general either.
Track record vs. present capability
We put statements like these in our first engineering progression:
Is able to plan & design the architecture on a project-wide level. Can discuss requirements with customers / stakeholders. Is able to set up processes. Can drive interactions / integrations between multiple, technologically diverse components or products.
Capable of leading regular projects, with several engineers involved or is starting to be widely recognized for his/her expertise in their field of choice. Share knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).
There are a number of problems with such statements. First of all, it is asking for trouble to use statements like: "is capable of...". What does that even mean? We've had many situations where engineers come to managers and say they can do X, but they don't have enough opportunities to prove it. It bit us many times, and countless hours were spent on such conversations during 1:1s.
The harsh truth is that no matter how you design your career ladder, there will be patches in the organization (a project or group of projects) where the local situation doesn't allow engineers to manifest or hone certain skills. For example, there may be a team that is effectively keeping the lights on for one of your legacy projects that will (hopefully!) be decommissioned next year, and they have limited potential to excel in architecture skills.
The same goes for the availability of leadership opportunities, such as taking the lead on initiatives that span multiple teams or stakeholders. While these opportunities may come up from time to time, there is still the issue of timing in the context of a given performance review cycle. There will be periods of time when some people may be technically ready for something, but they just haven't had the opportunity.
In my opinion, the better way is to have an actual track record. We should at least have some tangible - even if imperfect - proof that engineers are actually doing the work to a given standard. It may be a bit unfair (again, opportunities are not evenly distributed), but it saves a lot of headaches that can ripple throughout the organization.
The bottom line is to avoid phrases like "can do" or "is able to. It is much better to rely on "has a track record" or "has demonstrated the ability to do X more than once.
Frequency and intensity
There’s a similar kind of problem found in statements such as:
Shares knowledge with others (mentoring, conference talks, blog posts, workshops, meetups).
Is one internal workshop enough to qualify? How about one per year or one per quarter? I am against being too prescriptive, but there should at least be a guideline for what we expect. You definitely want to avoid the checkbox exercise where you're asking some people to do certain activities once to check the requirements for promotion.
Sometimes it might be enough to clarify that we are talking about the pattern of repeated behavior (such as: "this person is known for sharing knowledge with others") rather than concrete numbers ("you must do some form of knowledge sharing 3 times" for example).
Years of experience vs. speed of climb
I am not a big fan of role prerequisites based on years of experience. First of all, not everyone is the same - some people grow and learn faster than others. Second, not all years of experience are the same. As the saying goes: "Some people have 10 years of experience. Others have 1 year of experience 10 times over.” At the same time, experience that comes from practice is important. And practice takes time. Most experienced engineers would (and should) be suspicious of someone with 2 years of experience claiming to be senior.
I don't think we should be too dogmatic about this. I favor descriptively stating typical years of experience for a given level of seniority. It shouldn't be a showstopper for someone who doesn't meet those values, but it should at least make you suspicious and ask the right questions. Having some benchmarks might also make it a little harder for managers to give in in times of intense hiring pressure from the CEO or otherwise (and thus tendencies to lower standards).
The same goes for the time it takes to progress from one level to the next. If someone is progressing too fast, it shouldn't be a showstopper, but it's probably worth investigating. In the worst case, an exceptional individual comes to your attention thanks to such investigation. At best, you discover a situation where the manager gives in to pressure from a very salary-conscious engineer who, for example, threatens to leave if they don’t get a raise. At the end of the day, you want to be fair (promotions based on merit, impact, attitude), and allowing pushy engineers to be promoted faster does not do that. This is also related to the point made in Frequency & Intensity above. If we are going to focus on a "pattern of repeated behavior", it is definitely going to take some time to establish that.
What are the right values here? It depends on the organization, but a good rule of thumb might be to wait at least one or even two years before promoting to higher levels. Again, that's a guideline, not a hard and fast rule.
Is “up or out” effective?
The "up or out" scheme comes from some partnership systems, especially law and consulting firms. It generally says that you have a certain amount of time to reach a certain rank. If you fail to do so, you must leave the organization.
I don't believe in the myth that everyone in IT needs to advance their career indefinitely. This may be fine for some people (achieving certain roles as a life goal), but I think it is beneficial also to be able to accommodate people who want to stabilize (or pause) their career advancement for a period of time (e.g. more family-focused time) or even indefinitely.
Generally speaking, up or out doesn't make sense. However, I think it might make sense for entry-level positions - namely interns and juniors. If you subscribe to this line of thinking, it is worth making this expectation clear upfront.
Juniors require the mentorship and attention of mids and seniors and, as such, represent an investment. This investment is expected to provide a return on investment at some point. If that is the case, then there should be some pressure on junior engineers to get through those early stages in a reasonable amount of time. So, I think it makes sense to set benchmarks for how long we expect engineers to stay at the intern and junior level. Exactly how long depends on the specifics of your organization. After all, junior doesn't mean the same thing in every company. It is common for juniors in one company to be considered mid-level in another. I think the reasonable starting point is to expect interns to be promoted to juniors within at most 1 year and juniors to be promoted to mid-level within another 1.5-3 years.
If you want to ensure this is adhered to, it is worth codifying it explicitly in engineering progression.
Time to add more career tracks?
At some point you inevitably face the dilemma - is one of the roles sufficiently distinct to build a separate track for it? A separate track might have two manifestations:
It’s either a separate career ladder with distinct requirements and competencies (for instance, application developer vs UX designer paths).
Or it can be a branch from the existing career ladder (a typical example is software engineering branching into engineering management).
These examples are high-contrast. After all, the role of a UX designer is quite different from that of a typical software engineer. One might even ask whether UX design is really engineering at all. I will leave those philosophical questions aside. The bottom line is that UX designers are typically part of the engineering organization in most companies, so they deserve a career ladder just as much as anyone else in the engineering part of the organization.
What about data engineers versus application developers? I'd say it depends on the nature of the work in your organization. It's a lot of work to build separate career ladders, but fitting square pegs into round holes doesn't really serve the overarching goals of engineering development. If it is to add value, it has to be used, and that requires sufficient buy-in.
My quick rule of thumb is to build a career ladder for any role that affects more than 20 people in the organization (and at least consider it for roles with more than 10). If you decide to use a typical breakdown of competencies (hard skills, communication/teamwork, and leadership/organizational) for most individual contributor roles, it is likely that most of the time only the hard skills will vary significantly. The rest will remain largely the same.
It is hard to miss the point at which a separate career ladder is potentially needed. If the role is truly distinct and doesn't fit well into the existing career ladder, it's almost certain that people in that role will come to you and complain about it (which is great!). They may even suggest that they create a separate ladder for themselves (which is even greater!). If you decide that a separate ladder is worth the effort at that point, it is good to have a basic framework and structure thought out so that they can do it themselves.
In both cases (separate ladders and branching), it is worth making sure that lateral movement is possible (people moving to other departments or between individual contributors and management positions). How to do this from an organizational perspective (training, salary, position, etc.) is beyond the scope of this article, but from an engineering progression perspective, they should at least "feel familiar" with the new technical ladder they will be using (structure, organizational/teamwork skills, etc.).
There is also a more subtle area related to career branching. In some roles, there are several possible paths of development. These are often referred to as archetypes or trajectories and become apparent at higher levels of an engineer's career. At VirtusLab, we have defined the following archetypes:
Team Leader: The first step in a leadership career that begins with managing a single team. This is typically still a very hands-on technical role.
Rock: It describes a well-rounded engineer who can basically perform almost any task on a given project. They know the domain very well and are well versed in the business environment of the project. They usually spend long periods of time (many years) on a single project and tend to be the bedrock of the project, knowing it inside and out.
Subject matter expert: This trajectory describes an engineer with exceptional depth and/or breadth of knowledge, skills, and experience in a specific area. The area may be more technical (e.g., cloud platform engineering or stream processing) or domain-oriented (technology in InsurTech or manufacturing). The impact of these engineers comes from sharing knowledge/training others internally, supporting VirtusLab's outreach (articles, presentations, panel participation, community activity), helping with pre-sales efforts, and consulting with other teams.
Architect: Architects are often involved in pre-sales activities or the initiation of new projects. They must be able to understand the business environment, constraints, and customer requirements. Since customers often don't really know all of their requirements, engineers in this role need to have solid experience in figuring out what the real requirements are. Typically, they spend a limited amount of time on the project (6 to 12 months) or work on it part-time - while being involved in other initiatives (either continuously or from time to time in a more consultative manner).
Organization engineer: Organization Engineers thrive on building engineering organizations - they are often involved in key organizational tasks. They may play a leading role in areas such as engineering progression, building VirtusLab's ways of working, redesigning the hiring process, building training for new team leaders, etc.
At VirtusLab we distinguish these archetypes from the Staff+ level on. In our case, they don't require completely separate branches in the career ladder. They do, however, allow us to emphasize certain competencies and help guide engineering careers at a certain point. They are also specific to VirtusLab, based on our retrospective identification of notable senior engineers with different skill sets. I would be surprised if they could be applied "as is" to your organization. Here are examples from other organizations that may give you food for thought:
Meta – as described by Gergely Orosz – uses the following archetypes: Generalist, Specialist, Coding Machine, Tech Lead, Fixer, Systems Thinker, and Product Hybrid.
Flatiron Health – Cat Miller describes their journey that involved separating the Principal Track from the Architect Track starting from E6 (E6 is roughly Staff Engineer).
When promotion requires more than just meeting requirements
There is a tendency to treat meeting the requirements for a given engineering level as a sufficient condition to warrant promotion. "I've done what was required, so I should be promoted soon after" - right? While this is certainly true for some levels and perhaps even desirable for all, I don't think it's always and everywhere the case.
It definitely makes sense for the first part of the career: interns, juniors, mids, and seniors. As soon as the engineer meets the requirements, they are eligible for promotion. Things get more complex in the second part of an engineer's career and definitely in management roles.
Let's start with a simple example and assume that our management engineering career ladder looks like this:
Almost all steps in this career are based on available opportunities. You can't really move from team lead to engineering manager if there isn't a vacancy. Granted, opportunities abound as organizations grow, but of course, constant growth is not a given. In fact, it is almost guaranteed that your organization will plateau at some point. If attrition isn't perfectly aligned with the growth rate of your people, there will come a time when even people who meet all the requirements can't be effectively promoted.
The extreme case of this example would be the CTO position. Unless the current CTO of your organization leaves (by their own choice or otherwise), you are unlikely to promote anyone else into that role.
Going back to the pure engineering (non-management) roles, I think this also applies to the Staff+ engineering levels, although it depends on your organization’s stage (hypergrowth, stagnation, contraction, etc.) and the attrition rate. Would your organization be even able to utilize a new Principal Engineer every time there's a new person, who meets the requirements? It's worth thinking about.
The thing that helps here is that Staff+ engineers are less common than less experienced engineers. And Principals are even rarer. So, it is unlikely that the supply of these very senior roles waiting in line for promotion would become a major problem. Still, I think it is worth clarifying that meeting the requirements is not sufficient for some roles. Addressing this issue openly and upfront may save you some headaches down the road.
Next steps
That's about it. I've tried to cover a lot of the ground needed to build a successful engineering progression. It is a lot of work. Or rather, doing it right is a lot of work.
The real fun, however, starts with the rollout, building in the change process, getting buy-in, and dealing with the various outliers in your organization. This will be the focus of the third and final part of this short series, which I plan to publish in the next few weeks. If you've found this information useful, I'd love for you to subscribe to this publication.
Until next time.