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…
Advice for new principal tech ICs (i.e., notes to myself)
101–110 of 163 posts
Re: Advice for new principal tech ICs (i.e., notes to myself)
#102Earlier 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 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)
#103Earlier 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…
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)
#104Re: Advice for new principal tech ICs (i.e., notes to myself)
#105I 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…
Re: Advice for new principal tech ICs (i.e., notes to myself)
#106I 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.
Re: Advice for new principal tech ICs (i.e., notes to myself)
#107I 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.
Re: Advice for new principal tech ICs (i.e., notes to myself)
#108This is content plagiarized from internal wikis presented as original thought, with no citations
Wow that’s quite the accusation. Any evidence?
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)
#109Earlier 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…
“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)
#110The 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.