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

51–60 of 163 posts

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

#51

Post by questionableans »

the_af wrote: post #39
questionableans wrote: post #35

Earlier quoted context omitted.

It’s definitely not for everyone. But if the person, the org and role are a good fit, it’s not going to be that kind of worst case scenario. IMO, “nothing is not your job” is odd phrasing that doesn’t really mean “everything is your job,” it’s more like “see something, say something—-in a way that is received constructively and results in positive change, whether through your own actions or others’.” The unstated cor…

The way the author describes it (in contradicting terms; see the point where he claims if you're a Principal IC, you were promoted because you already acted like one, making the ~30 items of advice redundant) it's the most stressful position ever. Be critical, don't be in the critical path, be laid back in an advisory role but be hands-on or you're setting yourself up for failure, work on stuff you enjoy but be ready…

It’s all about being balanced and picking the right strategy for the situation, not doing everything all at once. A guide like this could be useful for someone to consult when they find themselves in a different situation, regardless of their seniority level.

And in my experience, more senior engineers don’t have a greater risk of being fired for a project going badly because they identify problems to work on that matter and are within their areas of expertise, and evaluate possible risks early and communicate them.

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

#52

Post by swaits »

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 100% how it works at Amazon. It is said you have to do the job (of Principal Engineer) to get promoted. But most Principal Engineers are doing a different job than the job you have to do to become one yourself. Signed, PE@Amazon for 9 years.

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

#53

Post by questionableans »

LPisGood wrote: post #50
the_af wrote: post #39

Earlier quoted context omitted.

The way the author describes it (in contradicting terms; see the point where he claims if you're a Principal IC, you were promoted because you already acted like one, making the ~30 items of advice redundant) it's the most stressful position ever. Be critical, don't be in the critical path, be laid back in an advisory role but be hands-on or you're setting yourself up for failure, work on stuff you enjoy but be ready…

All that and also without a team of engineers working with you on the same problems, and you have limited formal power to actually set priorities and assign work. That sounds miserable.

The way it works is you convince engineers and managers to want to work with you.

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

#54

Post by disgruntledphd2 »

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 managing people (well), and some really excellent people don't like the core job of management, but are really really strong in some technical area, or have a broad enough perspective and enough personality to convince other people to do stuff.

In some ways, it's the software engineering world's PM, given that you have influence but not direct hierarchical power, and what matters is the amount of teams that you can influence (like sometimes this is through a piece of software, designing and building Airflow was this kind of work).

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

#55

Post by neilv »

ninetyninenine wrote: post #43
neilv wrote: post #29

Earlier quoted context omitted.

This is much like real Principal Engineer roles I've seen. The skeptics of the role might not have seen how easily and badly a large multiple-team effort can go astray, and the value of someone spotting the problems, and making sure they get addressed, before the product line or company is ruined.

I agree with your second sentence. But Anyone can do that, it's not a skill exclusive to principals. The idea that only certain types of people have the intelligence to spot things like this are principals is wrong.

Agreed, many people do that, and that's great.

Maybe we should think of the Principal role as complementary? If you're working on a compiler, you're going to be interacting cross-team with hardware engineering team, etc., and spotting lots of things. But someone who is looking at all the teams, and not spending so much time on compiler details specifically, will spot some things the compiler person doesn't. So together you get better coverage of problems that neither alone could spot.

Of course, once we throw differing pay grades into an organization, everything gets more complicated. And people might resent something being called "complementary", if what's bothering them is that the role in question pays better or is considered more prestigious.

Though, the Principal role is in the engineering career track of that compiler writer, if they want that kind of ulcers.

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

#56

Post by LPisGood »

questionableans wrote: post #53
LPisGood wrote: post #50

Earlier quoted context omitted.

All that and also without a team of engineers working with you on the same problems, and you have limited formal power to actually set priorities and assign work. That sounds miserable.

The way it works is you convince engineers and managers to want to work with you.

Making your whole living on influence without authority sounds awful.

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

#57

Post by tyleo »

I’ve felt that leadership roles at tech companies tend to converge around the same goal, “make software happen.” Different roles have different expertise in that goal but that’s what they’re here for. That doesn’t mean, “write all the software yourself,” it’s about using all the skills at your disposal to advance the team’s mission.

I’ve jokingly used the example with my own management, “I’d plunge the toilets if they were backed up and became our biggest issue.”

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

#58

Post by balamatom »

LPisGood wrote: post #46

> 19. Don’t just say the “what”; also share the “why” you think so. I can’t believe this needs to be said. Who is taking “because I said so” as a (first) reason to make an engineering decision with no justification?

>Who is taking “because I said so” as a (first) reason to make an engineering decision with no justification?

Justifications, needing to say things, etc., are for the weak. The strong get away with shit. That's how you know they're strong!

Or at least that's what >50% of the people I've met throughout my life consider normal. Maddeningly, heartbreakingly, infuriatingly, that number seems even higher among computer programmers

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

#59

Post by balamatom »

fsociety wrote: post #45
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…

Sounds like you have some beef to pick, not sure why you feel the need to discredit this person you don’t even know.

Ok fellow kid

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

#60

Post by conception »

swaits wrote: post #52
LPisGood wrote: post #47

Earlier quoted context omitted.

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 100% how it works at Amazon. It is said you have to do the job (of Principal Engineer) to get promoted. But most Principal Engineers are doing a different job than the job you have to do to become one yourself. Signed, PE@Amazon for 9 years.

I think it’s how it works everywhere. People see who’s good at their job and promote them to manager; an entirely different job though people often think it needs the same skill set.
Post reply on HN