Live data from Hacker News

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

eugeneyan.com

101–110 of 163 posts

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

#101

Earlier quoted context omitted.

Some companies suck at promoting the right people, but a good principal engineer is the 10x person, or someone who makes several teams more effective by helping them figure out the bigger technical issues. If you think management is like 1x talent and effort, you should try management for a bit.

I have. It's more stressful. But it's still 1x talent and 1x effort. Anyone can do it, it's just harder in the same way being a garbage man is hard. 10x engineers don't need to be principals. The idea behind principals is that they don't do any engineering. They leverage the work of others to become 10x. It's very much considered a "leadership" or management role overall. A 10x engineer is usually literally a person…

Maybe you were just bad at management and didn’t know it.

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

#102
post #40

Earlier quoted context omitted.

I'm reading the first couple of pages of the "Staff Engineer" book and from the various descriptions of the Staff+ role, i can't help but think it's just management without the actual power/say of being a manager. It's _even more_ politicking than being a manager because you have to do it both the soft and hard way.

It really depends on the engineer. I've seen some engineers in that exact position you describe, their job description says they influence the org broadly so that's what they set out to do. They struggle against a political and technical machine, vying for power, and trying to build a fiefdom. Other engineers I've seen (a smaller sunset) have that job description more as an observation of their skills and influence.…

I would rather land in the latter too.

I actually don't mind that some people are good at influencing others, through well earned respect, good communication skills and technical chops.

I resent it when it becomes a mandate and some official "badge" in the career ladder. I'm suspicious of these principal/architect types who "parachute" out of nowhere into teams and projects, because it's "their mandate", ask lots of questions, mess with stuff, and then leave and don't take responsibility because "the team owns the project, not them". I've seldom seen this work well. A lot of teams end up politely ignoring what these types say, because they know if you're not a true stakeholder, what you're saying doesn't matter.

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

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

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", then because he was an introvert did it poorly and got a really bad performance review ("underperformer"), got upset and quit. Aftermath: his manager ended up getting fired because of this screwup, but truly that was scapegoating. What's worse is he was happy in his previous role, doing groundbreaking work, didn't want the promotion and wasn't planning on leaving.

I'm not disputing what you say, but in my experience the middle technical roles are the safest. Too junior and you'll be the first to be axed for mediocre performance, too senior and you'll be blamed for failures and fired (sometimes for playing the political game and losing). Meanwhile, the mid/senior programmers doing the work will keep on.

Unless there's another round of layoffs, those upset everything.

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

#104
The key difference between a Principal and Senior Developer is the pivot from what you know to who you know. Principal is meant to take initiatives and run with them. Senior Developers do the real work. Principals are called out by execs when they need to refer to ownership in a specific space. Senior Developer, not so much. I only glanced/searched at this individual's webpage briefly, but it seems like they weren't fully clicked for understanding organizational behavior. The difference between "what you know" and "who you know".

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

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

Job title defines your salary and size of your bonus/RSUs. Hell yeah it is your identity.

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

#106

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.

… wait until you see their HN submission history

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

#107
post #78

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.

That's why I flagged it and encourage you to flag it too. Let's keep this self-aggrandizing slop off of HN.

From the guidelines: Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.

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

#108
post #20

This is content plagiarized from internal wikis presented as original thought, with no citations

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”)

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

#109
post #39

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…

The contradictions are difficult but wisdom has always been like that. See for example the book of Proverbs, it’s full of contradictory advice.

“Do not answer a fool according to his folly, lest you also be like him.”

Versus

“Answer a fool according to his folly, lest he be wise in his own eyes.”

The skill is to understand the truth of both statements, and to discern when to apply each one.

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

#110

The subtle disdain I hear from these types of super elite principal distinguished architects about actually writing code amuses me. Of course actually writing code is far too lowly of an activity, they’re more of an “ideas guy”. Fred Brooks had a good laugh about these types decades ago.

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?
Post reply on HN