Am I off the mark? I suspect I may just not have been at enough orgs with a well developed career track, what the author here calls a 2-level technical track.
First, “state of the art”, with publications and recognition by professional societies. This is relatively easy to distinguish from a Senior, because the publications mount up.
Second, “state of the practice”, with extensive influence on major products/outcomes. The justification in this case usually comes in the form of testimonials like “X led the design and delivery of Y, and without him/her Z, for which Y is critical, would not have flown.”
This kind of person is harder to distinguish from a “solid Senior”. There is some resulting soreness among seniors who haven’t climbed to Principal. There’s a committee of Principals that gives recommendations but management makes the final call. Sometimes retention and organizational strategy are in play, besides just on-paper accomplishments.
Hiring directly into Principal does happen. The committee above makes a special out-of-cycle meeting to review such cases.
So, the difference between Senior and Principal can be in the visibility of the results and level of difficulty. The principal can still be the motor of a relatively small team - as small as 4 or 5 people - if the scope of the accomplishments is enough.
Specific numbers may be helpful. There are also two levels above Principal, Senior Research Scientist and (highest) Fellow. There are about 40 fellows in an org of 6000. There are about 250 principals. One of the fellows is Adam Steltzner, who designed the sky crane landing system for the Mars Curiosity lander.
I've seen many places that "only hire the best" or "only hire seniors" then end up with a bunch of engineers who dont mentor or force multiply but tend to just focus on what ever pice of a system they own.
I've also seen senior used only to justify a pay bracket as well.
Personally I agree that a senior or lead enginner needs to have these skills.
1. (In San Francisco) This can lead to reqs being open for way too long. My company had several roles open for upwards of a year and wouldn’t back off until I convinced my manager that we could train/mentor a less experienced hire to fill those reqs faster than we could fill them directly.
2. I think teaching a skill is important to the development of a skill. It forces you to distill what you do know, and articulate it in a way others can understand. This process is a huge boon to a lot of other traching-related soft skills as well.
3. (Personal opinion) I think we a professional, perhaps ethical, responsibility to improve the quality of our craft. I don’t think most places know how to write and maintain software well as an organization. The state of software as a profession will not improve until we raise the lowest common denominator and do a better job disseminating hard-earned lessons and best practices.
In my book, it's beneficial to stop thinking in titles, and start thinking like trades, in tasks. As a team you have to execute a number of incoming tasks. Tasks collide with a team member, and they can either handle the task or they can't. If they can't, they can ask a more experienced member to split up the task into more manageable pieces.
This has a powerful effect - you can usually add less experienced people to the system to get more throughput. As long as someone can split their own time consuming tasks into simpler tasks they can delegate, there is more throughout to be had.
And this in turn teaches people about the technology involved. Yes, you're just following instructions, but you should be picking up knowledge about configuration management, application management, databases, terraform, and so on along the way.
And with that, it's a lot easier to find people, because we can hire people directly from education. And I'm ethically fine with hiring people from education, because we're teaching them a broad set of valuable skills.
Sorry for the rant. I've been discussing the whole senior shortage for far too long.