What does a Principal Software Engineer do?

https://blog.devgenius.io/what-does-a-principal-engineer-do-2e6af918ff28?gi=df8d9ead7c29

235 164 5 years ago

blog.devgenius.io

When my partner and I first meet we were both senior engineers at larger SF tech companies. Three years later she is a principle engineer and I stayed a senior engineer. She and I agree that everything past a senior engineer is political. She is much better and handling the complex social dynamics of the management class. It's kinda a game of finding the least common denominator that works best by not pissing off people and making everyone maximally happy. That often means the decisions you make you know are not the most optimal, but the most politically optimal. Just our observations.

jason-phillips2• 5 years ago

That often means the decisions you make you know are not the most optimal, but the most politically optimal.

Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.

As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.

That process is almost completely independent from meat-space concerns, aside from the requisite UX design.

nicoburns• 5 years ago

As a lead or principle, I describe what I do as being a "fire-and-forget resource". I build everything myself and don't require supervision. I will deliver regardless and am also able to justify my decisions. People seem to be happy so far.

Terminology is subjective of course, but:

I would also expect the above from a "senior" developer.

I would expect a "lead" developer to additionally be involved in leading a team and coordinating work within that team. (either from a project, people or tech perspective, or all/both).

I would expect a "principle" developer to be working at a higher level coordinating work between multiple teams and making architectural decisions that cut across the whole org or a large subsection of it at a larger company.

ignoramous• 5 years ago

Not intended to quibble, but to me that smacks of the dreaded "mid-level management" tier.

Reminds me of the classic: https://www.ribbonfarm.com/the-gervais-principle/

phekunde• 5 years ago

She and I agree that everything past a senior engineer is political. She is much better and handling the complex social dynamics of the management class. It's kinda a game of finding the least common denominator that works best by not pissing off people and making everyone maximally happy. That often means the decisions you make you know are not the most optimal, but the most politically optimal.

A colleague of mine at previous company once described all this in two words "managing expectations" :)

lumost• 5 years ago

It goes beyond managing expectations. What goals do you take? What goals do you ouah back against? How do you do this? How do you route around cranky groups that get nothing done?

willob33• 5 years ago

Life is a human communication game first, as the “best system” we’ve socially engineered is externalized support towards common goals. It’s not science or engineering; it’s sympatico.

The problems we’re solving at these jobs (I reserve work for its meaning in physical systems, jobs/career for you know), are ostensibly people problems. So the decisions I make are optimized for that. I don’t call it politically optimal, but optimal, because that’s it; that’s THE game of life.

It’s subtle language emphasis maybe, but I used to visualize my thoughts as a text stream and “rewrite” constructs I did not appreciate in the moment. Redefining ideas like “optimal” to be human first behavior. Ideas like “optimal technical solution” are boxed away for when I’m working.

It helped me understand managements drive, to have folks doing useful things, but also made me question how useful much of this is except as busy work.

vp89892• 5 years ago

Nice post, I think "software engineering" is slowly becoming yet another "bullshit job".

dkarl4• 5 years ago

The political part is so important, and such a departure from solving technical problems. I feel like nothing in my life has prepared me for it, or maybe I just ignored everything that would have.

I think there's a continuum of political savvy, though, where most developers have some level of it. For example, if one of your developers creates a new service using a technology that is new to the codebase, and half of the senior developers say, "Ugh! I'm not touching that. It's just <developer's name> showing off his big brain. I'm not wasting my time figuring out that unnecessary academic crap," you can understand how that was a failure even if a purely technical evaluation concluded that the learning curve was reasonable and the benefits outweighed the effort required. Before committing to the technology, it was necessary to introduce the idea in a way that got the senior devs to buy in, and if you can't accomplish that, you can't use the technology at all, because it's going to create morale and social problems as well a creating an isolated service that few people will work on.

That's a basic level of political savvy I think most people can relate to, so, if you can understand that much, you have a base to build on.

WastingMyTime89• 5 years ago

In my experience the issue experimented technical contributors have with politics is not savviness, it's managing frustration. Unless you enjoy playing politics for politics sake and value the grind of improving your position in the system, the mix of ineffective compromises and letting things rot because the blame will go the right way tends to wear you down in the long run.

joshdev• 5 years ago

Another way to look at it is you are expected to include business factors into your decision making. Sometimes the most optimal engineering solution is not the most optimal business solution. Politics can definitely be a factor, but being able explain clearly why doing something helps the business can be a big part of making the jump to more senior roles.

baq• 5 years ago

so, making it possible to ship at least the org chart?

names_are_hard• 5 years ago

She and I agree that everything past a senior engineer is political

At the big tech company I work at, we're often told that even even senior is primarily a non-technical designation. Technical expertise and independence is expected of the level below senior, and in order to make the jump to senior you need to demonstrate leadership and other for skills - influencing others, project management, coordinating between teams, etc. Principal is a level above that that is kind of the same but more.

All this to say: every company is different.

etimberg• 5 years ago

I'd definitely recommend https://staffeng.com/ for anyone who's making the transition from senior to staff+. I found it invaluable when I made that transition.

dkarl4• 5 years ago

Always keep in mind that sometimes the "principal engineer" title is just a company's only way of hiring a senior engineer because their pay bands are so far below market rate. Don't let a description of a Google principal engineer scare you away from inquiring and applying for principal engineer positions at other companies.

Source: have been that person.

digitalsushi• 5 years ago

I'm stuck inside a 5000 person IT company hiding inside a much larger consumer product company, and 3/5 of us are all 'principal' engineers by title. This includes a bevy of old timers who exist just to run a few ancient shell scripts and otherwise keep a chair warm. Although they are shrinking quickly, they still vastly outnumber us coming in from the software industry. There is no title above principal here; we are hired into principal and that's it until we invariably get bored or stressed out and leave.

We have other titles above principal, which I wont name here because you could figure out where I work, but suffice, those titles are gated and only promotable by multiple director consensus. It keeps their numbers very, very low. My department wont mint a new one, but only hire outsiders already at the title.

yupyup54133• 5 years ago

My department wont mint a new one, but only hire outsiders already at the title.

Yikes, that sucks.

PragmaticPulp2• 5 years ago

Or more generally: Job titles aren’t portable between companies in the tech industry. Don’t assume that they mean the same thing at every company. Don’t assume a company is underpaying people just because they’re giving out Principal Software Engineer titles. Principal Software Engineer at one company could just be the equivalent of Senior Software Engineer II at another company.

On the hiring side, everyone knows that titles only indicate relative seniority within a company. Interviewers must actually interview candidates to determine what their role was, how experienced they are, and other factors.

It can be a warning flag, however, if a company is giving titles like “Principal Staff Software Architect” to someone who is clearly junior enough that they would require a lot of mentoring and guidance if they were hired. It’s common that candidates are resistant to downleveling their titles when changing jobs, so handing out enormously inflated titles is one way companies try to trap junior employees in their companies. At least until they realize that nobody cares about their inflated titles and they still have to pass the same tech interviews as everyone else.

pc863• 5 years ago

As someone whose first job title was "Assistant Director of IT," and who did nothing but write really bad PHP for a couple hours every day, this tracks with my experience. It also made interviewing harder because if you get a resume from someone with one job they've had for two years, and that job is Assistant Director, you're probably - rightfully - trashing that resume. I eventually learned to just change the title but then explain on first contact that my actual title was different, it just didn't bear any relation to what I was actually doing.

MillenialMan2• 5 years ago

The vast majority of titles in tech confer more prestige than deserved, because there's no downside to a company handing them out like candy. I don't look at it as a portability issue, the incentive isn't to be accurate to begin with. Inflated seniority is just a perk they can offer that doesn't cost them any money, so everyone offers it. Titles across the industry are meaningless unless you're calibrated to that company's levels.

nowherebeen2• 5 years ago

This reminds of a story I encountered in finance where everyone in the department got a bump in title as their bonus. I asked one what was difference in their role: nothing. Since everyone got bumped, everyone's role stayed the same. This was during the financial crisis and was the bank's (well known) cheap ass way to get away without paying a monetary bonus.

chrisseaton• 5 years ago

My very first job was 'senior'.

throwarayes2• 5 years ago

Title inflation is real.

2 years ago I was hired as Staff with pretty high bar to clear.

This year I know a team where all the seniors complain they’re not Staff, and now half the team are Staff engs.

Konnstann• 5 years ago

I was under the impression that Staff just meant you have some sort of leadership role, as opposed to just being an individual contributor. Is that not the case?

amznbyebyebye4• 5 years ago

Yes because everyone is resigning. L+1 today is easily what L was 2-3 years ago.

unbanned• 5 years ago

Possibly they're just better than you were 2 years ago? Tech education moves as quickly as tech itself

idunno246• 5 years ago

i had a job where i was the first staff, but when they started promoting everyone to staff cause every senior wanted a promotion, they had to create new levels of staff to differentiate

coldcode• 5 years ago

Exactly it's just a job description and name. In my last job our org rarely promoted anyone technical (only managers and above) so almost everyone was either Lead Software Engineer, or Senior Software Engineer. Other orgs promoted everyone to the max no matter what they did - I knew a group where the lead was a Director but coded, and all of his reports where Principals; yet they did simpler work than anyone in our org did.

thrwawayhack_• 5 years ago

My friend is a "Vice President of Engineering" at a fintech company. It's the lowest rung on their engineering ladder.

andi999• 5 years ago

Probably because their engineering team has a bus factor of two?

vultour• 5 years ago

Vice Presidents at large financial institutions are a joke. Coming from any other industry you'd think it's some sort of executive position. Nope, just a random senior software engineer 8 levels down on the corporate ladder. To be fair the first 6 levels (all the way to the CEO) are all "Managing Directors".

opportune• 5 years ago

Yes, this. Principal means something vastly different between Microsoft and Google (where at Microsoft it means “Staff”). I even got recruiting emails from some not-popular SV firms for “Principal software engineer” when I had 3 years of experience.

sumtechguy• 5 years ago

One company out there 'staff' is entry level. Whereas in all the companies I worked at 'staff' was a very prized title to have. Another company I worked at my title was basically just some random bits of roman numerals and something that sounded vaguely like a engineer. I usually just put sr software engineer/developer depending on the company and role.

destitude• 5 years ago

I've seen this exactly. Someone at my former company was a Principal engineer but when they left to go to Netflix they were then just a Sr. Engineer. They definitely were not Principal engineer material so think it was all to appease the pay-band gods.

cipheredStones• 5 years ago

Netflix doesn't have SWE titles other than "Senior" and "New Grad", so this means nothing about your former colleague.

eadmund2• 5 years ago

Are there many folks who care more for a title than compensation? Granted, a higher title might help one win more compensation when negotiating one's next job, but fundamentally one must back that up. I mean, you could hire me as a principal engineer for $100,000 today and I could hope I can get hired as a distinguished engineer for $800,000 next year, but somehow I don't think anyone with that much money to spend is going to make that terrible of a mistake.

Right? Because if not, I need to have a discussion about titles!

dkarl4• 5 years ago

I'm not aware of companies caring what your current or last job title is when they hire you, and for that reason I don't think most developers care what title they get when taking a new job. The titles are really only important internally, if companies have a culture of respecting certain titles, or when they have strict salary bands for each job title that are matched to some supposed industry standard. Salary bands are a blanket corporate policy that many companies use to enforce a very crude form of hiring discipline, and over time they can get really out of touch with reality (always on the low side, of course.) In the last couple of years I've spoken with several companies that limit the salary of "senior" developers to $160k or even less. Some of these are stodgy old companies like you would expect, but some are also midwestern companies that are switching to a "remote first" model but still have salary bands calibrated to their low-COL city of origin.

Managers deal with unrealistic salary bands via title inflation when they can, but sometimes their hands are tied. I joined a team that did have the freedom to use title inflation and ended up with a principal title in a team with more principal engineers than non-principal engineers.

darthrupert• 5 years ago

Same things as senior but more. Source: I've been one.

Senior and principal prefixes are there to provide respect in orgs that rely on titles for respect (possibly a sign of toxicity), or a way to explain to HR why someone's salary is higher.

lawn• 5 years ago

or a way to explain to HR why someone's salary is higher.

This is exactly how my company motivated it when I asked for a higher salary.

lanstin• 5 years ago

A bit of a problem tho for most orgs. If you can only pay more money by promoting people, the job market is suddenly so hot people will leave if you don’t get them more money, but it is a bit silly to just promote every one, and there is a useful distinction to be had between people whose work is mostly heads down coding vs people whose work is also mentoring and communicating technical views to larger numbers of people. The words around promotions usually seem to be about expanding influence and affecting larger numbers of coworkers. That is useful, and fun if you like it, but the purely awesome coders might also need big raises when job market spikes.

malermeister2• 5 years ago

Same thing as Senior, but better at office politics. That's what every title above Senior comes down to.

anononaut• 5 years ago

Is that unreasonable?

malermeister2• 5 years ago

Depends on your perspective I suppose. There's definitely an advantage to being able to play that game, but if you overdo it it tends to be to the detriment of the team or the company culture.

agentultra• 5 years ago

Try reading: https://staffeng.com/about/

tldr; it varies from company to company.

In my experience the more senior you get the more like an organizational therapist you are expected to become. Instead of writing code you're helping engineering teams and executives communicate, fixing communication silos, writing specifications and requirements, reviewing progress on large multi-team features, and generally trying to move the ball on big-picture projects that span multiple feature teams/code-bases/etc.

This kind of work needs high-functioning social skills, excellent written communication skills, an ability to understand a large problem domain and all of the organizational levers you need to move to get it done. You'll also need to be able to tolerate long feedback cycles as the projects you take on will probably take months to see the light of day and you won't be writing the software yourself most of the time. At most I've seen engineers at this level write prototypes or reference implementations. Some enjoy it while others quickly learn that staying at a senior level was probably better for them.

almog• 5 years ago

While I haven't read it, I listened to Will Larson's interview on SEDaily (before the show em... changed). It was quite interesting and it was in my reading list since then.

The interview itself is here: https://softwareengineeringdaily.com/2020/10/29/staff-engine...

BossingAround• 5 years ago

I feel like the summary of the whole article could be "important and/or impactful stuff". Saved you a click and a "you have 1 Medium article left" banner.

The definition bullets will probably be highly dependent on the company and while companies will likely copy those, they are likely not even transferable within a company, let alone across different companies.

For example, within company A, Mike is a manager that is a perfectionist leading a Java EE mid-sized application. Mike is hard on himself and is hard on his people. His people are probably underpaid, and that's how he likes it. Getting to a senior level is difficult. Getting above is political.

Within company A, Janet is a manager leading a relatively recent PaaS offering. She likes nimble, agile teams. She rewards quick thinking, wants her team to be satisfied, and gives her team yearly stock options because she doesn't want anyone to leave. Getting to a senior level is fairly manage-able after 1 to 2 years, provided one is viewed as a senior. Getting above is doable, provided one has peer support.

Now, company B is a consulting company that wants to offer "senior" engineers for $1000+/hour. They never hire anyone with the title "junior" (not even fresh grads) and promote practically everyone after 8-16 months to a senior title. Principal level is then another 6-8 months away, but they have very few of those due to insane attrition rates by that point.

clavalle• 5 years ago

Beyond just titles for pay reasons:

Principal Software Engineers are essentially the Engineer Owner of a solution or closely related set of solutions.

They're expected to know the ins and outs of the solution both at a business level ('Hey, Principal, how much would it cost and how long would it take to do 'x'?' -- Some Sales Person), and have responsibility for the solution's engineering ('Two months? Great! See you at the February demo for the users group!' -- Some Sales Person), and be able to solve the more difficult engineering issues that crop up ('The app you promised to integrate with by February only uses SOAP and consists of around 14,000 on-prem installs...I graduated after the year 2000 so I'm not sure how SOAP works, can you walk me through this 'wizdal' thing?' -- Some Senior Engineer that you asked to look into the new project).

rurban• 5 years ago

The principal is the one with bus factor 1

rgrmrts2• 5 years ago

The pay for principal SWE can get up to $1m+ (at large sv tech companies, or even at startups assuming their equity pans out).

That $800k number is more accurate for staff/senior staff.

rgrmrts2• 5 years ago

Also, I want to add a more positive anecdote to accompany some of the more negative ideas of principal engineers. I’m a senior software engineer (L5 in FAANG terms) and I’ve worked with a handful of principal engineers who have all been incredible colleagues.

All the principal engineers I have worked with have been humble and ego-less engineers. There’s this notion that they just write docs but they’re invaluable code/spec/design reviewers, they have taken on major refactors to tackle tech debt that just lingered for years, and have generally unblocked me on so many occasions. The strongest principal engineers have never taken credit for massive projects they have orchestrated but “everyone knows” they’re valuable.

It takes a lot of skill, and I’ve found they switch between the “archetypes” effortlessly. Beyond that, they’ve helped me grow in my career and find impactful projects that look good on perf reviews. In my mind, the good ones are definitely worth their cost.

amznbyebyebye4• 5 years ago

Principal software engineer: the old grumpy guy who berates and borderline verbally abuses new/junior engineers and jeopardizes mental health across the org.

activistee2• 5 years ago

As a Software Engineer, I consider it my obligation to ensure that people across an organization understand that it is not normal and not acceptable for a Software Engineer to be rude, angry, grumpy or dismissive. The genius mystique must be defeated. I behave as an activist employee: if there's a nerd bringing shame upon nerd kind, I make sure to tackle it head-on. I implore everyone to be activist employees. A nerd who berates someone? Your new mission is to get them out of the organization, and teach everyone who has been in the blast-radius of their bullshit that they were not a god, that their behavior _was not worth it_ no matter how good their code was. You'll change lives for the better, more so than your code ever will.

amznbyebyebye4• 5 years ago

Thank you for your service!! We need more of you. The problem is where I work these toxic characters are supported and enabled by equally toxic leadership and executives.

pc863• 5 years ago

Wrong, I've met plenty of seniors who fit that bill as well. :)

amznbyebyebye4• 5 years ago

No one said it was an exclusive property of principals alone :)

ryanianian2• 5 years ago

You can form a pithy but unnuanced and unhelpful caricature about every level.

Junior software engineer: arrogant, self-entitled child who thinks they know everything but doesn't even know what they don't know but insists that their ideas are better, creating a people-hostile minefield across the org.

herbturbo2• 5 years ago

Who want to know when they are being promoted in every review.

hu3• 5 years ago

I'm sorry that was your experience.

I have met some amazing people that were tech leads during my career. Some of them titled as principal software engineers.

Sometimes it can be hard to find friendly and kind teams. But they do exist. I promise.

kstrauser2• 5 years ago

I'd fire that person immediately. No one's so valuable that they get to poison the work environment.

fatnoah• 5 years ago

I've been a "Principal Engineer" at a large software company and I feel like I embodied each of those archetypes at various points. At various points I was neck deep in critical code, doing the dog and pony show at the executive level, coordinating with other engineering teams and several product managers, and generally doing all of things required to keep pushing something forward.

My relationship with my manager was much more of a peer partnership than manager/IC. I let my manager know what I was up to, progress on things, and any challenges that needed help. The latter bucket was usually empty, but occasionally some cross-org priorities need to be clarified and sorted out.

As others have noted, it really varies between companies, but the main difference between Senior/Staff and Principal is that the latter can be a much more "people" oriented role. You still own and carry the technical vision, but you increasingly interact with non-technical people to enable it and to make it happen.

vishnugupta2• 5 years ago

My relationship with my manager was much more of a peer partnership than manager/IC.

To all the managers out there please make note of the above. Do yourself a favour and please give senior engineers enough autonomy and freedom.

At my previous place I managed a senior engineer and made it amply clear to him that we are peers. Between us my job was to handle all the bureaucracy (including scheduling meetings, finding meeting rooms etc.,) and his was to be the team's tech lead.

herbturbo2• 5 years ago

I am currently a principal engineer and have exactly the work life you described. Maybe in a bigger company the Principal is split from those archetypes but in my smallish team (within a large global org) I am the Principal because I do all of those things.

rwmj• 5 years ago

PSEs are really earning $800k per year?

ryanianian2• 5 years ago

At faang-level tech companies. Total comp. Base is likely 30% of that. By the time someone reaches principal they've likely been at the company for 5+ years which for many is long enough for equity to snowball such that previous years' grants are vesting at 5x their grant valuation. (Or if they're hired on as principal they're likely leaving similar comp on the table so hiring managers have to make up for it, usually with future-vesting equity of similar current valuations.)

vishnugupta2• 5 years ago

At FAANG and similar companies yes. Note that it's total comp which includes RSUs. At senior levels RSU refresher is quite high and it all adds up.

marstall• 5 years ago

nope.

Kranar• 5 years ago

In total compensation yes. That means it usually includes stock and at that level about 50-60% of your compensation will be stock.

Look at https://www.levels.fyi to compare companies, but yes overall 800k to over 1 million is quite common for a Principal and typically it requires about 10-15 years of experience.

makach• 5 years ago

He makes the first mistakes.

dnndev• 5 years ago

freedom to work on whatever they want!

baby• 5 years ago

800k TC for a 7? That seems low

hackingforfun• 5 years ago

For anyone who is a Principal Engineer at a FAANG, what do you do day to day?

I'm a Principal Engineer, not at a FAANG, and that mostly means i'm an expert at what I do and know the product inside and out, and I spend a good amount of time coding. I do also help others, answer questions, and deal with complex problems. I'd say I do 80% coding and 20% meetings / other things.

I interviewed somewhere else and they wanted me to do 50% coding and 50% meetings / other things. Was a bit surprised, since i'd personally rather code and keep my skills up.

My take is companies should have their top engineers spending a sigificant amount of time coding, or at least architecting, but I could imagine, and have read, that at FAANG sized companies it becomes more political? Also with so many employees I guess in theory the idea is to have Principals spend more time leveling up the rest of their workforce? In practice does that happen?

hideo3• 5 years ago

It depends.

On the whole my responsibilities are a mix of things:

1. Technical strategy - primarily writing strategy docs and discussing with other tech PEs. Usually precursor to architecture.

2. Business Strategy - reviews with non tech staff and leadership (across the org) about what the business needs are, where we see the future going. Often takes the form of reviewing other peoples documents or contributing sections to those

3. Product design reviews - reviewing CX/UX documentation

4. Architecture - Creating architecture documents - lots of text and boxes and lines. Several rounds of reviews. Usually precursor to coding or reading other people's code.

5. Coding - takes the form of staring at various IDEs and scratching my head.

6. Reading other people's code - same as above. Also include code reviews.

7. Operations - On call stuff. Usually where all the architecture stuff falls apart :-)

8. Mentorship - structured 1:1s, feedback, etc

9. Prototyping and demos

I spend probably 90% of my time doing the items above. The mix among these items varies but I consider all of it my work. For the rest I sometimes get pulled into the items below that are not officially my responsibilities

- Conferences and public speaking - I could, but choose not to

- Project tracking and reporting

- Managing people's careers directly

- Funding decisions

My work is rarely political depending on how you define politics. To me politics is about "who gets the cool stuff" so mostly funding decisions. I do get pulled in occasionally to sort out "who should build this" discussions but they are usually good faith discussions trying to align expertise and charters before funding decisions are made. Biz and tech strategy does involve consensus building but I suspect the Real Politics™ happen behind the scenes at higher levels.

Apofis3• 5 years ago

I'm in love with #9. Looks like you have a good handle on the situation. The rest proves you're going places.

sciurus2• 5 years ago

You might find https://staffeng.com/guides/what-do-staff-engineers-actually... interesting.

topkai22• 5 years ago

Staff/principal level here. I accelerate my team. Sometimes that involves writing code, sometimes that involves teaching/mentoring others, sometimes it means improving our tools and processes, sometimes it involves hammer out our architecture and security approach, and sometimes it involves figuring out what baroque process I need to go through in order to get legal’s approval to launch our new product. I make sure almost all of what I do is well documented and communicated to the rest of my team.

The three rough metrics I’ve heard for how staff/principals are evaluated are “creating clarity”, “impact”, and “leadership.” Those metrics are all very difficult to perform on if I were focused on my code related output as an individual, although there are people who make and achieve within that level in my company who do more straight up coding then I do. The important thing is good judgement on where to spend your time to have the most impact.

If you wanted me to put numbers on it, I’d say my time is probably 25% coding, 20% meetings, 20% working on infrastructure and tools, 20% documenting/communicating, and 15% mentoring/recruiting.

jdc0589• 5 years ago

this is a great summary, and pretty much exactly reflects my role. My job is to help other engineers in our org be as productive as possible. That always means trying to include other people in what I'm doing from a mentor/career-development perspective, but otherwise follows your % splits pretty well.

The bits that people don't talk about frequently are things like "what do you actually do in the 20% of the time you are coding?" It's usually things like performance analyses and optimizations, solving misc tech debt that I have the flexibility to work on since my time isn't allocated to project teams/squads, architecture and PoC work for new capabilities we think we will need, and honestly sometimes its just picking up a couple super low level tasks anyone could do because keeping team members focused on other things is what's most important.

At least in my org the common theme is almost always "there's a hard problem over there, go help them fix it'.

Source: principal engineer for a couple years, senior for 6 or 7 years before that. Not at a FAANG, but in a ~350 person technology org at a company with nationwide offices and consumer product presence in the USA.

decodebytes• 5 years ago

I am happy to be open here if it helps others. I am not with a FAANG, I am employed by Red Hat. My title is Senior Principal Software Engineer. At Red Hat it goes Software Engineer -> Senior Software Engineer -> Principal Software Engineer -> Senior Principal Software Engineer -> Distinguished Engineer.

My main duties are that I lead a team of 7 engineers and we all work on open source security projects.

My day is a mix of half coding / half meetings. I am UK based, so my mornings are nice and free (while the US sleeps) and then around 2pm I have a large chunk of meetings. The meetings are mostly with my team, senior management, and open source community meetings.

For me being a Principal is a much more than just coding prowess. You also need good 'soft skills'. You need to mentor engineers and think about their growth. Make sure they are challenged enough to grow, but not so much that they end up stressed and out of kilt. You need to be able to communicate with not just other software engineers, but also product managers, directly with customers and many other verticals within a business.

nickm12• 5 years ago

I'm a staff/principal at a FAANG. My experience agrees with the other answers here that "it depends"—specifically, on what the larger org or team needs from me at the moment. There is a chunk of consistent work, though, which is somewhat of a mix between an engineering manager and an IC.

Like engineering managers, I am responsible for planning out a team's long term goals and reporting on them to senior management. Also like engineering managers I'm responsible for hiring and evaluating technical talent, particularly the senior software engineers in our org plus people who are under consideration for promotion or hiring into my level.

Unlike engineering managers, it's important that I do "hands on" work. This includes my own tech designs and coding, but much more reviewing the designs and code of others. I see my job as delivering technical artifacts through others. What's different between the principal/staff role and the senior eng/tech lead role is the levels of indirection. For a senior eng, you are generally owning the output of a team of people (roughly 3-7 people, though it varies).

At the staff/principal level you work at the level of a team of teams, so your job is really to develop and mentor the tech leads of those teams. Occasionally you might be called in as a tie-breaker or to assist on some cross-team issue, but ideally that doesn't happen too often because the tech leads know their stuff (and they'd better because there is no way you can know the details of multiple team's worth of systems).

darepublic• 5 years ago

When I started out as a developer the engineering part of the title wasn't as widely used. I was working at large enterprise and my manager started to use the term engineer to describe us to other teams, and my coworkers found it funny. It was chalked up as typical overblown language from my manager. Fast forward to now and everybody is an engineer. Also I have noticed a general inflation of the titles associated with it. Senior is the new Junior, etc. I'm sure its company dependent but my 2c

fourseventy• 5 years ago

"What would you say ya' do here?" - Bob

SavantIdiot2• 5 years ago

To achieve the “org-level” impact, principal engineers need to be very selective on what to work on and use as much leverage as they can. For example, to set them up for success and maximize their influence, a principal engineer usually directly reports to a “director-level” engineering leader.

Whoa, that is a cynical take and smells a little of sour grapes.

I 100% agree that the PE title is abused both out of nepotism, and out of site-wide populism, but the intent is relatively pure, at least at large companies where the title actually matters:

There are some engineers that are so good at solving problems that they can be dropped into any crisis situation and help fix it, like a special forces soldier. After 30+ years in engineering I've seen them in action, and most of the time they deserve the title. They are just that good. Those are your PEs.

However, you need a large enough sample population to produce PEs because it is based on relative performance. It is harder to identify one in a group of 10, but in a division of 1000 it becomes abundantly clear.

Typically how you become a PE is by waiting in line and keeping at what you do, because usually there are only so many PE's promoted per year to help mitigate abuse of the system (there will be some in bigger organizations). This idea of being selective is ... misguided. You don't really have a choice.

Now combine those last two paragraphs and I can see how it appears there is room for gaming the system by only picking cherry products. However, it is unlikely you would be able to say to a VP or GM, "Hey, I want to work on THAT project, not this crap one you stuck me on, because I want more visibility for promotion!" Maybe that'll work, but good luck?

xxpor• 5 years ago

However, it is unlikely you would be able to say to a VP or GM, "Hey, I want to work on THAT project, not this crap one you stuck me on, because I want more visibility for promotion!"

I think this is very dependent on the incentives that are set up for the GM. If they're being judged on how they're developing their org, and number of promotions is looked at, now they may agree with you that the non-crap thing is the best thing to work on.

There's also the more implicit side of it, where if you're just generally good at what you do (or more cynically, if you're on the manager's good side for whatever reason), they'll be more inclined to let you work on what you want regardless of the motivations.

SavantIdiot2• 5 years ago

This is what I was referring to with site-level bias. I've seen certain sites brag about their # of principal engineers. Ultimately sites are handed jobs based on their past performance, but this abuse of the system remains. I'm being a little naive, but that's just me, and these abuses aren't that frequent.

sciurus2• 5 years ago

There are some engineers that are so good at solving problems that they can be dropped into any crisis situation and help fix it... Those are your PEs.

I agree that "the solver" is one flavor of the role, but I think there are a few other valid ones too. Many of the staff+ engineers I've interacted with fall in the "tech lead" or "architect" category.

https://staffeng.com/guides/staff-archetypes

synergy20• 5 years ago

They write specs, High level design with lots of flowcharts etc.

Many of them can not really code anymore, just like those system architects.

I do respect those who can both talk and walk: design the system, write key sample code for major components, and let the team to enrich and expand.

If they only know how to write design documents(talk the talk), I can hardly trust them that much.

aenis• 5 years ago

Speaking as a principal software architect for a large (30bn) company: - convincing others to one's ideas of good architecture - and contributing to enterprise architecture, - lots of time spent to evaluate designs, ideas, products, acquisition targets, - every fourth blue moon - some actual low level design work and programming pet projects/pocs/prototyping. Rarely :-(

I like this type of work, gives good exposure to new tech and the ability to choose what tech is being used. For my next job I want something more focused on actual programming though.

elric• 5 years ago

If you're a senior engineer and you're sort of wondering "what's beyond senior?", you might be interested in the book "Staff Engineer: Leadership beyond the management track". I found it enlightening, and it's nice seeing companies embracing the whole "Staff plus"-track.

rahimnathwani• 5 years ago

This is an awesome book. It's not just based on one person's opinion or experience: it talks about different archetypes of staff+ roles (https://staffeng.com/guides/staff-archetypes).

https://staffeng.com/book

727374• 5 years ago

My definition is "Finds and creates the most valuable work for other engineers to do."

I really started to see the value once I moved from Principal to Manager. All of a sudden I was busy with boring manager stuff and needed an IC who could get deep into the details of our initiatives and make sure everyone's efforts were lining up. You don't need the title of Principal to do this role, of course, but ICs who see the big picture and understand what's important for the business are invaluable.

The other points in the article are on the money as well, especially around modeling and amplifying a good dev culture for the organization.

huetius• 5 years ago

I like this definition, even if it overlaps with the PM role. In effective teams I’ve been part of, the PM and engineering leads help each other winnow down the work, with the PM making the final call for priority (except in circumstances where that doesn’t make sense).

makecheck• 5 years ago

Having been at several companies, I think I was happiest about my career when I didn’t have a fancy title and did not really know anyone else’s either (aside from obvious managers). It was nicer just knowing who’s in charge of what thing, and seeing your influence grow as you are trusted with more things.

When I see titles, it just makes unhelpful thoughts enter my head, like: are all these people “at my level” really contributing as much as me? Sometimes I even thought the reverse, like: how can this seemingly-junior person still be stuck at that level, when he is clearly doing all this great stuff we depend on every day? Of course the especially soul-crushing case is when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you; and worse, I have occasionally seen those people promoted further!

It is also hard not to look at titles on places like LinkedIn. I know I shouldn’t care, since titles mean different things at every company, and some especially-impressive-sounding titles can range from “meh” to “god-level” depending on where it is. And yet, it gets in my head sometimes, making me wonder every few years if I am at the level I should be.

When the title “matters” at a company, it also makes me consider it a factor in annual reviews. If I get a raise, bonus, etc. but see my damned title stagnate year over year, suddenly I care about this and take it as a complete lack of recognition by the company (that literally would not happen if they simply did not tell me what my title is!).

pradn3• 5 years ago

You hit the nail on the head. It was very different coming from Microsoft, where people's title and level (about one-two levels corresponded to a particular title) were visible in every chat dialog, to Google where you can edit your title to anything you want and levels can be seen only by going to a tool and looking it up specifically.

ghaff2• 5 years ago

At my current company, where I've been for over ten years, I've always just made up a title to match my current focus/what seemed "fresh." My original external title that was made up to hire me didn't actually make a lot of sense and differed from the internal HR title anyway.

Ended up doing something similar in my original tech job as well. I'm not sure I've ever really used my official HR title and would probably have to look it up to be sure I'm remembering it correctly.

zhengyi13• 5 years ago

I've personally set my title to "Shennanigans Regularly Effected".

Also, lots of folk deliberately opt out of level visibility, too.

kelnos3• 5 years ago

When I started at Twilio, I set my title on whatever chat we were using to something silly like "Director of Naptime Initiatives". (Well, ok, when I started we just had a poorly-used internal IRC server, so I guess this was a bit later when we got HipChat or whatever.) Sadly, these days the title field on Slack is synced with Active Directory, which has the human-readable title name, plus the level number.

It's really dehumanizing. I think I'd rather not know people's titles, just what team they're on, and their role.

xmprt• 5 years ago

On the flip side, having a title is a good way to know if you're being compensated appropriately. If you see someone 2 levels above you working on much less impactful projects then perhaps it's time to have a conversation with your manager about pay or time to start looking for new jobs.

kstrauser2• 5 years ago

On a side note, I use to see people with higher titles than mine not visibly doing as much as me, and found it grating. Now I have one of those titles, and I'm working harder than before, but a lot of it is with vendors, contractors, and overseeing projects. To ICs inside a particular project, it probably likes like I'm not doing much of anything. It changed my outlook on such things a lot.

ipaddr2• 5 years ago

Why do you feel you should be paid more because you feel you are doing more work? You are paid the least amount possible to fill your position during the hiring cycle. Your worth is what the market will pay you.

The fact that someone else is doing more or less with a higher title shouldn't influence your life at all. Jealousy shouldn't tell you when you should look for a job. If you are unhappy leave if you are happy stay. If your happiness is determined by what a random person is paid you will never be happy.

soheil• 5 years ago

when you encounter people that clearly suck at what they do, and they’re 1-2 levels above you

I think this is a logical contradiction. If there exists people that you are in a position to judge their competence you deserve to be in their position or higher, therefore it cannot be that they are 1-2 levels higher than you.

burnished• 5 years ago

Do people get what they deserve? It seems unclear. Therefor, no logical contradiction.

Logic is a great tool by the way, but unless you are applying it formally you might be better off not trying to invoke it casually.

trgn• 5 years ago

That's all true, and yet, and yet.

and seeing your influence grow as you are trusted with more things.

That's the ideal scenario, that you earn the esteem and trust of your peers because the work you do speaks for itself.

The flipside with this is, this process takes time. It really takes years. Sometimes there will not be that time. You are a new hire brought in to do a high-impact thing; or a high-impact project crosses across the entire organization where suddenly all participants are relative stranger; or the team you worked in was of very low external visibility but a mentor recognized your potential and pulled you out to help recalibrate a different but malfunctioning team, etc...

Then titles are important. It is very unfortunate that we are very cynical of titles, because, in well-run organizations, they are meaningful, and in fact, should be meaningful. Imagine in the military if every officer had to prove themselves over and over again. It's unworkable.

At some point, larger organizations will need to grant leverage to a technical individual. A title helps with providing that.

vasco• 5 years ago

I agree and go further to say I've seen people with demonstrated contributions suddenly clearly being more valued when they get a title, to the point that nothing changes about what they do but others rate the impact as being larger after a promotion, to the point that they eventually are actually having larger impact just because others now believe they can / should.

I've also seen the opposite, perfectly fine engineers get worse after a promotion due to the weight of the title, without any other change to their work / schedule.

HeyLaughingBoy4• 5 years ago

I hadn't thought about it in this context before, but I used to train Kendo (https://en.wikipedia.org/wiki/Kendo), a Japanese martial art, a long time ago. One interesting thing is that Kendo doesn't have belts like most other martial arts, the principle being that seeing the color of someone's belt causes you to prejudge their ability. Ideally, you should only know how good they are by actually training/fighting with them.

I've been very disappointed by comparing people's titles with their actual technical ability -- somehow it never seems to be the case that the ability outstrips the title.

skeeter2020• 5 years ago

> somehow it never seems to be the case that the ability outstrips the title.

Really? You've never worked with a junior who's punching far above their weight? I've had several on my team and work as hard as I can to get them promoted asap.

lr1970• 5 years ago

somehow it never seems to be the case that the ability outstrips the title.

People get promoted until they reach their level of incompetence :-)

mfrw• 5 years ago

Kendo doesn't have belts like most other martial arts, the principle being that seeing the color of someone's belt causes you to prejudge their ability.

TIL: This is a really interesting perspective; Thank You for this! I will use it from now to calm myself down. I, always either got mortified by the extreme skill of my juniors or by the incompetence of seniors — not sure if it’s the case with me or is it a general feeling.

The Kendo way at-least makes me ignore the titles :)

Bolkan• 5 years ago

Reminds me of rocket league. It's 1v1s do not tell you the rank of your opponent until the end of the game. But you can clearly tell when you come across a player that is one rank above you. They play very differently.

Beating that higher ranked player promotes you to their rank (and demoted them). It's like a mini boss that the game doesn't tell you about.

renox• 5 years ago

A long time ago, Judo didn't have color belt either, they added it for the Europeans so that they could see their progression..

That's one benefit but I think that the main benefit is that when you've a high level, you'll know that this guy in front of you is a beginner and you'll go soft on him, which is quite important: if he doesn't know how to fall properly the beginner could be injured if the "high level" guy doesn't notice in time..

CodeMage3• 5 years ago

I'm waiting to find a place that won't push me to keep advancing up the career ladder, without leaving my salary lagging behind the rising cost of living.

Does having limited ambition make you a bad dev/engineer, if you keep learning new things and contributing quality code at your current level of responsibility?

LargeWu3• 5 years ago

It doesn't make you a bad engineer, but it does, generally, put a ceiling on the value you are able to provide to the company. Individual contributors can only get so much done in a given amount of time, and over a long enough time scale, are generally interchangeable with one another.

Sure, you might have some specialized knowledge or understand system X better than anybody else, but there's diminishing returns on that, hence why you won't get big raises forever.

As you move up the chain, it eventually stops being about your direct technical contributions and about your ability to multiply the value of everybody under you in your org.

monkeybutton• 5 years ago

What will you do when you're in your 50s? I've seen what happens to older developers, they're one layoff from being totally screwed. Ageism is a real problem in the industry and it motivates me to keep advancing.

kelnos3• 5 years ago

It certainly doesn't make you a bad anything. Your level of ambition is a personal thing. It's yours alone, and no one gets to look down on it[0]. This idea that a person's worth is tied to how far they want to and are able to go in their career is something that needs to die.

If you're happy with where you are, and happy with your salary and status, then it's fine to stay there! Certainly, as you say, continue to learn new things, make quality contributions, and get your work done.

Many companies will have what they call "terminal levels" for individual contributors (most probably don't really advertise this unless you specifically talk about it with your manager). The idea is that you can work at a level where you can get your day-to-day work done with minimal guidance, even if you need guidance on the bigger picture stuff (like what you should be working on, and why). You should certainly talk to your manager about this, if you feel comfortable. And if you don't, and/or they keep pushing you to climb the ladder further, then yeah, you should probably find a new gig.

One caveat: ageism is still an unfortunate thing in our industry, and as you get into your 40s and beyond, if you're still "only" a "senior software engineer", you may have trouble getting new jobs.

Companies don't want to get stuck with people who are perpetually "junior" and need a lot of hand-holding to get their jobs done. That's of course ok for a while someone is learning and growing, but if they aren't growing out of that, they're a liability and time sink. But once you're past that point, you should be ok. The only problem is if you end up at a weird place where no one wants to progress up through staff/principal/architect/fellow, in which case I wouldn't be surprised if everyone starts getting pressured to up their ambition. But that sort of scenario seems somewhat unlikely?

[0] Well, unless they are in your immediate family and your lack of ambition is putting their livelihood at risk in ways they can't mitigate. But I'm assuming that's not the case here ;)

berto4• 5 years ago

i feel like a lot of folks don't care for the title as much as the monetary incentives and perceived "power" that comes with it.

banner2018• 5 years ago

Don't get carried away by marketing of thoughts, few folks prefer to be the mouthpiece of some grandiose concept .. if crazy ideas have followers, it becomes a cult...a cult over to.e becomes religion.

There might be some honesty / truth behind what is described but in my 2 decades of IT work, mostly ass kissers have taken home the big bucks .

mathgladiator2• 5 years ago

I'm a principal engineer for the next 3.5 days, and then I retire.

The key element is that you are half technical and other half people. You could say the other half is political, but that's just what happens when you get a bunch of people together. The key is that larger companies are hard to steer. You can't have N engineers in N directions, and you need to point them in direction.

The way I look at it from a technical perspective is ensuring that the game being played is winnable. Is the project going to work? Or, is this a death march waiting to happen? Do people know what they need to do? Do they have the tools and knowledge? Are stake-holders bought into the picture? Is funding going to endure the march?

The title is entirely useless if you are not in a large organization. Turning the ship even 1 degree is a lot of talking and organizing... Meh...

I like to build, but I'm happy to never build a pyramid again.

posharma• 5 years ago

Would it be fair to say that half of the job is project/program management?

HeyLaughingBoy4• 5 years ago

Not in my experience: there are typically specific project and program managers. The job of the Staff/Principal Engineer is usually to perform some kind of technical leadership: guiding code reviews, mentoring, architectural or technology guidance (what framework should use use?), remember the lessons learned from previous projects, and also serve as a liaison between the technical and non-technical departments in a company.

And in most cases, that's in addition to writing code. One of my last job descriptions as a Staff Engineer had me writing code about 10% of the time :-(

mathgladiator2• 5 years ago

Not in my experience. I think a key thing is that a principal engineer is technical glue. You run around talking people getting insight on what is happening on the front-line, and then you nudge things in directions such that the game wins.

Does this meaning providing tactical insight for the project? yes.

Does this mean questioning priorities and aligning priorities? yes.

Does this mean that making sure the department is sustainable on hiring objectives? yes.

You could say that the role is being a smart technical person that is responsible at the level of "almost stake holder". A key thing here is that a principal engineer should also have significant stock. At a big company, this should be in the seven figures.

davidw• 5 years ago

This all sounds like it comes from the world of Action Item, Professional Super Hero ( https://professionalsuperhero.com/ )

Me? I just want to write, improve or even remove code to make software better.

alpb• 5 years ago

I would highly recommend reading articles/guides in https://staffeng.com/ for Staff+/Principal career path. They also have a podcast!

kjgkjhfkjf• 5 years ago

The descriptions in the article are roughly correct for companies that have modeled themselves on Google, which is most companies headquartered in the Bay Area.

Microsoft's Principal Engineer is much more junior than at these companies. It's more like Senior/Staff Engineer. Amazon (headquartered in Seattle like Microsoft), also has a Principal Staff Engineer role which is less senior than Principal at Google and most other Bay Area companies, roughly equivalent to Senior Staff at those companies.

What does a Principal Software Engineer do?

Related Stories