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…
On Being a Principal Engineer
91–100 of 337 posts
Re: On Being a Principal Engineer
#92This 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…
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
#93This 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…
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
#94Should 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…
Re: On Being a Principal Engineer
#95This 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…
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
#96Earlier 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…
How does that work? All the things you talk about are folded into my concept of "technical respect".
Re: On Being a Principal Engineer
#97Is 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…
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
#98So 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
#99This 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…
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
#100Earlier 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…