The Peterman Pod - Amazon Principal Engineer On Layoffs, Interviewing & Career Growth | Steve Huynh

Episode Date: March 2, 2025

Steve Huynh became a software engineer at Amazon with a Liberal Arts degree. He started as a Support Engineer and eventually became a Principal Engineer (top ~1% at Amazon) before starting his own career growth YouTube channel, A Life Engineered.We discuss:• Why most interview prep advice is garbage• Why most people don’t become Principal Engineers• Amazon’s performance-based layoff culture• How to avoid being laid off• Regrets & advice for his younger selfTimestamps:(00:00) Intro(00:37) Transitioning from liberal arts to tech(06:31) Becoming a software development engineer(17:37) Breaking into the tech industry today(22:56) Future of software engineering with AI(26:06) SDE1 → SDE3 promos(33:11) Perf-based Layoffs at Amazon(46:22) His Principal promotion project(59:53) Best parts of Amazon's culture(1:05:22) His best and worst managers among 20+(1:09:09) Career reflectionsWhere to find Steve:• Newsletter: https://alifeengineered.substack.com/• YouTube: https://www.youtube.com/@ALifeEngineered• LinkedIn: https://www.linkedin.com/in/a-life-engineered/• Instagram: https://www.instagram.com/alifeengineered/Where to find Ryan:• Newsletter: https://www.developing.dev/• X: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.net/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman To hear more, visit www.developing.dev

We will say no to people, even if their coding and system design is good. This guy was a principal engineer at Amazon. He conducted thousands of interviews while he was there. And last month, I went to his studio to ask him and teach me everything he knows about interviewing in big tech. He also shared a ton of unexpected stories from his promotion to principal engineer at Amazon. How many people are expected to be cut in Amazon typically? What I can say is... PIPST stands more performance improvement plan.

And then what about the worst manager you had? Yeah, I don't want to name names or anything, but... I know that you came from a liberal arts background. Your major going into college was actually English, right? Yeah, it was creative writing and English literature. So can you tell us a little bit about you getting into Amazon without a CS major? Yeah, I think just getting in as a liberal arts major, be a bit disingenuous. Both of my parents were electrical engineers. And so I've always had a

computer around the house and, you know, I used to program that computer. I still remember my first one. It was in IBM XT 8088 with 640K of RAM, no hard disk, two five and a quarter inch floppy disk. So it's a floppy disk that's actually floppy, not the hard one that you. you probably don't even remember. And so, you know, I've always been coding and since a really young age. In high school, I did the computer science AP tests. My sophomore year, I did the AB test, which was in Pascal, way back when. Pascal's a programming language.

And my junior year, it was in C++, and I did the BC test. And so I knew about the concepts of, you know, Big O algorithms and data structures, how to write programs. You know, I still remember making like a Tetris clone when I was in high school. So, you know, the fact that I broke in without a computer science degree, if you just said the part about the English degree, like I said, it's a bit disingenuous. And so I went to school. I got a liberal arts degree. I did get a minor in math and applied math, and I took some computer science courses. You know, when I got out of school, I was looking for work, and it was around 2005, 2006.

I still remember the story. I went and talked to my writing professor in one of my senior year seminars at UW, and I was like, Professor Bosworth, like, what type of job should I get? I want to be a writer. And he said, and he put his hand on my shoulder, and he was like, Steve, there's no job called writer. It's like, not yet. There is a job called waiter. And so you just have to find a way to sort of support yourself while you apply your craft.

Right. And so just finding some sort of way to eke by while you get some experience under your belt. I wasn't really turned on by that. And so I decided to. to revisit the skills that I had picked up in high school and before that. I see. So, I mean, to me, then it is disingenuous to say that as if you came from zero skill, but your resume came from zero is my understanding, right?

Because if you looked, if I was a big tech recruiter and I was looking through stack of resumes and English major comes along, you probably would not stand out when it comes to, you know, the job market. So what is the thing that you did that got you into Amazon? It was through networking. So somebody that I did AP computer science with, worked at Amazon. He went to University of Washington and got a proper computer science degree and was a software developer at Amazon. And so they needed some support engineers. And it was a contract position. And so I basically was like, can you get me an interview at the company. And I was just, I was not worried about a coding interview because of my prior experience, but also, you know, I think with support engineers, they're writing scripts and

maintaining systems. And so I got through on that interview and, you know, I was a green badge contractor for about nine months before I transitioned a full time. What's green badge mean? Just temp? Yeah, it's a temp. It's an Amazon term. Yeah. So the blue badge, would be full-time. I see. And then green badge is a contractor, yellow is like a vendor or a consultant or something. Like maybe today's environment is like a bit more intense

where people want to get into big tech and, you know, Amazon's a big name at this point. But also your resume, although it was not CS, the thing that got you in was that you knew someone and they gave you like a referral and that made a big difference. That at least got you the interview.

And then you had the skills because you were, you had been doing CS for a while. I think the way to think about it, if, you know, when I guide people trying to get a job, it takes two things. It takes, you know, some amount of opportunity and it takes some amount of study. And so you don't know when the opportunity is going to pop up. You don't know if your Uncle Daniel from church, you know, we'll talk to somebody that knows about a job opening. You don't know when that's going to land. It's very unevenly distributed where these opportunities come from. But I think over time, they will come and rear their heads or make themselves available.

I think the other side of it is the preparedness, right? So up-leveling yourself, gaining knowledge, gaining skills. That needs to occur. You can't just have the opportunity and then not have the skills, right? And so those two things need to marry. And so, you know, I think back then it was much more difficult to gain the knowledge that was necessary to get into big tech. today, you see all of these cottage industries around interview prep, getting ready for the coding interview.

None of that stuff existed when I was trying to get in. And so I think it would actually be harder back then to get your foot into the door in tech from a non-traditional background than it is today. I won't say that it's necessarily easy today. But at least in my mind, I think it was more difficult for me. Yeah, I remember when we worked on that post together, You said there wasn't even the idea of lists of leak code questions and things, and you are just collecting interview questions to prepare.

Yeah, so when I was a support engineer and they made me Blue Badge, so full-time employee, but I just wanted to be an SDE so bad. And so all I did. An SDE for the audience is software development engineer. Yeah. And so I wanted to be a software developer so bad. I just cornered everybody. I just became a collector of questions.

I was like, what do you ask during interviews? And I was like, don't tell me the answer. I'm going to go and figure it out. And so, you know, just did it the old-fashioned way, just firing up an IDE. And, you know, you don't have all these battery of test cases that get run, like, you know, with leak code and stuff now. And so, you know, generating your own test cases, you know, that's a way to sort of up-level yourself. So I feel like I did it in a, just in a time where, you know, we weren't so resource-rich. So I imagine that probably lowered the average performance of an interviewee.

And maybe because you had some extraordinary process of like collecting questions that you might have been like, you know, very outstanding when it comes to everyone. Because ultimately interview prep is a little bit competitive. You need to be better than the other people to get in. Yes and no. I think of the distribution of. demand for software developers is skewed. I just, especially today, I don't think there's a ton of demand for junior folks. I think there's an extraordinary amount of demand for senior and above.

The reality is that seniors come from mid-level and juniors. So I think the pipeline is a bit busted right now. I don't necessarily think of a ton of competition at the upper end. I do think that there is a lot at the lower end, but the competition, doesn't exist at the interview stage. I think the competition exists at the pre-qualification and selection phase. And so if you're able to catch the attention of a recruiter, say you know somebody that works at the company, or you're able to go really deep in a particular area and stand out, maybe you built an app, has some amount of customers, that's where the competition is. You need to

stand out on the selection side. By the time you get to the interview, like, it's just a matter of clearing the bar there. And so the dimension of competition is not at the coding level, I don't think. Why do you think that most interview prep advice is garbage? I think that most interview prep is non-optimal. And so, you know, there's a hyper focus on the coding interview. There's a hyper focus now on system design. but I think really people forget.

So they turn it into a test. And in some sense it is. If you can't code, then they don't want you. If you can't design a system and you're a senior, like, you know, it's not going to work out. Like if we put you in a role, you're going to be that 5% that leave, right? We don't want to do that.

And so the big overarching framework is the people on the other side of the table are trying to figure out whether they want to work with you, whether you're going to be a good fit for the culture. But people think about it in terms of a test. And so it's much more like a date than it is like at the SAT. Right. And but the, but the prep industry, the interview prep industry, it's much easier to think about it and present it as a test, right? And so I wish people would just embed this, you know, some things like, hey, behavioral interviews have an outsized impact on whether they're going to hire you and what level you're going to come in at. So instead of, say, spending 80% of your time on coding, or maybe let's say

60% on coding and then 35% on system design. And like the 5% is like the donate to charity. pie slice. Like maybe it's much more like 40%, 40%, 20%, right? Because that behavioral side, I think, is really where the match is made. And where behavioral is the 20%. I was a barraiser trainer and I trained thousands of people at Amazon on how to conduct interviews, assess talent and then level people. Before the training was, you know, now it's a set of videos, but it used to be live training. So I've trained many people on this. And what I used to say, and I'll say it right now, is the coding, so the functional parts of the interview, the coding interview, the system design interview,

those things are the anti. So they're the small blind and big blind. So I'll use a poker analogy. They're the small blind and big blind of getting into a company. And the behavioral part of the interview, that's the poker part. of poker. Right? That's like, do you have a good hand?

You're trying to beat the other hand of the other person. And so, if you thought about the coding part and the system design part as necessary but not sufficient, like that's the thing that I wish people understood. Right? We will say no to people that have poor behavioral answers. Poor, not in the sense that they don't have the experience

it needs. It's just we can recognize from far away that it's not going to be a good fit for the company. We'll say no to those people, even if their coding and system design is good. You're saying at Amazon, it's like the functional parts, like coding system design. That's like pass no pass. Yes. But once you pass it, you're leveling and the, I guess, the color behind how good you are is the behavioral. Yes. I see. Okay. So then what should people do to kind of, prevent from being down-leveled because their behavioral is bad? I think that they should spend some time on what I call packaging. So if you can package your experience and sort of communicate that packaging to your interviewer,

I think that's just optimal for both sides. So you are packaging your experience. You're communicating to them, what you're all about, how you operate, what things you've done in the past. And you can make that a good story. You can not, it doesn't have to be entertaining, but it can be efficient and you can, you know, if you are able to effectively articulate yourself and communicate it to your interviewer, I think now we're talking about empathy.

Now we're talking about things like, this is the fundamental question for interviews, is like, do I want to work with this person? That's the question that this whole song and dance for the very, the interview process is trying to figure out, do I want to work with this person or not? And I think spending some time on the behavioral side is about trying to help the interviewer answer that question. So you are just, you're really trying to act like yourself and not, you know, it's not necessarily, you want to put your best foot forward. You don't want to lie, obviously. You don't want to misrepresent yourself. But I really think,

that, you know, just being able to talk about who you are, what you're about and your experience, like that's the important part. That's the missing part from all of this cottage, like, interview prep that's going on on the internet. That's the big thing that's missing. Could you give me an example of packaging? Like what, maybe you could package your, as if you were going to sell yourself back and go back to tech. Yeah, you know, so just even something like, tell me about yourself. Right. I think people, people kind of gloss over that and they kind of run on sentence their way through it. And, you know, I think if I were to answer a question like that, it would just be like, hey, you know, my name is Steve Quinn.

I have, you know, I have a passion for back-end distributed systems. I really love to work on, you know, customer-facing products. I'm a sports fan. You know, I used to work at Amazon Ticket. and prime video sports. And, you know, I really love, like, building teams and really, you know, taking an organization's engineering culture and up-leveling it at that level.

Like, those are some of my passions, I think. I didn't prep for that. That was kind of an interview off the cuff. But, you know, hopefully you got a sense of, you know, who I am and what I'm about and the level that I operate. One thing that I like to say is that this, stories you tell, they sort of betray your level. The way that you communicate with people, they betray your level, right? And so if you have stories that are SD1 stories, right, entry

level stories, but you're trying to get a senior role, that that incongruity is the thing that's going to lead to the down-leveling. Yeah, that makes sense. And like the last thing that you said there was up-leveling teams, you're almost speaking to like a staff or hire rubric where, you know, it's not like you said, oh, I like to clean up the code or. Yeah, I love refactoring code. It's like, I do. Yeah. But that's not how I'm going to describe myself.

Yeah. Right. And so I'm trying to turn this into a video of some sort, but I just, I want to do a thing where I just talk with somebody for five minutes and I try to figure out whether they're senior or mid or staff or whatever they are. Oh, that'd be interesting. Like a blind. Yeah.

Yeah. Like you don't know and you just. Yeah. And maybe I'm, you know, maybe I'm overconfident. But I just, I feel like if I talk to a junior entry level person, I would know that they're a junior entry level person. They just, they just, just the way that they carry themselves, the, the things that they talk about, you know. Now maybe on the, you know, if they're a strong senior engineer, you know, are they going to be able to pass as a principal? Yeah, there's some, there's some places where I, you know, I'm, you know, I'm, you know, I'm, you know, I'm, you know,

might struggle, but I think I'm really calibrated in terms of level. So that's for the interview stage. What about before you get the interview right now, it's a really competitive job market. Do you have any advice for people to stand out? You have to be an outlier in some regard. And so being an outlier may mean, oh, I have a contact that can give me a referral to a big tech company. I think that if you just, if you cold, DMed some folks on a team that had an opening,

and it was, you know, you didn't like spam them, it didn't look like a, like an auto DM sort of thing or a script. You didn't sound like AI. And you were just like, hey, my name's Ryan. I noticed you work on this team and you have some openings. Like, can you tell me what it's like on your team? Like, what are the sort of things that you do on a day-to-day basis? And then also, you know, I'm a university student. I'm about to graduate in three months.

Like, how can I position myself optimally in order to get this job? I ran a poll on my Discord. And 90% of people said that if somebody did that and they were genuine about it, that they would interact with them and that they would actually extend a referral if they asked. right and so that's it that's an easy way to be an outlier in networking you know i i think about a lot you know there's this networking stuff where it's just like hey you know strengthen your your networking go up and talk to people there's this and it's american style too so it's like everybody thinks it's fake and surface level but that's not what i'm talking about right like you should do those

things but like really like networking is about making some sort of connection right and so If you're able to connect with people, they're in a spot to help you. If you can provide value to them, right? I think that's one way to be an outlier. I think if you're new and you're willing to pick up skills, hey, what's the skill that I should pick up so that I'm much more attractive to big tech or to getting a job? I think that most people should go.

deep instead of going broad. They'll be like, oh, I'm doing a React tutorial, then I'm going to learn Rusts, and then there's a machine learning Python thing with PiTorch, and they go breath, and there's no cohesion there. It's like, you know, mobile app development

and machine learning, yeah, you can make them sort of, you know, connect to each other, but at some sense it's contrived, and there's just so much to learn. And so I give the general guidance is just like, okay, well, what's the thing that interests you in a framework or a language that you are, you know, like you already know, like, how deep can you go in a particular, you know, in a thing that you already have some familiarity with?

2025, is there a top programming language that you'd recommend for someone to go deep in? The cheeky answer is English is the top programming language in 2025. What do you mean by that? we had talked about it a little bit before, but the ability to communicate yourself, the ability to package your experience and tell a good story, I think that's the thing that's the high leverage activity. In terms of languages, dude, I've been programming,

you know, I've done assembly and basic and Pascal and C and C plus, I learned C in 1990, right? Like languages are, they come and they go. I consider myself a pearl expert. Like that's no longer useful, right? And so, like the language itself, I think, in a sense, is immaterial. I think this is where I think, you know, your personal curiosity. Like, it's totally fine to pick up something that, you know, you have an affinity towards.

I think it's also totally fine to be like, hey, look at all of these jobs in Java. I don't think Java is going away or at least JVM-based languages. So I think it's totally okay to be like, well, I'm going to become an expert in Java. That's not very sexy right now. But that's a totally fine reason. So however you get there, my advice is just go deep, right? People will be like, okay, cool, well, I'm going to do a Java tutorial. And then I think an example of going deep is just being like, oh, what's going on in this virtual machine?

What are virtual machines? right what does it what does it mean to tune a garbage collector we can get it into a debate about whether you're going to shoot yourself in the foot with you know trying to tweak your Java garbage collection but if you are

willing to pop the hood on that and then sort of like take a look at what's going on in there that's a sort of thing that nobody can stop you right like you can just you can just try to go deep Steve said to go deep so I'm going as deep as I can until you get to the ones in the

zeros that are flowing through on that bus, right? Like, that is the thing that is rare. Last thing on this topic of, you know, breaking in. Recently, Zuck, he had this quote. He said on an interview that, you know, the capabilities of AI in this year will be able to produce mid-level engineer code already. Do you think that junior engineers are,

are screwed then because of that? I think it's super interesting. Maybe you should tell me you're the one that works at meta, right? But I'll say this. Folks at the CEO level, you know, they're very high performing. Their job is to look into the future. But they tend to make predictions that are,

they're not exaggerated, but they tend to make things like the timeline for which things happen. They tend to undershoot that. and then they tend to overshoot an ability. But the idea is that the vision exists and you work towards it. The fact that he says he equivocates, or at least he's hedging, he's saying mid-level engineers later this year.

If that was actually already there, he would have said senior staff-level engineers or 10-X engineers by tomorrow. The fact that he's pushing that out makes me think that the actual implement, like the rollout of a mid-level AI bot within meta is a little it's a little further away because his job is to move the goalposts just a little further than where we're at and so I so I have a little bit of doubt there now

if you want to talk about you know AI taking over some tasks yes absolutely they should you know I think when I was coming up as a mid and senior oh code generation look at these annotations we can put Lombach in our code you don't have to write getters and setters um There were, there was, you know, I have a lot of familiarity with Java. Java's a very verbose language. Oh, look, the IDE can help me refactor some code. The IDE can write some boilerplate for me. Yes, absolutely, we should be leveraging tools to make us more efficient.

But at this point, I think of AI help as an amplifier. If you just go through the different levels, if you're a non-coder, I think that you can go from zero to one very easily. Right. So we're getting to the point with products like Replit, where a non-coder could conceivably become a product manager and build like a mobile app, right? Soup to nuts from beginning to end.

But I have my doubts that if the app doesn't work exactly the way that it's intended, or they're like, hey, scale this thing to meta-scale, I don't think an AI is going to be able to do that. So I think very comfortably will be able to go from zero to one, but I don't think that it will go from like one to many. I think a one-x engineer is going to definitely turn into a 10x engineer today with the help of AI. But do I see a zero to 10-X engineer jump like later this year? I don't see it.

Okay, so then I guess moving into you being at Amazon, you went into Amazon. you converted to an SDE, and then you climbed all the way to Principal at Amazon, which I know that last jump is also very notoriously difficult. So you went from SD1 to SD2, SD3, and then Principal. Could you walk me through the high level? Maybe just tell me, you know, what was the main thing that made the difference at each level and, you know, just like a very concise high level, yeah. Yeah, I was able to get, you know, from support engineer, SD1, 2, and 3, around 3, 3 and a half years, something like that. You know, at SD1, I think it's the real focus is on some amount of independence.

So just understanding where you fit inside of the software development lifecycle, getting to the point where you can take tasks and see them all the way through, so you've gained a little bit of trust there. And you don't have to be handheld. I think that's the critical piece for junior level or SD1. I think I just want to add a caveat there, which is that doesn't mean you know everything, and that doesn't mean that you don't ask questions. It's just that you're much more comfortable asking a question if you're stuck.

You're much more comfortable surfacing an issue. There are some folks that have this idea that at SD1 or at any level, that you are completely self-contained. So self-contained is not the same thing as being independent. One of the common words I hear for that first promo is like doing things independently without guidance. Some people interpret that as I'm not going to ask for help and I got to do it all myself, which is obviously not right. But you need to know how to unblock yourself.

So it makes sense. And it's also insidious in the sense that it's not just not right so that it will hold you back for longer, It actually turns into a performance issue if you're hiding the fact that you're not able to perform or you don't know anything. If you're hiding progress because you're unsure about yourself and you sort of beat yourself up that you should know this thing. And suppose you have a task and it should take two weeks and then you're like, hey, everything's on track, everything's on track. And then the Thursday before, you're like, I've been blocked this whole time. That's a performance issue. right and so

you know there's a difference between oh it's just going to take you longer to get there to something that's actually detrimental to get to the next level I think for SD2 the word that pops into my head the most is ownership

and so you are an active participant in the software development life cycle you're much more of a steward of say your team's code base and And I just sort of think about it like, you know, hey, you're littering. Don't litter here.

And then maybe picking up some of the trash, that trash being tech debt, not actual trash in the code. You know, being able to get, you know, now you're able to leverage this independence and to start to make a contribution to the team's code base that's a little bit larger. Right? So basically every step up with SDE is kind of an argument that you deserve more scope. And so the scope of an SDE2 or mid-level engineer is, you know, at the team level, right? You understand your team's code base.

You know, you understand its weaknesses, its strengths. You can start to, you know, make suggestions about where it's going to be. At Amazon, we have an old operational culture. and so you're on call, you know how things break. You might have some ideas about how to fix some of these things. And so, you know, it's a very, you know, meat and potatoes sort of role. And, you know, this is what you need to go from 2, 2, 3. Yeah, I'm just talking about 2.

Oh, this is table stakes for you. Yeah, I think it's expectations for it. At least this is my conception of it. Right, right. And there's an eternal debate at Amazon about whether the SDs, or mid-level role is a terminal position or not. Can you retire as an SDE-2? The level granularity at Amazon is such that I think

SD2 is a very wide band. So I think at the upper levels of SDE-2, a lot of those folks are senior engineers at other companies, even within big tech, not just, you know, oh, they're a senior engineer at a smaller company or a startup. I think you're pretty strong as an SDE-2 at Amazon, just because the granularity for levels at Amazon is so terrible. And so I tend to bias towards like, yeah, actually at SDE2,

that could be a terminal level, right? Now, I don't advise that people think of it as a terminal level, but it's just a reflection of, you know, how much scope I think in SDE2 at Amazon can actually deliver against. So there isn't an up-and-out policy. Like if you were a manager at Amazon and you had someone that says, hey, I want to just stay at, you know, SD2. Is that okay?

Or would they get fired in Amazon's culture eventually? So, and it might have changed, you know, it's been close to a year since I've been gone. So I say we a lot as though I still work there. I'm still trying to train myself. I don't work at Amazon. So it's definitely up and out at SDE once. Yeah. And so if you've been at SDU1 for more than two years, you know, it's kind of like,

this is something needs to go. Is there a formal, like, you know, 24 months and then they start managing out, or it's a feel thing? I believe it's a strong, it's a progressively stronger guidance, the longer that you've been there, but it's not a 36 months and then you're out sort of thing. Yeah, yeah. I think for SD2, it's a much more interesting conversation. I think that will depend on the where the upper management, you know,

or that particular individual, where they land on whether SCE2 is a terminal level or not. And so if you happen to get a manager, this is basically like, no, you've been there for 10 years. You should be a three. If you happen to get that person, then I think it might be bad news for you. And you know, with the recent news about meta, A lot of people are likening or they're worried that meta would turn into Amazon because Amazon's famous for a culture of intense performance and cutting people who aren't making it. Yeah, from your time of Amazon, I'm kind of curious. Maybe you can give us the juicy details.

Like how many people are expected to be cut in Amazon typically? Because you were there for so many years. Is it some percentage per year or is it up to the manager's discretion? How does that work? What I can say is so I won't give an exact number. What I can say is that guidance, suppose it was 5 or 6% for the organization. That number used to be a recommendation. It would be kind of a soft one.

Hey, we need to manage out X percent of folks over the course of a year. I think in the past couple of years that has turned. into a much more, it's turned from guidance to much more of a mandate. I think coupled with the fact that up until recently they weren't doing backfills for folks, there was this sort of like, hey, keep on running because this thing's chasing you, right, from the back. I don't think that was necessarily healthy. And, you know, if I were to be quite honest, I consider myself a high performer.

And so if you're a high performer, you don't have to think about that stuff. And, you know, as much as I'd like to be empathetic about it, and, you know, I've been around some of these decisions and meetings and stuff like that. If you're down, it's hard for me to speak about what it's actually like, to feel like your job may be at stake, right? And so, you know, I think a lot of what I would tell you is just kind of cold and numbers-based. But there are real people here, right? If you, you know, getting fired from a job is, you know, that's a very, that's a highly emotional, psychological thing. So I just want to make sure that I bring that up. Maybe I'll say this.

And this is sort of how I guided other folks and other managers when they're asking me, hey, how do I think about this? The way to think about it is 5%. Suppose that was the number. So that's one in 20 people. And so just take a population of 20 people and I think there's a distribution there. And the people on the left-hand side of that distribution

in regular years where there are backfills, I think that they're not having a good time with Amazon's culture. They're not thriving, almost by definition. right we're just going to say hey everything on the left-hand side is people aren't aren't having a great time and so i think it's almost a relief that there's a way to sort of like leave a situation like that what's what's the alternative they stay and somebody that's not having a great time in amazon's culture which you know it's it doesn't have a great reputation part of me is like oh that's kind of nice that you know um it's kind of a blessing in disguise

that we would move them out. Now, without backfills, that's where I start to get a little uncomfortable because in basically any other year that they would be at Amazon, they would be totally fine. And I think even people that are sort of left shifted, but in that main part of the distribution, I think they're great. So that's where I start to go, like, this is not something that I really agree with. You're saying because it starts to cannibalize people who are,

they're doing good, but now we're forced to stackering people that were good. So suppose you had a 6% amount of folks that were let go, and that was a hard thing. And so you did all of the very tough work to identify those folks and have them move out. And now you need to do 6% of those folks that remain. And then you need to do 6% of those folks that remain. And so it's not 18%. I can't do that math. But now we're starting to talk about people that are very close to the mid point.

They're operating at a high level. And in any other year, they'd be totally fine. But now they're not. And so, you know, I have colleagues that were let go recently, and it just kind of blows my mind that they would be, that would be let go. And so I think the most amount of impact will come from folks

that say middle management where, okay, well, there's four middle managers within the sub-org right here. The bottom 6%. Six percent doesn't make sense when you're talking about four people or eight people, right? And so I was very surprised by some of the people that were let go recently.

So you said when in the past, I guess as a principal engineer, once you get higher up, you were privy to some of the conversations where people are being discussed if they're getting managed out. What happens in those conversations? How does a high level I see like you participate? Yeah, you start getting pulled in when you're a senior engineer and you definitely get pulled in when you're L7 or above. Those meetings are terrible, right? They're like three days long and you're locked up in a room and you're just sitting there talking about people and people, you start to lose the humanity, you just start to think of them in terms of, you know, the measurables, right,

and the feedback from other folks. I won't go into the specific process. But what I will say is it's not a linear algorithm. I think in a perfect world, you would just go through everybody in the org, and then you would have equal amount of time to talk about them and their strengths and their weaknesses. Typically, you just talk about the edges. And that's not a reflection of, you know, the people that are making the decisions and whether that's poor or not. It's just, it's the math. There are just too many people. And so the conversation tends to go to either side. And, yeah, it's just, it's not my favorite time of year. Yeah, no, definitely. It sounds intense, especially if they cut out some low performers and then the next iteration.

is like people where you objectively look at them and go, oh, they're solid, but you need to fork over some more people. Now, if you want to talk about meta, I think meta is on a hiring spree, if I'm not mistaken. I think, you know, if your fearless leader is saying, hey, low performers are leaving, and it's, say, at a 5% number, I think that's the number that's been floated around. I just have a sense that those folks are probably not having a good time at meta, right now. Right. Does that everybody? No. But I would say the vast majority of folks there, if you're talking about one in 20 people, 20 random people at meta, there's probably somebody

that's struggling, especially when you start multiplying that out across a large population. So because the inflow is much larger than the outflow, I wouldn't be too worried. Sounds like across big tech, there's this increased intensity. And historically, Amazon has been the one that's always had this level of increased intensity, or at least this process of like, let's manage out the low performers quickly, and let's just factor that into our processes. Given that you've been in a lot of those performance conversations, do you have any advice for the people who are on the border

where, you know, if this is how we're going to be operating in the future, people who are kind of just meeting expectations, what is the things that protects you? in those conversations that they could do for this coming year to be safe? I think it's just that. If you meet expectations, if you solidly meet expectations, if everybody across the organization met expectations, I don't think you have a 5% stack ranking,

like removing folks from the system. Right. And so, you know, I don't think that people that are, and I bristle a bit at the low performer label. I just, again, I think of it as like, the culture is not working out. There is a mismatch between me and the ambient environment at any particular company.

I don't think it's a low performer. You know how hard it is to get an offer at Meta? Like, you are not a low performer. Yeah. Right? You have to be driven. There is a song and dance that you need to, that you need to perform under pressure in front of somebody.

Like, you go and take a leech code hard, and you have to go look at some, you know, you have to code it in front of some SDE that's like got a bad expression on their face. Like you are more than qualified, you're smart as hell, and now you're working at a company, and maybe you thought it was something different

than what it actually was. What I would say is, I don't think these low performers, these so-called low performers, they should try to become high performers. Right? I think by focusing on trying to be a high performer or focusing on trying to get to the next level, there's usually a reason why you're considered,

you're labeled that way. And so try to figure out what is that dimension that you're being judged and measured against that's holding you back from meeting expectations. So I think you need to crawl before you walk before you run. What is that thing that they're doing? judging you on and then I think you should be real with your manager and you should say hey I just wanted to check in in my meeting expectations and if I'm not then like let's let's do a preemptive

plan right so PIP stands for performance improvement plan can you do a pre-PIP can you can you proactively put together a plan to get you to a spot where you're going to be safe that's what I would that's what I would recommend just be proactive about growth to get back to the median Asking your manager for a proactive PIP. I would maybe not use those words. That's hilarious. Okay, so it sounds like, I mean, obviously, meet expectations, work with your manager. Well, I don't think it's obvious.

I actually, if you took a survey of software developers and you asked them, have you used these words with your manager? Suppose you're my manager. Hey, Ryan. You know, I just started here at Meta. I just wanted to get a sense of what my, your expectations of me, what are those, right? Have you explicitly asked about expectations with your manager? I think like 25% of people have actually done that. I think most people are trying to guess at what those expectations are.

And so I think that would be my first bit of advice is just like straight up ask what expectations are and then ask if you're meeting them or not. That would go so far. Definitely. Yeah, that makes a lot of sense. I think most people, I don't know if it's being shy or what, but I feel like most ICs don't directly talk to their manager and say, I want this or, you know, how do I meet expectations?

How do I get promoted? Kind of just do the work and do it well and hope that things go well. Well, obviously there's going to be an answer. Yeah. And so it's like, hey, Ryan, Ryan, what's your expectation of me? and am I meeting it? It's like, no, Steve, you are not meeting expectations, and it's starting to become a problem.

Even that is a better situation than not knowing. Oh, yeah, for sure. Right. And so there's a mutual friend of ours, Rahul Pandy from Terra. I stole this saying from him, and I don't know if he stole it from somebody else that worked at Meta, but it's basically like bad news that's delivered early is just news. Right. Bad news that's delivered late is terrible news.

Yeah. So if you are asking about expectations and it's early in your career, it's early in cycle, you know, and they're like, hey, this is a problem. Well, now you've surfaced the issue and you have a fighting chance of actually addressing it. If you are like, hey, what's up with my expectations? Oh, it's really bad. And it's December, right? So the month's preceding performance review, you're not in a good spot.

Yeah. Right. And so I just encourage people to deliver or try to find as much bad news as early as possible. For your principal promo, I think a lot of it comes down to having the opportunity and then delivering. But it's interesting to dig into how you got the opportunity to even deliver on principle. scope. So kind of curious. Can you tell the story about how you got that? So I was reorged back into Prime Video. And so the previous team to that was a team that I cared deeply about. It was called Amazon Tickets. We sold tickets like Ticketmaster, built a bunch of

really awesome tech, filed a ton of patents. I love music. I love going to live shows. And so I was like, oh, this is great. They spun that business down. And, They reorged that whole team into Prime Video. And basically the 30 or 40 devs that were in that organization, they kind of just scattered into the wind. Right. And I had a bad taste in my mouth. And so I didn't want to talk to any other teams.

So I was basically like, okay, well, what do I have here? What they had was a team that was a team that was. focused on delivering live sports on the prime video platform. And I'm a big sports fan as well. And so I was like, okay, well, this is interesting. And then I looked around and I was like, oh, there's a bunch of principal engineers here. Okay, so cool. I can learn about what's going on there.

And there was this really big need that was there. Just the catalog work. And, you know, I just made a decision about whether I wanted to pick it up not, right? And I decided to. It was just in reality much larger than any other project that I had ever done. I wouldn't say it landed on my lap. It was a combination of staying and then sort of saying, okay, well, if I stay, I need to do this. I see. So it's some scope that principal engineers were aware of, needed to be done, was particularly difficult. It was just sitting there for someone to take it on. You took the initiative, say,

I'm going to take it and stay on this team, and then you delivered on it. Yeah, it's, you know, the way that the principles were organized back then, it's changed now, but essentially the principles were assigned to different areas, say like playback or clients or catalog or wherever they were. And the work that needs to be done was in the gaps between those orgs. So it had to be an end-to-end solution. And so even though the thrust, the main thrust of the work was in these sort of centralized services. And so that's why, you know, nobody, none of the other principles had done it.

Because they were kind of, they were doing all of this other stuff that was necessary for us to deliver. Okay. So that makes a lot sense, too, because I imagine also if you delivered on that, so each principle to each, I guess central vertical, and you're delivering some glue work. If you did that job really well, not only is the scope huge, but also these principal engineers are, you know,

they're going to have context on your work and speak to your packet and be champions for you. So I'm sure that was helpful too. A lot of people, they say getting to principal, Amazon is so difficult. People don't even recommend doing it.

You know, there's all this job hop advice. So what is the thing that usually blocks, people from going from senior to principal at Amazon? There's a lot of reasons. I think, just to back up a little bit, I am of the impression that Amazon just skipped a level. So they should just insert a staff level.

Staff level. They could do that right now. Basically, they would say, okay, well, everybody that's principal, we'll call you principals, shove staff in there, and then just say, hey, for, you know, for the really high performance,

streaming SD-3s. We're just going to move you there preemptively. And that would be so great. But I think the big problem is that you're essentially jumping two levels for that particular promotion. And so the big thing that's holding them back is that you need to jump two levels. So there's basically double the amount of criteria to get to that next level. And I think it's kind of impossible to exhibit all of the moving to criteria for principle in a year. So if you think you're ready, hey, I'm a senior engineer, I've been doing really well, I'm going to make a big push. I think it's like it's because the job is so different, because now you're influencing multiple teams. It's very difficult to find the opportunity

and then also be able to perform at a level where people would consider you for the next level, 12, 18 months. And so what ends up happening for, you know, the failure mode that I see the most is they think they're ready. They will make a push. They will get a rejection. And they will get some amount of feedback. And then what they'll do is they'll, you know, they'll just go back to their strengths.

And then they'll continue to work on their strength. They might, like, address one or two of these PC. is a feedback, but it just takes so long to close one of these cycles. And so a lot of people give up. I know so many folks that went to META and they're thriving, or they went to Google, absolutely thriving right now, senior staff, EA, you know, principal at Google, which is, you know, two levels past staff and one level above senior staff.

They're doing awesome. They just couldn't make that jump. from SDE3 to principal. And so it turns into this thing where I think there's this two-year sliding window of where you kind of have to pack in basically a new job. You have to basically be doing two jobs

because there's an anti-pattern where you just stop doing all of the things that you need to do for SDE3 and you just focus on the principal level stuff. And then performance review time comes around and then they're like, you're actually low performance at SD3, even though you're a high performer doing principal level things.

How's that possible? Like, what are those two jobs and how they're so different? Well, the reason it's possible is because performance and promotion are decoupled. Two different processes. What's the performance process at Amazon? Performance process is yearly, and then every six months, there's a smaller version of that. And then the promotion process depends on the level,

so it could be quarterly or it. It could be every six months. So they might line up generally, but the idea is that there's not a dependency on one with the other. And so if you're trying to make a big push for a promotion, and you're doing all this principal stuff, and then it's, so here's a big example. Senior engineers need to code, right?

That's a very important thing that they do. And principles are also expected to code, but not as large of a contribution generally, Like direct contribution is not rare, but it just, that needs to be balanced with their other obligations. So they might be a sponsor of a project or they might be acting as a backstop or they might be acting as a catalyst or an evangelist for a particular initiative. And so, you know, those roles, they are pan team, right? So it's cross-functional teams. There might be product teams.

or might be five dev teams. These dev teams may be spanning multiple organizations. You might act like a TPM. I was accused of that in one of my promotion assessments. It's kind of hard to figure out whether Steve's an SDE or a TPM. Kind of took offense to that. I'm like, are you kidding me, dude? And one of them came back, like, hey, you need to code more.

I'm like, I have checked in so many lines of code. And so, okay, well, there's some sporadic, you know, six months where I didn't code a lot. It's like I didn't get any credit for time served. I see. Okay, so they looked at the code delivered in those six months when you're going for principal. They looked at it, not a lot of code. And so they said, okay, we're blocking you because you're not doing the senior job. Yeah.

But principal was good because you were doing all the cross-functional. Yeah. And so then it got kicked. So then it's like, okay, well, now I'll go. go code. Right. And they'll be like, oh,

it's been, you know, it's been a long time since he's been on call. He's not in the day-to-day operations for an individual team. It's like, I've been,

you know, I was there for 18 years. I have been on call longer than probably, like time on call longer than most people's careers at Amazon. By far. I've probably been on call like four years

continuously. Yeah. And so you get feedback like that and you're just like this, like I'm battling the process now. Right. And so to be quite honest, I was promoted in 2020. And I thought I was ready at 2016. So, you know, I was promoted to senior in 2012. So it took eight years to get there. I thought I was there in 2016. And four years and you went for promo every year and they gave you like this

TPM feedback or other. Yeah, there was there were a number of obstacles. But, you know, they changed the process three times during that four year span. I, I would, I would, Just to be honest, I probably hadn't generated enough evidence that I was operating at that level. That's not to say that I didn't have the ability, but you need to generate this tangible evidence that goes into your packet. So I wasn't quite there yet. You need the support of your manager. And so there was a number of reasons why I wasn't able to get there. But a lot of it was just battling the process itself.

I don't think I necessarily up-leveled myself. I think I just became an expert in the process. of getting promoted. And so what did you learn from becoming an expert of that promo process for senior to? Yeah, I think about it. And is that a useful skill? Yeah, I think so. I think it's useful for people that are in Amazon.

I learned a couple of things. So the big ones are, don't wait to start. I think a lot of people postpone themselves. And so they're like, oh, well, after this big project lands, that's when I'll get my packet together. But the project landing may not be the thing that you would be rejected for. And so I'm a big proponent of being kind of impatient and putting your packet in early and then getting that actual feedback about where the gaps are.

So that's one failure pattern. I think the other is, you know, you do get some amount of credit for strengths in your promo packet. And so suppose your strengths are, you know, he's a great communicator. very data-driven. He does a lot of, you know, he's a strength. There's a strength with interviewing. Great coder. Cool.

Feedback. Oh, well, he's not scaling through others. He could be a better mentor. He doesn't communicate upward very well to directors or VPs. So let's work on that. You don't really have to put so much emphasis on the strengths. Just make sure that they don't regress internally. into problems, but I think you can just focus on the Delta, because that's what the promo panel

is going to do. We try to make the promo packet sticky to a particular set of individuals. And so it's like, okay, well, Ryan, you know, rejected. You get the big red stamper thing on a piece of paper. And, you know, six months later, it's like, oh, Ryan, he's not promoted yet. Okay, like, let's dig in. Again, with humans, just like the talent review process, you're going to look at the delta. You're going to look at the outliers, right? And so you're going to be like, okay, well, what changed? And just like, let's look at the evidence that's there. And so if you're able to really focus in on the areas for growth, the places where there aren't as many data points, then I think you'll be pretty successful. When you get that packet back, you're saying

there's the strengths and then there's things that blocked it. And you're saying strengths, they're good. You don't need to worry about those. Just focus on the weaknesses and closing those gaps. I would just say prioritize the weaknesses and gaps. And you just, I think about it like you're in a kitchen with a lot of pots and pans everywhere. It's like your strengths, you can put that on the back burner. Right.

But, you know, this risotto, like you're going to sit here and make sure that the risotto is good. right? It's like you're adding broth. You just can't, you have to make sure that you got that right. And so you said you were at Amazon for 18 years. Amazon's culture is very specific. They have the leadership principles. It's its own, yeah, culture. What's your favorite parts of Amazon culture? And then we'll also talk about the worst parts too. The worst parts in it. You know, I think there's some amount of Stockholm syndrome for me being there for so long. I'm drinking the Kool-Aid. I still say we, even though it's been a while since I worked here. What's your favorite Kool-Aid then?

Well, the big thing is customer obsession. Oh, yeah. I think, especially when Bezos was there, nobody ever gave lip service to the customer experience. That was the highest priority. From interns to VPs, you were always going to be doing the right thing if you had the customer in mind. Absolutely, 100%.

And I just, I think that's a great North Star. And so, you know, I think you chase profits or you focus on competitors or, you know, there's a lot of other trappings that are there. You might optimize for the wrong thing, right? If you optimize for short-term next quarter profits, it's going to bite you in the long run. If you optimize for, you know, if you're just sort of chasing, that's another problem, right? And so if you actually work backward from the customer, you know, Jeff Bezos has that saying. They're like, hey, long-term profits and customers,

those are the same thing. There's no difference there. I think that's wonderful. Another thing that I absolutely, I think, is a superpower for Amazon, is their writing culture. You know, I think the ability to write a six-page doc that was accelerated by the fact that I have a writing degree. And so I didn't realize that I had the precursor to a superpower.

or when I joined, I was worried about learning Java, right, or learning how to deploy to prod. Man, I wish people would have a college class to figure out how to, like, send an email or to be clear about, like, the work that's in front of them. And so what comes with a wonderful writing culture is a wonderful reading culture. We literally will spend the first 30 minutes of a meeting

reading the document. And then we will have a discussion afterwards. There's no, this never works. It's like, oh, I sent you the document. So after you've read the document, we're all going to get in the, no, nobody does that, right? Like, they should. It's like a best intention sort of thing, right? But the fact that you're forced to read it at the same time,

and everybody's just sort of fast forwarded to the same place, and then you can have a discussion, like, that's actually super powerful. So if someone was onboarding to Amazon, They really want to make sure they hit the ground running and plug into the culture. Would you say that's one of the most important things? Yeah, if they are curious about how we know we're doing right by the customer, yeah, I think that's a, if you have a curiosity about that, you will do really well. The writing culture, I think that's just the medium by which we express our ideas.

That's learnable. that's something that I wouldn't necessarily focus on before you joined. You said you're drinking the Kool-Aid, but there's got to be something that you don't like about Amazon culture. What would be the number one thing? I don't mind. What's that? I remember this was like a joke among my friends and I, Amazon.

There's the leadership principles, right? And there's a list of 11 or 12 things that, yeah, everyone's kind of basing everything off of. And there's one there that was just like the recurring inside joke among our friend group, which was frugality. So basically anything, anytime something was crappy or cheap or whatever, we would just say, oh, frugality. So, you know, no free food, no, there was some other things too.

Like a hardware wasn't particularly good. Yeah, you know, I think free food, that's a perk. If a company doesn't provide you food, that doesn't mean it's a bad company. So it's great on the upside, but I don't think it says very much on the other side. I do think, you know, frugality.

We have a term called being frupeed, where you are so frugal that it's kind of stupid. I had to beg, borrow, and plead for hardware. Right? Like, I'm trying to get a MacBook Pro with, like, some RAMs. so that it doesn't, like, the fan doesn't overheat when I'm running, like, building my code. It's like, if you're going to hire, you know, tens of thousands of software developers,

you won't, like, get them a computer that works. Now, I'm not saying, like, I need the top of the line thing. I just, I just need a computer. I'm a software developer. You know, give me a computer that works. You know, when intern season would come and then the interns would leave, and then the vultures would come to try to steal the monitors. Right.

And so it's just like, you know, it just reminds me like all the other twists. It's like, you know, it's like, more please. It's like you just want a little bit more gruel. Yeah. One thing that I wanted to dig into, and I guess this is switching to another topic, is in your time at Amazon, you had 17 managers over 18 years. So you've seen a lot when it comes to managers. What was it that made your best manager?

the best manager out of 17. I think I had more than 17 managers actually. Oh, really? Yeah. I think it was in the 20s last time I checked. I took a screenshot of my phone tool. You know, I think a lot about this. You know, sometimes people would complain about a micromanager,

but there's a class of folks that kind of like a micromanager. Like they kind of need to be led. They kind of need things broken down for them. I do think that a lot of what makes a good manager is personal. the ones that I resonated with, they tended to be principles-based. So not just the leadership principle stuff, but the way that they operated, they sort of reason through, you think of these principles as axioms. And so you fix certain things, and those things have implications.

And so the best managers, I think, they fixed customer obsession. They fixed things that I value, like sort of thinking ahead in the few So they were maybe willing to entertain some stuff in the short term, like a hack. But it was always within the context of like, what should we do? What's the right thing to do in the future? Okay. So like let's make a tradeoff for that. Instead of, you know, maybe some managers that I didn't like are folks that are maybe two delivery oriented.

Right. So it's just a constant death march. It's about delivery. It's about near-term delivery. So folks that kind of thought it a little bit ahead in the future And we're maybe not so constrained by what we had in front of us I see and then what about the worst manager you had out of 20 something managers Yeah, I don't want to name names or anything but

You know sometimes I think about how did we get here Right and so like we live in a in a moment right now and so I'm talking to you and so I like I can can see it, you know, a year ago he was here and a year before that he was here. And I can kind of see the progression of how you get from, you know, maybe a university student at UCLA to where you are right now. Like that progression makes sense. I think some people that I worked with, you're like, how did you get here? Like, it's sort of like the Silicon Valley thing. I forget the name of the guy that... Big head? Yeah. Yeah. It had to have been some sort of big head. scenario where, you know, he fell up, right?

Luck happened and everything just sort of landed in their lap. So, you know, I think the worst managers I had would be a combination of like not my style. Right. So again, you know, micromanager, one person is a really caring and engaged manager to another person. And then just a little bit of like WTF, like, how did you get here? I thought that the whole performance and promotion process and the hiring process was supposed to filter a certain set of folks out. And here we are. At the end of each interview, I like to go over just general reflections of people, kind of looking over the career.

What are the things that you learned and various other things? One thing that I'm curious about, because you were at Amazon for 18 years. And in this industry, that is extraordinary. People already call me fossil for being at VETA for greater than four or five years. So, you know, what kept you at Amazon so long? I think that, you know, we had talked about the number of managers that I had reported to. I had many careers, many, many careers at Amazon. So I worked on the first Kindle, and I worked on the precursor to Prime Video before I went back to Prime Video.

And I worked on in payments. So, you know, I think the fact that Amazon does so many different things has allowed me to work on a variety of different things, you know, and didn't feel like I've been on one team. It's not like I worked in the accounting department for 25 years, and they handed me a gold watch, right? And so, you know, there's a VP. I think he's still a VP in advertising Paul Kodas.

He told me one day, he said, I've never switched teams. Wow. Right? Like Amazon just kind of refactored itself around him until he was VP of ads, right? And so, great guy. And so, you know, I don't think it's to that extreme, but, you know, I had a wide variety of experiences there. And so it doesn't feel like one 18-year contiguous,

sort of experience. So it sounds like you were still challenged learning. I think when I was at Amazon for my short stint, it was difficult for me to not have wandering eyes because there were these other hot companies, recruiters were messaging me and, you know, I was just seeing that, oh, maybe I can get more somewhere else. Did you ever consider leaving Amazon? Yeah. Yeah, absolutely. I think, you know, especially early, career. It makes a lot of sense to jump companies. You know, everybody hears the common advice. It's like, hey, you want to maximize your total comp. You should be job hopping. I think that works until you get to the equivalent of senior. After that, I think, you know, you're an outlier here,

but I think after that, it makes sense to put roots down, right? The levels, at the highest levels, I don't think you're going to find a lot of distinguished engineers or principal engineers or senior staff engineers that haven't been on the team, like the jump, the thing that got them to that level, I think what you'll find is that, you know, there was like five years, you know, at least like at least three, but more like five or so, where they really stayed on the same team on the same problem. right and so you know i think if you want to min-max it what i would say is you know job hop every two years till you get to to mid maybe a little bit before and then go to um you know and then try

to put roots down if you want to become a high-level tech i see for me i think that because i was able to to go to different teams and you know because i don't have that computer science background I think staying put made a ton of sense because I felt like I didn't there was so much to learn, right? You know, there was so much code that you had access to. There were all of these wikis,

you know, these internal videos. And so I felt like I could still grow in the ways that I wanted to by staying at Amazon. I remember even when I was at Amazon, the stock was climbing like crazy. Did you have any years where you were just super overcompensated?

And if so, how much were you making in that year? So here's the thing. I would, you know, I was basically divesting and then, you know, putting money into other investments. And I won't say that I missed a lot of, like, the Amazon's climb because a lot of it was sort of invested. Right. I don't know.

I think 2020 or something like that, I probably got, like, extra 350k that I didn't deserve, you know, just from from the market returns and extra RSUs that were given to me. When I left, so 2024, on the on the vesting schedule that I was on, I would have made 750K, just not a lot compared to like the upper end of the salary ranges, but quite a bit just sort of objectively as a number to make in the U.S. at this point in time. decided around, I think, 2018 or 2019 to maybe, like, not divest my Amazon shares because it was always like, you're dumb. Like, you shouldn't put all of your eggs in one basket. But every time I sold stock, if you just look at the stock price, it was just, it was just the wrong move.

Right. And so I was like, I'm done. I'm done. I'm not going to keep every single little bit, but I'm going to keep some. And so that turned out to be okay. You said extra equity. Does Amazon have a, for high performers, like a discretionary equity or additional equity?

Not that I know of. I think compensation is largely... You're talking about like refreshers then. Yeah. Yeah, it's at the discretion of managers. And so, you know, one of my best managers, he was basically like, yolo. He was like, I'm out.

And so he hooked me up. up, you know, and left me go. But it's not like these insane, like, million dollar things that I ever got. How big of a difference to that? It was that 350 Delta is what I'm talking about. Oh, I see, I see. It's just like, that was nice. It's over four years or? No, it was, it was, just, here's 350. Okay, that's pretty good. Yeah. Yeah, it was, it was the equivalent of that. He was, he was basically on his way out and he gave it to me and then he left and then that appreciated essentially the next year, like immediately. Oh, that's amazing. It wasn't, it wasn't, here's, you didn't write me a check. It was just a combination of the,

um, of sort of getting an outsized, um, performance bonus and, and the stock price just doing really well. Okay. So over the course of your career, 18 years of Amazon, one thing that I'm curious is what was your biggest regret? Um, yeah, certain teams, I think, just, just reading the, the, the writing on the wall and making a sober decision about whether to stay or whether to leave. I think, there was a lot of inertia. I think your default mode is to just stay put for some amount of time. And I don't know if that's useful.

I guess the career regret is noticing when you're in a bad situation or a bad team and just taking the initiative to change that situation, just leave. The regret is just, did you make it a decision or not? Did you take in all of the considerations and then said, okay, I am going to continue to stay.

It's the deferral of a decision, and so the default becomes just staying put. That's the regret. It's just like, just turn it into an explicit decision. And the last question I like to ask, and I ask everyone this question, is if you could go back to you, or you just graduated college,

you're right about to enter the industry, you could tell yourself something, what would be the thing that, you want to tell yourself. I think maybe saying something around people pleasing, right? You know, in the culture that I was raised in and, you know, there are these tracks that you get on. And it's like, okay, we'll do well in school and then go get a job and then go get married. And like, you know, you have this feeling of being a head.

head or behind, right? So that relative comparison. But then also after you do a thing, after you make some sort of achievement, you're kind of looking for to someone else for validation. And I don't know if my younger self would have like listened to be quite honest with you, but, you know, just if I could somehow learn this lesson that like the person that you really need to please is yourself. Like just being like, are you doing what you want to do? Are you doing it because that's the expectation of somebody else? Are you climbing the ladder because you want to get to the top?

Or are you climbing a ladder because the ladder was put in front of you? Just examining that. That makes sense. Cool. Well, thanks so much for your time, Steve. I really enjoyed the conversation. Absolutely. Yeah, I guess now it would be the time if we,

If you want to shout out, anything that you're working on. I have my YouTube channel. It's called Life Engineers. So go and subscribe to that. I have a weekly newsletter that gets sent out. So, you know, it takes a long time to make a YouTube video. And so, you know, if you want more for me, the newsletter is there. And then if you want to chat, just join my Discord.

Awesome. Cool. All right. Well, thanks so much for your time. Steve. Really appreciate it. Absolutely.