The Pragmatic Engineer - Working at Amazon as a software engineer – with Dave Anderson

Episode Date: April 16, 2025

Supported by Our Partners• WorkOS — The modern identity platform for B2B SaaS.•⁠ Modal⁠ — The cloud platform for building AI applications• Vanta — Automate compliance and simplify security with Vanta.—What is it like to work at Amazon as a software engineer? Dave Anderson spent over 12 years at Amazon working closely with engineers on his teams: starting as an Engineering Manager (or, SDM in Amazon lingo) and eventually becoming a Director of Engineering. In this episode, he shares a candid look into Amazon’s engineering culture—from how promotions work to why teams often run like startups.We get into the hiring process, the role of bar raisers, the pros and cons of extreme frugality, and what it takes to succeed inside one of the world’s most operationally intense companies. We also look at how engineering actually works day to day at Amazon—from the tools teams choose to the way they organize and deliver work. We also discuss:• The levels at Amazon, from SDE L4 to Distinguished Engineer and VP• Why engineering managers at Amazon need to write well• The “Bar Raiser” role in Amazon interview loops • Why Amazon doesn’t care about what programming language you use in interviews• Amazon’s oncall process• The pros and cons of Amazon’s extreme frugality • What to do if you're getting negative performance feedback• The importance of having a strong relationship with your manager• The surprising freedom Amazon teams have to choose their own stack, tools, and ways of working – and how a team chose to use Lisp (!)• Why startups love hiring former Amazon engineers• Dave’s approach to financial independence and early retirement• And more!—Timestamps(00:00) Intro(02:08) An overview of Amazon’s levels for devs and engineering managers(07:04) How promotions work for developers at Amazon, and the scope of work at each level(12:29) Why managers feel pressure to grow their teams(13:36) A step-by-step, behind-the-scenes glimpse of the hiring process (23:40) The wide variety of tools used at Amazon(26:27) How oncall works at Amazon(32:06) The general approach to handling outages (severity 1-5)(34:40) A story from Uber illustrating the Amazon outage mindset(37:30) How VPs assist with outages(41:38) The culture of frugality at Amazon  (47:27) Amazon’s URA target—and why it’s mostly not a big deal (53:37) How managers handle the ‘least effective’ employees(58:58) Why other companies are also cutting lower performers(59:55) Dave’s advice for engineers struggling with performance feedback (1:04:20) Why good managers are expected to bring talent with them to a new org(1:06:21) Why startups love former Amazon engineers(1:16:09) How Dave planned for an early retirement (1:18:10) How a LinkedIn post turned into Scarlet Ink —The Pragmatic Engineer deepdives relevant for this episode:• Inside Amazon’s engineering culture• A day in the life of a senior manager at Amazon• Amazon’s Operational Plan process with OP1 and OP2—See the transcript and other references from the episode at ⁠⁠https://newsletter.pragmaticengineer.com/podcast⁠⁠—Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [e-mail]. Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

have not heard any of their companies where the largest outages are taken so seriously by everyone, the whole leadership. Operational excellence and dives deep and all these kind of things tie into 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 where 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 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. The connections that you have and the data you have sometimes are so mind-bogglingly big. What does it like to work at Amazon as a software engineer? Dave Anderson is an engineering manager and director of engineering at Amazon for more than 12 years. He's now retired and so can speak with more candor than usual. In our conversation, we cover engineering manager career levels at Amazon from L4 to L10,

the interview process for engineers and Amazon's unique barraiser interview. Amazon's infamous PIP slash 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, 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 this 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 worked at Amazon as an engineering manager. How is Amazon called? SDM. SDM. Yeah, yeah, I started off as an SDM and then went up that engineering management chain. You're a software development manager. Before we get into what it's like to work as a dev manager there, you manage that and work with a lot of software engineers.

What is it like to be a software developer? And what levels does Amazon have for devs and also for managers? And how do they overlap? Yeah, the numbers overlap except for, so when you get hired out of college, like the entry level that lasts like a year and a half to sometimes more years, is level four. That's for whatever reason. We start at level four for engineers. Then there's level five,

which is like the beginnings of middle level engineer, which equates to the first level of SDM. 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.

That's actually where I started. So there's level five. Then level six is what you might, what called a C. senior software engineer or software development manager, which is like the software development manager level six is the most common management position where you manage a two pizza team, you own your space and you usually don't have managers underneath you. 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 the, you could almost equated to like a level six manager has a level six engineer in a perfectly designed team, which is a level six engineer, which sort of be the head engineer for a team. And then you hit level seven at Amazon, which is principal software engineer. And they would theoretically be over a group of teams, the lead, you know, sort of directing. And as you could imagine, as you get to like larger groups, you get to more broad ownership. So a principal engineer 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. And that equates to level seven manager, which is senior software development manager, 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 a senior principal engineer, which is just more senior, bigger orgs, bigger scope, etc., which equates to director for development management. And then you get up to level 10 because there's no nine for whatever reason. 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. But anyway, you jump up to 10 and you get to distinguish engineer or VP, which is sort of, you know, the pinnacle

of where any of us normal humans would get to. This episode was brought to you by WorkOS. If you're building a SaaS app, at some point your customers will start asking for enterprise features like SAML authentication, skin provisioning, and fine-grade authorization. That's where WorkOS 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. WorkOS also provides a free user management solution called AuthKit for up to one million monthly active users. It's a drop in a replacement for Alt Zero and comes standard with useful features like domain verification, rule-based, access control, bot protection, and MFA. It's powered by Radix components, which means zero compromises in design.

You get limited as customizations as well as modular templates designed for quick integrations. Today, hundreds of fast-growing startups are powered by WorkOS, including ones you probably know, like Cursor, Versal, and Perplexity. Check it out at Workos.com to learn more. That is WorkOS.com. This episode is brought to you by Modul, 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 subsecond container starts and instant scaling to thousands of GPUs, it's no wonder companies like Suno, Ramp, and Substack already trust Model for their AI applications. Getting an H-100 is just a pip install away. Go to modal.com slash pragmatit to get $30 in free credits every month. That is M-O-D-A-L.com slash pragmatic. Why do you think it starts with L-4?

This is so strange because at Google, Uber, I think even potentially Stripe, it all starts at L-3. It's also for a historic reason. But L-4 at most companies is like the mid-level engineer. And here at Amazon, it's the entry-level one. And I don't even know why. It's not like we don't have different pay scales. So I'm pretty sure if you get to the FCs that I don't remember the levels for the

FC workers that there's like one, two, and three and like, you know, that their levelings start for, fulfillment center. So when you get to the fulfillment center, 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'd touch on something. So I'm pretty sure that their levels start lower. And if you get to a few weird positions like QAT 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, they would be level three. So there's like, there's 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. No idea why they decided their numbering schemes needs to start there. And how easy 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 say the like, four to five for engineers isn't too bad at all or for just about any position. I mean, you know, there's level fours for some other roles. But 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 in most teams and they're just going to end up promoting you like, hey, look, 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 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. So level five is sort of like you can be trusted to work on a project, not a huge project, but a decent size project at the start of level five at least 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 at level five. Past that, you get to a lot harder. So there's these 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, which was just these detailed of like at level five, you. And it describes it in fairly good detail. I mean, hand wavy as you could imagine in terms of, uh, a project with a scope of a team, a project with the scope of multiple teams.

Yeah. So those are actually what's mostly used when managers go to write promotions. So Amazon's, in comparison to a lot of companies, Amazon has a very document culture, I mean, 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...

Oh, even for promotions. For even for promotions. And it's actually, I would say, one of the first. of the aspects that's the hardest for managers. And one of the big differentiators between having a good manager or 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. I just contrast that quickly with, I worked at Facebook for a bit. I don't know. And I remember being an OLR there. And a manager said, oh, my engineer is so good, they really need to be promoted to level six. And a couple of people said,

yeah, yeah, are you sure? Like, yeah, I remember, I heard they were good. It's like, yeah, they're good. Okay, sounds good. Moving on. And I'm flabbergasted. I was just like, my mind was blown. I'm like, are you kidding me? Because at Amazon, what you have is this document,

which has like a lot of required fields where you have to explain, like, write this big narrative. First of all, there's some like normal fields of like how long is their time in position, which again is like a criteria to look at and say like, oh, only 13 months. That's not very long. Are you really sure you can perform them that fast? like this it's a very uh um it's a hard process to get through let's say yeah 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, 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. 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 complete.

you have to have a lot of VPs and directors on your doc writing out narrative blocks of text explaining all the things they've done with you. 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. Five to six is a pretty big promotion. Six to seven is super damn hard. It's already hitting levels of slightly less bad for management, which I can explain in a second why.

but principles have like additional hurdles they have to get past sort of unfairly in my mind. The technical assessments of exactly what they've done by multiple principles who seem to have incentive to say no, it's really tough. And so I would say in ways that makes it have the wrong incentives for managers, one of the big things for managers is how big is their team? because of your level if you're 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, this dude has 55 people reporting to him and he's level six. That makes no sense. We really need to promote them. So managers have 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 initiatives you can almost guarantee a promotion if you just grow your team enough yeah incentives are are an interesting thing and taking us a step back we talked about what it's like to be inside amazon and you know get hired in there how do you get hired as as an engineer and what what is the injury process is it the pretty standard you know the ones we know

what Google and meta does, the algorithmical coding interview, et cetera, or are there some unique things for Amazon? For the most part, I would say it was very, very similar. 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 out as a barraiser at Amazon, which I'll explain barraiser in a second for anyone who doesn't know. But I got added to the loops, and I was like, oh my God, this is the exact same thing. Everyone's doing the same thing. It's extremely similar. At least the groups I was in, I was just added to the loops. It was exactly the same.

Nothing was different. So for the most part, with some exceptions, interview loops are five people. You do a phone screen. 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 usually five people, of which four is usually on the team or closely related to the team. team and then one person's the barraiser who is a essentially a third party person who can veto a higher decision and they also are running the loop as in 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 the loop is set up correctly and they have the ability to say no um because 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 barraiser. So it's like 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 as a hiring manager. You can't really get around the barraiser. But as a barraiser 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.

It was a hiring manager. Like, dude, quick, quick, before anyone else gets them. Because sometimes hiring managers have weird opinions. But yeah, for the most part, it has to be yes, from both the hiring manager and the barraiser. And then like I think we can all imagine, you know, the interview you go as a candidate, correct me if I'm wrong, but you know, you apply to Amazon, you have the first screening. You're through.

You're put on to maybe you have a technical pre-screening, but then you have the onsite or, you know, it might be virtual, but you'll probably be coding, architecture, hiring manager, 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 on some.

What happens behind the scenes? How does it deep brief happen? So the loop is set up and there's, at no point, Amazon's very bad at consistency across all of Amazon. So everything, just about everything I say has a grain of salt.

The only thing is not just like, yes, bar racers are always included. But other than that, I don't know how many times I've said, this is the way you do things. And someone else is like, at all. You're totally wrong, which is funny because, like, we're both wrong. It's just, 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 orgs. So I have a pretty good idea of what's consistent. You set up a loop 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 at least one leadership principle style interview, which is like checking your leadership skills. 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 coworkers. It's like, well, they've had no coworkers. They lived in a dorm. Like I've heard some really weird stories when I try to ask those

kind of questions. Yeah. There's one time my roommate was, was, was, staying up really late in night and I had a test in the morning. I'm like, okay, maybe we just move on. So in normal interviews with experienced people, 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 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 discussion about the candidate. So the Marizer leads that meeting. You start off the meeting for the most part,

you started off by saying, okay, everyone read. So you all start reading and you read, which takes time is just like typical across Amazon, right? A lot of meetings. Yeah, Amazon's document culture here. It's like you start off, 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 candidate's answers, you read the interpretation of those answers. And then how the rest of it proceeds is very much up to the barraiser and like their org and like how they tend to do things. I usually would say like some version of now that you've read all the feedback, are you changing. Oh, sorry, part of the interview notes is what is your vote for higher or not higher?

And so I would sort of carefully go around and say like what are your current thoughts on hire or no higher? 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. And you sort of get an idea of like where is the room 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 the barraiser'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 I was like, 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 in fact, like, as what you use. said was sometimes you're almost always you'll have a good interview and a bad interview. Like, that's extremely common. And so hopefully what the barmezer is doing is making sure you have a good discussion over like everything seen. 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. What kind of hints did you give? What kind of hints did you not give? Then you just try to arrive at the idea of like, should we have them or not. So is it fair to say that the barraiser tries to, you know, make the debrief a bit more fair? Even out things compensate for less experienced interviewers and maybe some of their biases,

given the barraiser is it's both an experienced interviewer, but is there like a special like training or like how do you go a barraiser? Yeah, for the most part. So you again, org-wide, like there's a lot of differences across Amazon. For the most part, it's like once you've had 100 plus interviews, sometimes 50 you can start training. But like usually 100-ish interviews is when you get to train as a barraiser. And for the most part, the training is you watch a barraiser do their thing.

for a while and then you start to do the barraiser thing while they watch and then criticize you behind your you know later on um criticized uh in that can last anywhere from like 10 interviews to 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 barraiser 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. I don't know how many times I've seen like the question, the candidate'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're 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 I would say that that's sort of where the barraiser like a thing comes in is like

trying to, like you said sort of fair, like a fair. like a fair evaluation of a candidate. 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, you know, one of the things you're looking for, for example, is more of like growth, 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 were already pivoting their answer. you're 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 people who can change their mind over time.

Awesome. So once you get hired and you start inside of Amazon, back in your day, what was the kind of tooling stack? And I know it's changing these days because I'm hearing more and more of it. It's pretty much AWS, 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 thing. So, yeah, I would say it changed. It was changing over time. And 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 Marketplace back in the time, which was like originally was Grupa and then was multiple versions of new web hosting platforms 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 no lot of teams weren't yet. And then you move over to I dozen devices and like the mobile stacks. And that was pretty much using straight up like the development tool.

that need to be used, you know, by Apple and by Google in terms of, like, the Android development system and stuff. And so 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 that's one of the reasons. Like when we talk about a job I didn't mention of the bar racers is also, for example, I've seen people complain that, candidate only coded in Python for their answers. And definitely a bar is their 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 Kotlin or something for coding because why not this team does it or you know this software stack we've decided to switch and you want them for the most part we want engineers to be fungible to be able to switch over and you know you move over to um we had some like not c plus plus but c code inside of one of the AWS teams I was on for example 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 I'm saying something about like stupid memory management. And I'm like, wait, see? Like, cool. I mean, I haven't looked at the code in a while. That's not an SDM thing at Amazon. But I'm going to look at this. Like, I'm sort of curious because 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 is on call and how brutal it can be. Like, what is on call like? 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 think it's a super interesting and also I would say one of the more interesting differences between like Facebook and Amazon.

So at least in the teams I was on a 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. At Amazon, it was like it's a core aspect of most teams, 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 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, 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 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 of 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 one or two a.m. because there was a problem. But also, I believe that managed, well, you know, you go into work two days later after a couple big emergency nights. And we say, okay, we're stopping all feature development and we're fixing these problems, right? That's like the done well part is we are not patching this. We are not saying it to reboot every night 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. I would say that contrast in the negative way, there were some systems at 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 will 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. On the other side, side, like the poorly run teams where you hear like it's been nine months now and everyone is page 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. They're like that's, that's a management problem. I think more than anything.

So yeah, so the rotation is usually on most teams. Let's say you have a team of like seven people. Seven's a good, maybe eight, 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 p.m. 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. 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. 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 you get it resolved. Yeah. Well, I think there's always a downside of being too close to the problems, right? Because you do have to be responsive. But if it's set up in a way that you're actually page for things that truly matter and matter to, like, let's say customers, you're now going to fix it faster.

I think, you know, we've always. all you 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 it. They might not even know about it. Or the 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? As 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.

And I'd be like, what do you mean? Like last week and I have to go like quickly run a report because usually manager is not page into everything unless it escalates. Like if they can't fix it within 10 minutes, then I get pages or something. And they say, oh, yeah,

we got pages eight times last week. I'm like, 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 in anything else? If you're going to be page seven times in a week like that's not okay. So I usually would say, like, you should only be okay with being on a non-cloud rotation if you also have the capability 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 also redirect your resources. Those things have to come

together. And so I would say most teams and Amazon had that. And certainly there were teams where they felt like were helpless and just had a terrible time of it. But well-run teams, you would say, like, they're not going to be okay with, again, a bad operational situation. And then what outages happen? What is the categorization? I think there's different levels between the severity of the outage, right? So like a page comes in, someone decides, the on-call decides that if it's an outage and then they have to assign a level to it. How does that work? Yeah. 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 quickly go edit our wiki 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 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 show them the instructions. It was great how people would just believe these things. That was like a barraiser thing, too. It's like,

that's not allowed. And I am the barraiser, so I would know these things. And like, oh, okay. Cool. Smart hack. Oh, man. Yeah.

With confidence, you can get past almost everything if you need to. But yeah, so most of the, most of the time in most teams, there is severity one through five. And five means we're never going to 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. Severity two is severity two and one are the ones that would like page people, make people pay attention and make their phones freak out. Um, severity two and one are just emergencies. And for the most part, severity two is what we use for most things. Severity one is like company wide emergency is sort of, um,

uh, know, SEV-1, 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. Sev one is usually like this is where I, um, so for a while I was on the on quotation of manager, you get page in instantly for SEV-1s. It was like, you would have a big last, you could set up a, you know, a distribution list where a whole bunch of people would get alerted for your SEV-1, including maybe your VP, maybe

your SVP for AWS style seven ones that was frequently like I was writing to JASI right away with a list of other SVPs and VPs on a list saying we have an AWS outage like blah blah so I actually have a really interesting story and one of the reasons I asked that this we had a senior director joined from Amazon he was a senior director there and he became a senior director of my of my of my Amazon doesn't have senior directors that's that level nine thing that doesn't exist okay well I'm not maybe maybe it is or some senior directors and anyway people like to invent their own titles. 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's Sev 1 was L5, like for us, L1 was the smallest, and L3 is internal. L4 is like, you know, it's just the opposite. So L5 is the highest is when it's actually company-wide. So it impacts a whole product. We're actually losing revenue or something like that. And then there's like levels, there's like low, 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 one of the payment methods in India just stopped working because the thing had an outage there. And it was pretty routine for us. Like this is something that we couldn't do anything about beyond alert,

you know, the third party. And so we were just having one of the things. 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. So, okay, have you guys page the third party? Yeah, we paid. Suddenly, my, 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 a, this is Al five, right? It's a highest one, right? Like, it's like, yeah, it is. He's like, okay, I'm here. Use me. How can put out the fires. So then I learned that on at Amazon, VPs jump onto seven one. And we were just having really casual. Like for us, like enough five wasn't really like this. We just knew this was just

our regular off five because we had to follow. We couldn't do anything about it. But it just made me realize how Amazon stayed 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 just shows. It gave me a sense of how. serious Amazon scenes, and I have not seen any other companies or have not heard any other companies where the largest outages are taken so seriously by everyone, the whole leadership. So I think that's, you know, it's a bit of a story there. Operational excellence and dives deep and all these kind of things tie into together.

And there's this culture, which, you know, sometimes people complain about like new external hires. Sometimes Amazon has had these pockets of like, you know, a bunch of, you know, a bunch of VPs hired from a different company where they don't join the on-call. Don't join this F-1. And it's like this like, oh, my God, like 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 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 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 at like the connections that you have and the data you have sometimes are so mind-bogglingly big.

You know, it's like 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 what you want in which what you usually have is we need X done and you need it done right now. And that's the kind of thing of VP or director, whoever, you know,

whoever the really senior person is around for is like, oh, okay, you need, you know, we need a 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 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 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 sounds to me if you, you know, like this might sound a bit like cheeky. But 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,

awesome opportunity. Oh, man. Where else would you be able to even experience this? I have heard from, I believe, like, if you're talking about, like, 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, 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, see, I've got on a 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 and a separate phone call from the engineers talking about whatever tests 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 hosts so we can try something out? 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 probably. happen when you push code.

So just the way things work. Funny thing of like the amount of pages that happened when Amazon historically did lockdown 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. But yeah, I think the experience, I think 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 also just Amazon's famous for and people get surprised for is that frugality. Yeah. Can you tell me what, you know, what engineers experienced or whether engineers complained to you who joined from like companies that were a bit more generous, you know, like I worked at Uber. I visited friends at Google Meta. You have like these like, you don't just have standard perks like lunch at I think at Uber we had like these vending machines. you could get like whatever like mice.

Free stuff from the vending machines. Yeah, yeah. Our vending machines were head profit. Yeah, they got a profit from our vending machines. It wasn't even like that cost. Oh, my God. Yeah. Yeah, no, no.

I think Amazon, and there's, there is some interesting points that sometimes we 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 frupidity, like the stupid, frugal thing. It's just this ridiculous, stupid level of frugality. But sometimes they do, there is interesting explanations because Amazon has fulfillment centers and we have the majority of Amazon's workers are very, very low margin per person. You can't afford it.

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 nowhere at risk for unions forming across the world because they're giving unfair benefits to corporate workers. You look at something like 401K match, for example, was something that came up. It was like, couldn't we just do it, you know, double the match, do a 100% of whatever? And they're 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. 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 when you try to give, you know, try to give comparable benefits to corporate workers and you have these issues. 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 successful. you would definitely want your company to be frugal. Like 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 dollars a year spent per person on food compared to their salaries, nothing. So why not do it? 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 to 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, because we're wasting money. And they're like, so we have billions. Like, what? Like, it's 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, sometimes you do anything 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 the kind of stuff. But I think 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 inches or something ridiculous. And literally, and it was, I mean, it was both hilarious, but also frustrating. It was like, it. 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 the steals and what else is. Yeah, that was a fripidity. Oh, my God.

It was so stupid. Oh, but I think it is context, like just understanding where the company is coming from and that is a unique setup in the sense that there are so many fulfillment center workers, which most companies do not have. and they don't have this. So I was aware of that part. I mean, data driven, I've been on teams where they wrote six page

explaining why they needed, you know, the top of the line Mac pros instead of the middle grade Mac pros and they explained the, you know, productivity benefits. And someone said, okay, 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 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 elsewhere. But it definitely can be frustrating. Trust isn't just earned, it's demanded. Whether you're a starter found or navigating your first audit or seizing 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. Vanta can help you start or scale your security program by connecting with auditors and 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 Vanta to establish trust by automating compliance needs across over 35 frameworks, like SOC2 and ISO-2701. With Vanta, they centralized 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 Banta at vanta.com slash pragmatic.

That is VANTA.com slash pragmatic for $1,000 off. Now, one thing, when I did my Amazon deep dive on Amazon's engineering culture, one kind of, one of the most negative things that came up was Amazon's so-called URA target, unregulated attrition target, which if rumors have it, that every year about 6% of staff is expected to, as undergrina nutrition and what this results in is basically the focus plans which which is what comes before pip and there's pips and the people i again i have like friends at amazon and many of them mentioned that either they were on a pip or they had a someone else 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're clearly you were also like maybe subject to this on your end. How scary is this? And how does it play out in reality? I would say for most people, it wasn't scary. And it like, so, you know, at various times, it was between 6 to 10% of people had to be. And exactly what's measured was a little different over time of like, whether you're not, you were like, 6 to 10% had be rated poorly or 6 to 10% had to be put into,

like, coaching or whatever. or six to ten percent have to be fired. 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. 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 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 of my peers.

Suddenly it becomes very scary. Because 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. I actually had a friend who was put on a PIP. He thought it was really unfair.

He was there for four years. He actually made it out of it. but he kind of became bitter, especially as yours his manager. Almost never happens, yeah. 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 make fun of college hires because of like how much they move from kids to adult overtime, right? Like you're in college and you're a kid and then you become an adult. How many times they get hired in like their three months into their job? and I see them posting on Instagram at four 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. Like, that's kids, right? 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 you can get a pit that you can get out of because they decide to buckle down and actually do their work. You let them back out because you think they're competent. They're just need to grow up. But, if you think about like the incentives, right, you're running a team. I have 50 people working for me because usually the criteria of that like 6 to 10 percent is only if you're in a big enough work. So let's say I have 50 people. So now the criteria hits me because usually it's 50 or so when you start to have these expectations. If I need to rate 10% of my team poorly, let's say,

and I have 50 people. It 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. Review periods every six months, every 12 months? 12 months, yeah. And again, like at various times we had checkpoints, six month checkpoints. Sometimes HR would care that you're flagging people. Sometimes it's like for the most part, especially when you're talking about like firing people would be like by the end of the year you need to have fired six five people. And sometimes it's like, well, we already did four along the year because of various things that happened.

So that 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 Helen. So you like, now you're okay. But I would say 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 bloods.

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 is not doing great. Everyone on my team is doing well. Now you end up in frustrating situations. And most of the time, I would say it was it was not a big deal and wasn't that stressful

because it, again, 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 organ, why they don't deserve it 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 have to talk through all the people who are like on that borderline and explain why they're not whatever at this level. because for the most part, they were very, very hardasses on making sure that you hit these, the goals. And then from a soft range of your perspective, you know, you're kind of like blissfully unaware, you're kind of working away. And 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 someone.

Usually when when this happens, you know, like you kind of in your group, you circle down on like, all right, this is this person. these are the people who are underperforming. Yep. Is there also a part where there is like reasoning given of why so that the manager can go back and say like, right, here's, here's a difference. Here's why you're not meeting expectations. Or is it just more like, well, you know, you're bottom of the pile. Like, sorry, here's a pip.

So I guess the first thing to say is like there's often a definition issue. And even with the managers sometimes. Like, boy, this is where managers screw up the most often. And you almost need like a barraiser for HR processes. The description of that lowest rating and the description of letting people go is all about not meeting expectations. It is least effective. And so the argument is that we explain to people is if we have 100 people, we want, let's just, let's just pick an easy number. You know, the bottom 5%.

Five people out of that 100. 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 100 people aren't great. Like, they might be okay at their job. Comparatively, right? Comparatively, like they're a fine, let's say, engineer, right? 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's been telling them this all long. It's 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. Then 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 had 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 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 situation you know you in the last four sprints you know, specifically in the last four sprints, you have missed your, you know, your projects

haven't been completed like we thought would be completed in the sprint, every single spring for the last four sprints. We've already talked about this. 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's really, I've actually heard quite a bit that the problem that some of the people I talk with who were in a situation, their manager was new or did not understand and some of those things. But 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 tests where they regularly

reevaluate people and they're not saying you're not meaning expectations. You're just like, well, if someone is not, they actually do the other way around. They're saying if someone is not worth fighting for keeping, we don't necessarily want to retain them. In fact, we might let them go. They communicate the subfront, whereas with Amazon, if I understand, they're saying you're the least effective, which, again, people got into Amazon. It's hard to get into their typically good engineers. They might be awesome at a lot of places. But Amazon says, okay, let's, you know, we want to, 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. like, 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.

It's 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 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. It's just never safe. And at Amazon, it's definitely not safe.

And 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. Well, also, I feel some companies that I wrote about this, I feel, I said some companies are starting to become a bit more like Amazon. So Facebook has done 5% performance-based layoff for this time. I think Stripe was doing something similar. So previously, I think we saw there was these kind of golden years, if we will. you know, when the job market was really good, Amazon kept doing this.

And Amazon was really the kind of the bad company, if you will, the only one who were doing it besides Netflix. 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 going to be tougher places to be at. And, you know, they'll just keep pushing people 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, I think one of the things to keep in mind in terms of like ego and like how does it feel to be told all of a sudden like you're not doing well. I guess partially is an 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 will 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 moved 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. 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. I'm pretty sure that it's coming towards me. Can I get off that you? This is like 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 is like unfair thing that managers know is if your manager says you know that wasn't so great what you did recently is like okay well switching teams like as fast as I can because uh um most managers won't not 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 three years and suddenly they start giving you performance feedback. That's a really bad sign.

If you run for the hills fast enough, it's possible you'll get away before they flag you in the system is non-transferable. Yeah. And I guess it's just worth keeping in mind that some of you who have not worked that these are companies internal transfers are possible. And you do want to take advantage of when it makes sense. It's still better to do it 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. And I think, again, it frequently is not that you're a bad manager, 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 not the safest thing 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. If you want to keep your job, get off the team. I feel Amazon might make some of these kind of universal truths a bit more emphasized. Because I remember, like, for example, I worked at Microsoft at a time where Microsoft didn't let people go. And there were people who were doing really bad. Like, we knew.

Like, they were doing bad work. But for some reason, management didn't want to let anyone go. So there were dead weight. But if, and by the way, when, you know, like actually when this, when this is, policy. I wasn't there when it changed, but I heard it heard when I changed there. One of the first wants 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 one 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 at what 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 you're just not much you can do yeah i think that there's 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

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 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 solid thing at Amazon. And, and there are bad managers. I think like half the time someone gets fired, it's probably because their manager is like, you know,

it's a relationship issue. And I guess it's fair to say this is specific to Amazon and maybe it's some other companies you can get by. 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. It might be even worthwhile, you know, like depending on a situation. But oftentimes I hear people following their managers to other companies.

You know, they joined a year later. they reach out, do you want to have a coffee? Guess what? They're going to be their right hand at that company as well. I actually know people who have risen with and, you know, these good managers usually, not always, but oftentimes they're good at, you know, getting ahead, especially because they do bring some of their team. So if you know or if you have a good manager or if you had in the past, just hit them up again,

it's rare. Like, it's not that easy to have that. If you've had no managers that you have a good enough relationship where you've, want to go move with them, then you've either had a really unfortunate choice of managers, or maybe you're having the issue with the relationship. Sometimes it's you, not them. But, yeah, and all I've heard before for managers, especially as you get higher levels, like if they don't pull in a number of people into their org as 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, every time I move 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. And that's what you expect. That's what you should have. And especially within Amazon, that's a totally expected thing is the person comes over and

then suddenly like all the spots fill up with the people who have fouled them for the last three org, you know, org moves. And that's just, yeah. And it's a good way to shuffle. I think it's healthy, especially, you know, companies like Amazon where you want fresh blood and new ideas, new thoughts. 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 new hires. 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, oh, we hired that person from Google and it didn't really work out. A small company 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 either large tech companies and then they like some that even have like maybe a shinier brand like Google, meta, OpenAI, et cetera, and they do pretty well there. But they also go to

startups and they do pretty well there 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, corporate-wide is not a crappy startup. It's a big old behemoth that can't turn to save its life. So, not that I'm biased or anything, but sometimes like HR policies and stuff. Like, you know, with a few Amazon wide 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. So corporate wide or not. But when you get down to a dev team, like I loved the fact of like almost everything is controllable at the lowest possible

level. And so, you know, everything from stupid changes people can make are awesome changes that they can make that you have a lot of control. Every individual dev team can pick their process, can pick their coding language, can pay 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 very important middleware like service out of LISP. And it's like, what are they thinking? Like, it's, It is a cool language. I mean, 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. And I think it was like two engineers on the team had this great idea. And they were at the whole damn service. And like, great, they built the service. And then 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 Amazon wide policy saying you're not allowed to write anything except if it's in Java or something. So teams would regularly build stuff in whatever language they want and whatever tool set they want at whatever pace they want. They can do agile. They can do waterfall. They can do scrum or they can not do sprints. I liked the fact that unless there's a strong, strong, strong reason for something to be dictated by Amazon or VP or director or whatever else.

For the most part, the culture was you can't tell me what to do in a good way. As in like, you know, the director would say something like, why don't, once in a while you hear someone say something like, why don't we line up all the sprints and everyone just starts stopping 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, 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 organization and all the engineers are like, oh, I don't know. It does sound a good line very as a dove. Yeah. And I appreciate it. I really like that culture of like, someone says we should all flip to max and like no 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 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 and so again like you're on call because it's your software and it feels in most cases like you're in a seven person startup or a 10 person startup because like

you picked your language you picked your your uh how you deploy you're it, you picked how you QA it, you pick, 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? I think there's a lot of skills like, you know, I can't name the exact gaps, but sometimes you'll, you know, I would talk to the Facebook engineer and it's like they've never dealt with an emergency of like how fast, you know, it's like, where our alarm, you know, where are, that was like an example.

I said something about like where are your metrics and stuff like that for the system. And they're like, I don't know. I'll have to go look for them. 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 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 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 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 metal, the work. You're in a small team. You have a lot of ownership. Your whole team. You have to wear multiple hats. You cannot afford to like, you know, like buy all sorts. to like use budget because Amazon doesn't want you to. Plus one thing.

That's not my problem is something that, you know, that's one of the quotes in the leadership principles. Like you can't say like that's a product decision. Yeah. Like go la la 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.

Yeah. Which is already, I guess like, you know, like a startup founder would like say like, these are my ideal folks. Yeah. Plus on top of it, when you leave. any big company, Google, meta, 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 cloud 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 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 this next project because we, you know, us collectively on this team want to learn that tool, so we're going to use it. I'm like, that's pretty awesome. Like that's 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. 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 either go to big tech or become a founder this amazon does open multiple paths you can keep going on in larger companies you can 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 in amazon is related to the like independence thing of like everyone can do whatever they want is imagine 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 page 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. 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 six months. They don't. And like, the actual stats are not in some pockets they do. But in some pockets they do.

Absolutely. I have met teams that had no one, like 13 engineers on one team, no one had 10 year 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 those places became great after I had new managers.

And so I had great. great managers. We had great orgs, great peers, and you would just see pockets of terrible ness here or there, but 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 send to Facebook as well, but in total, how long did you spend at Amazon? I think it was a little over 12 years at Amazon. A little bit of Facebook, a bit of Facebook. Afterwards, you had a little stint-out. I took a leave of absence and like towards the end. it took a leave.

And then you worked at Bayes Academy for a little bit as well. But then you made a decision to retire. And you're still young. You don't look 65 to me. So how did you decide on retiring? And what did it take to build up a kind of financial independence to be able to do this? What do you do right now? 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 a bunch about it and learned math, you know, like financial math in terms of like withdrawal rates and investment things and index funds and stuff. And so many, many years ago, and in my 30s or whatever, yeah, I guess that's a while ago, early 30s, let's say, I realize like how much money I would need and like keep an eye on our expenses every year and stuff like that. And so Amazon pays well. Stocks go up. Like over time, if you're making tech salary, they used to.

They did. They used to back in the day, back in my day, stocks actually. Hopefully they will. Yeah. Yeah, hopefully they will again someday. And I would say almost like as for tech workers, it's like keeping an eye in 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. And so thankfully, 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 us 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. So there's just like that fundamental, like, what am I going to do with my life when I don't need to work? I can keep working.

I enjoy working, like some aspects of it. I don't like waking up in the morning and commuting sucks. But I really appreciate sometimes, like, hanging out with smart people and talking to them 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 what, like, what do I do next with my life?

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. And so I 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.

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. One of them was the main one, in fact, was like the Amazon Leadership Principles article that a lot of people know about. Yeah. 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'd 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'll do a newsletter for a bit. 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. So I just pushed some button and said, I thought, well, 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. And this is Scarlet Inc, right?

This is Scarlet Inc. Yeah. So the short thing for Scarlet Inc is I got that domain a long time ago when I thought, like, I want to do some kind of writing, a blog, a newsletter, a book, or something. 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 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 black print.

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 I got Scarlet Inc. I wrote the Scarlet Inc. newsletter. It was really fun. And I was writing for a bit. And I kept saying and thinking like I'm just sort of on a sabbatical 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 interviews. I talked to some people at Google.

I talked to some people at other companies. And it was like, meh. But the newsletter kept growing. And then 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 job 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 article. 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. 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. Sitting in the office and being forced to do it for 40 plus hours a week doesn't sound quite appealing. So it sounds like you built up really good savings as a mix of just working in back tech being at a good time where, you know, like there were stocks awarded where it were. Yeah, back when stocks went up.

It was appreciation. But you also read upon financial independence, the planning. you actually start 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 nonprofit job at the Basis Academy, whether you should work at other companies. And then you just did something that kind of like just worked out. Yeah. Sounds like because you didn't, is it fair to say that maybe it worked out because you just didn't really have the pressure?

I mean, if this didn't, if this like once a week newsletters didn't work out, you probably would try something else, right? Because you have no pressure right now. 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 if you're not trying to impress people, your work product for creative things is probably a bit better because I'm not, I wasn't. and I don't try to appeal to like what do people really want to hear like what's the hot topic. 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.

Which I still believe in. But 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. I did some, I did actually some code 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 we first met you. You were still doing a little bit of that. Yeah. Yeah. So I was doing hourly coaching and I, my wife and I argued about it because 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 because 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 because I was making such a huge amount of money per hour. And people are 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 I lowered the rates a little bit and then people were still buying and I ended up just turning it off. I just told everyone like, sorry, I'm not getting joy out of it anymore. And I don't know why I'm doing it. 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 fundamentally something that 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

will be like, I got a raise, so I spend more. 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, over time, like, you know, you can afford things and say 15% of the next time. time, you know, your next raise, you can save 20% of your salary, 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, you can retire pretty damn fast if you're

saving 85% of what you make. And then where did you learn about financial independence or for people who are thinking about like, okay, I'm actually an inspired. I like to learn more. Where did you started. You have some pointers of books, resources? Yeah, the internet. I would say, Mr. Money Mustache, and he doesn't write as much anymore, but you could definitely, he has some pretty fantastic archives. The Mr. Money Mustash is a blog, you know, newsletter. Mad Scientist was another one who also, he's been retired for a year. 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 the right once every two months because they're busy with their life. And like, yeah, the driving. That's what they wanted to do.

It was their thing. So almost no active newsletter exists that was from the time of which I originally read about it. But yeah, Mr. Money Mustache, Mad Fienist are the biggest ones that I read about at the time. But there's a good selection of, actually, hold on one second. There's a, I was going to look up the book. I can't look it up right now. There's a book that I recommend on my website, in fact. You can set it over and then we'll put it in the show notes afterwards. This was really fun. Yeah. Both about software engineering and a little bit of working on management. We didn't go into too

much easier at this time, but perhaps on a follow-up one. Yeah. Well, thanks very much for being here. This is fun. Thanks for having me. It's been fun. I enjoy chatting on these topics. I hope you enjoyed this deep time into how engineers at Amazon work, as well as how

working at a large tech company like Amazon could help getting to your retirement like Dave has done so. Thanks to Dave for a great conversation. You can read more from him on his news that are 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. 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.