Recently I’ve come across a couple of articles that go into what higher levels of software engineers do. Namely, the levels beyond Senior Software Engineer1—Staff and eventually Principal Software Engineering positions—are fairly common within engineering organizations once a career ladder has been formalized, and are meant to be the culmination of its technical seniority. Folks have chimed in on what their experiences have been like as a principal engineer, and opined on how the role isn’t necessarily a linear expansion of technical complexity from previous rungs on the engineering career ladder. That latter article got a strong negative reaction in its associated Hacker News thread, as engineers complain that it just sounds like stingy management wanting more work out of its senior technical staff.
As someone who has worked with, managed, and coached engineers at these levels, these descriptions resonate. There are certainly principal engineers who reach that level based primarily on technical merit2, but I’d say that most make the claim based more on their breadth of impact, and often beyond the confines of the software engineering organization.
This discussion reminds me of one of my favorite definitions of career seniority: the ability to find and implement solutions to increasingly less defined problems.
Unpacking that statement a little bit, the idea is that job levels represent the scope of problem that employee should be able to handle, and the higher the level, the bigger the scope—and the solution likely more complex. For interns and entry-level engineers, the problems are clearly laid out in technical terms, e.g., build this feature. As the levels rise, more senior engineers are generally expected to be more autonomous technically and be able to implement systems and architectures to achieve a business objective set by their product counterparts or managers. Even more senior still—getting into Staff and Principal levels—are engineers who can take business requirements and figure out how to achieve them by technical means, while leveraging other engineers and teams to help with its implementation.
Another way to frame this definition is: how much does someone else have to figure out, stemming ultimately from a business goal, for an engineer to be effective? Engineering managers often have to break down projects into tasks for their junior engineers, but can expect their senior folks to execute on self-defined project plans. Again, the more senior an engineer’s capabilities, the less their manager has to explicitly scope, trusting that the engineer can figure things out for themselves.
Note that with all of this, there’s recognition that not everyone is a great fit to take on the wide scope that a principal engineer typically claims, and that’s perfectly fine. Most career ladders have terminal levels—rungs on the ladder that are good stopping points for individuals who don’t have a clear path to continue ascension. Principal engineers are pretty rare, as it often requires development of some of the same soft skills and multi-functional influence that goes into management, and those who are not interested in cultivating that skillset will find themselves stabilizing slightly below. The scope of project work can also be a limiting factor; teams typically only have a handful of company-wide problems, with potential technical solutions, at any given time.
It can be a bit disheartening to hear that higher rungs of engineering career ladders can end up trading further technical depth for cross-functional breadth. But at high enough levels of an organization, there are fewer managers and translators of abstract needs into technological solutions, and those who thrive at those altitudes understand how software has become such a powerful industry: by creating business value.
Which, despite title creep and associated skepticism, has value in most career ladders beyond simple years of experience.↩
I was lucky enough to have worked with Mike Bostock, of D3 fame, in the early days of Square.↩
