Where Engineers End Up

Often, I end up relating my own experiences in industry to other software engineers and managers to help them in their careers. At times, it’s someone on the same team at work, one of my direct or skip-level reports. I also tend to segue into it when I’m interviewing a candidate for a role, or when I’m the one getting interviewed, or when engaging with a mentor or mentee. And while our industry is indeed still young and evolving, we have converged into a set of well-trodden, informally standardized, common career paths as software developers.

This post spells them out at a high level:

• Independent, i.e., consulting
• Technical track, senior and principal engineer/architect
• People manager/director/VP

After the first couple of years of experience learning the ropes of professional software development, these branches reveal themselves as sub-specializations in our industry. The required skillsets overlap to a large degree, but each archetype necessitates expertise in additional, adjacent areas: salesmanship and client relationships; technical abstractions and systems knowledge; people and process management. Of course, the common engineering foundations allow people to switch between branches to some degree, and I’ve worked with some folks who have bounced between one engineering type to another across a series of jobs, quite seamlessly. Some even make it a point to move between each track multiple times, leveraging the inherent emphases in each role elsewhere.

Less apparent in this framework is that progress through each career ladder itself is not linear; the higher up in the ladder you get, the more each step is a discrete jump, in both duration and capability. So a software engineer may start their career like this1:

1. Entry-level developer, learning how to write software professionally for the first time
2. Mid-level developer, able to develop features mostly independently
3. Senior developer, mostly autonomous and able to in turn guide entry-leveled folks through their careers

Usually, the work independence required at the senior level—or whatever the equivalent title is elsewhere—is the prerequisite and foundation to pursue a set of complementary skills that result in one of these career paths. For instance, within the consultant track:

1. Consultant, executing on client projects
2. Senior consultant, helping define requirements with a client en route to execution
3. Principal consultant, helping lead engineering team to make technical decisions with respect to business needs

Likewise, something like this for senior technical individual contributors (ICs):

1. Staff developer, building systems/services
2. Principal developer, setting technical direction for the engineering team
3. Technical fellow, setting technical direction for the software industry

And for managers, whose career progression is most visible as most companies employ managers at these various levels:

1. Manager, leading a team
2. Director, leading managers and multiple teams
3. VP, leading an organization

Levels aside, what may not be completely obvious in the above descriptions is that progression up the ladder often requires an additional skillset that is less visible lower on the ladder; it’s usually not enough to stay in role long enough for a promotion. On the management track, I’ve written about what aspiring directors would need, above and beyond what they’ve already developed as line managers. The same dynamics exist further on that particular track, but also for the other career paths as their impact and areas of influence expand.

What this also means is that engineers can and do end up staying on parts of the ladder below the final level. At bigger companies, I’ve heard this be called terminal levels: simply, just the set of senior levels where it’s accepted that people can stay on that level permanently, without having to advance to the next one2. Sometimes this is due to not having the capabilities to execute at the next level, but there are plenty of folks who choose to not advance—understanding the shifting skillsets and responsibilities required, and opting out of some of the added stress and politics and salesmanship.

All of which is to say, that the eventual destination for engineers can be trifurcated into these 3 paths, but each path itself contains a spectrum of endpoints, all of which can serve as the zenith of a career in software development.