Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Being a Principal Engineer

blog.dbsmasher.com

Post reply on HN
Print view View original

31–40 of 337 posts

Re: On Being a Principal Engineer

#31

Post by nevir »

xtreak29 wrote: 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?

At our company we've implicitly split the technical ladder at the principal level into "broad" principals (this article), and "deep" principal (expert at their field).

We're struggling to formally define it, though. How much pure IC work do we expect of broad roles? How much coordination/communication do we expect of deep roles?

Re: On Being a Principal Engineer

#32

Post by analog31 »

maxxxxx wrote: post #19
ryanong wrote: 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. 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…

I'm in exactly this situation, at Senior Staff level. It is quite possible that a person is actually getting paid enough to make it hard for them to leave, which seems strange because it's not not the norm. The company may want to keep them because of what they can do for that company, not because of their potential market value to another company. They may know things about you, that are hard for you to communicate in a job application situation, such as how you work with people.

I've decided to adopt the attitude: Enjoy it while it lasts, but don't count on it lasting forever. Live a lifestyle consistent with your market value, and squirrel the rest away. I'm also conscious about keeping my tech skills up to date.

I'm reminded of an old saying among people in the entertainment business: Think about how you treat people on your way up, because you will meet them again on the way down.

Re: On Being a Principal Engineer

#33

Post by mlthoughts2018 »

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 realize for themselves that this can be accomplished with some soft skill application, so be it. If they realize this will happen if they do not delegate some critical task and instead clear the calendar so they can write the code that time, that is good too. And lots in between.

But autonomy is the critical thing. These are engineers that you’ve decided to trust greatly, so you cannot get in their way with compulsory person management overhead, adding them to every product meeting, burdening them to “sell” their vision on some architecture, recruiting policy, whatever.

These are the very people who you should be getting out of the way of, letting them decide how to be a force multiplier.

Re: On Being a Principal Engineer

#34

Post by [deleted] »

maxxxxx wrote: post #21
toomuchtodo wrote: post #10

Earlier quoted context omitted.

Staff/principal SWE compensation is the premium an org pays for your tribal knowledge, and arguably non-transferable. “Golden handcuffs”.

Outside the big companies in Silicon Valley there are no golden handcuffs for engineers. With each promotion you make just a few percent more.

[deleted]

Re: On Being a Principal Engineer

#35

Post by twblalock »

ryanong wrote: 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…

Tribal knowledge is good to have, and inevitable, but it is also a blinder that tends to limit people to a particular set of architectural assumptions, and this gets worse the older the company becomes. It’s also an obstacle to bringing in new people.

Some people are able to join a company and expand/modernize/build on the tribal knowledge to make things better. It’s a rare gift but I’ve seen a few people do it. People like that could be a principal engineer at almost any company.

Re: On Being a Principal Engineer

#36

Post by [deleted] »

d4mi3n wrote: post #22
mharroun wrote: post #8

Earlier quoted context omitted.

This depends on the culture & hiring philosophies of the company. I've seen many places that "only hire the best" or "only hire seniors" then end up with a bunch of engineers who dont mentor or force multiply but tend to just focus on what ever pice of a system they own. I've also seen senior used only to justify a pay bracket as well. Personally I agree that a senior or lead enginner needs to have these skills.

I’ve been at the kinds of places you describe as only hiring seniors. I’m personally not a fan of that kind of mentality for a few reasons: 1. (In San Francisco) This can lead to reqs being open for way too long. My company had several roles open for upwards of a year and wouldn’t back off until I convinced my manager that we could train/mentor a less experienced hire to fill those reqs faster than we could fill them…

[deleted]

Re: On Being a Principal Engineer

#37

Post by mlthoughts2018 »

d4mi3n wrote: post #5
ryanong wrote: 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…

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 lot of technical respect from my teammates, but nobody cares at all about my perspective on architecture, scoping, technology investment, tech debt, etc. They had decided merely by the manner in which I joined to give no credibility to my ideas.

The next time I will require the role to be some type of director or IC/distinguished engineer hybrid that is operating with an authority level above that.

Re: On Being a Principal Engineer

#38

Post by MisterOctober »

maxxxxx wrote: post #19
ryanong wrote: 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. 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…

I can really relate to this. I 'climbed the ladder' in company X and thereby acquired a lot of company-specific domain knowledge that didn't really have much value outside the company. I realized what kind of a fix I was in years ago and started to lay some groundwork for moving to another firm, but it took until this year to find a company that would place enough value on my [opaque] work at X to hire me at a salary that was comparable.

Lesson learned : make a conscious and focused effort to acquire + maintain general skills and keep a visible portfolio updated!

Post reply on HN