Building engineering progression - Part I: Groundwork
The path to building an engineering progression framework for your organisation
Building a world-class engineering organization isn't always plain sailing. At VirtusLab, where I wear the CTO hat, we've learned a few things along the way. This is the first of a three-part series to share those lessons and help you build an engineering progression for your organization. In this first installment, I’ll cover the case for introducing a structured engineering progression and the basic groundwork to be done ahead of implementation. In subsequent articles, we’ll explore building blocks, structure, rollout, and maintenance processes.
The context
An important part of VirtusLab's business is the efficient delivery of custom solutions for clients in various industries. The majority of these projects involve building software, ranging from proof of concepts (POC) or small components that take a few weeks to develop, up to large-scale systems that may take years to build and maintain.
As our business grew and the number of engineering teams increased, we realized we needed to have a clearer and more consistent approach to engineering career progression. Eventually - and this was around 2017 - we decided to build one. Back then, our entire engineering team consisted of less than 50 engineers and was mostly homogenous - mainly backend engineers and a few frontend devs, all of them working in application-level development. In the context of engineering progression, it was enough to introduce something simple.
Our first engineering career progression implementation looked like this. It was inspired by the engineering progression used in Basecamp back then (now called 37signals). We introduced it pretty much “overnight” - I wrote the initial version over the course of 1 or 2 evenings, which was followed by 2-3 weeks of review. It did the job pretty well for several years until we noticed some big cracks starting to appear.
To be fair, we got a few things right. First, we looked at our company operating model to see what skills and attitudes would help us to grow. In hindsight, the operating model seems a little naïve, but at least we made an honest attempt at doing this part of the groundwork.
And yes, we made a lot of mistakes. We mixed engineering with management, we put too much emphasis on non-core activities (mixing core work with nice-to-have activities that are more related to the culture of the company), and we blindly adopted certain roles without checking whether they were really applicable to our business at the time (e.g. Principal Engineers). Finally, we added a lot of vague, broad statements that could easily be interpreted in different ways.
In 2023, we started rebuilding the engineering progression framework. By then, the company had grown from 50 to 400 employees and was way more diverse.
So, that’s the context. Let's move on to the main part.
The basics
What is an engineering progression framework? In essence, 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.
Do all companies need an explicit engineering progression framework?
No. Not all companies have or need an engineering progression framework to function well. There are two kinds of organizations that typically don't need an engineering progression framework.
Small organizations tend not to have an explicit framework for engineering progression. They typically rely on salaries and responsibilities being discussed directly between the engineer and the employer (usually represented by the CEO or CTO). Typically, salaries and responsibilities are discussed directly between the engineer and the employer. This informality makes sense for small teams (a few dozen engineers) due to two factors:
Limited processes: Most small but growing organizations lack many of the processes and standardization that take shape as the company matures. This is usually due to working in a restricted environment (resources - including attention - are scarce). Growing companies have a lot to juggle, and whatever they can postpone in exchange for prioritizing product-market fit should usually take precedence.
Direct communication: Due to their size, the best communication channels are direct and verbal. This is feasible and efficient in an organization of 20-40 engineers that can be run directly by top management, often the founders themselves.
The other example of organizations that get away without implementing a structured engineering career ladder are flat organizations. Flat here means that all engineers are treated the same (in terms of expectations & compensation) - they don't necessarily have to be flat from a management perspective (e.g. contrary to the Valve example - see page 4 of their employee handbook). Netflix is a notable example of a flat organization at the engineering level. But what does having a flat engineering structure mean in practice? If the level of expectations & compensation is roughly the same for everyone, it must mean that you need to hire very senior engineers. The alternative, i.e. hiring only junior engineers, doesn't seem to be a sustainable solution in the long run 😏. Few organizations, outside of the hottest Silicon Valley startups in ZIRP times, have the luxury of doing this. And, let's face it, a lot of the work in many technical organizations can be done by less experienced engineers, who, of course, cost less and are easier to hire than seasoned seniors.
Why most companies should eventually adopt an explicit engineering progression
Interestingly enough, even Netflix eventually ditched the flat engineering-level concept circa 2022 (which is covered neatly by Gergely Orosz in this post). It's pretty remarkable that Netflix, a huge tech company, managed to keep flat engineering for so long. By 2022, they'd been around for over 20 years and had grown to about 2,000 engineers. It seems that the reasons for the shift were similar to those that often drive companies to adopt an engineering career framework.
Those reasons are:
Most organizations need to have a mix of seniority levels.
Sometimes this is a conscious decision. The organization recognizes that not all types of work require top-level expertise, or it recognizes the benefits of mixed teams, which is well described here by Luca Rossi. Or it's forced on the organization by economic factors, cost constraints, or talent availability issues.Organizations grow beyond 40-50 engineers.
This is typically the size at which direct communication stops working. It's no coincidence that this number roughly corresponds to Dunbar's circle of best & good friends. Beyond that point, not only does communication become more difficult, but decisions about promotions, compensation, and hiring become less centralized. In organizations that are growing rapidly and hiring is (for lack of a better word) hectic, the need to be explicit about expectations is all the more important.
Finally, as the organization grows, hiring decisions are made by someone who may not even work directly with the founders, and the greater the distance between them, the more important it is to codify the career progression.Providing a sense of accomplishment or career progression.
From a psychological point of view, many professionals need a sense of career development; a progression in other words. This is confirmed by many studies over the years (as well as popular science books such as Daniel Pink’s Drive), where financial motivation is only part of the equation. This is a challenge in organizations with a flat engineering structure. Some organizations try to get around this by offering some sort of progression based solely on the length of time someone has been with the company. However, this provides a financial increase in compensation and not necessarily a sense of career advancement. It also penalizes the experience of people who've had diverse careers prior to joining the company. In reality, as the company grows, it becomes increasingly important to leverage diverse experience backgrounds and outside perspectives. This is difficult to do if your advancement is based solely on years with the company.Organization becomes more organized.
It is worth emphasizing that not every small organization (<50 engineers) is in a continuous growth mode. In fact, it's not necessary in every case, and there's no hard and fast rule that says it should be. I'd say that the perceived need for continuous growth has done as much harm as good over the past decade. Many companies can, in fact, run a solid business with a fixed number of employees (even if that is not what the media likes to tout). A company can mature in its processes even if it remains relatively small. In such cases, I’d argue that implementing a proper engineering progression is a useful thing in itself. Since an engineering progression usually has to start with a deeper understanding of the values and needs of the engineering organization, it is likely to force the organization to at least think about these issues. It can also lead to a non-trivial employer branding tool - allowing for a better employee-employer match but also improving how candidates pre-select themselves to apply to certain organizations (you can see good examples on progression.fyi ).
Given all this, let's think about how we can start putting together an engineering progression for your company.
Things to be clear on before building your engineering progression
First things first: You cannot design an effective engineering career framework without first thoroughly examining and understanding your organization. These are the key points you need to understand:
Values & culture of your organization
Every organization is different. Some keep the quality bar aspirationally high (they tend to focus on bugs first, for example). Others value getting things done quickly and iterating from there, while others emphasize business results, and still others focus on performance (either efficiency in resources or speed). With so many different types of companies and niches relying on software engineering, there are many approaches that can work. The tech department of a large European utility company will likely have a different culture and values than a mobile app startup or mid-sized consulting firm in the US fintech sector.
Whatever culture your organization has chosen (or rather, however, your organization has evolved over time - because you don’t always really choose culture), it’s absolutely essential that you take it into account and bake it into your engineering progression.
The nature of work
As with values & culture, here also, every organization is different. Much of the nature of your work comes from the organizational values & culture that have grown over the years. But there are also other factors to consider:
Product or professional services focus. This is perhaps the starkest difference you’ll see between organizations. In professional services firms (including consulting firms), engineers tend to be much more involved in client interactions. They are typically client-facing, often work hand-in-hand with client teams, and typically place more emphasis on communicating, courting, and nurturing clients, especially at higher levels of employee seniority.
Type of customer. One axis might be B2B vs. B2C. Another might be the type of customer segment (e.g. finance may leave a different footprint on daily work than the advertising industry).
Regulations/mission-critical systems. Working on peripheral systems (e.g. side LLM/RAG search module for social media platform) will likely require a different approach than working on core/mission-critical systems (e.g. software to run a nuclear plant). One might favor bleeding-edge experimentation, move-fast-and-break-things, the other might require a cautious approach, relying on boring-but-proven technology, extensive testing and validation, and shitloads of documentation.
Maturity of your business. The same company might value different things at different stages of its life (e.g. pre-market fit vs. post-market fit).
These are only a few contrasting examples. There are others to consider. The bottom line is that you need to understand the nature of your business and how it affects the engineering organization.
Most of these will move your organization toward different expectations of engineering work, so it is critical that you strike the right balance in your engineering progression. Ultimately, you want to have a progression that rewards (promotes) people who demonstrate attitudes that are aligned with the work your organization does. This leads us to the final point.
Existing issues & direction of the travel
Few organizations stand still, and even fewer stay relevant without constant evolution. As one wise Greek once said, "The only constant in life is change”. This is especially true in business. Change can be internal (the organization moves through its maturity stages) or external (the market shifts). The cause of the change doesn't matter - what matters is that your organization needs to adapt. This often means changing attitudes and behaviors. Even more disruptive is when existing attitudes aren’t the ones needed to move the needle in the future.
In extreme cases, this may mean letting go of some of the key people - yesterday's heroes. More typically, it means that a company-wide realignment is needed. And for any large organization, it is not enough for leaders to just talk about it. It has to be embedded in the organization in a systematic way (affecting 1-1s, promotions, and improvement plans). In other words, it has to be part of the engineering progression ladder.
Organizational debt is also a common cause of drift in engineering characteristics. A debt that an organization acquired, either by being casual about certain values (which may indicate poor leadership) or by growing significantly due to a rare market opportunity - an opportunity that had to be seized before it disappeared. In such cases, organizations may have deliberately relaxed their hiring standards or attention to some of their values. It is likely that the market opportunity will end at some point, and the organization is left with an organizational debt. Perhaps some people were green-lit to hire engineers who wouldn’t have been hired otherwise. Or maybe some people were promoted to certain levels of seniority who otherwise wouldn’t be. Or, worst of all, some people have been promoted to leadership positions who wouldn’t normally meet the criteria for such positions.
Eliminating debt in one or two quick moves is not something most organizations have the luxury of doing. Instead, they must readjust gradually and painfully. Again, engineering progression is your way of codifying such changes (e.g. modified or elevated expectations) for certain roles. This leaves the question of what to do with people who no longer meet the requirements for certain positions. There are a number of options, but I'll cover them in the article on implementing engineering progression in your organization.
Depending on how clearly these areas are defined in your organization, doing this groundwork may be as simple as summarizing what is already defined, or it may involve weeks or months of intense debate. The latter would probably be ineffective, but you need to at least cover some basics in these areas. It will not do you any good to skip this stage altogether.
Leadership Management vs Engineering
The topic of individual contributor and management pathways is so relevant and worthy of consideration that it must be thought through in advance. Especially since it requires thinking about how to design and incentivize your entire organization.
Companies typically divide engineering career growth into at least two broad categories: leadership vs. individual contribution. Personally, I think this is a false dichotomy for most companies. For many organizations - perhaps with the exception of the most prestigious big tech companies - a pure individual contributor career without a leadership aspect is very shallow. It usually ends somewhere around the senior engineer level. What happens beyond that depends on the nature of the company. The name is usually Staff or Expert Engineer (apart from acronyms like E6 that some companies use). However, the nature of the role can vary between companies and even between individuals. Will Larson names the following archetypes for Staff Engineers:
Tech Lead - leads the execution of an engineering team.
Architect - responsible for technical architectural direction.
Right Hand - assists senior leadership in navigating particularly complex problems/organizations.
Solver - expert in a particular domain or set of problems.
This is very close to some real-world examples. Meta is one such example. (Gergely Orosz covers this aspect of Meta extensively in his article "Inside Meta’s Engineering Culture"; it is behind a paywall, but it is definitely one of those rare online publications that are worth paying for).
The thing here is that out of these archetypes (or trajectories), most include an element of leadership. This is obviously true for Tech Lead or Right Hand, and perhaps less obvious for Architects. However, the days of architects with long gray beards descending from the heights of their ebony towers with intricate UML scrolls are pretty much over in most organizations. Today, the role of the architect is much more hands-on and collaborative and requires significant social and leadership skills. The leadership aspect is probably the least required for the Solver archetype. However, it's worth noting that in many organizations, all Senior+ roles are expected to pay a lot of attention to developing and mentoring others around them, which is an important part of most definitions of leadership.
The bottom line is that leadership, in one form or another, is required in both engineering career paths. So, my personal preference is to talk about management (or maybe even people management) instead of leadership. Some companies also recognize it as Manager vs. Maker (echoing the vibes of PG's famous essay: Maker’s schedule, Manager’s schedule). I like this distinction, too.
While the above point may be perceived as more philosophical, there is another important point regarding the ladder structure. It's now well understood that the move into management should not be a "promotion" in the classical sense, but rather a lateral move from a pure individual contributor role. Clearly, setting up the system to make management more lucrative tends to encourage good engineers who have neither the inclination nor the talent for people management to move in that direction. Ultimately, this is detrimental to both the individual's career and the organization as a whole, so it is better to remove this incentive as much as possible.
The elephant in the room, however, is that in most organizations (again, with the exception of big tech), the individual contributor path is shallower than the management path. This seems to be a fact of life for many companies - both from the perspective of organizational impact as well as paygrades (in short, VPs have more impact and are paid more than Staff or Principals). I’d argue that this - to a degree - actually makes sense for most organizations. You can see the differences illustrated in the Exhibit A below:
The diagram on the left is marked as questionable. It isn’t healthy to have a completely separate path for engineering management. Ideally, new Team Leads or Engineering Managers have some hands-on experience. Whether that experience branches out at the level of Mid or Senior is probably up for debate, and the needs of each individual organization, but making it parallel from the Junior level is likely to be suboptimal to the entire organization.
The diagram in the middle shows a workable scenario for most technical organizations:
It branches from a Senior individual contributor role (and therefore requires a solid understanding of the craft itself).
It allows for parallel development over a significant period of time (although it clearly shows that the Management role can go further).
The diagram on the right shows an anti-pattern (at least for the organization that claims to be a technical organization) - where the individual contributor’s path is very short, and the organization strongly incentivizes the movement from individual contributor to management. This incentive will ultimately be detrimental to the organization.
So, we can see that there are some key guidelines:
There should be a separation between pure engineering and management paths.
Management (at least at some level) shouldn't be the only way to advance an engineering career beyond senior positions.
You want to make sure that individual contributor and management paths are at least reasonably balanced.
That’s it, what’s next?
So, we’ve now explored both the organizational need and the groundwork to put in place before building your engineering career progression.
A quick recap. Keep the following in mind before you start working on your engineering progression:
Review communication and size to determine if your organization really needs an engineering progression.
Get clarity on your organization’s culture. You’ll want to bake this into the progression.
Consider the types of activities and ways of working that are used. Identify the one you most want to instill.
Assess the existing organizational issues (e.g. org debt) and the direction of the travel so you can build it in.
Make sure you balance individual contributors and management paths.
Once you've laid the groundwork, it's time to move on. Part 2 explores the artifacts, materials, and approaches to use in building your progression. Part 3 covers the process of rolling it out and optimizing it within the organization.
I’ll follow up with the next installments in the series in the upcoming weeks. In the meantime, don’t hesitate to comment or get in touch. You can find contact details on my About Me.