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

Advice for new principal tech ICs (i.e., notes to myself)

eugeneyan.com

Post reply on HN
Print view View original

91–100 of 163 posts

Re: Advice for new principal tech ICs (i.e., notes to myself)

#91

Post by bwfan123 »

nadam wrote: post #27

I find it amusing how people take this 'leveling game' at big companies so seriously. The title they get at these companies become their identity. They live by the rules the company imposes on them. Amusingly almost the opposite of independent thinking, which they are so proud of. What I found during my career is that some people blossom at these big companies, and some, with equal talent cannot really realize themse…

Can we coin a new archetype called the "performative engineer" who plays to the leveling game ?

Re: Advice for new principal tech ICs (i.e., notes to myself)

#92

Post by ffsm8 »

mattgreenrocks wrote: post #85
dwb wrote: post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities. I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT. I have seen extremely talented engineers not get their promo to this…

The value an individual provides to the company is - at best - correlated with their position in said company.

It it usually correlates even more with their ability to portrait themselves as capable.

Thankfully, there is significant overlap between these groups, but sadly not a full circle if visualized as a Venn diagram.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#93

Post by SR2Z »

cmiles8 wrote: post #65
nvarsj wrote: post #36

Earlier quoted context omitted.

> I find it amusing how people take this 'leveling game' at big companies so seriously. It has a huge payoff (think 7 figure TC/year for principal+ at big tech), with little personal risk required. It's no wonder people take it so seriously.

At higher levels or extremely specialized roles perhaps. But your typical big tech “principal” IC isn’t consistently making 7 figures.

A principal engineer makes this much money at virtually every SV company because principal is a very high level.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#94

Post by SR2Z »

bwfan123 wrote: post #91
nadam wrote: post #27

I find it amusing how people take this 'leveling game' at big companies so seriously. The title they get at these companies become their identity. They live by the rules the company imposes on them. Amusingly almost the opposite of independent thinking, which they are so proud of. What I found during my career is that some people blossom at these big companies, and some, with equal talent cannot really realize themse…

Can we coin a new archetype called the "performative engineer" who plays to the leveling game ?

Why, when we're all already used to calling them boss?

Re: Advice for new principal tech ICs (i.e., notes to myself)

#95

Post by maccard »

LPisGood wrote: post #47
dwb wrote: post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

My favorite bit is all the contradictions > 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it. And > 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while Say you need to keep doing what you’re doing, but also change everything.

This is a bit reductive and I’m surprised to see this sort of take on here.

Technically that’s true of any step change - a junior developer is expected (loosely) to fix the bugs and do the tasks, to the spec. They should ask for help early and often, and should have enough slack in their estimates from their leads that they have time to mess up to learn. If they continue to do that they will stay junior forever.

They need to learn when to ask, how to estimate and how to avoid certain pitfalls. When they stop asking the basic questions and learn to research, they’ll be promoted to mid level (which they’re already doing). To be an effective mid level though you need to start making mistakes, but in a different way. You can’t be stuck on not being able to install a tool for 3 days, for example.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#96

Post by brown9-2 »

akdev1l wrote: post #77
YuukiRey wrote: post #24

I find it a bit strange when people write about themselves in third person on their own website (see footer and about). Anyway, the article seems very Amazon centric since I have no idea what an L6 or an L7 is. I get that they’re career ladder steps but that’s it. And having testimonials about yourself on your own website… The whole website feels like I clicked on an Ad for a person.

L6 is a senior engineer - typically effecting change and setting direction within a development team (or small group of related teams) L7 is a principal engineer - typically effecting change at org level which will impact many teams

Amazon skipping “staff” and jumping straight to “principal” seems like such title inflation

Re: Advice for new principal tech ICs (i.e., notes to myself)

#97

Post by mattgreenrocks »

ffsm8 wrote: post #92
mattgreenrocks wrote: post #85

Earlier quoted context omitted.

I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities. I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT. I have seen extremely talented engineers not get their promo to this…

The value an individual provides to the company is - at best - correlated with their position in said company. It it usually correlates even more with their ability to portrait themselves as capable. Thankfully, there is significant overlap between these groups, but sadly not a full circle if visualized as a Venn diagram.

Agree. I wouldn't say it's broken; the somewhat-overlapping Venn Diagram metaphor is apt. But like many other domains of power, there's a persistent belief that those who are recognized (promoted) are indeed the best candidates and that false negatives eventually correct themselves.

Believing otherwise is psychologically dangerous: if the system is somewhat arbitrary, then that opens up the possibility that their promotion was also somewhat arbitrary and not under their control.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#98

Post by johannes1234321 »

LPisGood wrote: post #47
dwb wrote: post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

My favorite bit is all the contradictions > 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it. And > 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while Say you need to keep doing what you’re doing, but also change everything.

You've got to change to do the next job. So you are always paid one level below the Job you are actually doing ;)

Re: Advice for new principal tech ICs (i.e., notes to myself)

#99

Post by hosh »

LPisGood wrote: post #47
dwb wrote: post #42

Are you an individual contributor if the vast majority of your work isn’t individual contribution? And you’re not a “working-level” IC? God I hate all this big corporate hierarchy terminology. Along with all the pontification about what a “staff” or “principal” or “senior” really is , as if the terms have (or can have!) a stable meaning that we definitely agree upon enough for this all to make sense.

My favorite bit is all the contradictions > 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it. And > 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while Say you need to keep doing what you’re doing, but also change everything.

25 and 26 has been my experience with this as well (not at Amazon; at much smaller organizations) Those paradoxes happen there.

Just my opinion: one of the key mindset shift that happens before someone steps into staff and principal engineering is understanding that the technical choices you make are tradeoffs. You give up conceits (or one should) that a technical opinion is separated from context, while also getting to deeper technical principles that appear across architectural levels or disciplines (such as queues). You also see how technical systems are inseparable from the people using it, and being a part of it.

When you start seeing that, you start seeing that everywhere. You start to act in a way that is informed from that understanding. You need to be on the critical path in order to do what matters, but you also need to connect those dots that are overlooked.

But that is also one flavor of principal engineering. I tended to do the horizontal influence than deep technical and domain expertise. At early stage startups, people have to wear multiple hats, often exceeding the scope of what they were initially hired for.

Re: Advice for new principal tech ICs (i.e., notes to myself)

#100

Post by the_af »

disgruntledphd2 wrote: post #54
the_af wrote: post #37

To me, in a way, it reads like Principal IC is the worst possible job. You're doing all the politicking and influencing stuff many of us presumably don't like and associate with management roles, while also being expected to be "hands on" and at the top of your technical game. "Nothing is not part of your job", as this article describes it. Someone who's not doing this, the article argues, "is setting themselves up f…

> To me, in a way, it reads like Principal IC is the worst possible job. It depends on the person, I think. Personally, I often end up doing this sort of work, particularly in smaller companies. I really like it, but appreciate that the vast, vast majority of people I work with would hate it. For some people, they prefer to lead through influence, rather than through a reporting line. There's a lot of toil in managin…

A valid perspective. I don't mind influencing people in the areas I know, but I resent the politicking and being forced to do it outside my area of expertise (and I don't believe about Principal IC can really know enough about everything, like the article implies).

You worked in the design of Airflow? We're heavy users at my current company.

Post reply on HN