## Intro [00:00] have not heard any other companies where the largest outages are taken so seriously by everyone the whole leadership chain operational excellence and dives deep and all these kind of things tie in together and there's this culture which you know sometimes people complain about like new external hires sometimes Amazon has had these pockets of a bunch of VPs hired from a different company or they don't join the on call don't join this F1 and it's like oh my god these bad external people who don't understand how we do things but I would say yeah the longtime Amazonians like we would sometimes have for example in AWS you'd have the engineers mirrors call where they're all discussing fixes and then sort of separately like there's also the VP SVP call of like give us the updates, what's the current status and some of this is a scale thing, right? Like Netflix is down in like half the country because there's some global networking outage and we're like talking to the backbone providers trying to get them to fix things faster. We're telling them exactly where the backbone broke because our alerts are much better than theirs. I was shocked sometimes that the connections that you have and the data you have sometimes are so mind-bogglingly big. What is it like to work at Amazon as a software engineer? Dave Anderson was an engineering manager and director of engineering at Amazon for more than 12 years. He's now retired and so can speak with more candid than usual. In our conversation, we cover engineer and manager career levels at Amazon from L4 to L10, the interview process for engineers and Amazon's unique bar raiser interview, Amazon's infamous PIP/underperformer target and how performance management actually plays out on call and incident management inside Amazon and many more topics. If you're interested in understanding how Amazon works differently than most big tech companies and why startups often have success in hiring engineers and engineering leaders from Amazon, this episode is for you. If you enjoy the show, please subscribe to the podcast on any podcast platform and on YouTube. Dave, welcome to the podcast. Thanks. Glad to be here. So, you've you've worked at Amazon as an engineering manager as a how is Amazon called? SDM. SDM. Yeah. Yeah. I started off as an SDM and then went up that engineering management chain. You were you're a software development manager. Before we get into what it's like to work as a dev manager there, you you manage and work with a lot of software engineers, what ## An overview of Amazon’s levels for devs and engineering managers [02:08] is it like to be a software developer and what levels does Amazon have for for devs and also for managers and how do they overlap? Yeah, the the the numbers overlap except for um so when you get hired out of college like the the entry level that lasts like a year and a half to sometimes more years uh is level four. That's for whatever reason we start at level four for engineers. Uh then there's level five which is like the beginnings of middle level engineer which equates to the first level of SDM. Uh Amazon technically has SDM at level five and six. Level five is more rare and it's more for you know you almost want to call it junior except no one would want to call it junior SDM because it'd be a little insulting. Um that's actually where I started. Um so there's level five and then level six is what you might what called a senior software engineer uh or a software development manager uh which is like the software development manager level six is the most common management position where you manage a two pizza team you you own your space and uh you usually don't have managers underneath you uh and that's senior software engineer which is where I would say a lot of software engineering careers end as in that's a senior position you're uh you could uh almost equate it to like a level six manager has a level six engineer in a perfect perfectly designed team which is a level six engineer would sort of be the head engineer for a team and then uh you hit level seven at Amazon which is principal software engineer uh and they would theoretically be over a group of teams the lead you know sort of directing you know and as you could imagine as you get to like larger groups you get to more broad ownership. So, uh a principal engineer would wouldn't be necessarily focused on one system because you're theoretically leading across multiple teams. So, you get more and more architecture, you know, bigger scale designs, things like that. Um and that equates to level seven manager, which is senior software development manager, uh which would be a manager of managers, the first level where you're really managing multiple teams. Then you get to level eight which is uh uh senior principal engineer uh which is just more senior bigger orgs bigger scope etc which equates to director for uh development management and then you get up to level 10 because there's no nine for whatever reason. Um I don't know if I ever got a straight answer on why there's no nine. It was like you know this idea of like a senior director position that never got created. Um but anyway, you jump up to 10 and you get to distinguish engineer or uh VP. Um which is sort of, you know, the pinnacle of where any of us normal humans would get to. This episode is brought to you by work OS. If you're building a SAS app, at some point your customers will start asking for enterprise features like SL authentication, skin provisioning, and fine grain authorization. That's where Work OS comes in, making it fast and painless to add enterprise features to your app. Their APIs are easy to understand and you can ship quickly and get back to building other features. Work OS also provides a free user management solution called OKit for up to 1 million monthly active users. It's a drop in replacement for Ozero and comes standard with useful features like domain verification, rolebased access control, bot protection, and MFA. It's powered by Radics components which means zero compromises in design. You get limitless customizations as well as modular templates designed for quick integrations. Today, hundreds of fast growing startups are powered by work OS, including ones you probably know like Cursor, Verscell, and Perplexity. Check it out at work.com to learn more. That is works.com. This episode is brought to you by Modal, the cloud platform that makes AI development simple. Need GPUs without the headache? With Modal, just add one line of code to any Python function and boom, it's running in the cloud on your choice of CPU or GPU. And the best part, you only pay for what you use. With sub-second container start and instant scaling to thousands of GPUs, it's no wonder companies like Sunno, RAM, and Substack already trust Modal for their AI applications. Getting an H100 is just a PIP install away. Go to modal.com/pragmatic to get $30 in free credits every month. That is m o d.com/pragmatic. Why do you think it starts with L4? This is so strange because at Google, Uber, I think even potentially Stripe, it all starts at L3. It's also for a historic reason, but L4 at most companies is is like the mid-level engineer. And here at Amazon, it's the entry- level one. And I I don't even know why like it. It's not like we don't have different pay scales. So So I I'm pretty sure if you get to the FC's that I I don't remember the levels for the FC workers that there's like one, two, and three, and like you know that their leveling uh fulfillment center. Sorry. Fulfillment centers. So when you get to the fulfillment centers, of which I've had very little to do in my career, so like, you know, once in a while I touch on something. So I'm pretty sure that their levels start lower. Um, ## How promotions work for developers at Amazon, and the scope of work at each level [07:04] and if you get to a few weird positions like uh QA was a position which I don't know exists anymore. It existed and then didn't and then existed again and didn't. So I don't know what the current status is. It was a quality assurance tester which is like a non not like QAE which is quality assurance engineer. uh they would be level three. So there's like this weird quirks where you'd touch level three once in a while, but for the most part, yeah, Amazon just starts off at level four. Um no idea why they decided their numbering schemes needs to start there. And how easy or or difficult are promotions? I think you kind of alluded a little bit to that when you said that a lot of people get stuck at L6, which is the senior level. Yeah, I would I would say the like four to five for engineers isn't too bad at all or or or for just about any position. I mean, you know, there's level fours for uh some other roles. Um but, uh I would say that's not too hard. If you're competent, you complete your projects on time, you hit like two years in or so on and most teams and they're just going to end up promoting you. Like, hey, look, they because the idea of like a level four is sort of like you need assistance. You know, imagine hiring someone straight out of college. Like there's very few college hires who are competent enough to be handed a project and actually work on it. It's just just think about how you were in college. like you you finished, are you really ready to work on like large scale work now? Like someone's sitting over your shoulder helping you, explaining what you're doing wrong, like don't forget to test before you push. Um so level five is sort of like you can be trusted to work on a project, not a huge project, but a decent sized project at the start of level five at least um on your own. So hopefully after a year and a half or two years of work, you've repeatedly demonstrated that you can work on your own. So you're promoted to level five. Past that you get to a lot harder. So there's this very detailed document of the criteria for what's the difference between level four to five, five to six, six to seven for both for every position at Amazon actually like there's a big archive in SharePoint last I saw um which was uh just the detailed of like at level five you and it describes it in fairly good detail. Um I mean hand wavy as you could imagine in terms of uh a a project with the scope of a team, a project with the scope of multiple teams. Yeah. Um so those are actually what's mostly used when managers uh go to write promotions. So Amazon's in comparison to a lot of companies. Amazon has a very document culture. I mean for for everything including projects, the famous six pagers, right? Yeah. Yeah. And so you write a famous six-pager for promotions as well. And so uh oh even for promotions for even for promotions and it's actually um I would say one of the aspects that's the hardest for managers and one of the big differentiators between a having a good manager and not is and one of the reasons you want a manager who can write is that your promotion document is the thing that gets you promoted or not. Um I just contrast that quickly with I I worked at face Facebook for a bit meta now. Um, and I remember being in OR there and a manager said like, "Oh, my engineer is so good. They really need to be promoted to level six." And a couple people said, "Yeah, yeah. Are you sure?" Like, "Yeah, I remember. I heard they were good." Like, "Yeah, they're good." Okay, sounds good. Moving on. And flabbergasted. I was just like, my mind was blown. I'm like, are you kidding me? Um because at Amazon, what you you have is this um document which has like a lot of required fields where you have to explain um like write this big narrative. First of all, there's some like normal fields like how long is their time in position? Uh which again is like a criteria they'll look at and say like oh only 13 months that's not very long. Are you really sure you can proponent them that fast? Like this it's a very uh um it's a hard process to get through let's say but then you have to write this narrative multi-page narrative explaining how they meet the criteria of the next level. So you know everyone has the doc of here's what a level six engineer does. You have to be able to, you know, read through that, understand what the the criteria is, and then you have a narrative where you explain how they've done that thing at the next level repeatedly. And then you need quite a few people at the next level or higher uh saying that they believe you have met the criteria for the next level. And they usually have to give some anecdotes of why they're pretty convinced that you should be promoted. And so level four to five is pretty darn easy. again like you say they completed this project, this project and this project and then a few level five engineers will write down saying, "Yeah, yeah, totally cool. Thumbs up." Uh by the time you get to like level seven to level eight, like it is serious amounts of documentation, lot you know, years worth of project completion. You have to have a lot of VPs and directors on their dock writing out narrative blocks of text explaining all the things they've done with you. Um, and so I would say that each level you go up, it gets I would probably say exponentially harder to get promoted, which is why four to five is not a big deal. 5 to six is a pretty big promotion. Six to seven is super damn hard. Like it's already hitting like levels of um slightly less bad for management, which I can explain in a second why, but um principles have like additional hurdles they have to get past sort of unfairly in my mind. um uh like technical assessments of exactly what they've done by multiple principles who seem to have incentive to say no. It's it's really tough. Um and so uh um ## Why managers feel pressure to grow their teams [12:29] and I would say in ways that makes it uh have the wrong incentives for managers. One of the big things for managers is how big is their team? Because if you're a level if you're a level six manager and over time your team scope has grown and you eventually got some more managers reporting to you and then they get more engineers and then you start getting more managers more engineers and someone looks at your team and says uh this dude has 55 people reporting to him and he's level six like that makes no sense. We really need to promote them. So, uh, managers had this sort of artificial pressure and incentive to get their teams larger, which is until recently was one of the big things almost everyone did was like a huge part of your job as a manager to grow your career was just grow your scope, figure out more projects, more teams, more everything else. You could take on Yeah. more initiative. You can almost guarantee a promotion if you just grow your team enough. Yeah. Incentives are are an interesting things. Yeah. Taking a step back, we talked about what it's like to be inside Amazon and, you know, get get hired in there. How do you get hired as as an engineer and and what what is the ## A step-by-step, behind-the-scenes glimpse of the hiring process [13:36] interview process? Is it the pretty standard, you know, the ones we know what Google and and Meta does, the you know, algorithical coding interview, etc. Or are there some unique things for Amazon? For the most part, I would say it was very very similar. Um, in fact, I would say at least when I went to Facebook, I was there for about a week and I started getting added to interview loops because they heard I was a bar razer at Amazon, which I'll explain bar razer in a second for anyone who doesn't know. Um, but I got added to the loops and I was like, "Oh my god, like this is the exact same thing." Like, everyone's doing the same thing. It's extremely similar. Uh, at least the groups I was in, we were I was just added to the loops. It was exactly the same. Nothing was different. Um so for the most part with some exceptions uh interview loops are you have five people uh you do a phone screen they they just sort of check whatever they feel like checking to make sure that you're like a vaguely competent candidate and then you have an interview loop of of usually five people of which four is usually on the team or or closely related to the team and then one person's the bar raiser who is a essentially a third party person who can veto a higher decision and they also are running the loop as in um you're you're putting someone who's very experienced interviewer on the loop to make sure that everything goes well, everyone interviews well, that you the loop is set up correctly and they have the ability to say no. Um is like their special power and so but they cannot say yes, right? So they're not the hiring who says yes? Is it the hiring manager? So a yes requires a yes from the hiring manager and the bar raiser. So it's like a a combo decision. So either one of them can say no and it doesn't happen. Now in reality once you're there long enough there's lots of ways to get around that as both the not not as a hiring manager. You can't really get around the bar raiser but um as a bar raiser a few times I've had hiring managers saying no. I'm like that's cool. I'll just pass them off to my friend here as a hiring manager like like dude quick quick before anyone else gets them. Um because sometimes hiring managers have weird opinions but um yeah for the most part it has to be yes from both the hiring manager and the bar raiser. And then like I I think we can all imagine you know the interview you're going through as as a candidate correct me if I'm wrong but you know you apply to Amazon you have the first screening you're you're through you're you're put on to maybe you have a technical pre-screening but then you have the on-site or you know it might be virtual but you'll probably have coding architecture hiring manager may maybe multiples of some of these you have all these interviews which we talked with all these people you probably think you did great on some you did on terrible some what happens behind the scenes? How does a debrief happen? So, the loop is set up and um there's at no point Amazon's very bad at consistency across all of Amazon. So, everything every just about everything I say has a grain of salt. The only thing is not is like yes, bar raisers are always included, but other than that, like I don't know how many times I've said this is the way you do things and someone else is like not at all, you're totally wrong. Which is funny because like we're both wrong. It's just um I worked in a good number of groups so I have fair confidence that I've been in you know like five six six groups at Amazon so like very different or so. So I have a pretty good idea of what's consistent. Um you set up a loop with for engineers for example you would have usually like two coding interviews a design interview if it's a senior engineer you'd add an architecture interview and then um at least one leadership leadership principle style interview which is like checking your leadership skills. Um, level four interviews are sometimes a little different because they have no leadership because they're college hires and like it's a little bit of a waste of time to spend much time asking them about times they've had conflicts with co-workers. Like, well, they've had no co-workers. They they lived in a dorm. Like, I've heard some really weird stories when I try to ask those kind of questions. Um, yeah, this one time my my uh my roommate was was staying up really late at night and I had a test in the morning. I'm like, "Okay, maybe we just move on." Okay. Um so, uh in normal interviews with experienced people, you you have all these things. Everyone takes detailed notes on both the questions they ask and the answers they give and your interpretation. Like there's three parts of a good interview notes. And everyone takes notes. You you interview independently. You shouldn't be talking in between the interviews. Like each interviewer does their thing. And you take these notes. Then you get into what we have as a debrief, a a discussion about the candidate. So the raiser leads that meeting. You start off the meeting for the most part. You start it off by saying, "Okay, everyone read." So you all start reading and you read typical across Amazon, right? A lot of meetings. Yeah. Amazon's document culture here. It's like you start off and you say, "Everyone read." And you're going to spend like if you have a depending on how long the debrief is, half an hour, hour. Like you sit there and you read, you read the questions, you read the candidates's answers, you read the interpretation of those answers. Um, and then how the rest of it proceeds is very much up to the bar raiser. like their org and like how they tend to do things. Um I usually would say like uh some version of now that you've read all the feedback are you change because oh sorry part of the uh interview notes is what is your vote for higher or not hire and so I would sort of carefully go around and say like what are your current thoughts on higher or no hire? Um not like are you I would usually not say are you going to change your mind because people are reluctant to change their mind. I like to say just like now what are your current thoughts? You've read all the feedback. Um, and you sort of get an idea of like where is the room uh landing. In I would probably say like 90% of the cases it's not all yes or all no. I would say almost always there's at least one no and one yes even on the worst or best candidates. And so you preferably then go through and try to pressure test both directions of like what happens if we don't hire this person? Like are we missing something really good or what happens if we hire this person? What's the big risk that we're overlooking? And um the bar raiser's main job is to make sure you have a really good discussion that you don't overly obsess with one little bit of feedback. You know, sometimes people are like, "Oh my god, I hated that answer. Yeah, we need to say no." And okay, that was one sentence given by the candidate for one of the interviewers like let's try not to obsess over that too much. But um uh in fact like as what you said was um sometimes you almost always you'll have a good interview and a bad interview. like that's extremely common. And so hopefully what the bar raiser is doing is making sure you have a good discussion over like everything seen and and one of the reasons in fact what we do to coding interviews almost always is because it gives you more chances to have good answers. I don't know how many times I've heard oh yeah they couldn't code their way out of paper bag and the other person says they did just fine for me and now you have a good discussion like why do we get two very different answers? What exactly did they put as their answer for the other person? let's compare them, let's take a look, you know, what kind of hints did you give, what kind of hints did you not give? You know, uh, and you just try to arrive at the idea of like, should we have them or not? So, is it fair to say that the bar raiser tries to, you know, make the the debrief a bit more fair? You know, even out things, compensate for less experienced interviewers and and maybe some of their biases given the bar raiser is it's both an experienced interviewer, but is is there like a special like training or or or like how do you become a bar raiser? Yeah, for the most part. Um, so you again orwide like there's a lot of differences across Amazon. For the most part, it's like once you've had a 100 plus interviews, sometimes 50 you can start training, but like usually 100ish interviews is when you get to um train as a bar raiser. And for the most part, the training is you watch a bar raiser do their thing for a while and then you start to do the bar razor thing while they watch and then criticize you behind your, you know, later on. um criticize. Uh and that can last anywhere from like 10 interviews to I've I've literally I've seen 50 or plus more of like they keep watching them and saying they're still not ready to do this on their own. Um depending on how picky the bar raiser is and or how bad the person in training is. Um and uh but for the most part I would say in a lot of my interviews I had more time interviewing than everyone else combined. And so a lot, you know, a lot of the bar raisers do have 400, 500, 600 interviews under their belt. And a lot of the interviewers have done 10, 15, 20. Like, so, so you are not just like a bit more trusted, you are wildly more experienced than other people on the loop. And so very frequently you're both a sort of a louder voice in the room in terms of people can just trust your opinion on these things but also I will look at their question the c I don't know how many times I've seen like the question the candidates's answer and then their interpretation I think is wrong. I'm like that's actually a pretty good answer. I can see where they were going with this and you're like absolutely wrong and I'm thinking that's actually not wrong. It's not it's an interesting you know it wasn't the approach you liked but I actually see where they were going with that and I think it was fine. So, um I would say that that's sort of where the bar raiser like thing comes in is like trying to like you said sort of fair like a fair evaluation of a candidate. Um because we're not trying to hire people who have the exact answer you have like that you know they want to hear. What you want to hire is people who can come up with good answers as they work here for many years. And so um you know one of the things you're looking for for example is more of like growth uh you know the possibility of growth like is this person willing to hear things you know sometimes it'll be in the first interview they said this by the last interview they said this other thing I'm like that's interesting like they already pivoting their answer sort of recognizing what we want to hear that's totally fine with me like if they recognize ownership is sort of a key leadership principle and they sort of switch their answers to demonstrate more ownership great like that's sort of what you want is uh people who and change their mind over time. Awesome. So once you you get hired and and you start in inside of Amazon back in your day, what was the the kind of tooling stack? And I ## The wide variety of tools used at Amazon [23:40] know it's changing these days because I'm hearing more and more of it. It's pretty much AWS which is which is super unique across all of the companies by the way like you know Google doesn't use GCP internally and Microsoft is starting to use Azure a little bit but not nearly as much and you know Meta has their own you know thing. Uh so yeah, I would say it changed it was changing over time and it dep it was actually one of the interesting things you know like I was mentioning before of people would say like you're totally wrong like no one used that. Um there were homegrown like uh web hosting stuff that we used in um marketplace back in the which was like originally was Groupa and then was multiple versions of of new web hosting platforms that that teams were building on. And you get over to AWS and they're like well obviously everyone's using all AWS systems now to build things. And I thought it was sort of funny because it's like obviously we're all using this and like a lot of teams weren't yet. Um then you move over to uh IDOs and devices and like the mobile stacks and that was pretty much using straight up like the the development tools that need to be used, you know, by Apple and by um uh Google in terms of like the Android development system and stuff. And so it it was highly dependent on what stack you're building on. Is it like a homegrown web hosting platform or are we building, you know, AWS tools or are we building devices? And um and that's one of the reasons like when we talk about like a job I didn't mention of the bar racers is also um for example I I've seen people complain that a candidate only coded in Python for their answers like and definitely a bar raiser answer for that is we don't care what language they code in because we every time you change jobs you're frequently going to use different tools. like it's just there's just such a wide selection of tools and again there's some homegrown some AWS and you want people to pivot to different tools you want them to be able to say sure I'll flip to Cotlin or something for coding because why not this team does it um or or you know this software stack we've decided to switch and you want them for the most part we want engineers to be funible to be able to switch over and you know you move over to um we had some like not C++ but C code inside of one of the AWS teams I was on, for example. And which as a side note was sort of funny because I think I knew more C than a lot of the engineers because I'm old enough to like that's what I was learning in college. Oh yeah. And so I remember them saying something about like stupid memory management and I'm like wait C like cool let me I haven't looked at the code in a while. That's not a SDM thing at Amazon. Um but I'm going to look at this like I'm sort of curious because um like you're suddenly flipping back into my wheelhouse now that you're looking at really old code. One thing I've kind of heard a few horror stories about Amazon ## How oncall works at Amazon [26:27] is on call and how brutal uh it can be. Like what is on call like? Uh how is it organized? How important is it? And I think we all know or most of us will know about Amazon's customer obsession. How does that translate onto on call? Yeah, I I think it's a super interesting and also I would say one of the more interesting differences between like Facebook and Amazon. Um, so at least in the teams I was on at Meta, like there's no emergency support. It's, you know, there's a completely separate team that was dealing with emergencies. I think that's true of Google as well. Um, at Amazon, it was like it's a core aspect of most teams way that they operate is if you wrote the code, you're also supporting it in production. And not just like when we talk about supporting, we're talking about literally you're the one deciding which fleets host your code and which data centers and how distributed do you need to be and how are you sharding your database and all this kind of stuff. It's very, you know, the ownership stack is is or the ownership leadership principle comes into play on a lot of this stuff. But that also means that your team in most cases sets up a rotation where there's someone responding to emergencies in real time when emergencies happen. And the the philosophy behind it is if there's problems with your software, you want the problems to land on the person people who know it best. And the pain of bad software lands on the people who have the responsibility to fix it. And so there's this when done well, and there's a couple caveats there. When done well, I really appreciate it. Like as a manager of a team, I've been paged in way too many times at 1 or 2 a.m. because there was a problem. But also I believe that managed like you know you go into work 2 days later after a couple big emergency nights and we say okay we're stopping all feature developments and we're fixing these problems. Right? That's that's like the the done well part is it's we are not patching this. We are not setting it to reboot every night to to fix it. We're not letting people get paged at 2 a.m. because that's ridiculous. So we're going to fix it right now. We're going to rewrite this code. Whatever. Um, I would say like contrast in the negative way. There were some systems that Facebook I remember people talking about like, "Oh, they've been having problems for months." Like they're just restarting this thing constantly. Some point in time we'll get someone to fix it. And I was like, "That's interesting because at least the teams I ran, we would have fixed that thing right away because it would like you would lose your mind if your system was always having errors like this." Um, on the other side, like the the poorly run teams where you hear like it's been nine months now and everyone is paged two or three times a night. Anytime they're on rotation, they never sleep because they're getting paged every single night. That's just a nightmare. Like that's just not okay. Things are broken there. Like that's that's a management problem. Um, I think more than anything. So yeah, so the rotations usually on most teams, let's say you have a team of like seven people, seven's a good maybe eight. uh eight people. You usually have someone go on rotation for a week. And for that week, you're responsible for responding to emergencies. On most of my teams, that would be, let's just say like two times in that week, you would be paged sometime off hours. A lot of times it's 9:00 p.m. Uh frequently it's when code gets pushed. So if you are pushing your code at 10 p.m., which is a common enough time of like, hey, we have a downtime in traffic. Let's push the code and make sure it works. The pager goes off. Um, it's not a big deal. I think when you have a team having issues and you're getting paid two or three times every night, that's just a nightmare. Um, but again, most of the time that was fixed pretty quickly. Like the engineers aren't okay with it. Hopefully the manager is not okay with it and then um you get it resolved. Yeah. Well, I I think there's always a there's always a downside of being too close to the problems, right? Because totally you do have to be responsive. But if it's set up in a way that you're actually paged for things that truly matter and matter to like let's say customers, you're you're now going to fix it faster. I I think you know we've all used software where like there were some annoying bugs and you can tell when it's there like months later that that is not paging anyone inside of they might not even know about it or people with and I think it's like can you tie responsibility for your schedule like in terms of like what are you working on next? tie that to the responsibility of responding to problems and tie that to the responsibility of having a good customer obsession and that's where it's done well right um as I I sometimes have to remind people over and over again like I'd hear from an engineer like oh yeah that was such a hard on call last week and I wasn't paying attention as a manager or something or maybe I'm the senior manager um and I'd be like what what do you mean like last week and I have to go like quickly run a report because uh usually manager is not paged into everything unless it escalates like if they can't fix it within 10 minutes, then I get paged or something. Um, and they say, "Oh, yeah, we got paged eight times last week." And I'm like, "Well, what you know, what did you have to fix?" They say, "Oh, we haven't had a chance to fix it yet." And you're like, "Oh my god." Like, dude, why are we working on anything else if you're getting paid seven times in a week? Like, that's not okay. Um, so I usually would say like you should only be okay with being on an on call rotation if you also have the capability of of saying that this is the next most important thing we're all going to work on. So I think it's not fair when you put responsibility on people if you don't give them the authority to to also redirect your resources. You know, those things have to come together. And so um I would say most teams at Amazon had that. I would and certainly there were teams where they felt like were helpless ## The general approach to handling outages (severity 1-5) [32:06] and just had a terrible time of it. Um but well-run teams you would say like they're not going to be okay with again a a bad operational situation. And then when outages happen, what is the categorization? I I think there's different levels between the severity of of the outage, right? So like a page comes in, someone decides the on call decides that it's if it's an outage and then they have to assign a level to it. How does that work? Yeah, it and it was different across teams a little bit of like what the exact severity meant again because Amazon hates consistency in all ways and for the most part. I love the lack of consistency because you can just invent things and just tell. One of my favorite things as a side note was uh someone would say like, you know, that they're doing something and I don't like it, right? And I would say I would quickly go edit our wiki and and write in a rule against whatever they just did and then say like as you can see here in this document, that's not allowed. And then they would look at the wiki and say, "Well, that's true." Okay. And I'm like, I was never called on to the fact that I just edited like the rule set or the, you know, instructions or the step-by-step whatever that I just like edited and then showed them the the instructions. It was great how people would just believe these things. Um, that was like a barra razor thing, too. It's like that's not allowed. And I am the bar raiser, so I would know these things. They're like, "Oh, okay. Cool. Smart hack." Oh, man. Yeah. With confidence, you can get past almost everything if you need to. Uh, but yeah. So, um, most of the time in most teams there's severity one through five. And five means we're never going to do fix anything because it's not doesn't doesn't matter at all. Most things are like level three, which is um it's a problem. You should work on it someday. Uh severity two is severity two and one are the ones that would like page people, make people pay attention, make their phones freak out. Um severity 2 and one are just emergencies. And for the most part, severity 2 is what we're used for most things. Severity one is like companywide emergency is sort of um uh you know, sev one. It's a it's was usually like the phrasing for it. um in certain groups like uh let's say AWS in in SEV 2 is there's a system problem and we need to fix it and you'll probably let your manager know SE one is usually like this is where I um so for a while I was on the encroation of manager you get paged in instantly for SE ones it was like you would have a big less you could set up a you know a distribution list where a whole bunch of people would get alerted for your SE one including maybe your VP maybe your SVP um for for AWS style SE ones that was frequently like I was writing to Jasse right away with a list of other SVPs and VPs on the list saying we have an AWS outage like blah ## A story from Uber illustrating the Amazon outage mindset [34:40] blah blah. So I actually have a really interesting story and one of the reasons I I asked this we had a senior director join from Amazon. He was a senior director there and he became the senior director of my of my group. Amazon doesn't have senior directors. That's that level nine thing that doesn't exist. Okay. Well, I'm not maybe a director. Anyway, people like to invent their own titles or or or maybe it was a director who became a senior director, but he was senior director, which meant that he had about like 300 engineers in his group and we we had an outage. So, my team was payments and the way Uber did it. So, Amazon SE1 was L5 like first L1 was the smallest and L3 is internal. L4 is like, you know, it's just the opposite. So, L5 is the highest out is is when it's actually companywide. So it impacts the whole product. We're actually losing revenue or something like that. And then there's like levels there's like low, high, medium or high. And my team pretty frequently had an L5 low outage which meant that payments were down in one part of the world. Typically we had a third party issue. Let's say um one of the payment methods in India just stopped working because the thing had an outage there. And it it was pretty routine for us. like this is something that we couldn't do anything about beyond alert the uh you know the third party and so we were just having one of these things and we always have a call it's kind of routine like everyone's just sitting there bored saying okay have you guys page the third party yeah we page suddenly my the this new director is in the call saying all right what's the situation can I help anyone here and I'm like it's like Jeff what are you doing here he's like it's it's a this is this is L5 right it's the highest one right like it's I was like, "Yeah, it is." He's like, "Okay, I'm here. Use me. How can put out the fire?" So then I learned that on at Amazon VPs jump onto SE one. And we were just having really casual like for us like an off five wasn't really like this. We just knew this was just our regular Ali because we had to follow we we couldn't do anything about it. But it just made me realize how Amazon's taking it way more seriously. And this this senior like jumped out of some important meeting to go there and for me it was just like whoa. like this is this is new for me. Yeah. So it it just shows I it gave me a sense of how serious Amazon seems and I have not seen any other companies or have not heard any other companies where the the the largest outages are taken so seriously by by everyone the whole man the whole leadership chain. So I think that's you know just it's a bit of a story there. Operational excellence and dives deep and all these kind of things tie in together. So, and and there's this culture which you know sometimes people complain about like new external hires. Sometimes Amazon has had these pockets of like uh you know a bunch of VPs hired from a different company where where they they don't join the on call you know don't join this F1 and it's like ## How VPs assist with outages [37:30] this like oh my god like these these bad external people who don't understand how we do things. Um, but I would say yeah, the longtime Amazonians like we would sometimes have for example in AWS you'd have the engineers call where they're all discussing fixes and then sort of separately like there's also the VP SVP call of like give us the updates what's the current status because and some of this is a scale thing right like Netflix is down like we're sitting there and like Netflix is down in like half the country because there's some global networking outage and we're like trying to also Amazon scale you know we're we're talking to the backbone providers trying to get them to fix things faster. We're telling them exactly where the backbone broke because our alerts are much better than theirs. Like there I was shocked sometimes at like uh um the connections that you have and the data you have sometimes are so mind-bogglingly big. You know, it's like you you see the news articles coming out and it's like like we know about the backbone outage in whatever place because we can see exactly where it is in the network based on all of our alerts and alarms and all that kind of stuff. But yeah, it was very expected that depending on the scale of your outage or issue going on that your VP would be joining in the call if not not usually to run it unless it's really important but definitely like um what you want and which is what you usually have is we need X done and you need it done right now. And that's the kind of thing a VP or director, whoever, you know, whoever the really senior person is is around for is um like, oh, okay, you need, you know, we need a the kind of thing that would come up sometimes is like, oh my god, we need 100 extra servers right now. You know, these big beefy things. We need them provisioned immediately in Dublin. And they say, okay, we're, you know, I'm I'm calling that, you know, the head of EC2 right now on the phone and we're going to get that, you know, some engineer to allocate those to us in the next about two minutes. And so boom boom boom they get this thing done and a bunch of servers are turning on um because the person can do the direct call and just say I need this right now and they say got it. So I think that that's useful. I mean it it sounds to me if you you know like this might sound a bit like cheeky but if if you get it to Amazon and usually being on an outage you don't really want to be on an outage as an engineer but if you're in one of these outages and it already happened it's kind of an awesome opportunity. Where else would you be able to even experience this? I have heard from I I believe like if you're talking about like um building skills in terms of like running running software, not like just writing software, but like running software, right? If you want to go to a startup and run software, um you hire like if you get an Amazon engineer who's been in the thick of things sometimes, it's like you're not just good at writing software, but you've seen what happened. like Twilio calls you know I got on the phone with you know the CTO of Twilio company you know it's like we're having this issue it's in this specific region and we're like we have engineers in the room you know we're talking to them on the phone in a separate phone call from the engineers talking about whatever test they're running on whatever trace routes and figuring things out and like the skills you build in terms of product and what can we ask the customer to do can we ask them to test something can we get access to their host so we can try something out um it's it's such a cool experience I think it sucks that it's happening at 3 a.m. sometimes, but I would say most of the time it's not because it usually problems happen when you push code. Just the way things work. Uh uh funny thing of like the amount of pages that happen when Amazon historically did lock down sometime around Thanksgiving time. You would just stop pushing code changes out in this exponential drop off in pages because changes are what breaks things in the world. Um, but yeah, I think the experience I think you you talk two years later about like, oh, we had such a good time on the team together, didn't we? You always talk about the outages and stuff because that was the exciting times at work. Yeah. Yeah. One interesting thing about Amazon that's that's also just Amazon was famous for and people get surprised for is the frugality. Yeah. Can can you tell me what you know what what engineers experience or what did engineers complain to you who joined from like ## The culture of frugality at Amazon [41:38] companies that were a bit more generous? You know, like I I worked at Uber. I visited friends at Google Meta. You have like these like, you know, just kind of standard perks like like lunch uh at at I think at Uber we had like these vending machines. You could you could get like whatever like mice free stuff from the vending machines. Yeah. Yeah. Our vending machines hardware, you know, they got a profit from our vending machines. It wasn't even like cost. Oh my god. Yeah. Um Yeah. No, no. Uh I think Amazon and there's there is some interesting points that um sometimes we've had these arguments of like oh my god like the amount of money that you pay engineers why can't you be a little bit more generous and some of it comes down to fridity like the stupid frugal thing. Um this is like just this ridiculous stupid level of frugality. Um but sometimes they do there is interesting explanations. Um because Amazon has fulfillment centers and we have the majority of Amazon's workers are very very low margin per person uh you can't afford to and then they talk about for I think legal and other reasons that they can't offer different benefits and different things perks to corporate workers versus fulfillment workers whether or not that's legal whether or not that's just like now we're at risk for unions forming across the world because they're giving unfair benefits to corporate workers. Um you look at something like uh 401k match for example was something that you know came up was like couldn't we just do a you know double the match do a you know 100% of whatever and like yeah we could for engineers but we definitely can't afford that for FC workers because our margin there is like 0.5%. If we give them any more money we're losing money on every item Amazon sells. Like we have to be very very careful. It's super expensive to have million workers. I mean for good reason like it's just expensive. So, uh, when you try to give, you know, try to give comparable benefits to corporate workers and you have these issues. Um, but then you get to just how Amazon operates is unless there's a really damn good reason to spend the money, we don't do it. And that's the same thing for resources. I think if you had to choose, I guess as a business owner, a person who wants a company to be successful, you would definitely want your company to be frugal. Like that the amount of money wasted when I was at Facebook, it just blew my mind. I mean, just some things are great. It's very relaxing to get free food. It's very and no big deal. Like, in comparison to the amount you're paid, like you calculate it out and it's like, okay, what you know, a few thousand dollar a year spent per person on food compared to their salary is nothing, so why not do it? Um, but then you get to just like the stupid levels of waste of like building products that no one needs or something like that. And at Amazon, I kept be like, "Oh my god, we would never I remember saying once like, "This project looks like a duplicate of this other project. Shouldn't we shut it down?" When I was at Facebook, shouldn't we shut it down? And they looked at me like I was crazy and like, "Why would we shut it down?" I'm like, "Well, cuz we're wasting money." And they're like, "So we have billions. Like what? What?" Like it was just kind of like confusion over like, "Why would we not build something pointlessly just for fun?" And very deep in Amazon's culture is this like we do things efficiently. Now sometime sometimes you're doing things efficiently to launch something faster. So you'll rewrite someone's code because it's faster than integrating with theirs or something like you know you're you're always balancing speed of building versus efficiency of resources and all that kind of stuff. But I think um if your if your answer is always unless there's a strong reason to do it, let's not do it leads to like at least the first half of my tenure at Amazon engineers would get like one monitor of only 16 in or something ridiculous. And um like literally and it was I mean it was both hilarious but also frustrating was like an intern would leave and before the IT group came up to take their equipment it was like the sharks would swim in all the engineers would run over and take their equipment, take their extra keyboard, take their monitor and stuff because they wanted two monitors and the only way to get it is to steal someone else's. That was stupidity but oh my god it was so stupid. But I think it is good context like just understanding where the company is coming from and that it is a unique set up in the sense that there are so many fulfillment center workers which most companies do not have and and they don't have this. So yeah, and and fix things. I mean, data driven. I've been on teams where they wrote six pager explaining why they needed, you know, the top-of-the-line Mac Pros instead of the middlegrade Mac Pros and they explained the, you know, productivity benefits and someone said, "Okay, now now you've explained it." Like finally someone came up with an actual math reason, not just like we would like it and boom, everyone got their stuff and we moved on. But um I would say like if you had to choose between frugality and not frugality, you'd want frugality. It just makes things operate better when you spend money on the things that need to be spent on and not waste time uh elsewhere. Um, but it definitely can be frustrating. Trust isn't just earned, it's demanded. Whether you're a startup founder navigating your first audit or seasoning security professional skill in your governance, risk, and compliance program, proving your commitment to security has never been more critical or more complex. That's where Vanta comes in. Vantic can help you start or scale your security program by connecting with auditors and experts to conduct your audit and set up your security program quickly. Plus, with automation and AI throughout the platform, Vanta gives your time back so you can focus on building your company. Businesses use Vant to establish trust by automating compliance needs across over 35 frameworks like SOCK 2 and ISO 2701. With Vanta, they centralize security workflows, complete questionnaires up to five times faster, and proactively manage vendor risk. Join over 9,000 global companies to manage risk and prove security in real time. For a limited time, my listeners get $1,000 off Vant at vanta.com/pragmatic. That is van na.com/pragmatic for $1,000 off. Now, one thing when I did my Amazon deep dive on on Amazon's engineering culture, one kind of one of the most negative things ## Amazon’s URA target—and why it’s mostly not a big deal [47:27] that came up was Amazon's so-called UR target, unregulated attrition target, which if rumors have it that every year about 6% of staff is expected to leave as unregulated attrition and what this results in is basically uh focus plans, which which is what comes before PIP and and there's pips and and the people I again I have friends at Amazon and many of them mentioned that either they were on a PIP or they had a someone else be be on a PIP. There there is a bit of a you know scare uncertainty especially for for people entering Amazon. You were on the other side of this. You were a manager plus you clearly you were also like maybe sub subject to this on your end. How scary is this and how does it play out in in reality? I would say for most people it wasn't scary and it like so you know at various times it was between six to 10% of people had to be it and exact exactly what's measured was a little different over time of like whether or not you were like 6 to 10% had to be rated poorly or 6 to 10% had to be put into like coaching or whatever or 6 to 10% had to be fired. um sometimes different levels of goals in terms of like the cascading level of like as you're managing people out there's goals to hit. Um but I would say it wasn't scary for the vast majority of people because you're looking ahead. You're thinking about how do I get promoted? How do I, you know, do these projects well so I can get ahead in my career. I don't think you're I don't think most people are thinking I'm probably in the bottom 10% of all my peers, right? I think most people don't think that you're not worried about being the bottom 10%. And I would say until it pops up, right? You move to a new team, your manager doesn't like you, and you think about like, huh, my manager doesn't like me and seems to like all my peers. Suddenly, it becomes very scary because I I've actually heard this from people I know of the same story that I they've been with Amazon for some time, great, either a new manager came or they moved to a new team and that's when things became, you know, I actually had a friend who was put on a pip. He thought it was really unfair. He was there for 4 years. He actually made it out of it, but he he kind of became bitter, especially if she was his manager. Almost never happens. Yeah. Yeah. Uh he he actually turned it around, but yeah. Still, yeah, I think there's a few a few edge cases where people can make it out of pips. And mostly that I would say the vast majority of people who get out of those is something like a college hire. And you know, this is just a common thing. I I make fun of college hires because of like how much they move from kids to adult over time, right? Like you're you're in college and you're a kid and then you become an adult. how many times they get hired and like they're three months into their job and I see them posting on Instagram at 4 in the morning and then the next day they don't show up to work and they're like, "I was sick." I'm like, "Yeah, I bet you were sick." Like alcohol poisoning is definitely an illness. Um, like that's kids, right? Like it's like, "Dude, you haven't done any work in two weeks and you're out late and you show up to work at 1 p.m. Like then then you can get a pit that you can get out of because they decide to buckle down and actually do their work. Yep. you let them back out because you think they're competent. They're just need to grow up. Um, but if you think about like the the incentives, right? You're you're running a team. I have 50 people working for me. Uh, because usually like the the criteria of that like six to 10% is only if you're in a big enough or work. So, let's say I have 50 people. So, now the criteria hits me because usually it's 50 or or so when you start to have these expectations. Um, if I need to rate 10% of my team poorly, let's say, and I have 50 people, that means I need to find five people by the time the review period rolls around. I need to be like considering who's not doing great. Um, review period is every six months, every 12 months. 12 months. Yeah. 12 months. Yeah. Yeah. And it again like at various times we had checkpoints, six month checkpoints. Sometimes HR would care that you're flagging people. Sometimes it's like a a um for the most part, especially when you're talking about like firing people, it would be like by the end of the year, you need to have fired 65 people. And sometimes it's like, well, we already did four along the year because of various things that happened. So the fifth one is the only one we're looking for. And so you're going through the review period with your 50 people and you need to find one person. It's not a big deal, right? You talk to that would probably be like seven or eight managers at least. one of them has some employee who's not doing great or one of your managers is annoying as hell and so you like no you're okay. Um but uh um I would say it it becomes an issue when your team especially if your team is more stable like if you're constantly hiring people like there's always going to be new blood someone wasn't interviewed well someone's just like not at all suited to be here and that makes it easy. when your team's more stable and you've been for the most part with the same people for two years and you're running into yet another review cycle and you're like, "Oh my god, like we already got rid of everyone who was not doing great. Everyone on my team is doing well." Now you end up in frustrating situations. Um, and it most of the time I would say it was it was not a big deal and wasn't that stressful because uh it again those those expectations don't come into play until you have a bigger organization. So like you're a dev manager and you'd say no, everyone on my team's good and as long as you have backbone, you're okay with that. And then you get to be a senior manager and you have 47 people. The criteria doesn't apply to you still. Now you start to have like, you know, boy, you have 47 people, you have no one underperforming. Are you sure? Like 47 people. Like now you start to get to the point where your manager sits down with you and says, let's go through and tell me the bottom five people of your or why they don't deserve to be rated as least effective. Um, and then you get to bigger orgs and that's where you get this weird like the organizational pressure of like now you hit your director. You know, I have 150 people reporting to me. I need to come up with the I don't know 11 people who are in coaching by the end of the year or something. And like now I sit down with my managers and say, "Okay guys, like we have eight. I need 11." Like sorry, we we have to talk through all the people who are like on that borderline and explain why they're not whatever at this level. um because for the most part they they were very very hard asses on making sure that you hit these um the the goals. And then from a software engineer perspective, you know, you're kind of like blissfully ## How managers handle the ‘least effective’ employees [53:37] unaware. You're kind of working away. Let's imagine that you know like one day your manager probably had this like discussion with their director or you know their manager and they identified you as as someone. Usually when when this happens you know like you kind of in in your group you circle down on like all right this is this person these are the people who are underperforming. Yep. Is is there also a part where there is like reasoning given of why so that the manager can go back and say like all right here's here's the difference here's why you're not meeting expectations or is it just more like well you know you're you're b you're bottom of the pile like sorry here's a pip. So, so I guess the first thing to say is like there there's often a definition issue and even even with the managers sometimes like boy this is where managers screw up the most often and you almost need like a bar razor for HR processes. Um the description of that lowest rating and the description of letting people go is all about not not meeting expectations. It is least effective. And so the argument is we explain to people is if we have a hundred people we want let's just let's just you know pick an easy number you know the bottom 5% five people out of that hundred we want the least effective of them it doesn't mean not effective it doesn't mean that they're not doing their job but if you pick the bottom five people and say would you rather keep them or would you rather interview and find someone who might be just this amazing awesome hire and most of the time you would say well I mean the bottom five out of a 100 people aren't great. Like they might be okay at their job comparatively, right? Comparatively, like they're they're a fine, let's just say, engineer, right? They're they're a fine engineer. Most people get that work done in a week and it takes them two weeks because they're slower. Like it's just like they're not great. If their manager is doing well, their manager has been telling them this all along is like, "Hey, do you notice that your work is getting done slower than everyone else on the team?" Right? Because again, this is the bottom five of a hundred. Like they're slower than everyone else. they're making more mistakes, like whatever it is that makes them at the bottom. Hopefully, they've been getting feedback along the way. And then in this discussion that inevitably happened, right, you have all the managers in a room with their senior manager, maybe with the director, and you're having detailed discussions. And we're saying, "Okay, their productivity is lower. They make a lot of mistakes. their peers complain a lot about them because almost always there's like a lot of peer like I really don't want to work with Dave on this one because boy Dave always is slower and you have to do most of the work for Dave right so you have this collaborative discussion with whatever feedback you have available to say okay definitely Dave has to be in that bottom five now hopefully again the manager of Dave has been giving him feedback throughout the year and and maybe this happens not at the very end of the year like preferably it's not just like all of a sudden wham everyone gets surprised. Um but if it has happened then yes you you the manager should be able to sit down and say you are being rated as least effective or you're being put into coaching or whatever you know whatever it is the step is because here's the the you know the situation you know you in the last four sprints you know specifically in the last four sprints you have missed your you know your uh projects haven't been completed like we thought would be completed in the sprint every single sprint for the last four sprints we've already talked about this Um the issue usually comes up is if the manager has been saying you're awesome, you're awesome, you're awesome, and then suddenly like terribly sorry, you're in coaching now because you're not awesome. And that I've actually heard quite a bit that the problem that some some of the people that I talked with who were in the situation, their manager was new or did not understand and some of those things. But this this does make sense. In some ways, it feels to me, correct me if I'm wrong, but this feels somewhat similar to Netflix in the sense of, you know, Netflix is also very open about having the keeper test where they re regular re-evaluate people. And they're not saying you're not meeting expectations. They're just like, well, if if someone is not, they actually do the other way around. They're saying if someone is not worth fighting for keeping, y we we don't necessarily want to retain them. In fact, we might let them go. And they're they communicate this up front. Whereas with Amazon, if I understand, they're saying you're the least effective, which again, people got into Amazon, it's it's it's hard to get into. They're typically good engineers. They might they might be awesome at a lot of places, but Amazon says, "Okay, let's you know, we we want to this is this is their performance philosophy." Yeah. Yeah. And I think a good number of the times if you talk to someone and say like you know someone who's getting this kind of feedback and they're saying but I did complete that eventually or something like that and say but do you agree that every person on the team would have gotten that done faster than you? Like you know it's well yes. is like okay so at least you would agree out of your 11 peers on the team that you are the slowest engineer like you know it's like I think people understand one of the hard things is just like the difference between least effective which is just like hey at the bottom of the pile you're all you're going to be at risk if you if you think if you look around the room and you're thinking yep I'm the worst one here that's not a great situation to ever be in um it's just never safe and at Amazon it's definitely not safe at some other companies where they just might you know do layoffs once every four years you might be safe for quite a while but Amazon has this sort of regular cycle you know well also I feel some companies ## Why other companies are also cutting lower performers [58:58] and I I wrote about this I I I feel I sense some companies are are starting to become a bit more like Amazon so Facebook has done 5% performance based layoff for uh this time I think Stripe was doing something similar so previously I I think we saw there was these kind of golden years if you will you know when the job market was really good Amazon kept doing this and and Amazon was really the kind of the bad company if you will the only one who were doing besides Netflix. Yeah. And it seems to me Amazon hasn't changed anything, but some of the other companies are doing so. Maybe as software engineers, we should accept that, you know, like some of these top companies in terms of brand compensation, Yeah. they're they're going to be tougher places to to be at and and, you know, they'll just keep pushing people to to to do better and they'll keep comparing people with one another. Yeah. And in in terms of like as an individual if you're joining as an engineer or or manager, you know, anyone um I think one of the things to keep in mind in terms of like ego and like how ## Dave’s advice for engineers struggling with performance feedback [59:55] does it feel to be told all of a sudden like you're not doing well. Um I guess partially is like awareness of I would actually say as a manager even like 50% of that performance frequently is your relationship with your manager and like your team how well you fit in with the team with your peers with your manager. So many times I've had someone who was either doing amazing on one team, they move to the next team and they're like actually not doing well at all or someone who was not doing well escapes to another team before they get fired and they do well. Like they, you know, I've had people who I was planning on firing who managed to transfer off my team in time and they ended up getting promoted someday. And the same thing, I've had people who said like, "I'm about to be fired. Uh, I'm pretty sure that it's coming towards me. Can I get off the This is like my my sneaky recommendation for anyone is like if you start to hear performance feedback whatsoever from your management chain. If you have any opportunity at all, get off your team fast as possible. Like that's that's the uh as we frequently say it's like unfair thing that managers know is if your manager says, you know, that wasn't so great what you did recently. And he's like, "Okay, well, switching teams like fast as I can." Because uh um most managers won't. Now, if you trust your manager, they might be actually just giving you honest feedback, which you'd like to be able to receive. But for the most part, if you've been working for someone for 3 years and suddenly they start giving you performance feedback, that's a really bad sign. Um if you run for the hills fast enough, it's possible you'll get away before they flag you in the system as is non-transferable. Yeah. Yeah, and I guess it's just worth keeping in mind that for you people who have not worked that these are companies internal transfers are possible and you do want to make take advantage of when when it makes sense. It's still better to do or easier to do internal transfer than to start a new job search process to start you know like your network will if you change companies you'll have to start to rebuild your network and so on. Yeah. I and I think again it frequently is not that you're a bad manager or a bad software engineer, a bad project manager or something. It's just, you know, sometimes it doesn't work out with you and your manager. And I think the same thing like if you're like, "Boy, I don't get along well with my manager, but I like this team." Like that's that's not the safest thing to to to put up with. I've heard people saying that like, "My manager doesn't like me, but I really like what we're working on." I'm like, "Dude, get off the team." Like if you want to keep your job, get off the team. I feel Amazon might might might make some of these kind of you know universal truths a bit like more emphasized because I remember like for example I I worked at Microsoft at a time where Microsoft just didn't let people go and there were people who were who were doing really bad like like we knew like they were doing bad work but for some reason management didn't want to let anyone go so they were dead weight but if and and by the way when you know like actually when this policy I wasn't there when it changed But I heard heard when I changed they were one of the first ones to let go and no one was surprised. But the point is like it's this is usually how companies work in like either normal times or when when times are a bit tougher. Right now it is a bit tougher and it's just good to prepare for that. So like speaking for myself I was always paranoid and in most most of my companies especially when I joined the first like six to 12 months of I assumed I probably was not doing that good. So I tried to do my best and you know hope that it was enough. over time you could become more comfortable. But as you said, I was as a manager as well, if you're not getting with your manager, what you said, like like you need to switch managers, like try to fix it if you can, but if you can't, sometimes there's just not much you can do. Yeah. I think that there's like the the mistake that people will sometimes make is like my manager doesn't influence my job that much because I can work independently or, you know, I don't need to figure this out with my manager because I can, you know, work with my peers or I have this great engineer on my team. I can work with. Um, but especially at a place like Amazon, like your manager is responsible for your rating, which is like tied directly into comp. Like they're definitely responsible for your promotion. Like you're never ever going to get promoted if your manager doesn't like you. And uh, every year at least, your manager needs to pick out a number of people who are not doing great. And so if you're not getting along with your manager, you need to fix it or you need to move on to another team. Like that's just a a a solid thing at Amazon. and and and there are bad managers. I think like half the time someone gets fired, it's probably because the manager is like, you know, it's a relationship issue. And I guess it's it's fair to say the this is specific to Amazon and maybe at some other companies you can get by. ## Why good managers are expected to bring talent with them to a new org [01:04:20] But I think it's fair to say the other thing as well, right? If you have a great manager, someone where you really click, they have your back, you've got your back, you work well together, y it might be even worth follow, you know, like depending on the situation. But often times I hear people following their managers to other companies, you know, they join a year later, they reach out, do you want to have a coffee? Guess what? They're going to be their their right hand at that company as well. I actually know people who have risen with and you know these good managers usually Oh yeah, not always but but often times they're good at you know get getting ahead especially because they they do bring some of their team. So if if you know or if you have a good manager or if you had in the past just hit them up again. Uh it it's rare like it's not that easy. Oh, totally that if you if you've had no managers with that you have a good good enough relationship where you want to go move with them then you've either had really unfortunate choice of managers or maybe you're having the issue with the the relationship you know sometimes it's you not them but uh yeah know I've heard before from managers especially as you get higher level is like if they don't pull in a number of people into their or soon as they transfer over and like there's not a list of people ready to transfer over then maybe there's an issue with that person because you want them to say how like every time I moved groups I would frequently start off with how many open roles am I going to have because I have a number of people who I want you know who will be happy to come over and join and take all those open positions um and that's what you expect that's what you you should have and especially within Amazon that's a totally expected thing is um the person comes over and then suddenly like all the spots fill up with the people who have followed them for the last three or you know org moves and that's just yeah and it's a good way to shuffle um I think it's healthy especially you at companies like Amazon where you want fresh blood and new ideas, new thoughts like it's a good way of you know orgs sort of shuffle around you know your VP leaves and suddenly half your management team leaves like that's a good thing that means the VP was liked by some people they move off to somewhere else to bring some new ideas in and then you get a whole fresh swath of of new hires ## Why startups love former Amazon engineers [01:06:21] so I'm getting a sense that Amazon and obviously I got that sense when I was refreshing Amazon but talking to you even more so that Amazon is just not not a typical what you would expect a large company to be. And one thing I've noticed that I think underscores this is when startups hire from large tech companies. When I'm talking with founders or people who have hired in the past or engineers who work with them, there's a lot of eye rolling like gh we hired that person from Google and it didn't really work out at a small company or or meta or some other companies. One thing that I rarely hear is that this Amazon hire didn't work out. In fact, I see so many Amazon people go to, you know, either large tech companies and then they like some that even have like maybe a shinier brand like Google, Meta, OpenAI, etc., and they do pretty well there, but they also go to startups and they do pretty well there as as employees, not just as founders. Why do you think this is I mean, I think we've already touched on a few things why it could be because Amazon feels a bit like a scrappy startup even though it's a big company. I mean, corporatewide is not a scrappy startup. It's a big old behemoth that can't turn, you know, to save its life. Uh, so, not that I'm biased or anything, but sometimes like HR policies and stuff like, you know, with a few Amazonwide things, it's like good luck freaking changing anything. It's like bang my head against the wall so many times trying to get things changed. Um, so corporatewide they're not, but when you get down to a dev team, like I I loved the fact of like almost everything is controllable at the lowest possible level. And so, um, you know, everything from stupid changes people can make or awesome changes they can make that you have a lot of control at every individual dev team can pick their process, can pick their coding language, can pick how they're deploying their code, like what tools they're going to use. And sometimes it becomes stupid like it's just like what the there was a team that built their whole um very important middleware like service out of lisp and it's like what are they thinking like it's why I mean is sure but no one else knows the damn language like no one else has written anything in Lisbon like no one knows what you're doing. Um, and I think it was like two engineers on the team had this great idea and they wrote the whole damn service and like great, they built the service and they all transferred off the team and then they had to rewrite the code because no one knew how to support it and it was this nightmare. But they could, right? And thankfully no one came up with an Amazonwide policy saying you're not allowed to write anything except if it's in Java or something. Um, so teams would regularly build stuff in whatever language they want, in whatever tool set they want, at whatever pace they want. They can do agile, they can do waterfall, they can do scrum or um they can not do sprints, they can I liked the fact that unless there's a strong strong strong reason for something to be dictated by Amazon or VP or director whatever else for the most part the culture was you can't tell me what to do like in a good way as in like um you know the director would say something like why don't once in a while you'd hear someone say something like why don't we line up all the sprints and everyone just starts stomping their feet saying hell No, you can't. They want to do a three-week sprint, but we like four-week sprints or whatever it is. And it's like um I use that as an example because that did happen a couple times where like someone thought like, you know what, we should do is line up all the sprints across our organization and all the engineers are like, "Oh, that does sound a good line." Bear as a dove. Yeah. And I appreciate like I I really like that culture of like someone says we should all flip to Macs and like no, I like my Windows laptop. Why? Because I do. Or like someone else has a Linux laptop. It's like, well, I'm just going to do that because I feel like it. And um unless there's a reason to dictate it, like a really really strong reason, the default answer is just everything goes to the lowest level. So again, like you're on call because it's your software and it it feels in most cases like you're in a sevenperson startup or a 10 person startup because like you picked your language, you picked your your uh how you deploy it, you picked how you QA it, you picked, you know, how you monitor it, you you set your own monitors and alarms. It's not like there's some global Amazon click the alarm button like, oh god, no. Like you have to make all this stuff up and people make it up wrong, but you learn, right? you I think there's a lot of skills like uh you know I can't name the exact gaps but sometimes you you know I would talk to the Facebook engineers and like they've never dealt with an emergency of like how fast you know it's like where are alarm you know where are that was like an example was I said something about like where are your metrics and stuff like that for this system and they're like I don't know I'll have to go look for them and I'm like blew my mind because if you're an Amazon engineer you have a freaking hot link on your browser right because you have to click the button really fast when there's an emergency and see all your alarms and they better be on like one one big dashboard with the alarms that you know about and the metrics you know about because you support this system and you know exactly how everything works and you know that your memory usage is higher than usual so what the heck is going on and so um I think it just builds a lot of skills at that like really low level of like we own the whole stack we own the product we you know frequently like you're you're making product decisions because there's not enough product managers for your space or things like that so on the frugality side of things for example Well, so I'm sensing that you're like as an Amazon engineer, you're actually really close to, you know, the the metal, the work. You're in a small team. You you have a lot of ownership, your your whole team. You have to wear multiple hats. You you cannot afford to like, you know, like buy all sorts like use budget cuz Amazon doesn't want you to. plus that's not my problem is something that you know that's one of the quotes in the leadership principle is like you you can't say like that's a product decision and like go la I don't want to make a decision like no dude like sorry you're an engineer I know but you have to make this product decision now and then you also need to listen to customers and stay close to them which is already I guess like you know like a a startup founder would like say like these are my ideal folks plus on top of it when you leave any big company Google Meta uh uh maybe even Microsoft, you're used to internal tools that do not exist outside of the world. But with Amazon, especially these days, you're using AWS. Guess which one is the most popular? Yeah. you're lucky service. I would say both lucky but also I definitely heard teams at Amazon switching to publicly available tools in part because they say I wanted to learn this like this is a popular tool these days which is again is like one of those big advantages of a a a system like Amazon where you can just choose to use whatever you want is someone saying the hot new way of doing Android development is X so we're going to do that for our for this next project because we you know us collectively on this team want to learn that tool so we're gonna use it like that's pretty awesome like Such a good way of keeping on top of tech is being able to say we're just going to use whatever we want and we've read a lot about this thing. It looks like it's popular so we're going to try it out. Yeah, this is awesome. I mean my my view changed a little bit about Amazon because it just seems like unlike some big tech jobs that you know you can you either go to big tech or become a founder. This Amazon does open multiple paths. You can keep going on in larger tech companies you can you know found a startup because you've kind of seen how it's done. You can join a startup. You can join a scale up. Pretty cool. Yeah. And I think I think the the downside which I would say absolutely exists at Amazon is related to the like independence thing of like everyone can do whatever they want is uh imagine the the manager who says we're going to be working on these projects. No, we can't go do that operational excellence. We're just going to put two people on call and we'll get paid 17 times a week. And like there's not the uber Amazon policy holder who says like you manager are doing it wrong. you need to be fired right now. Like, so so you do end up with these pockets of just absolute horribleness because people can do whatever they want. And so once in a while you talk to someone and you hear about what it's like on their team. And I'm like, that sounds horrific. Like I can't believe your team sucks so much. And so when someone says, you know, you'll see on Reddit or something about like, you know, oh my god, don't go to Amazon. Everyone leaves after 6 months. They don't. Like the actual stats are not at all. But in some pockets they do. But in some pockets they do. Absolutely. I have met teams that had no no one like 13 engineers on one team. No one had a tenure more than 12 months because they all left. They were all leaving. People would join the team, realize how terrible it was and they transfer off and it just like just pop on, pop off, pop on, pop off because the team was terrible, the manager was bad, their senior manager wasn't paying attention. Like there are these pockets of terribleness. And so again on the like if you're in a bad spot, move somewhere else. Internal transfers are great. And I assure you like I was in six orgs. I had a bad manager I guess sort of like two bad managers. They were both fired like everywhere else was great. Like and those places became great after I had new managers. And so I had great managers. We had great orgs, great peers. And you would just see pockets of terribleness here or there. That's almost like the inevitable downside of having thousands of little startups around the way is like once in a while you end up with a really bad situation. I know you had a short at Facebook as well but in total how long did you spend at Amazon? I think it was a little over 12 years uh at Amazon little Amazon a bit of Facebook afterwards you had a little stint. I took a leave of absence in the like towards the end I took a leave um uh but yeah and then you worked at at Basil Academy for a little bit as well but then you made a decision to retire. What what and you're you're still young. You don't look 65 to me. So how did you decide on retiring and and you know like what did it take to build up a kind of financial independence to be able to do this and what do you do ## How Dave planned for an early retirement [01:16:09] right now? So yeah. Yeah. So many years ago, I have no idea how I got so lucky that I stumbled on the idea of financial independence and read about a bunch about it and learned math uh you know like financial math in terms of like withdrawal rates and investment things and um index funds and stuff. And so many many years ago and in my 30s or whatever, yeah, I guess that's a while ago. Uh I I early 30s, let's say, uh I realized like how much money I would need and like keep an eye on our expenses every year and stuff like that. And so, uh, Amazon pays well, stocks go up, like over time. If you're making tech salary, you don't They did. They used to back in the day. Back in my day, stocks actually they Yeah. Yeah. Hopefully they will again someday. Um, and I would say almost like as for tech workers, it's like keeping an eye on your expenses is probably more important than keeping an eye on your income because you're probably making enough to retire if you don't spend a lot. Um, and so thankfully my wife and I don't and it comes down to that kind of thing. And so a good number of years ago I built a lot I mean I don't know eight years ago I built a spreadsheet and I could tell about when we would have enough money where I wouldn't need to work anymore. And that was my position when I was getting promoted to director at Amazon. I could see like essentially like my next vestings make us way past my safety margin and so I don't need to work anymore. Um, so there's just like that that fundamental like what am I going to do with my life when I don't need to when I don't need to work. I can keep working. I enjoy working like some some aspects of it. Like some I don't like waking up in the morning and commuting sucks. But um I I really appreciate sometimes like walk hanging out with smart people and talking to them or or doing creative things. So Bezos Academy poached me out of Amazon at a convenient time when I didn't need to work anymore and I was having a little bit of that existential crisis of like what do I do next with my life? Um, so they poached me. I worked there for a bit and then ended up deciding that that's not like the right kind of job for me. Um, and so I ## How a LinkedIn post turned into Scarlet Ink [01:18:10] thought, well, like my dream since I was young was to write a book, you know, actually like fiction book. I want to write sci-fi or fantasy about dragons and stuff, but how do you force yourself to write? Because I've been wanting to write for years and I have like literally 20 stories of like 50 pages each. Um, and so I thought, well, how do you force yourself to write regularly? Newsletter is an obvious answer. So, I'd written years before while I was at Amazon, I'd written a few very popular articles on LinkedIn that just sort of blew up. Um, one of them was one, the main one, in fact, was like the Amazon leadership principles article that a lot of people know about. Y uh where I'd written an article or sorry, I'd written an email that I would forward to people when friends or family or relatives or whatever else said, "Hey, I want to interview at Amazon." I would forward them this email that essentially said, "Here's what you need to know about interviewing at Amazon." So, I turned that into an article on LinkedIn. And it became wildly popular. And so, I thought, well, why don't I do that more? Like, that's sort of fun. I I I'll do a newsletter for a bit. I I start a newsletter and like by the second or third article, I had like thousands of subscribers. And I was like, holy smokes. Okay. Well, I need to write a paid newsletter is what I need to do just for fun. And this was literally like I just see the tools where I can click paid and say like you could pay and like how much should they pay me? I don't know, $5. Um, so I just pushed some buttons said I I thought I'll just write two articles a week then. So things have changed over time, but in general it just blew up and for a while it was I'm going to write a new article. Scarlet Inc., right? This is Scarlet Inc. Yeah. So the short thing for Scarlet Inc. is I got that uh uh domain a long time ago when I thought like I want to do some kind of writing, a blog, a newsletter, a a book, something. Um I wanted red ink because I always like the red pens at Amazon when I mark up documents, you know, document culture, right? You sit there like with a piece of paper in front of you and I'd always use the red pens because I could see it better against the uh uh black printouts. And so I thought red ink, but red ink was taken and it was really expensive to buy the domain. So I thought scarlet, it's even more literary. Scarlet ink. It sounds really fancy. So, um, so I got Scarlet Inc. I wrote the Scarlet Inc. newsletter. It was really fun. Um, and I was writing for a bit and I kept think I kept saying and thinking like I'm I'm just sort of on a sobatical where I'm writing and then I'll figure out what I want to do for a job like do I want to take another nonprofit job? Do I want to go to a startup? Do I want to go to, I don't know, Google or Microsoft or something? And I did a couple small interview like I talked to some people at Google. I talked to some people at other companies and it was like me. But the newsletter kept growing and then it's you start to get to the point of like but why would I go to a company again when I'm making so like I don't know a couple years a year and a half ago two years ago I sort of crossed where we were making in my newsletter more than we were spending and so like I haven't actually withdrawn any of my retirement money withdrawn any from the I mean it's only grown because I don't need to touch it because I have this newsletter going and then it gets to this weird point of like why would I go get a when I'm writing a newsletter that already pays me a salary and I'm not spending all that much time on it. I'm not commuting. I'm sitting in my little office here writing one artic I end up writing like one article a week. I enjoy writing. I sit down. I write for a few hours. Sometimes I'll write over a period of a few days. Like I'll just, you know, sit down for a couple hours, write something, brainstorm. I'll be on a walk and I'll text myself an idea of something I could write about. Um, and so you sort of like the idea of getting a job fades away when you realize you have so many other things you can do in life. Uh, sitting in the office and being forced to do it for 40 plus hours a week doesn't sound quite appealing. So sounds like you you built up really good savings as a mix of just working in Becktech being at a good time where where you know like there were stocks awarded where where yeah back when stock it was appreciation but you also read upon financial independence the planning you actually started to make a plan and then there was this point where you crossed the boundary where like okay you are financially stable and you could afford not to work you kind of explored some things different things you know like the the nonprofit job at at the the basis academy whether you should work at other companies and then you just did something that kind of like just worked out. Sounds like because you didn't Is it fair to say that maybe it worked out cuz you just didn't really have the pressure? I mean if this didn't if if this like once a week newsletter didn't work out, you probably would try something else, right? Because you you have no pressure right now. Yeah. If you imagine. Yeah. And that's it's I don't know if it's responsible for the newsletter working out. The fact that I didn't need it. I mean, if I really wanted to make it work, that probably would have worked. Also, I think a little bit of what might have happened was um if you're not trying to impress people, you your work product for creative things is probably a bit better because I'm not I wasn't and I I don't try to appeal to like what do people really want to hear? Like what's the hot topic? Like I I've only written about AI like once or twice. Like I think only once like real an article about AI, which is mostly saying like now it's all overblown. Um which I still believe in. Um, but uh uh I think that for the most part it's like you're writing about the things that you think are interesting or what someone else has talked to you about and you're like, "Oh, that was such a cool thing." Um, I did some I did actually some co like one-on-one coaching for a while, too. Like that was like one of those side things once I started writing and I actually I think when we first met you, you were still doing a little bit of that. Yeah. Yeah. Yeah. So, I was doing hourly coaching and then I my wife and I argued about it cuz it was like I was making a lot of money doing hourly coaching and uh I kept raising my rates and she's like, "Stop it. You're not going to get any more work." I'm like, "Well, I know cuz I don't want to be doing this anymore." So, I kept raising the rates trying to send people away and then I started feeling guilty cuz I was making such an huge amount of money per hour and people were still signing up for it. But then you start to have this like performance pressure of like, am I worth that many, you know, that much money? like, "Oh my gosh." Like, "Holy crap." So, uh, uh, I lowered the rates a little bit and then people were still buying and I I ended up just turning it off. I just told everyone like, "Sorry, I'm I'm not getting joy out of it anymore." And I don't know why I'm doing it. It's it's a weird existential problem to run into when you like realize that money incremental money won't change anything other than like a nicer car or something which is like like fundamentally something like if you if you feel that way like this is how you reach financial independence is not to keep growing your spending because a lot of people be like I got a raise so I spend more. Yeah. If you stop that from happening at the right time then as your career improves and you make more and more money the only thing it's doing is increasing your savings rate and that's how if you have a good tech job um over time like it you know you can afford things and save 15% and the next time you know your next raise you can save 20% of your salary and then 25 and then 40 and then you know by the end we were my wife was working at Amazon which is partially how this happened. I mean, she she retired a couple years before me, but you know, we had two tech workers. We were saving like 85%, I think, of our income. Like, it you can retire pretty damn fast if you're saving 85% of what you make. Um, and then where did you learn about financial independence or or for people who are thinking about like, okay, I'm actually inspired. I'd like to learn more. Where did you start? And do you have some pointers of books, resources? Yeah, the internet. Um, I would say, uh, yeah, Mr. money mustache and he doesn't write as much anymore but you could definitely he has some pretty fantastic archives. The Mr. Money mustache is a blog you know newsletter. Um Mad Scientist was another one who also he's been retired for years. It's sort of funny like you these financial independence newsletters in particular are just sort of hilarious because they'll be like I have you know $10,000 and I want to retire in five years. And so they write like mad for five years and they're like I've made it. like I think I've made it and then you notice like the newsletters just sort of peters out and stops like they'll write once every two months because they're busy with their life and like the the driving that's what they wanted to do. It was their thing. So uh almost no active newsletter exists that was from the time of which I originally read about it. Um uh but yeah, Mr. Money Mustache, Mad Fientist um are the biggest ones that I read about at the time. But um there there's a good selection of of um actually if you hold on one second. There's a I was going to look up the book. Uh I I can look it up right now. There there there's a a book that I recommend on um on my website. In fact, you can set it over and then we'll put it in the show notes after show notes. Yeah. Yeah. This was really fun. Yeah. Both about software engineering and a little bit on management. We didn't go into too much detail this time, but perhaps on a on a follow-up one. Yeah. Well, thanks very much for for being here. This was fun. Oh, thanks for having me. It's been fun. I enjoy uh uh chatting on these topics. I hope you enjoyed this deep dive into how engineers at Amazon work, as well as how working at a large tech company like Amazon could help getting to early retirement like Dave has done. So, thanks to Dave for a great conversation. You can read more from him on his newsletter at scarleting.com and you can find him on social media as linked in the show notes below. We previously did a more detailed deep dive on the engineering culture at Amazon. Check it out linked in the show notes. If you've enjoyed this podcast, please do subscribe on your favorite podcast platform and on YouTube. This helps more people discover the podcast and a special thank you if you leave a rating. Thanks and see you in the next one.