on the contrary it seems like title deflation as Amazon principal engineers typically work at a higher level than staff at most other orgs (at least I remember a Microsoft principal would be basically an Amazon L5-6 level)
Ha, this is true. I thought the post was quite useful beyond getting the author’s name out there.
It can get much more navel-gazing than this, such as the posts by 24yos who insist they finally figured out what life is about after working at a startup for 3 years. :)
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.
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 dislike the term "IC" too but it does at least have a stable meaning in most companies: it means you don't have direct reports in a managerial capacity.
I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities.
I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT.
I have seen extremely talented engineers not get their promo to this role because they were "too into coding." And I have advocated for one of them (w/o their knowledge), arguing the project wouldn't exist in it's current form without their technical contributions, and then witness the org retcon their judgment into a staff-level promotion without any significant change in duties.
Makes it hard to take too seriously, honestly. If the purpose of a system is what it does, then it's meant to be a miserly, inertial source of institutional status. One that can get you a lot more money, of course, so play the game as best you can without losing yourself in the process.
Agree. I wouldn't say it's broken; the somewhat-overlapping Venn Diagram metaphor is apt. But like many other domains of power, there's a persistent belief that those who are recognized (promoted) are indeed the best candidates and that false negatives eventually correct themselves.
Believing otherwise is psychologically dangerous: if the system is somewhat arbitrary, then that opens up the possibility that their promotion was also somewhat arbitrary and not under their control.
> 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it.
And
> 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while
Say you need to keep doing what you’re doing, but also change everything.
This is 100% how it works at Amazon. It is said you have to do the job (of Principal Engineer) to get promoted. But most Principal Engineers are doing a different job than the job you have to do to become one yourself. Signed, PE@Amazon for 9 years.
I think it’s how it works everywhere. People see who’s good at their job and promote them to manager; an entirely different job though people often think it needs the same skill set.
25 and 26 has been my experience with this as well (not at Amazon; at much smaller organizations) Those paradoxes happen there.
Just my opinion: one of the key mindset shift that happens before someone steps into staff and principal engineering is understanding that the technical choices you make are tradeoffs. You give up conceits (or one should) that a technical opinion is separated from context, while also getting to deeper technical principles that appear across architectural levels or disciplines (such as queues). You also see how technical systems are inseparable from the people using it, and being a part of it.
When you start seeing that, you start seeing that everywhere. You start to act in a way that is informed from that understanding. You need to be on the critical path in order to do what matters, but you also need to connect those dots that are overlooked.
But that is also one flavor of principal engineering. I tended to do the horizontal influence than deep technical and domain expertise. At early stage startups, people have to wear multiple hats, often exceeding the scope of what they were initially hired for.
This is a bit reductive and I’m surprised to see this sort of take on here.
Technically that’s true of any step change - a junior developer is expected (loosely) to fix the bugs and do the tasks, to the spec. They should ask for help early and often, and should have enough slack in their estimates from their leads that they have time to mess up to learn. If they continue to do that they will stay junior forever.
They need to learn when to ask, how to estimate and how to avoid certain pitfalls. When they stop asking the basic questions and learn to research, they’ll be promoted to mid level (which they’re already doing). To be an effective mid level though you need to start making mistakes, but in a different way. You can’t be stuck on not being able to install a tool for 3 days, for example.
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.
Meh, when I worked at AWS a few years ago, I found to average L7 to be more of a political animal than a very knowledgeable engineer. Many interactions with various L7s where they didn't understand how their own services or common software like browsers worked.
> 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.
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.
Well “there was a time” when it was more true. Now so not really. With the exodus the bar at Amazon/AWS for taken has fallen quite a bit and in many areas a leading L7+ at Amazon is maybe a B-lister at best elsewhere. Especially in competitive areas like AI and ML where Amazon can no longer attract and retain the best in the market.
See recent press on leaked internal doc about folks at AWS whining that they struggle to secure speaking spots for their folks at AI conferences because nobody sees AWS as having recognized leaders in this space.
I'm not sure, just last year a company I contracted for had the same issue, but this time with a person from Google who were trying their hardest to employ "Google-like" processes onto something that really shouldn't have been so complicated.
I think every company that has a "strong culture", no matter what direction, tends to impact people deeply enough that they try to take that with them when they join new places, often creating lots of friction and adding complexity where there shouldn't be any.
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.
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.”
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".
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.
Thank you for writing this. I worry it may be lost on a lot of people on this forum: the need to accrue and gain status is a very first-half-of-life concern for many, and leveling systems are designed to leverage this instinct for the org's behalf. For those who grew up 'gifted,' or accomplished, then it can be hard to not see themselves that way, and the title is tightly coupled to identity at a subconscious level. (Note the disproportionately negative reply to the parent's post.)
I went through a period where I cared a bit too much about an org's leveling system. Not surprisingly, I wasn't promoted, even after giving up some technical work. Eventually, I became really unhappy: I had cut myself off of any work that was fulfilling. It really did feel like I was letting some important part of myself wither away in pursuit of a bullshit hierarchy. I eventually left and joined a startup. I'm slowly remembering how much I like to write programs. Needing to work towards survival is a very tangible goal that has the benefit of making politicking and made-up titles less of a focus...for now.
It's honestly a bit scary how you can lose parts of yourself in these systems. Tread carefully if you aren't 100% into them. Also semi-convinced that some tech middle managers project their own anger/grief over leaving the IC work behind onto those rising through the ranks instead of processing it and finding a sustainable equilibrium.
> 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.
* 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.
>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 programmers
I'm a fairly senior member of a development team whose programmers have a big range of skill levels.
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.
We have no widely accepted metrics for code quality, so almost everything in software beyond “does it work” is subjective. It’s opinions and taste all the way down.
If you ask why the vast majority of people have no answer other than “because I like it that way”.
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 have one of those jobs, and I don't contribute a lot of code at work anymore (sometimes, when it makes a difference or I can help save a lot of time).
I still write code almost daily however, e.g. for personal projects or in FOSS. For one, I love it as an activity - writing code is stress-relief for me. If I don't do it for some time I really feel deprived. I also think it's necessary to keep the first-hand knowledge of stacks and tools alive and well, e.g. for effectively communicating with engineers in a way both sides will enjoy.
I also do still make a point to e.g. do a MR regularly at work, partly to make sure I know the processes and their pain points, also so I can use my clout to complain if we make engineers waste time with stupid stuff, as processes also tend to accumulate cruft over time.
And obviously I don't think of writing code as a "lowly activity". Quality and skill matter on every level.
For that matter, you can also encounter quite a lot of "the architects don't know how to code"* stereotypes, so the subtle-disdain thing can go both ways (your comment may be exemplary). I try to prove them wrong by having written more and more different stuff than most :-)
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.
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.
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).
Another way to look at it is that you’re getting to do all of the fulfilling parts of management roles (helping your team(s) to grow and develop) without the less fulfilling parts (endless meetings, budget spreadsheets, unpleasant conversations, having to give up writing code).
> 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.
At this level the job is qualitatively different from what went before - you do start as a rookie in this role, and if you only try to keep doing what you’ve done before only better then you’re not setting yourself up for success.
> Do we need to move up or out?
Not to this extent, no. If you are still a Junior after 15 years, that’s a problem and questions will be asked. But if you want to stay in a role where you keep doing what you’ve done before only better, then that’s generally completely fine and the right choice for many people.
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. 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.
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.
> 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 managing people (well), and some really excellent people don't like the core job of management, but are really really strong in some technical area, or have a broad enough perspective and enough personality to convince other people to do stuff.
In some ways, it's the software engineering world's PM, given that you have influence but not direct hierarchical power, and what matters is the amount of teams that you can influence (like sometimes this is through a piece of software, designing and building Airflow was this kind of work).
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.
A valid perspective. I don't mind influencing people in the areas I know, but I resent the politicking and being forced to do it outside my area of expertise (and I don't believe about Principal IC can really know enough about everything, like the article implies).
You worked in the design of Airflow? We're heavy users at my current company.
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".
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 corollary is if you’re in a shitty organization that just will not get better, the most positive change you can make for the world is to stop wasting your time helping them and go somewhere better, where you can make a difference.
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 to justify why it needs a Principal or you're "working on the wrong thing", sponsor, consult, explain to leadership, mentor, code, be present, do not be too present, "feel the pulse", don't attend too many meetings, don't attend too few, gently nudge, don't speak all the time, be careful about staying quiet, etc etc.
Seems like hell. And presumably, you'll get fired if things turn out badly with a project.
All that and also without a team of engineers working with you on the same problems, and you have limited formal power to actually set priorities and assign work. That sounds miserable.
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 matter and are within their areas of expertise, and evaluate possible risks early and communicate them.
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.
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.
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.
There needs to be roles for pure ICs. In deep tech orgs, it’s almost impossible to get work done unless you have a bench of folks with domain expertise, comfortable on your software, and in tune with and guiding product direction. Diluting the core IC responsibility in these orgs with mandatory influence/scope guidelines is counter productive.
That being said, when I was in the role of a principal engineer at a major tech company - my ultimate responsibility was to get the project to success. What that meant on any given week could have alignment, coding, guiding, or reviewing.
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 who can output 10x through his own work alone. As a sidenote, with AI everyone is now 10x. So it's really a 20x thing now.
> 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 be sitting alone in an office staring at a wall.
The reason why anyone would ever talk to me is because I have well over a decade of experience more than every other scientist in my org (200+ people) doing very complicated things, at scale, across many areas of AI/ML, and publishing many dozens of papers in top venues. So I know what I'm doing and can find problems, shortcuts, keep them from wasting time, find creative fixes to AI/ML issues, and see connections to business problems. Basically help scientists deliver better features faster. I can find new projects that those scientists are excited about. And I can communicate with product, managers, leaders about very complex technical ideas in ways that more junior scientists cannot.
People in my org come to me because I provide value basically. Not because they have to.
> You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort.
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. 20% is working on projects that scale with many people. 10% is strategy for new experiments and projects.
For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best.
Maybe an example would help. Sorry that I need to be a bit vague. A large project recently was going in a particular direction. I saw two months ahead of time that this direction was going to run out of steam for a combination of science and business reasons. It would end up missing metrics. Leadership was asking for something that was broadly correct but subtly wrong. I spent a month finding a new direction that was the opposite of what everyone thought we had to do, finding the right small 1-2 person experiments to derisk the new direction, get senior people to understand it and agree to it, set up the correct relationships to make it viable, and then I had the evidence to convince project leadership and management to shift. A few days later we had a VP review and the response was that they're delighted with the direction, it's far better than they ever though, and this will be a flagship for an org with tens of thousands of employees. That review would have gone horribly without what I did because the problem I saw two months ahead of time would have surfaced and the project would be seen as dying and aimless. But the team got the credit for being on top of things as a whole, not me. As it should be.
> They are managers that don't need to do 1 on 1s.
I have more 1:1s than managers, because they can afford to just tell people what to do. I need to develop junior scientists, keep relationships up, stay on top of other orgs, business priorities, etc.
Managers fail by creating chaos around them. Principals fail by becoming irrelevant.
This is much like real Principal Engineer roles I've seen.
The skeptics of the role might not have seen how easily and badly a large multiple-team effort can go astray, and the value of someone spotting the problems, and making sure they get addressed, before the product line or company is ruined.
I agree with your second sentence. But Anyone can do that, it's not a skill exclusive to principals. The idea that only certain types of people have the intelligence to spot things like this are principals is wrong.
Maybe we should think of the Principal role as complementary? If you're working on a compiler, you're going to be interacting cross-team with hardware engineering team, etc., and spotting lots of things. But someone who is looking at all the teams, and not spending so much time on compiler details specifically, will spot some things the compiler person doesn't. So together you get better coverage of problems that neither alone could spot.
Of course, once we throw differing pay grades into an organization, everything gets more complicated. And people might resent something being called "complementary", if what's bothering them is that the role in question pays better or is considered more prestigious.
Though, the Principal role is in the engineering career track of that compiler writer, if they want that kind of ulcers.
From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager. The manager has to you like as a person and some how believe that all these activities are adding value.
> From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager.
As you go up the chart you have more independence and are less tightly coupled to your manager. By the time you get to principal you should be largely independent. At the same time, you have much more responsibility.
That's just a practical problem. As your manager becomes more senior (director/VP) their scope also increases. They just cannot "manage" you the way someone would manage a more junior IC. Also at the principal level you aren't just bringing value to your manager, but to other parts of the org as well.
In other words, I can't ask my manager "what should I do today?". I cannot even imagine what his reaction would be if I asked that question.
> The manager has to you like as a person and some how believe that all these activities are adding value.
For what it's worth my manager is a great person. But he wouldn't for a moment believe anyone when they say they add value.
It's up to me to find ways to document and express my value. Figuring out how to do this is part of becoming a principal. So I keep notes, I record wins, I make sure that I do things that bring me visibility, that I present new ideas, I contribute to larger roadmaps at the org level, I make sure that other scientists can say good things about me, I help fix problems that other orgs have so that they report I was useful, etc.
>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, 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. If your work earns you no visible credit, then no one really knows what you contribute. And if no one knows, how could anyone justify promoting you in the first place.
That is the ideal. In the ideal world, principals are elevated because they have a visible history of making the system better. They build frameworks that others rely on. They turn chaos into structure. They guide teams through impossible projects. Their reputation is not something they chase, it forms naturally from the wake of their work. In the ideal, visibility is the residue of real impact. People talk about them because their fingerprints are on every success.
But the corporate world rarely functions on ideals. In the real world, power accrues to whoever is closest to power. Titles often flow through social gravity more than technical merit. Some people climb because they deliver, others because they simply survive long enough to become unmovable. The higher you go, the more politics matters and the less evidence is required. Impact becomes subjective. Influence becomes reputation. And reputation, once earned, decays slowly.
In that reality, being invisible is not a liability. It can be a strategy. 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. The irrelevant survive because they are not a threat to anyone’s ego. The company quietly carries them, paying tribute to their title while forgetting their function.
Even the ideal, though, cannot escape the need for visibility. A principal who does great work in secret still fails the fundamental requirement of leadership: to be seen. Influence requires perception. You cannot guide a culture if nobody knows you are there. Quiet impact might keep systems healthy, but it does not create belief, and belief is what organizations promote. The best engineers learn to make their results legible. They translate their impact into stories others can tell. Without that, the work disappears into the background noise of everyone else’s effort.
So there are really two systems running in parallel. The first is the ideal, where promotion is earned through visible excellence and quiet authority. It demands both impact and awareness. The second is the reality, where promotion is often granted through time served, connections maintained, and an ability to avoid friction. The ideal rewards contribution; the reality rewards endurance.
You can succeed in either system, but they ask for different currencies. The ideal asks for mastery, courage, and the discipline to lead by example. The reality asks for patience, diplomacy, and the instinct to stay useful enough but never threatening. One builds respect. The other builds stability.
And most companies, if we are honest, prefer stability. Stability requires engineers to act the way you describe but talk the way I do. You talk about the ideal, you even believe you walk it, but because no one can see your impact, no one can tell the difference.
I've held the ranking of staff in many companies. I've interacted with principals, staff, and distinguished engineers and I can tell you visibility is required to fulfill the ideal. If visibility wasn't there, than the person earned the rank through other un-ideal means.
> 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 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.
How do you get a role like this (even with the 10 year head start) without owning the organisation? Very few places I’ve worked have the kind of long-horizon pragmatism to invest in this kind of role.
Big companies tend to have Staff/Principal/Distinguished type roles. Usually those roles give you a lot of independence. But that independence means you need to be able to find projects to do and advocate for them and get them staffed and planned and executed and out to production. Often those projects can span many teams and multiple organizations, depending on how the company is structured. So I suppose the most valuable skill is being able to earn the trust of the managers so that you're able to even get them to listen to you so your stuff ends up on their roadmap.
so i do sympathize with a lot of the negative sentiments about the role here in this thread, and i think that in general there is a lot of navel gazing about the staff+ tech ic roles, there is an actual place for them as tech leads of large projects.
One way to gather the skill set is to rotate through and master different aspects of the role. First become really solid at the technical fundamentals. Then volunteer to spend some time focusing on complementary skills like project and product management (in very technical areas, where you couldn’t just hire a nontechnical person in one of those job families). Start looking out for the problems worth solving that take multiple technical experts to accomplish, and make the solution great. Maybe be a manager for a while. Understand how to make your managers for at least a couple of levels up better in some ways, and help them with that. You will become someone trusted to get the right things done well. When it comes time to find the next job, focus on carefully vetting opportunities and interviewing prospective employers at least as much as they do when hiring, to find that opportunity you can be truly great at.
If you have the skill and you're in a smaller company, you can just keep doing the role and the org will adapt to use you in it
If you have the skill and you're in a larger company they may already have a structure around it you can apply. Otherwise you should talk your manager into trying it, or you should find a new job in an org that does have this kind of role
If you don't have the skill, you should get the skill first, by making your team more effective, then make your team and all related teams more effective together
> People in my org come to me because I provide value basically. Not because they have to.
In most orgs sadly that's not why people talk to a principal. It's that the process requires it, the manager wanted them to and/or there's you i.e. someone else to take responsibility. Of course they won't tell you that directly.
I guarantee you that the "10x" engineer would not be able to co-ordinate anything with any other team or department in the company. Of course the hierarchical structure of companies means that just having good people skills, and good management skills, means better compensation. But the most important skill in any capitalist economy is organizing labor, since capitalism is a way of organizing labor, so those who are the best at organizing and directing labor are the most well compensated since they are able to produce the most profits.
This is just another stereotype. I’ve seen plenty of managers struggling to form coherent communication where an engineer would express with perfect ease. The problem with communication comes when you add layers of bureaucracy between people, often under the guise that engineers can’t communicate.
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.
If I’m understanding right, he has a side hustle as a public speaker. So the website is an ad for him.
L6 is a senior engineer - typically effecting change and setting direction within a development team (or small group of related teams)
L7 is a principal engineer - typically effecting change at org level which will impact many teams
Amazon skipping “staff” and jumping straight to “principal” seems like such title inflation
on the contrary it seems like title deflation as Amazon principal engineers typically work at a higher level than staff at most other orgs (at least I remember a Microsoft principal would be basically an Amazon L5-6 level)
Note that these are Amazon's definitions - at many companies L5 is Senior SWE and L6 is usually a lead or a step towards staff engineer.
… wait until you see their HN submission history
Welcome to Hacker News blog posts
Ha, this is true. I thought the post was quite useful beyond getting the author’s name out there.
It can get much more navel-gazing than this, such as the posts by 24yos who insist they finally figured out what life is about after working at a startup for 3 years. :)
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.
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 dislike the term "IC" too but it does at least have a stable meaning in most companies: it means you don't have direct reports in a managerial capacity.
I'd argue not every engineer is necessarily cut out for staff-level positions and responsibilities.
I've always felt staff+ was a bit of a trojan horse on the IC ladder. I understand the role and its importance to be closer to the work. But some companies really seem to love separating you from the work to be done in pursuit of the almighty iMpAcT.
I have seen extremely talented engineers not get their promo to this role because they were "too into coding." And I have advocated for one of them (w/o their knowledge), arguing the project wouldn't exist in it's current form without their technical contributions, and then witness the org retcon their judgment into a staff-level promotion without any significant change in duties.
Makes it hard to take too seriously, honestly. If the purpose of a system is what it does, then it's meant to be a miserly, inertial source of institutional status. One that can get you a lot more money, of course, so play the game as best you can without losing yourself in the process.
The value an individual provides to the company is - at best - correlated with their position in said company.
It it usually correlates even more with their ability to portrait themselves as capable.
Thankfully, there is significant overlap between these groups, but sadly not a full circle if visualized as a Venn diagram.
Agree. I wouldn't say it's broken; the somewhat-overlapping Venn Diagram metaphor is apt. But like many other domains of power, there's a persistent belief that those who are recognized (promoted) are indeed the best candidates and that false negatives eventually correct themselves.
Believing otherwise is psychologically dangerous: if the system is somewhat arbitrary, then that opens up the possibility that their promotion was also somewhat arbitrary and not under their control.
My favorite bit is all the contradictions
> 25. To get to principal, you need to put yourself on the critical path. To be effective as a principal and go beyond it, you need to actively remove yourself from it.
And
> 26. If you were promoted to principal, it’s because you’ve been acting as a principal for a while
Say you need to keep doing what you’re doing, but also change everything.
This is 100% how it works at Amazon. It is said you have to do the job (of Principal Engineer) to get promoted. But most Principal Engineers are doing a different job than the job you have to do to become one yourself. Signed, PE@Amazon for 9 years.
I think it’s how it works everywhere. People see who’s good at their job and promote them to manager; an entirely different job though people often think it needs the same skill set.
25 and 26 has been my experience with this as well (not at Amazon; at much smaller organizations) Those paradoxes happen there.
Just my opinion: one of the key mindset shift that happens before someone steps into staff and principal engineering is understanding that the technical choices you make are tradeoffs. You give up conceits (or one should) that a technical opinion is separated from context, while also getting to deeper technical principles that appear across architectural levels or disciplines (such as queues). You also see how technical systems are inseparable from the people using it, and being a part of it.
When you start seeing that, you start seeing that everywhere. You start to act in a way that is informed from that understanding. You need to be on the critical path in order to do what matters, but you also need to connect those dots that are overlooked.
But that is also one flavor of principal engineering. I tended to do the horizontal influence than deep technical and domain expertise. At early stage startups, people have to wear multiple hats, often exceeding the scope of what they were initially hired for.
This is a bit reductive and I’m surprised to see this sort of take on here.
Technically that’s true of any step change - a junior developer is expected (loosely) to fix the bugs and do the tasks, to the spec. They should ask for help early and often, and should have enough slack in their estimates from their leads that they have time to mess up to learn. If they continue to do that they will stay junior forever.
They need to learn when to ask, how to estimate and how to avoid certain pitfalls. When they stop asking the basic questions and learn to research, they’ll be promoted to mid level (which they’re already doing). To be an effective mid level though you need to start making mistakes, but in a different way. You can’t be stuck on not being able to install a tool for 3 days, for example.
You've got to change to do the next job. So you are always paid one level below the Job you are actually doing ;)
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?
Meh, when I worked at AWS a few years ago, I found to average L7 to be more of a political animal than a very knowledgeable engineer. Many interactions with various L7s where they didn't understand how their own services or common software like browsers worked.
> 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.
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.
Well “there was a time” when it was more true. Now so not really. With the exodus the bar at Amazon/AWS for taken has fallen quite a bit and in many areas a leading L7+ at Amazon is maybe a B-lister at best elsewhere. Especially in competitive areas like AI and ML where Amazon can no longer attract and retain the best in the market.
See recent press on leaked internal doc about folks at AWS whining that they struggle to secure speaking spots for their folks at AI conferences because nobody sees AWS as having recognized leaders in this space.
I'm not sure, just last year a company I contracted for had the same issue, but this time with a person from Google who were trying their hardest to employ "Google-like" processes onto something that really shouldn't have been so complicated.
I think every company that has a "strong culture", no matter what direction, tends to impact people deeply enough that they try to take that with them when they join new places, often creating lots of friction and adding complexity where there shouldn't be any.
Nicely written up in this recent Register article: https://www.theregister.com/2025/10/20/aws_outage_amazon_bra...
>Amazon brain drain finally sent AWS down the spout
Well anecdotally it now looks like the bar has been lowered from “rockstars of our industry” to folks writing self-aggrandizing slop for LinkedIn
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”)
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.
Any chance the author contributed to the wikis?
Nope. It predates the author
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.”
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".
Individual Contributor
Integrated circuit, surely? ;)
IC is an integrated circuit. And don't call me Shirley.
Synthesis: Integrated Contributor
Hail spirit of the machine. Essence divine. In your code and circuitry the stars align.
Sorry my Omnissiah is acting up again
Incident Commander
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.
Thank you for writing this. I worry it may be lost on a lot of people on this forum: the need to accrue and gain status is a very first-half-of-life concern for many, and leveling systems are designed to leverage this instinct for the org's behalf. For those who grew up 'gifted,' or accomplished, then it can be hard to not see themselves that way, and the title is tightly coupled to identity at a subconscious level. (Note the disproportionately negative reply to the parent's post.)
I went through a period where I cared a bit too much about an org's leveling system. Not surprisingly, I wasn't promoted, even after giving up some technical work. Eventually, I became really unhappy: I had cut myself off of any work that was fulfilling. It really did feel like I was letting some important part of myself wither away in pursuit of a bullshit hierarchy. I eventually left and joined a startup. I'm slowly remembering how much I like to write programs. Needing to work towards survival is a very tangible goal that has the benefit of making politicking and made-up titles less of a focus...for now.
It's honestly a bit scary how you can lose parts of yourself in these systems. Tread carefully if you aren't 100% into them. Also semi-convinced that some tech middle managers project their own anger/grief over leaving the IC work behind onto those rising through the ranks instead of processing it and finding a sustainable equilibrium.
> 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.
At higher levels or extremely specialized roles perhaps. But your typical big tech “principal” IC isn’t consistently making 7 figures.
A principal engineer makes this much money at virtually every SV company because principal is a very high level.
Yes they are
https://www.levels.fyi/?compare=Netflix%2CGoogle%2CFacebook
Job title defines your salary and size of your bonus/RSUs. Hell yeah it is your identity.
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?
Can we coin a new archetype called the "performative engineer" who plays to the leveling game ?
Why, when we're all already used to calling them boss?
Sounds like you have some beef to pick, not sure why you feel the need to discredit this person you don’t even know.
Ok fellow kid
A junior principle is as simple as this:
* 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.
Interesting article. What do they mean with: "You’ll want to be careful not to ship your org chart to customers."
Refers to Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law
> 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 programmers
I'm a fairly senior member of a development team whose programmers have a big range of skill levels.
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.
We have no widely accepted metrics for code quality, so almost everything in software beyond “does it work” is subjective. It’s opinions and taste all the way down.
If you ask why the vast majority of people have no answer other than “because I like it that way”.
I find it strange that number 1 is not about political capital and how you it got it or maintain it.
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 have one of those jobs, and I don't contribute a lot of code at work anymore (sometimes, when it makes a difference or I can help save a lot of time).
I still write code almost daily however, e.g. for personal projects or in FOSS. For one, I love it as an activity - writing code is stress-relief for me. If I don't do it for some time I really feel deprived. I also think it's necessary to keep the first-hand knowledge of stacks and tools alive and well, e.g. for effectively communicating with engineers in a way both sides will enjoy.
I also do still make a point to e.g. do a MR regularly at work, partly to make sure I know the processes and their pain points, also so I can use my clout to complain if we make engineers waste time with stupid stuff, as processes also tend to accumulate cruft over time.
And obviously I don't think of writing code as a "lowly activity". Quality and skill matter on every level.
For that matter, you can also encounter quite a lot of "the architects don't know how to code"* stereotypes, so the subtle-disdain thing can go both ways (your comment may be exemplary). I try to prove them wrong by having written more and more different stuff than most :-)
* = https://i.programmerhumor.io/2021/11/programmerhumor-io-prog...
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.
> While you should still be writing code
Did you miss this?
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).
Another way to look at it is that you’re getting to do all of the fulfilling parts of management roles (helping your team(s) to grow and develop) without the less fulfilling parts (endless meetings, budget spreadsheets, unpleasant conversations, having to give up writing code).
> 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.
At this level the job is qualitatively different from what went before - you do start as a rookie in this role, and if you only try to keep doing what you’ve done before only better then you’re not setting yourself up for success.
> Do we need to move up or out?
Not to this extent, no. If you are still a Junior after 15 years, that’s a problem and questions will be asked. But if you want to stay in a role where you keep doing what you’ve done before only better, then that’s generally completely fine and the right choice for many people.
There’s a reason burnout rates go up at staff+ levels. Expectations go up w/o a commensurate amount of managerial control.
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. 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.
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.
> 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 managing people (well), and some really excellent people don't like the core job of management, but are really really strong in some technical area, or have a broad enough perspective and enough personality to convince other people to do stuff.
In some ways, it's the software engineering world's PM, given that you have influence but not direct hierarchical power, and what matters is the amount of teams that you can influence (like sometimes this is through a piece of software, designing and building Airflow was this kind of work).
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.
A valid perspective. I don't mind influencing people in the areas I know, but I resent the politicking and being forced to do it outside my area of expertise (and I don't believe about Principal IC can really know enough about everything, like the article implies).
You worked in the design of Airflow? We're heavy users at my current company.
> Nothing is not your job.
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".
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 corollary is if you’re in a shitty organization that just will not get better, the most positive change you can make for the world is to stop wasting your time helping them and go somewhere better, where you can make a difference.
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 to justify why it needs a Principal or you're "working on the wrong thing", sponsor, consult, explain to leadership, mentor, code, be present, do not be too present, "feel the pulse", don't attend too many meetings, don't attend too few, gently nudge, don't speak all the time, be careful about staying quiet, etc etc.
Seems like hell. And presumably, you'll get fired if things turn out badly with a project.
Thanks, but no thanks.
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.
All that and also without a team of engineers working with you on the same problems, and you have limited formal power to actually set priorities and assign work. That sounds miserable.
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.
It’s a lot better than the reverse.
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 matter and are within their areas of expertise, and evaluate possible risks early and communicate them.
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.
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.
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.
There needs to be roles for pure ICs. In deep tech orgs, it’s almost impossible to get work done unless you have a bench of folks with domain expertise, comfortable on your software, and in tune with and guiding product direction. Diluting the core IC responsibility in these orgs with mandatory influence/scope guidelines is counter productive.
That being said, when I was in the role of a principal engineer at a major tech company - my ultimate responsibility was to get the project to success. What that meant on any given week could have alignment, coding, guiding, or reviewing.
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 who can output 10x through his own work alone. As a sidenote, with AI everyone is now 10x. So it's really a 20x thing now.
I've seen zero people become 10x because of AI. Conservatively it seems closer to ±0.5x and it takes a while to figure out if it's + or -
I didn't understand the point of managers until I got a good one. Perhaps you've just been unlucky
Maybe you were just bad at management and didn’t know it.
> 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 be sitting alone in an office staring at a wall.
The reason why anyone would ever talk to me is because I have well over a decade of experience more than every other scientist in my org (200+ people) doing very complicated things, at scale, across many areas of AI/ML, and publishing many dozens of papers in top venues. So I know what I'm doing and can find problems, shortcuts, keep them from wasting time, find creative fixes to AI/ML issues, and see connections to business problems. Basically help scientists deliver better features faster. I can find new projects that those scientists are excited about. And I can communicate with product, managers, leaders about very complex technical ideas in ways that more junior scientists cannot.
People in my org come to me because I provide value basically. Not because they have to.
> You tell 10x people to do 10x work and you get 10x the credit when management only is like 1x of talent and effort.
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. 20% is working on projects that scale with many people. 10% is strategy for new experiments and projects.
For the vast majority of what I do other people get 100% of the credit and my name is a small footnote at best.
Maybe an example would help. Sorry that I need to be a bit vague. A large project recently was going in a particular direction. I saw two months ahead of time that this direction was going to run out of steam for a combination of science and business reasons. It would end up missing metrics. Leadership was asking for something that was broadly correct but subtly wrong. I spent a month finding a new direction that was the opposite of what everyone thought we had to do, finding the right small 1-2 person experiments to derisk the new direction, get senior people to understand it and agree to it, set up the correct relationships to make it viable, and then I had the evidence to convince project leadership and management to shift. A few days later we had a VP review and the response was that they're delighted with the direction, it's far better than they ever though, and this will be a flagship for an org with tens of thousands of employees. That review would have gone horribly without what I did because the problem I saw two months ahead of time would have surfaced and the project would be seen as dying and aimless. But the team got the credit for being on top of things as a whole, not me. As it should be.
> They are managers that don't need to do 1 on 1s.
I have more 1:1s than managers, because they can afford to just tell people what to do. I need to develop junior scientists, keep relationships up, stay on top of other orgs, business priorities, etc.
Managers fail by creating chaos around them. Principals fail by becoming irrelevant.
This is much like real Principal Engineer roles I've seen.
The skeptics of the role might not have seen how easily and badly a large multiple-team effort can go astray, and the value of someone spotting the problems, and making sure they get addressed, before the product line or company is ruined.
I agree with your second sentence. But Anyone can do that, it's not a skill exclusive to principals. The idea that only certain types of people have the intelligence to spot things like this are principals is wrong.
Agreed, many people do that, and that's great.
Maybe we should think of the Principal role as complementary? If you're working on a compiler, you're going to be interacting cross-team with hardware engineering team, etc., and spotting lots of things. But someone who is looking at all the teams, and not spending so much time on compiler details specifically, will spot some things the compiler person doesn't. So together you get better coverage of problems that neither alone could spot.
Of course, once we throw differing pay grades into an organization, everything gets more complicated. And people might resent something being called "complementary", if what's bothering them is that the role in question pays better or is considered more prestigious.
Though, the Principal role is in the engineering career track of that compiler writer, if they want that kind of ulcers.
From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager. The manager has to you like as a person and some how believe that all these activities are adding value.
> From what little I have seen, this kind of role is tightly coupled and dependent on the their Manager.
As you go up the chart you have more independence and are less tightly coupled to your manager. By the time you get to principal you should be largely independent. At the same time, you have much more responsibility.
That's just a practical problem. As your manager becomes more senior (director/VP) their scope also increases. They just cannot "manage" you the way someone would manage a more junior IC. Also at the principal level you aren't just bringing value to your manager, but to other parts of the org as well.
In other words, I can't ask my manager "what should I do today?". I cannot even imagine what his reaction would be if I asked that question.
> The manager has to you like as a person and some how believe that all these activities are adding value.
For what it's worth my manager is a great person. But he wouldn't for a moment believe anyone when they say they add value.
It's up to me to find ways to document and express my value. Figuring out how to do this is part of becoming a principal. So I keep notes, I record wins, I make sure that I do things that bring me visibility, that I present new ideas, I contribute to larger roadmaps at the org level, I make sure that other scientists can say good things about me, I help fix problems that other orgs have so that they report I was useful, etc.
>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, 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. If your work earns you no visible credit, then no one really knows what you contribute. And if no one knows, how could anyone justify promoting you in the first place.
That is the ideal. In the ideal world, principals are elevated because they have a visible history of making the system better. They build frameworks that others rely on. They turn chaos into structure. They guide teams through impossible projects. Their reputation is not something they chase, it forms naturally from the wake of their work. In the ideal, visibility is the residue of real impact. People talk about them because their fingerprints are on every success.
But the corporate world rarely functions on ideals. In the real world, power accrues to whoever is closest to power. Titles often flow through social gravity more than technical merit. Some people climb because they deliver, others because they simply survive long enough to become unmovable. The higher you go, the more politics matters and the less evidence is required. Impact becomes subjective. Influence becomes reputation. And reputation, once earned, decays slowly.
In that reality, being invisible is not a liability. It can be a strategy. 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. The irrelevant survive because they are not a threat to anyone’s ego. The company quietly carries them, paying tribute to their title while forgetting their function.
Even the ideal, though, cannot escape the need for visibility. A principal who does great work in secret still fails the fundamental requirement of leadership: to be seen. Influence requires perception. You cannot guide a culture if nobody knows you are there. Quiet impact might keep systems healthy, but it does not create belief, and belief is what organizations promote. The best engineers learn to make their results legible. They translate their impact into stories others can tell. Without that, the work disappears into the background noise of everyone else’s effort.
So there are really two systems running in parallel. The first is the ideal, where promotion is earned through visible excellence and quiet authority. It demands both impact and awareness. The second is the reality, where promotion is often granted through time served, connections maintained, and an ability to avoid friction. The ideal rewards contribution; the reality rewards endurance.
You can succeed in either system, but they ask for different currencies. The ideal asks for mastery, courage, and the discipline to lead by example. The reality asks for patience, diplomacy, and the instinct to stay useful enough but never threatening. One builds respect. The other builds stability.
And most companies, if we are honest, prefer stability. Stability requires engineers to act the way you describe but talk the way I do. You talk about the ideal, you even believe you walk it, but because no one can see your impact, no one can tell the difference.
I've held the ranking of staff in many companies. I've interacted with principals, staff, and distinguished engineers and I can tell you visibility is required to fulfill the ideal. If visibility wasn't there, than the person earned the rank through other un-ideal means.
> 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 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.
How do you get a role like this (even with the 10 year head start) without owning the organisation? Very few places I’ve worked have the kind of long-horizon pragmatism to invest in this kind of role.
Big companies tend to have Staff/Principal/Distinguished type roles. Usually those roles give you a lot of independence. But that independence means you need to be able to find projects to do and advocate for them and get them staffed and planned and executed and out to production. Often those projects can span many teams and multiple organizations, depending on how the company is structured. So I suppose the most valuable skill is being able to earn the trust of the managers so that you're able to even get them to listen to you so your stuff ends up on their roadmap.
so i do sympathize with a lot of the negative sentiments about the role here in this thread, and i think that in general there is a lot of navel gazing about the staff+ tech ic roles, there is an actual place for them as tech leads of large projects.
One way to gather the skill set is to rotate through and master different aspects of the role. First become really solid at the technical fundamentals. Then volunteer to spend some time focusing on complementary skills like project and product management (in very technical areas, where you couldn’t just hire a nontechnical person in one of those job families). Start looking out for the problems worth solving that take multiple technical experts to accomplish, and make the solution great. Maybe be a manager for a while. Understand how to make your managers for at least a couple of levels up better in some ways, and help them with that. You will become someone trusted to get the right things done well. When it comes time to find the next job, focus on carefully vetting opportunities and interviewing prospective employers at least as much as they do when hiring, to find that opportunity you can be truly great at.
If you have the skill and you're in a smaller company, you can just keep doing the role and the org will adapt to use you in it
If you have the skill and you're in a larger company they may already have a structure around it you can apply. Otherwise you should talk your manager into trying it, or you should find a new job in an org that does have this kind of role
If you don't have the skill, you should get the skill first, by making your team more effective, then make your team and all related teams more effective together
> People in my org come to me because I provide value basically. Not because they have to.
In most orgs sadly that's not why people talk to a principal. It's that the process requires it, the manager wanted them to and/or there's you i.e. someone else to take responsibility. Of course they won't tell you that directly.
I guarantee you that the "10x" engineer would not be able to co-ordinate anything with any other team or department in the company. Of course the hierarchical structure of companies means that just having good people skills, and good management skills, means better compensation. But the most important skill in any capitalist economy is organizing labor, since capitalism is a way of organizing labor, so those who are the best at organizing and directing labor are the most well compensated since they are able to produce the most profits.
The most competent engineer I've ever worked with, the only one I'd consider 5x+, was fantastic at cross team collaboration.
This is just another stereotype. I’ve seen plenty of managers struggling to form coherent communication where an engineer would express with perfect ease. The problem with communication comes when you add layers of bureaucracy between people, often under the guise that engineers can’t communicate.
Yet another in the ever lengthening list of "have you seen how fantastic I am" ego stroking write ups disguised as a technical blog post.
#28 is concerning. Sponsorship? Consultancy?
Can you explain what you find so concerning about it? Surely consulting is a part of the job description of Principal engineers