61–70 of 163 posts
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.
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.
Earlier quoted context omitted.
> In short, you manage people. You tell others what to do and you think about what to do. As a principal scientist I definitely don't manage people. Mainly, people managers have power to tell people what to do and when. I have zero power over anyone. No one needs to listen to me. Ever. If people ignore me there's literally no one I can complain to. And no one tells me what to do. If I wasn't competent at my job I'd b…
>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…
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 because so much of your work is normally invisible. It means being an active participant with discussions with leadership, clearly being the person that sets the agenda on something, becoming someone who other principals turn to on a topic and then report to their managers, leading the conversations on a topic, being the person that people can bring a hard problem to and then see results, picking up on a business need first and finding a way to deliver on it, etc.
In the example I gave for the quiet change in direction of that project, there are many ways in which I get visibility. I told my manager this was a risk and I have a strange solution. I told the manager of that project. The other principals that I needed to involve and their directors know I pushed this. My VP knows because no one talked about that kind of feature until I did. I checked how crazy this direction change would be with more senior scientists and product people. I actively make sure that these gentle communications happen, and in a sense they're natural, because I'm taking the lead on something.
But no one is going out of their way to say "I take credit for all of this work that everyone else did".
> A principal who keeps their head down, avoids controversy, and stays on friendly terms with the right directors can outlast a dozen brilliant but abrasive engineers.
I don't think that abrasive people should become principals until they change their ways. There's so much cross-org coordination that you need to do, if you're abrasive, that's going to hurt everyone.
That doesn't mean you should be a pushover. I don't back down from technical arguments if I know I'm right and have the data to back it up. I have gotten into deep weeks-long disagreements reported far up to chain. But it's important that you can still go have lunch with your peers and collaborate on other topics even while you're trying to show that they're totally wrong in one area. That's part of building trust.
> In that reality, being invisible is not a liability. It can be a strategy.
A strategy to be fired. This is not viable.
There is no tension between "quiet authority" and visibility. If you're invisible no one will ever come to you. Visibility is what consistently demonstrates to people that talking to you will make their lives better.
> 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 pr…
One thing I've found personally rewarding is having to articulate why I believe certain designs / choices are bad ideas, and be ready to propose better alternatives.
If all of my team members were equally experienced, there would be much less need to do this. But it would probably mean atrophying the knowledge underlying my gut instincts, and not being so open to valid alternatives.
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…
> 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.
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.
> 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 pr…
If you ask why the vast majority of people have no answer other than “because I like it that way”.
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.
I dunno, maybe in Silicon Valley or the US in general, but I think most places outside of that took a much more balanced view of those people even back then, they're just humans after all.
Many people experienced working with those "rockstar" engineers outside of Amazon, "rockstars" who still tried to work as if they were still at Amazon, and the obvious effect of that was that it created a lot of needless friction between the people who saw themselves as "I'm the best engineer because I was L7 at AWS" and the rest of the company.
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…
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.
Other engineers I've seen (a smaller sunset) have that job description more as an observation of their skills and influence. Their mandate isn't to influence, they just do. They are respected for their vast knowledge, historical success, and insight. So they naturally are heeded by most, and consequently they broadly influence the org.
Both cases sound miserable in their own way, but if I had to choose I'd much rather land in the latter. The latter still involves some politics, but at least it sounds like you're not wasting your life playing stupid games.