This comes after he interviewed close to a dozen staff/principal engineers at various companies of the likes of Stripe, Mailchimp, Fastly, Slack, Split and others. The stories/interviews[2] are worth reading to get a better picture of exactly what staff/principal looks at each of these companies.
PEs rarely provide new ideas in design reviews (our product teams don't need help with that) but often will strike things down or modify existing ideas to fit in with other products, for business reasons, or perhaps because their human management counterpart doesn't like the idea.
Alongside, they usually have some variety of R&D style side projects that they pursue according to their interests/specialties.
Having a good manager is the single most important factor to success and happiness at work.
(I've placed over 10k developers at 100s of companies, mostly startups)
As such there were only about 1 per 2000 employees, and they were always people who are actually Senior, like 20+ years work experience.
I'm co-founder of Levels.fyi - we think of this a lot and have developed a 'Standard' leveling based on what we've observed the roles and responsibilities are across many companies. This is the description we have for Principal Engineer:
Impact spans across organizations within the company. Entrusted with business-critical projects and for setting technical vision for an org or multiple orgs. Responsible for reviewing and providing feedback on technical designs across an org. Little to no day-to-day coding. Role depends highly on organizational / company needs and becomes loosely defined. Expected to operate fully autonomously.
You can see descriptions for other levels at: https://www.levels.fyi/standard/
* do some publications and/or publications in their field of expertise
* provide technical leadership (input on technology decisions, some architecture support, help write guidelines etc.)
* be part of the escalation path if problems cannot be solved otherwise
* help others in the company level up with their skills (at least as far as they are interested)
Here, principals are actively discouraged from becoming team leads (tech and people leadership are separate paths, which suits me quite well).
Someone with plenty of experience who chooses to invest in interesting people problems and tries to coordinate towards a future that is shared across silos
What I usually expect:
Someone with plenty of experience who chooses to invest in interesting software problems. Said investment may or may not ever propogate out in a tangible sense, being more akin to an R&D project or something.
---
None of the above is based on what the role is meant to be but what it "feels" like having observed a few people with that title
I would say they usually have 3 role dimensions and each principal has a different percentage of each: 1) Architecture 2) Orchestration 3) Direct Problem solving
Some are 10/0/90, others are 70/30/0, others are almost like Project Managers, something like 10/90/0.
My personal preferred for them style is something like 40/10/50, but usual expectations are more like 40/50/10, which very few are.
* communicate with clients * does the architecture design * does the API stub implementation * does code reviews * provides technical leadership / last word on a choice