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

101–110 of 337 posts

Re: On Being a Principal Engineer

#101

Post by techslave »

ww520 wrote: post #78

Those stated in the blog are leadership stuff which team leads and senior engineers need to have. Principle engineers are simply people who can design and build a major product, a major project, or even a company's technology by themselves, alone if needed to.

no way! principal engineers are those who have the technical vision and understanding to build a product by themselves. And the people and leadership skills to lead a large multilevel team of engineers to actually do so.

a project that could actually be built by a single person doesn’t have enough scope to warrant “principal”.

Re: On Being a Principal Engineer

#102

Post by pm90 »

analog31 wrote: post #32
maxxxxx wrote: 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…

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…

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

Same here. Its kinda easy to be fooled into feeling complacent when you get compensated very well and are respected for what you do and have done so far. But it will never be enough to keep you around forever; there are so many failure modes that you have to think about the possibility of being on the job market again.

Which is another reason why (apart from plain old human decency) I do make it a point to reply to most of the recruiters that try to recruit me with a polite explanation that I'm happy where I am currently but please lets stay in touch so in the future if things change we can try again.

Re: On Being a Principal Engineer

#103

Post by tibbetts »

maxxxxx wrote: post #81
javadocmd wrote: post #60

Earlier quoted context omitted.

I would argue that company-specific historical knowledge is not the value you (et al) are bringing. The value is the soft-skills of effective leadership that distinguish Principal from Senior (to use the article's parlance). Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills. And, of course, in finding a company and an interview panel that understands…

“Successfully transferring this to another company is an exercise in knowing how to demonstrate and sell those skills” Any ideas for doing this other having a lot of public visibility? I may have answered the question already but there may be other ways .

Learn to talk about your accomplishments like an entrepreneur or executive would: impact with quantified customer and company value. Not “I switched our development from Java to Go” but “improved time to deliver new customer functionality from 8 weeks to 4 weeks through new platform choice. Improvements in agility yielded $8 million in revenue growth.”

Another thing I don’t see enough in this thread is emphasizing software you managed to avoid writing. That’s the real secret of being a 10x engineer: telling your organization when building something expensive is not necessary, either because you don’t really need it, can use something simpler, or can adopt something that already exists.

Re: On Being a Principal Engineer

#104

Post by md5person »

I appreciate the idealistic take on what a "principal" role should be like, but in all actuality, principal engineers are commonly the ones that simply stayed there long enough (ie. to survive multiple re-orgs), and played their politics cards wisely. They were playing the title game. Often, their work is invisible to most. They perpetuate tribal knowledge, and have trouble letting go of the past and accepting change.

You'll notice plenty of comments here from people who claim to be principal engineers - stating that they "kinda follow it all". I wish we could talk to their colleagues though (the juniors, seniors, PMs, tech-leads, support/escalation engineers, as-well as other principals).

Re: On Being a Principal Engineer

#106

Post by solipsism »

nevir wrote: post #24

Though I am a principal that tracks very closely to what this article describes, I think eng organizations need both "broad" and "deep" principal technical roles. E.g. at that level, the road forks three ways: deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role). The tricky part is making sure that the deep role doesn't devolve into promoting people purel…

deep principal ("pure" IC, & an expert in an area), manager, and broad principal (the hybrid force multiplier role).

I don't understand what a "deep principal" would be. If this person is a SME with incredibly deep knowledge and experience, what an incredible waste it would be to not turn that person into a "force multiplier". I don't care how complex the code is -- that person's impact would be tenfold showing/guiding others compared to doing it themselves.

Perhaps I'm misunderstanding something about the distinction.

Re: On Being a Principal Engineer

#107

Post by techslave »

jeffdavis wrote: post #43

This article uses "individual contributor" too freely. Many decisions even for small projects have long-term impact on thr team. Even if you believe it's an accurate term, I find it a bit dimunutive or even condescending.

how much experience in tech and how many companies have you worked for? i ask because IC is not intended as a condescending term. it’s industry jargon, and not related to the importance or impact of the person.

for one thing, it defines where they are in the sexual harassment stack. as an IC you require only an hour of training a year and you can freely have relationships with people who aren’t in you mgmt chain. stuff like that.

Re: On Being a Principal Engineer

#108

Post by solipsism »

lclarkmichalek wrote: post #26
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?

You can totally do that in a FAANG. It's hard, but it's a recognized archetype.

These companies usually expect advancement, and advancement requires participation-in/production-of higher and higher level design/architecture. You can hang around for a few years, but eventually people are going to ask why you're not progressing. Depending on the FAANG you'll either be stack-rank laid off, or put on a PIP and pushed to voluntarily leave.

EDIT to add: On the contrary, non-FAANG is where you want to go. At many non-FAANG type companies you advance based on a combination of success and tenure. You'll accumulate raises and promotions just as a function of sticking around doing your job.

I know, because at such a company I became a manager and then was made aware that a person reporting to me was making twice as much as me. Because he had been there 10+ years, just producing code.

Re: On Being a Principal Engineer

#109

Post by techslave »

justicezyx wrote: post #93
mlthoughts2018 wrote: post #33

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.

but the eng himself isn’t going to make those calls. he needs to work closely with PMs and other business side folks as a team.

Re: On Being a Principal Engineer

#110

Post by pm90 »

valleyjo wrote: post #90
maxxxxx wrote: 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…

I’ve seen this happen even within the same (large) company. Someone is a director level who has maybe 100 reports. The entire product gets cut. The IC’a find other jobs within the company. There are only so many Director level positions around and many of them are achieved organically. The ex-director then goes somewhere else as a regular engineering manager unlikely to ever have such a position again.

Yeah this is pretty common in most large enterprises. If your company is not in a hyper-growth stage (i.e. its a cash cow) then upper management positions become a game of musical chairs and political infighting as some leaders try to promote "their" people to top positions to hold on to their power and status.

I guess there are certain folks who find this enjoyable. Personally I find it a massive waste of really good talent and perhaps the single biggest reason why I enjoy the dynamism of the SV startup ecosystem even if I don't directly participate in it.

Post reply on HN