In short, you manage people. You tell others what to do and you think about what to do.
It's technical management. You create impact off the work of others. You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort.
I met a principle engineer who didn't know what a database transaction was and it still fits every description on this site. We shouldn't call these people engineers anymore. They are managers that don't need to do 1 on 1s.
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.
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 themselves, while they blossom at other organizations, perhaps in startups, or just at more interesting problems. What some people do not realize is that this aspect that as you level at these companies 'you get the big picture more and more' is not really true in a lot of cases. Efficiency and big picture thinking is almost orthogonal. Efficiency is context dependent, high level thinking is less so. I have seen people getting the big picture on things even at low levels or even considered a junior, while people on high levels suprisingly small minded. Higher level at these organizations means that you are more productive in the given field, given organization, for some reason, this can be because of good political skills, because you work your ass off, or because you have a very efficient brain, but it does not necessarily mean that you have better high level vision, or taste or maturity even.
Sometimes it is almost laughable how these people who treat these leveling system seriously and get to a relatively high level treat young colleagues. They are almost naive about how young people think. They think that L3 juniors cannot do anything alone. While I see even young kids playing with suprising autonomy if they are thinking in the right problem space.
True role models of mine never were/are L3, L4, L5, etc... They were/are awesome engineers or scientist from the get go. (Like the Johns: The von NEumann and the Carmack.) Experience lets you get better and better, but if you are stuck at a role or organization, the problem might be that you need to find something that you are more passionate about and not necessarily that you are low level because your thinking is not 'independent enough' or you are not 'high-level enough'. At least that is my experience.
These roles with fancy titles may come with astronomical compensation for an engineer—and rightfully so—but they're essentially buying your soul. You're not an executive, and are still below them on the political and compensation ladder, but you'll easily have 10x more on your plate than an executive. You'll be expected to act as a lap dog for the company for anything tech-related, while you probably will only enjoy 10% of that work. Your guidance will only be appreciated when the stock goes up, while you'll be the first to be held responsible for any technical screw ups.
So, nah. I'd rather continue to enjoy my work, maintain my freedom and peace of mind, and still get paid well enough as a perpetual "senior".
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 for failure." Yikes! These are not rookies if they reached Principal IC, but the most experienced team members ever, yet the author still feels the need to say this. Which makes me thing it's a really perilous path.
Seems highly stressful. I'd rather stay a low-level IC. Do we need to move up or out? (In general I mean, I wouldn't want to work at Amazon).
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.
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.”
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.
* Bring that new external shit back to your organization, which requires integration and knowledge transfer
* Inspire people with the new stuff. This means actually talking to people, but its more than that. Its motivating and inspiring people.
That's it. A principle is not a people manager, so there is a lot they don't have to deal with, but they are required to demonstrate and prove their new knowledge in the context of the current organization. This proof can be research papers or MVPs.
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".
20 comments
[ 1.4 ms ] story [ 42.0 ms ] threadIt's technical management. You create impact off the work of others. You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort.
I met a principle engineer who didn't know what a database transaction was and it still fits every description on this site. We shouldn't call these people engineers anymore. They are managers that don't need to do 1 on 1s.
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.
True role models of mine never were/are L3, L4, L5, etc... They were/are awesome engineers or scientist from the get go. (Like the Johns: The von NEumann and the Carmack.) Experience lets you get better and better, but if you are stuck at a role or organization, the problem might be that you need to find something that you are more passionate about and not necessarily that you are low level because your thinking is not 'independent enough' or you are not 'high-level enough'. At least that is my experience.
Yeah, screw that.
These roles with fancy titles may come with astronomical compensation for an engineer—and rightfully so—but they're essentially buying your soul. You're not an executive, and are still below them on the political and compensation ladder, but you'll easily have 10x more on your plate than an executive. You'll be expected to act as a lap dog for the company for anything tech-related, while you probably will only enjoy 10% of that work. Your guidance will only be appreciated when the stock goes up, while you'll be the first to be held responsible for any technical screw ups.
So, nah. I'd rather continue to enjoy my work, maintain my freedom and peace of mind, and still get paid well enough as a perpetual "senior".
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 for failure." Yikes! These are not rookies if they reached Principal IC, but the most experienced team members ever, yet the author still feels the need to say this. Which makes me thing it's a really perilous path.
Seems highly stressful. I'd rather stay a low-level IC. Do we need to move up or out? (In general I mean, I wouldn't want to work at Amazon).
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?
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.”
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.
* Learn new external shit
* Bring that new external shit back to your organization, which requires integration and knowledge transfer
* Inspire people with the new stuff. This means actually talking to people, but its more than that. Its motivating and inspiring people.
That's it. A principle is not a people manager, so there is a lot they don't have to deal with, but they are required to demonstrate and prove their new knowledge in the context of the current organization. This proof can be research papers or MVPs.