Live data from Hacker News

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

eugeneyan.com

121–130 of 163 posts

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

#121
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…

There’s a reason burnout rates go up at staff+ levels. Expectations go up w/o a commensurate amount of managerial control.

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

#122
post #110

Earlier quoted context omitted.

It’s not necessarily disdain, it’s the fact that writing code is necessary but not sufficient to make a successful software project. To have the most positive impact, sometimes you have to focus on the parts that everyone else finds difficult or uninteresting, yet are still important.

Sure! You mean writing documentation, aligning divs, writing tests, caring for the infrastructure, right?

If it’s important and it’s not getting done, yes.

Let’s take aligning divs.

What’s the real problem here? The front end looks really bad and it’s causing us to lose potential customers.

Why is that? Maybe we have a shortage of frontend devs. Maybe the frontend code is a mess and people are just hacking in small changes here and there to minimize the time they spend with it. (Maybe both.)

What do you do about it? Fix the alignment now to stop the bleeding. Through that exercise, understand what’s wrong with the front end architecture, get engineering buy-in on an easier approach, and train devs and/or refactor code (efficiently, prioritizing and allocating effort commensurate with the problem), pairing with some devs who have been suffering from the pain and are interested in finally being able to fix it. Advise management on whether we’ll need more frontend talent even after we fix the alignment issue. If so, suggest who might be a good candidate to transition to more frontend work, or else work with sales to lobby for hiring more front end devs even though we have zero headcount budget.

That’s principal level aligning divs.

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

#123
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…

Not only that, but leading through a reporting line is 90% influence, too. Relying on pulling rank will get your best reports to find a way to leave ASAP, and others will follow.

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

#124

Earlier quoted context omitted.

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.

That’s life. Unless you’re a hermit, a complete pushover, or a slave master, you’re constantly trying to influence without authority.

Want to go out to dinner with friends? That’s influence without authority right there.

Want to get your PR approved? Influence without authority.

Trying to get your point across to strangers online? Ditto.

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

#125
post #103

Earlier quoted context omitted.

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 ma…

Being balanced about political/soft skills makes me nervous, especially when it becomes a mandate and your main role. Some people are good at it, some are bad -- but it's completely irrational to expect this to be the logical next step for ICs and senior engineers. I've seen it backfire spectacularly when a very senior engineer who worked in a critical part of the product was forced into this "because of promotions",…

That’s why a lot of companies only promote after demonstrating a track record of performing at the next level.

It can also be an argument for secret levels. Although I’m not sure how useful that really is in practice.

For someone who does well at influence, it’s not a mandate, it’s permission to spend some time on the nontechnical factors that are necessary to make your work turn out better. And that also means helping others who have good ideas but aren’t comfortable with the influence part themselves.

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

#127

Earlier quoted context omitted.

If money is your identity, you’ve already lost the game. Especially if you’re trying to do it as an IC engineer. C suite, directors, and many more probably laugh at their salaries.

I'm not playing a game. I'm paying a mortgage as quickly as possible.

What’s the rush?

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

#128
post #108

Earlier quoted context omitted.

Wow that’s quite the accusation. Any evidence?

#15 is copied verbatim. #18, #23, #26, #27, #30 are paraphrased. Most of the other advice have been shared in talks for ages, and are not new advice. It’s intellectually dishonest for the author to present collective advice as the their own (“I’ve distilled … My perspective”)

Welcome to the brave new world these days:

1 - Very few people conduct "proper scholarship", and fail to trace ideas back to their original inception and cite them correctly. This happens time and again in deep learning, where 30+ year old ideas are claimed as "novel" over and over. Many times out of malice by the authors, sometimes out of ignorance.

2 - Peer review in many parts of the industry+research is a joke. Mostly shouldered by early graduate students who don't really know the field well and an incredibly noisy process.

3 - It is common practice now to dump out one's "kitchen sink" of ideas rather than properly refined stuff. Hence the increase in LinkedIn spam, blog spam, arXiv spam style of papers.

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

#129
post #79
post #61

There was a time when the L7+ principal IC at Amazon/AWS were rockstars in our industry that represented the pinnacle of one’s career. It’s been sad to watch the talent exodus there on my LinkedIn these last 12+ months as these folks flee the ship for elsewhere. So much experience and knowledge just gone and the bar for L7+ with those left has tumbled off a cliff.

Right, now I see Amazon experience as probably a negative - its not a sign of strength.

Why's that?

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

#130

Earlier quoted context omitted.

>But the team got the credit for being on top of things as a whole, not me. As it should be. >If only! 70% of the work I do is invisible small course corrections here and there across multiple orgs that fix things no one ever hears about but would be disasters down the road. >For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best. Then your case is the exception…

> Then your case is the exception, not the rule. To reach the level of principal, you generally have to be recognized for delivering high impact. Visibility is not just ego, it is how organizations perceive value. Of course you need visibility and impact. But it's not the kind of crass taking credit for what other people did that the original poster talked about. As a principal you need to actively build visibility b…

>A strategy to be fired. This is not viable.

Not true at all. Plenty of invisible people in the world who don't get fired. You're ignorant.

Your initial post talked about lack of visibility, now you're talking about it as if it's required comically to the point of claiming that "invisible" people are absolutely on the path to get fired or that people who keep their head low and don't grab attention isn't a strategy. Ever heard of the saying the tallest blade of grass is the first to be cut? Also have you seen how Xi, the current leader of China rose to power?

Part of being a principal is the perception of principled and expert reasoning/expertise. That means being able to flip what you're saying on the fly so that other people continue to perceive you as an expert who knows what they are talking about. Did you say something that was completely off and wrong and it made no sense? How do you hide this from the people above you?

You expertly did this with your response. First you say you take none of the credit, now you say taking credit and being visible is required. Expert pivot and THIS is truly the primary skill of a principal engineer and you display it unequivocally.

You don't even need to actually be responsible for all the changes you claimed to have influenced. You just need people to perceive the reality as if you were responsible. And I see this kind of BS in many, many engineering organizations.

A lot of this is self delusion too. These high level strategies and directions aren't hard to come up with. Likely tons of lower engineers have thought of the method too, they just don't have the "visibility" or the time to actually drive that direction into the organization. Some people tend to think the ideas they have are genius and that these ideas are what makes them "principle". No. It's mostly politics that puts you into a position to take credit for ideas anyone can come up with.

Post reply on HN