11 ms·
Advice for new principal tech ICs (i.e., notes to myself)
- abetusk 11mo agoIndividual Contributor
- taneq 11mo agoIntegrated circuit, surely? ;)
- trashtensor 11mo agoSynthesis: Integrated Contributor
- dotancohen 11mo agoIC is an integrated circuit. And don't call me Shirley.
- ninetyninenine 11mo agoIn 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.
- DiscourseFan 11mo agoI 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.
- BobbyJo 11mo agoThe most competent engineer I've ever worked with, the only one I'd consider 5x+, was fantastic at cross team collaboration.
- microflash 11mo agoThis 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.
- lumost 11mo agoThere 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.
- light_hue_1 11mo ago> 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.
- jackblemming 11mo agoThe 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.
- shermantanktop 11mo ago> While you should still be writing code Did you miss this?
- questionableans 11mo agoIt’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.
- rixed 11mo agoSure! You mean writing documentation, aligning divs, writing tests, caring for the infrastructure, right?
- questionableans 11mo agoIf 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.
- Simon_O_Rourke 11mo ago[flagged]
- deleted 11mo ago[deleted]
- 8e8m 11mo agoThis is content plagiarized from internal wikis presented as original thought, with no citations
- LPisGood 11mo agoWow that’s quite the accusation. Any evidence?
- 8e8m 11mo ago#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”)
- archagon 11mo agoAny chance the author contributed to the wikis?
- 8e8m 11mo agoNope. It predates the author
- gajjanag 11mo agoWelcome 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.
- huflungdung 11mo ago[dead]
- YuukiRey 11mo agoI 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.
- xoac 11mo ago[flagged]
- mattgreenrocks 11mo agoHa, 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. :)
- deleted 11mo ago[deleted]
- imajoredinecon 11mo agoIf I’m understanding right, he has a side hustle as a public speaker. So the website is an ad for him.
- akdev1l 11mo agoL6 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
- trenchpilgrim 11mo agoNote 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.
- nadam 11mo agoI 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.
- nvarsj 11mo ago> 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.
- 11mo ago
- imiric 11mo ago> 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".
- questionableans 11mo agoIt’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_af 11mo agoThe 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.
- piggg 11mo ago#28 is concerning. Sponsorship? Consultancy?
- LPisGood 11mo agoCan you explain what you find so concerning about it? Surely consulting is a part of the job description of Principal engineers
- deleted 11mo ago[deleted]
- the_af 11mo agoTo 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).
- ares623 11mo agoI'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.
- deltaburnt 11mo agoIt 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.
- the_af 11mo agoI 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.
- dwb 11mo agoAre 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.
- LPisGood 11mo agoMy 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.
- swaits 11mo agoThis 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.
- conception 11mo agoI 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.
- LPisGood 11mo ago> 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?
- balamatom 11mo ago>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
- CoastalCoder 11mo agoI'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.
- sarchertech 11mo agoWe 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”.
- balamatom 11mo ago>“because I like it that way” That'd be refreshingly honest.
- tyleo 11mo agoI’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.”
- JCM9 11mo agoThere 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.
- cmiles8 11mo agoWell anecdotally it now looks like the bar has been lowered from “rockstars of our industry” to folks writing self-aggrandizing slop for LinkedIn
- deleted 11mo ago[deleted]
- CaptainOfCoit 11mo ago> 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.
- JCM9 11mo agoWell “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.
- deleted 11mo ago[deleted]
- cranx 11mo agoI find it strange that number 1 is not about political capital and how you it got it or maintain it.
- austin-cheney 11mo agoA 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.
- sys_64738 11mo agoThe 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".
- fittingopposite 11mo agoInteresting article. What do they mean with: "You’ll want to be careful not to ship your org chart to customers."
- vayup 11mo agoRefers to Conway's law: https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law