Ask HN: What are the expectations of a principal engineer in your company? | Hacker News Reader

Ask HN: What are the expectations of a principal engineer in your company?

104 pointsdhab21 comments

Because the role varies across companies, and could be vastly different between mainly tech vs non-tech companies, could you provide the industry the company operates in as well?

View on HN

This varies wildly by company, and dynamics of the org/team. The best summary I’ve found is the staff/principal engineer archetypes article[1] by Will Larson. He identified 4 archetypes: Team Leader, Architect, Solver and Right Hand. This categorisation broadly matches my own observations & experience at Uber - even if the formal, internal company definition does not put these as such.

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.

[1] https://lethain.com/staff-engineer-archetypes/

[2] https://staffeng.com/stories

Great links; thank you.

In my corner of Amazon, PEs are the technical peer to high-level people/program managers. The people/project managers are there to make sure that human work proceeds according to plan and have small understanding or concern for nitty gritty technical architecture. In comparison, the PEs have small understanding of the nitty gritty of the human labor management and are there to drive design reviews and act as kind of a veto board for architectural decisions.

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.

You can be more specific using the role guidelines.

Principal Engineers work on projects that span the entire organisation, usually addressing cross cutting concerns of several teams. They advice Directors and VPs on strategical, mid/long term technical decisions. They set the standards of quality for the org and engage with the community at large. They work on extremely complex and highly ambiguous problems.

In a chat with a PE he told me that this is the first role where he wasn't told what to do. In that sense, PEs often proactively look for problems to solve or new initiatives that will have a large positive impact in the company, rather than work in items assigned by others.

Lastly PEs are expected to have strong communication and interpersonal skills. They should be a force multiplier, align teams and handle scalations.

Thanks, that is mind expanding. I'm young in my career and I don't think I've looked at the role guidelines for any role other than my own.

I like this overview of Mozilla's engineering track: https://twitter.com/Gankra_/status/1046438955439271936/photo...

Don't worry so much about the role, just make sure you're working under/with someone who'll get the best out of you.

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)

Are you a headhunter? And if so, would you put your contact info here? (Don't feel bad. You didn't put yourself forward or advertise. I asked.)

I'm not looking at the moment. But I keep a file of headhunters for when I am looking...

Nope, built a leading recruiting platform. You probably have a profile already.

At the large companies I've worked for, Principal Engineers were more or less strong engineers with the management skills of a Director or VP. That is: strong people skills, project management, program management, leading teams, high business knowledge, strategy, etc. If necessary, they could easily go in and lead an organization of 30-200 people. But they choose to focus on a little bit more engineering/architecture instead of people.

As such there were only about 1 per 2000 employees, and they were always people who are actually Senior, like 20+ years work experience.

This will vary by company and what they value. I've worked at LinkedIn and Amazon. At both, the common thread is generally that PE's have impact across several teams. Coding is often minimal and typically focused on highly complex / mission critical code or prototyping. Majority of time is spent reviewing / developing architecture. The problems and solutions they tackle become more ambiguous. In many cases, PE's are the ones identifying problems proactively. Often at smaller companies, this role may be more code heavy.

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/

Depends if you mean “tech” companies or “traditional” companies. Principal engineers at traditional companies is someone who has lived and breathed the product for 10-15+ years. Principal engineers at a tech company is someone who has a vision for a technology and understands what it’ll take to gather a team to execute on it.

Here (noris.de), a principal engineer is expected to:

* 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).

I meant to write "publications and/or public speaking"

I'm not sure we have that title at my company. Our senior program technical leads might fit there. Theres really no set criteria - it's just if the people above you think you deserve it (kind of like any position). I do remember HR put out some example competencies. The only one I remember around that level was that a person could demonstrate that level of knowledge by having a book professionally published on a pertainate technology. Needless to say, there are very few people at my company in that level.

In my experience they walk around all projects making the odd comment. They are across all projects, but don’t do a lot. If there are issues between projects, they will help solve them.

What I hope for:

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

In my company there are several types of Principal Engineers.

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.

Can you please expand on what you mean by "Orchestration" ?

sounds like getting the right things to happen in the right order and JIT fit schedule

At my company, the PE is simply the Team Leader, who does:

* communicate with clients * does the architecture design * does the API stub implementation * does code reviews * provides technical leadership / last word on a choice

Reply on news.ycombinator.com