Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

91–100 of 337 posts

Re: On Being a Principal Engineer

#91
post #30
post #19

Earlier quoted context omitted.

"But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. What we have tried as a company, what we haven't, why we built some things the way we did, how things work currently, how the politics works and the trust I have built. " This worries me too. Within my company I…

Market forces can be tough to predict. There was a dearth of software engineers in the last 8 or so years and many of us have reaped the rewards. The hacker news articles used to be about switching jobs every 1-3 years to advance your salary and career. I don't see so many of those these days, which makes me suspect that many have found themselves in senior-level or managerial roles that they find satisfying, and may…

I think it more likely companies adjusted their salary bands to be at least in the ballpark of each other, so you either need to move locations or take a “riskier” job if you want an automatic large bump in salary. There are clearly exceptions to this, but in general, companies have started to wise up.

Re: On Being a Principal Engineer

#92
post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

>> I am not sure if the title of "staff/principle" can be transferred

It usually can, actually, assuming you're going to a company of roughly the same stature. I.e. if work at a small company, your title doesn't mean much when going to a large company unless you're otherwise known in your field. And if you're a Staff engineer working at e.g. FANG, you can demand the "God Emperor" type title at a small company and you'll probably get it if they feel they need you.

The only things that matter are really:

1. Whether you'd enjoy the work

2. How much you get paid

Titles are arbitrary and they don't mean anything outside a particular company. Even between otherwise comparable companies there are significant misalignments, see e.g. https://www.levels.fyi/SE/Google/Facebook/Microsoft

Re: On Being a Principal Engineer

#93

This article, along with a boatload of companies, fundamentally misunderstands the way that senior / principal / staff engineers add value. The article mentions it briefly in the small part about “force multiplier” but then seemingly reverses course when talking about “soft” duties & especially emotional labor. The value of staff engineers is to give them autonomy in deciding how to be a force multiplier. If they rea…

This is pretty insightful!

To me this capture the right gist of being more valuable than senior eng.

Next for principal, it must involve business decision. Their work must noticeablely affect top or bottom line of the company.

Re: On Being a Principal Engineer

#94

Should principal engineers necessarily be managers? My company has non-manager principals, manager seniors, manager principals etc... Manager is just an extra title added to someone to give them extra responsibilities, regardless of their engineering experience. Is my company different than "usual"? I don't know how they decide who is senior who is principal, but principal engineers are absolute rock stars. They know…

I think it is very hard for a principal engineer who is also managing people to be effectively plugged into all the things going on that make him/her a "principal" engineer while also being an effective manager, and vice versa.

Re: On Being a Principal Engineer

#95
post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have.

That happened to me, and in my opinion and experience:

. Now you're competing with other managers for managerial roles

. The way you sell yourself for a managerial role is different, and in some ways a lot harder, than an individual contributor

. You have the option of gunning for 'lead' roles that aren't necessarily managing staff. That's what I do.

. You also have the option of architect roles, which is also what I do.

You're a higher tier employee now, and you're now competing with others of that tier level. While for most of us it's actually harder, not easier, to find roles that match, the plus side is there's a reputation and comp upside.

The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.

Re: On Being a Principal Engineer

#96
post #5

Earlier quoted context omitted.

In my experience it’s rare for orgs to hire for principal/staff/architect roles. What I’ve seen instead is people getting hired on as senior engineers and get promoted up from there after they’ve settled into the org.

I was hired into a company as a staff engineer, and I probably won’t consider it again. The existing engineers resented me for it, though it was super clear that the product was suffering because the existing engineers had serious skill gaps in critical areas. Meanwhile, to other managers & directors, I was just some new engineer they didn’t know, a political unknown quantity. I hit the ground running and earned a lo…

I ... earned a lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc.

How does that work? All the things you talk about are folded into my concept of "technical respect".

Re: On Being a Principal Engineer

#97
post #18
post #7

Is there a path where one can get to work on code without getting to design and architectural space. Is this thought as career stagnation when someone doesn't wants to work more on higher level design and to remain close to implementation side of things?

I would call it more of a plateau than stagnation. The senior title is a pretty beautiful spot, well paid and always more to learn but the value to the company is limited to the work you get done. You may be able to get it done faster and better than anyone else, but there are diminishing returns on speed and quality of an individual. I miss being a senior sometimes. Being able to go heads down and pair with someone…

I agree with what you have to say about it being a plateau... but what are these companies where a senior engineer's impact is limited to the work they get done as an individual?

Part of the definition of "senior", everywhere I've read it, is that your impact has started to spread outside yourself and to the team level. If you're a "strong IC", you're not a senior, in my reckoning. You're a senior when you're pulling up those around you.

Re: On Being a Principal Engineer

#98
In my experience, the best principal engineers are those who think of themselves as just engineers and simply focus on the best ways to make a difference without much preconceived notion of what that entails. The worst are those who have these strong preconceived notions about what they are supposed to be doing, often focusing exclusively on the more visible, politically expedient tasks in the name of having organizational impact, while eschewing hard technical tasks. Well if that was all that was needed, we don't need the technical ladder - managers that used to be engineers are perfectly capable of handling most of those. It's important to realize why principal engineers are given such autonomy and organizational influence - they are supposed to the best engineers that the organization has to offer and other engineers look up to them because they can do the same things they do but better. What you value in principal engineers should not be something you don't value in other engineers and vice versa. This idea they should be working on different types of tasks altogether and focus less on technical things specifically makes a mockery of the technical ladder.

So the worst part about this article, to me, isn't necessarily this notion that principal engineers shouldn't be all about tech - that I think is relatively uncontroversial. But the reality is that if your organization needs to stress this at that level, this should also be true at every level. If you want to have a great engineering organization, nobody, not even the most junior engineer should merely be converting tickets to code - they should ideally be doing all the things that she thinks principal engineers are doing. And whether someone on the team works more on soft, cross-team stuff or hard technical tasks shouldn't depend on one's level - it's entirely possible that interfacing with other teams or stakeholders is something your mid-level engineer can do well and also solving a very narrow technical problem is something you want your principal engineer should work on because it's extremely difficult. I will go even farther and say that if your engineering organization's challenges are such that the hardest problems that your best engineers should focus on are exclusively non-technical, you should reconsider why you need principal engineers instead of much cheaper project managers.

In one specific instance I observed at this organization, principal engineers were, on the whole, less technical than their managerial counterparts or senior engineers. Because the organization bought into this "principal engineers ought to focus on high-level, organizational, cross-team stuff" - their principal engineers were for the most part too busy trying to direct other teams' and people's work to do anything themselves. They had no deliverables beyond being the multiplier so they were also even more removed from the technical reality than line managers, who are at least forced to deal with what their reports are doing.

Re: On Being a Principal Engineer

#99
post #2

This rings true to my experience. I'm a Staff engineer and of my 40 hour week about 10-15 of those hours are interviews, meetings, and answering questions. Questions about technical feasibility, architectural discussions and planning, long term strategic planning, and lots of one offs from other developers. I enjoy the soft work I do, a lot of emotional labor for other developers, soft sells for tech/feature work aro…

But I am also at this weird point where I am not sure if the title of "staff/principle" can be transferred to another company. A lot of the value that I add now is because of the historical knowledge I have. That happened to me, and in my opinion and experience: . Now you're competing with other managers for managerial roles . The way you sell yourself for a managerial role is different, and in some ways a lot harder…

> The exception to the last paragraph are those that constantly broadcast on social media and make a name for themselves that way and doing presentations at conferences, etc. Not my cup of tea, personally.

These are folks who get hired by BigCos as "Evangelists". They're not gunning for the same roles that you are.

Oh hey... the system just works! : )

Re: On Being a Principal Engineer

#100
post #68
post #42

Earlier quoted context omitted.

> I don't think any leverage I have my with my current company will translate into finding jobs at other companies. You are right. Even if you are at FAANG, it doesn't really translate to a new environment, unless you are a direct pick by a CTO (you have to be famous in some way) or use your networking, which I consider unethical and don't do it.

I think you misunderstand networking. Perhaps you think it's a way for people to create and then exploit their connections in order to get a job that they're clearly unqualified for. I will agree that's unethical. But that's not typically what networking is about, almost no one wants to recommend someone for a job if that person turns out to be an unqualified idiot. Networking is more about finding people/companies y…

It feels like the OP came from a corrupt or communist locale where cronyism and nepotism were rampant. I grew up in a communist country like this and always found networking distasteful for that reason. However on the spectrum of hiring signals available it just turns out to be one with a very good SNR due to the trust involved.
Post reply on HN