The Peterman Pod - Meta Senior Manager (M2) on Manager Career Growth, PIPs, Amazon vs Meta | Stefan Mai

Episode Date: August 15, 2025

Stefan Mai was a Senior Manager (M2) with experience across Meta and Amazon. We went over his career story in growing to M2 which is equivalent to Senior Staff (IC7) in big tech. Since he started his own company now, he was happy to be fully transparent about the behind the scenes of managing in big tech. Since he founded the interview prep company, Hello Interview, I also thought it’d be interesting to talk about trends he’s seeing in AI cheating tools and how to get offers at OpenAI/Anthropic. We discussed:• Meta Senior Manager (M2) career growth story• Amazon vs Meta culture• Which company had stronger engineers• How low performer quotas & PIPs work• Eng vs manager career growth• Transitioning to AI/ML as an eng• Getting offers at OpenAI and Anthropic• Advice for his younger selfTimestamps:(00:00) Intro(00:59) Early career at Amazon (05:46) Growth to eng manager at Amazon(11:31) Storytelling tips(16:28) Why he left Amazon(22:59) Transitioning to AI/ML(27:01) Senior manager (M2) promo story at Meta(31:30) Mutiny and manager politics(40:34) Are managers harder to layoff?(49:50) Senior manager (M2) skill gaps(53:21) Eng vs manager career growth(56:27) Amazon vs Meta culture(01:00:34) Amazon vs Meta performance(01:05:24) Low performer quotas(01:08:55) Can you get out of a PIP?(01:12:23) AI interview cheating(01:16:42) Passing OpenAI & Anthropic interviews(01:18:33) Job hopping(01:22:37) When he grew the most(01:24:22) How to write better (01:26:22) Career motivations past M2(01:28:11) Advice for younger selfWhere to find Stefan:• LinkedIn: https://www.linkedin.com/in/stefanmai/• His company: https://www.hellointerview.com/Where to find Ryan:• Newsletter: https://www.developing.dev/• X/Twitter: https://x.com/ryanlpeterman• LinkedIn: https://www.linkedin.com/in/ryanlpeterman/• Threads: https://www.threads.com/@ryanlpeterman• Instagram: https://www.instagram.com/ryanlpeterman

Companies are ruthless right now with performance. This is Stefan Mai. He was a senior manager with experience across Amazon and meta, and last week I asked him about the behind the scenes of managing in big tech. You mentioned Pips. Are they just a formality to create a paper trail? Like at Amazon, HR really just wanted to make sure that it was a pretty savage culture, to be honest.

Low performer quotas, how do they work? It's mostly like a group survival thing, But in most cases, what ends up happening is that... I also asked him about his career story growing to senior manager at Meta. What was the thing that made you leave and want to join Meta? The second thing that kind of bothered me is that Amazon in general... Meta versus Amazon, what are the cultural differences that stand out to you? Probably on average, I'd say meta engineers were a bit stronger, but they weren't as...

Let's get into it. I think that the things that... I wanted to ask you, I mean, because you were a senior manager in big tech, I feel like there's a lot that goes on behind the scenes and managing orgs. And I thought it would be really interesting for, you know, all the ICs out there, all of the, you know, PIP stuff that happens, all of the stack ranking, behind the scenes performance management. And of course, I was curious about your career. So I guess before we dig into all that, maybe we can start with Amazon. Can you tell me a little bit about what you worked on? and how you got to Amazon.

Yeah. So I guess for me personally, I was one of those engineers who was like not very focused on school. I always wanted to be building. And my initial work was just kind of scattered. I did consulting and worked at startups. I didn't really find the technical depth. And so when I had the opportunity to go work at Amazon, this is I think back in 2012,

I basically leapt at the opportunity. It seemed like a place that they were working on some really hard problems at scale. Now, funny enough, Amazon had this reputation at the time. This was before the New York Times had published this article about people crying into their desks. But it was a place that was known for just grinding down engineers. And I think that's still true of its branding today. But I ended up joining the early advertising group. Advertising for Amazon now is a gigantic business.

It's one of them with profitable units. It basically makes up for all the retail lack of, profitability. But I was part of one of the early teams that was building out self-service advertising. So they had done a bunch of work with Procter & Gamble, et cetera, et cetera. And my team was responsible for building out and scaling the ability for individual vendors to basically create advertising and presence on the site. And it was kind of a weird situation. My manager was eccentric, I will say. He was a very inspiring guy. He was a very inspiring guy. And I look back on the time and I kind of look through this lens of what does this mean for me as a manager.

But he very much had this idea of how things would be done that I don't agree with today. And so I remember, I think within my first week, my manager came down. I think it was like six o'clock. We were all gathered in a conference room. And he said, I've got an idea. This is what we're going to build. And we're going to work nights and weekends until it happens. And I want to do it by October.

So he was basically committing us to this death march for about, you know, six to eight months at the time. And, you know, I had just left another job. I had told a bunch of people that I was going to, you know, go work in this big tech company. And I was committed. I think now if someone had told me that, I would have been like, I don't think so. But I really leaned into that. And it formed kind of the basis of some of my early development, both as an engineer and how I thought about leading teams. But it also gives me a flavor for like what Amazon is like in kind of its raw as form. And I feel like that death march is kind of emblematic of a lot of people's experience, at least on the negative side with Amazon. You went towards the advertising space.

Was that something that you picked? or was that something that there was a general pipeline and you were placed somewhere? No, good question. So Amazon at the time wasn't doing kind of general recruiting. So basically, you would get reachouts and you would engage with a specific org. And in my case, the recruiter that I was working with was strictly in advertising. I did have a choice between multiple teams. And I basically chose the team that seemed like it had the most growth and most opportunity. The pitch was pretty strong and ultimately it was a very important business. Like this was the beginning of Amazon ad.

So, you know, from a career perspective, it was a good choice. But, yeah, I didn't have an option to go work on S3 at AWS or something like that. And so it looks like it turned out to be a huge grind. And I saw that you stayed there for some time. You know, what was the average work like or was that just an early death march for you? Yeah, I would say that that wasn't completely. standard throughout my career. There was certainly times where things settled down. I'd say like the average was working hard. I think any big tech job is going to require quite a lot of effort.

And even more so if you're ambitious and want to get things done. So, you know, for me, working 50, 60 hours a week was fairly common. But it wasn't always the case that it was working nights and weekends. Right, right. Okay. That's good to hear. I saw that you went from, you know, you grew through the early levels and then you also transitioned to management at Amazon as well. Are there any notable stories from your growth to an SDM? Yeah. So that was kind of an interesting transition. In part because I guess my level of ownership and engagement early on meant that in many places I was a de facto lead for the team. I guess technically probably would describe my responsibilities pretty well.

well. And I felt like in a lot of cases, I was acting like manager of the team. My, my boss really didn't have time for a lot of the niceties that normal managers would provide. And so in some sense, I was doing that for the team. But that title actually was quite a bit lagging, at least as it felt to me, it always feels like this for manager transitions. People were like, I'm ready. And what you don't realize is how far you have to go. But, you know, I really push to try to get that title, to have those responsibilities. And I would say I probably got it prematurely. They should not have given in. Ultimately, I think that manager transition is really fraught. For a lot of people, they make a ton of mistakes early on. I'm no different. There's a lot to learn. And in some sense, the support structure

that you have around you is going to dictate a lot of your success. I remember for the first year feeling very uncomfortable, and maybe rightfully so. I was failing in a lot of different ways that I probably didn't completely realize. And it wasn't until, you know, 18 months down the road that I started to really get a knack for things and realize, yeah, this is actually something that I feel like I can do quite a bit better than other people can. What were those early manager mistakes that make you say it was premature? I think, you know, management is a really soft discipline. You don't have the same sort of output metrics and things that you can point to that are obviously yours. And in a bunch of cases, it's really about storytelling. It's like, you know,

how do you take account of your contribution to this team? How did you level people up? But I think for me, a lot of those soft skills were missing, at least initially. So as an example, I don't think I spent enough time really getting to understand and know the goals and objectives of all the people on my team. This sounds like Manager 101 stuff, and maybe it is. I think I really at the time that this was important, but I didn't know how to do it. I didn't really know how to break through to people. I didn't know how to get them to open up about the most important aspects of their work. And as a result, I wasn't able to cater both the support that I offered, as well as kind of the work that we were assigning and helping people to find to the individual.

I was kind of making a very elementary mistake as it pertains to management. I see. You mentioned. mentioned getting people to reveal their goals. Do you have any tips for that as early manager or four early managers? I think being a new manager is very tricky because in a lot of cases, you'll make that transition in a team that has seen you as an IC as a peer. And the relationship is necessarily different. I think a lot of people think, oh, you know, I've got a good relationship with a bunch of other engineers. we're able to talk about stuff, they'll be able to be transparent. What they don't realize is that power dynamic that is introduced is really corrosive to some of those bonds. And ultimately, the same kind of information is not all that useful.

So it's not enough to know that your friend is having a good time or a bad time. What you really want to know is deeper questions around, you know, what are their career objectives? What is it about the work that they're doing right now, that's really dragging on them? And so I think for new managers, the first thing that I would say is being able to actively listen. Active listening is something that is very familiar to people who are not engineers, but can take a while for engineers to learn. And it's basically this idea that, you know, when someone else is talking, show your interest. Sometimes people will talk about subverbals, so you know, ms and ahs and I heard you.

Reflect back to them things that they've said to you so that you can make sure that you heard it well and they can feel heard. And then ask them questions that show your curiosity and interest. A lot of times engineers will enter these really transactional relationships where they're used to talking in almost like APIs. But most of the time people aren't quite like that. And so it's really important that you are getting people to open up. Because in some sense, you know, the jewel that you're able to access is the thing that's going to help you be an effective manager for that person. But they're not going to just give that up to you. Most people aren't kind of that well trained.

The API thing makes me laugh a bunch because when I was really early in my career, I treated my one-on-ones as, you know, pure transactional. We're going to go through this laundry list of things in the most efficient way possible. And I always remember people, you know, there's often this preamble at the beginning of a 101 where you say, hey, you know, how's your weekend or, you know, what are you doing tonight or later or something like that? That's, I always thought that that was, you know, a waste of time. But now as a manager and just as a more normal person, I see the value in it for sure. And so that makes a lot of sense. You mentioned storytelling. I think obviously for managers, there's a lot of sense.

lot of value in that. And I think also for ICs too, people talk about the storytelling behind talking about your work or maybe getting people interested and getting buy-in behind things. Do you have any tips on how to improve your storytelling? That's a good question. And I agree that storytelling is kind of like bedrock essential skill set to develop. I think, you know, part of it is just practice. I think a lot of people don't really realize that they're telling stories all the time, but they're not necessarily putting a lot of attention to it. So like when you recall details to someone, it's a story in some respects. Or, you know, when you wake up in the morning and have to motivate yourself to get out of bed, you're probably telling yourself a story. And so I think

the first trick for a lot of people is just to recognize those moments and start to critique them. It's like, what story am I telling myself today? I'm going about, you know, getting to work because, you know, it's going to give me money or, you know, this was the most exciting work that I could think of three months ago. And while it's hard right now, it's going to get better. And, you know, here's the trajectory that we're headed to. You know, one of them is going to help you get out of bed and the other one is not all that good. And so noticing that and being able to critique it is kind of a first step to developing your awareness of the pervasiveness of it. But once you're able to be critical of your own stories, then you can start to practice and get better at telling them.

That was actually always something that came a little bit more naturally to me, at least than some of my peers as managers, that I always love to tell the stories of my team's success. And so what I wanted to do every few months is just look back at all we had accomplished and then paint it in the clearest picture so that people could feel proud of their work. It's like a lot of times we just go to the sit in it to the grind and we're delivering things all the time but we don't take a chance to just really reflect on how far we've come. And being able to say, yeah, we started with a Tina 2 and our on call was garbage and we really invested in that and turned it around and with the extra bandwidth, we were able to crush it,

that can be really motivating for people. And it also provides this really great foundation for you to also describe what the future looks like. To be able to say, you know, here's where we came from, here's where we are now, and here's how it's going to get us to the promised land. it's kind of the foundation of a great inspirational story. And I think a lot of people, and I would say the average manager, doesn't have a good handle on this. And as a result, people are kind of wishy-washy. But if you can have a team where you are winning, and as a manager, you get to define what winning actually is.

But a team that's winning, a lot of other things are downstream of that. You know, how people relate to each other, whether they have zero-sum mentality, whether they're getting in bickering, matches or excited about their work, if you've got a good story and your team feels like they're winning, those things will come very naturally. On the other hand, if you don't have that story and your team doesn't feel like they're winning, all of those problems are going to fester and become insurmountable. So, yeah, I think the key is really about being able to critique the stories that are already so pervasive in your life and then use that in your practice to be able to improve. You mentioned your manager didn't have time for the niceties. What was your

manager doing then? And how did you have that opportunity to kind of do that role before you even had that title? So I guess my manager was a senior manager and the expectation would be that he would be managing other managers, but didn't really feel like he should have hired other SDMs. I think it's the title at Amazon, or at least wanted to wait as much as possible. The impression I got is that this was just a way of exerting control over product. This is the thing that he was most excited about and liked to spend a lot of time working with design, refining the product and making sure that we went to market with something that he thought was going to be successful. Debatable whether that was the best use of his time, but it was invariably the thing that

he was most focused on. And that meant a lot of things kind of fell by the wayside that traditionally an engineering manager and SDM would be doing things like, you know, checking on the team's progress, understanding their career, mentorship, things along those lines. It just weren't quite as important. So then if you were to survey the sentiment of his org or the people that were reporting to him at the time, do you think that it would have been really negative and there was attrition and people were unhappy with his behavior like that? Yeah, you had a lot of people who were pretty upset about the situation.

I wouldn't say things were particularly good. I see. Okay. And so coming to the end of the Amazon leg, what was the thing that made you leave and want to join meta? Okay. Amazon, I guess, is a really special place. I speak some of the negativity on it, but there's actually some really cool aspects of the company. It's undoubtedly very successful.

the engineering discipline is actually very strong inside the company. There's a ton to learn there. And so I think, you know, I don't want to give the impression that Amazon is not a worthwhile company to work for. I think it certainly is. But there was a few things that kind of like stuck out to me after I had spent a pretty considerable lot of time there. One is that part of being successful at Amazon is kind of assimilating into a weird kind

of leadership. Amazon calls it their peculiar way. or at least they used to. They had a nice little mascot that they had around this. And what you start to realize is you're a good Amazonian. You're not necessarily a good engineering leader, or at least it's unclear if you spent your entire career there. And that started to kind of like fester in me. I wasn't sure whether I was just overfitting to this Amazon opportunity and I wasn't sure whether I was growing much. The second thing that kind of bothered me is that Amazon in general, I think there's a better job of maintaining evenness in compensation and

talent development. But in some sense, it makes some sacrifices in order to do that. So like, I remember getting a promotion or maybe it was a really high rating at one point and having no change to my compensation. And I thought, well, what's going on here? This doesn't really make sense. That was quite frustrating for me. And I think the explanation was, oh, the stock had appreciated a lot. So, you know, you already got your pay. And it's kind of like, well, that's true of everybody on the team. That seems a little bit silly. But the last thing, and I, you know, I would periodically respond to recruiters who are reaching out. But when Facebook had reached out, I thought, well, I'm not a big fan of the product itself, but I'm a big fan of the engineering culture in this

company and the team that they had kind of like pegged me with, I was a team in integrity, which was basically doing work around child safety and preventing terrorism and things along those lines. And I thought, well, this is really interesting because I mean, I had been working in supply chain at the time. I was doing a bunch of ML work. And while moving Amazon's, you know, profitability a little bit, clearly had some impact on people, lower prices, whatnot. It wasn't the same type of qualitative impact that could have at another company. So those first two things kind of motivated me to look and then, you know, the last piece really was enough to tilt me into a new opportunity. You mentioned Amazon's peculiar ways and how that might be different from what a good

engineering leader is. What are those things that stick out to you where you thought, I have that at Amazon that's good for Amazon, but that may not actually be the thing that's for a good engineering leader is? engineering leader? All leadership is trade-off. Like styles have pros and cons. I don't think that there is one best way. And so I don't want to kind of give that impression. At Amazon, one of the ways that their leadership works is built around this idea that the company for the longest time was very low on margin. You know, it basically made money by being efficient. It's operationally very lean. And you'll actually hear this reverberated through some of the leadership culture, talking about lean manufacturing and so forth. And what it usually involved from a leadership

perspective is each layer of the management chain, just getting involved, very detailed level of the layers beneath them. And that even meant as a line manager that it was almost expected that I understood what every person on my team was doing at any moment. And the benefit of this is things didn't just happen. People were aware of them. They were very closely tracking metrics, understanding what was moving around. There's a degree of discipline that's required in order to make that happen. But on the flip side, it can be really stifling to creativity and kind of like the ability to work on innovative new approaches if in some sense your boss needs to be queued in to all the things that you're doing. That was one aspect of Amazon's culture that I don't quite understand

until I was kind of out of it, but that I think limits their ability to go into new opportunities, to innovate with new products. But with the trade-off, that it's very effective at kind of like these growth stage where the sole purpose in some sense is just to move 1% on your revenue or to drive your cost down by 1%. In those cases, that style of management, is completely appropriate. I think Kent Beck has this nice framework. I'm not sure if you've heard of it, but I think he calls it the three Xs

or explore, expand, extract. And what he's talking about in those early phases is that, and this is true of like a seed stage company where you have asymmetric upside. So what you're doing is you're taking a constant tax in the early phases. You basically have a cost just of keeping people around. But the sole goal is to try to achieve

that breakout velocity to find that new opportunity that's going to be worth, you know, 100x. And so moving really quickly and not constraining yourself is really important for teams and companies in that explorer phase. And then if you fast forward to the extract phase, these are teams where the benefit that you could have in the best case is like a one or two percent improvement. But you have this catastrophic risk that's constantly looming. It's why most companies don't allow employees to just jump on to social and represent the company. Because even though they might have a banger post idea, they could also just completely trash the company's reputation. And so in those cases, you want to be pretty risk averse.

And I find that Amazon culture tends to lean toward the later stages of Kent's framework, in part because that's how the company has grown over the past 30 years or so. Yeah, and at that stage of its growth, I mean, it's a more later stage. companies, so it kind of makes sense that it's on the later end of that life cycle. You mentioned that at some point you transitioned to working on ML work and forecasting at Amazon, and I know you continue to work, and integrity is a very machine learning focused space. How was that transition for you? Was that challenging? I think it always is. ML is pretty different than traditional SWE work in ways that are kind of hard to explain.

where, you know, in a typical suite project, you've kind of got binaries. Your things are working or they're not. You can sometimes prove it, actually. Whereas with ML, you're oftentimes dealing with shades of gray. It's like a very common occurrence for people to have bugs in their training pipeline that they just don't notice for years. And then they fix them and then get marginally better performance. It's a really fascinating phenomenon.

But it means that how you operate in projects like this is very scientific. and a very experiment-driven. And that style of work is, or at least was, for me, fairly unfamiliar. It's also a field that has quite a bit of depth in terms of fundamentals. I found when I was wanting to make that transition, I was reading a lot of books, was participating in Cagle competitions, it was building models on the side. The goal for me was just to start to develop that experience so I could be effective in a different role. And I find that, you know, this type of transition is much more popular these days,

especially with AI. People are always thinking about, you know, how do I pivot into AI? But the, kind of like magic of it in some sense is being able to really execute. And I think that's missing for a lot of people. They really treat this as like a study session. Like, I need to go, you know, learn the 101. And the 101 is important. Don't mean you wrong. But your ability to be effective as either a leader or an engineer is also dependent on your judgment and instinct, which only can be honed if you actually go and build something, if you practice it. So you're saying the thing that helped you successfully transition was not necessarily learning those fundamentals, although you did it. It was the experience building, the

intuition behind what is improving model performance, and building your own taste in intuition. Is that right? Yeah. In some sense, I feel like the key for me, at least, was participating and Kaggle competitions and then finding ways to work ML into my present role. So that way I would be able to start to get that experience. There's just a lot of things that are non-obvious until you practice. Right. What was the motivation for moving into ML? I always thought that ML was just really interesting.

At the time, it was obvious that machine learning was just a very different style of how computers could work for us. And it was seductive in some respects. It's like for someone who had spent and I coded from a pretty early age, instructing computers on how to do things, this idea that we could just kind of like imply basically a program from the data what was really attractive. And it also felt like a lot of what was societally important at the time were actually ML applications.

It's like we didn't completely understand what was going on there. You talk about ranking in newsfeed or recommendation systems or in Amazon supply chain. There was a tremendous amount of machinery from predicting when trucks would arrive and whether vendors would actually submit inventory on time to what customers would demand. All of these pieces fit together in a really magical way to produce an output that, you know, is just pretty forgettable. It's like the item arrives at your front doorstep. But there is just so much complexity.

I think it's quite beautiful behind those systems. And that's true of general software systems, but maybe not in the same way. I found ML systems to be particularly attractive, I guess. You're going to your time at Meta. I saw that you got promoted from a frontline manager to a senior manager. And I think a lot of people struggle with that growth. So I'm curious, you know, what did that look like for you? What was the story behind that promotion to M2?

Yeah, it was a long story. I think I got promoted about three and a half years into my time at Meta. Overall, I had, I think, seven different managers over my time. So like one every six months. So it was very tumultuous for a bunch of different reasons. I think ultimately that held me back. And maybe part of my promotion story is actually like how to handle organizational shifts and, you know, maintain some momentum. some there. But when I first joined, I wanted to be useful as quickly as I could, which actually fit very well with what Metta was looking for Facebook at the time. And so I joined me on call. I started writing code. I basically acted like an engineer. And I think both this built a lot of trust with both the engineers on my team as well as some of the peer teams, but also made me much more comfortable with the work than I think some of my peers who really tried to stay out of it.

that's not sustainable. I don't think that, you know, people can do that for a long time. And in fact, I needed to shift my focus to recruiting. I basically had a blank check on recruiting for my director at the time. But that base was really important because in some respects, you know, how people perceive you, especially as a manager, is going to either be a huge headwind or a major tailwind for your progression. I think a lot of people do end up in spots where people feel like they know who they're going to. this person is and where they fit. And that can actually be devastating for your career just because it means those opportunities may or may not be coming to you. People have difficulty shifting what they think a person is going to be like in the future. So that was really important. After I had kind of like established myself and shown the effectiveness of our team, I was eventually given an additional manager who would work with me. And she kicked ass. She did a really great job. We, worked pretty well together. There was a bunch about that process of leading another leader that I really needed to learn. I'd say it's kind of the same process. You know, becoming a manager has a lot of

things that just hit you differently and you don't really understand them completely until you sat on the other side. Because I think there's this expectation, especially amongst a lot of line managers that I talk to that, okay, I know how to lead other people. I know how to, like, have impact indirectly. Surely, layering another manager beneath me is just kind of that same thing, right? It's that same pattern. And that, the response that I have to that is like, yes and no. Like, it is nowhere near the same degree of difficulty shift from making that initial

transition. But I think if you assume that leading other managers is going to be, like, leading engineers, then you are going to fail very quickly. For a lot of people, it'll just be mutiny. You know, your managers will find some way to displace you. I think what people don't realize is that, especially in manager stacks, that in some sense, you're competing with each other. Like, it's basically unstated in a lot of fashion.

But, you know, if your org is not growing, the path forward for some of the managers who are leaf nodes in this org is actually to take the position of the people that, you know, they're reporting to. And in many cases, that person will just leave. and, you know, someone will take that spot. In other cases, you know, that person will get displaced, in part because the people beneath them are far more competent.

And so there is a very weird dynamic that unfolds amongst managers, leading managers. And I had a surface level grasp of this, but there was a lot more for me to learn in order to be effective and also just to add value to people beneath me. You know, that went on for some time. That transition didn't happen until I had an org of about, 30 to 40 people. In other companies, I guess, you'll typically see a promotion before then, but by that point,

you know, I was basically sitting in calibrations alongside a bunch of other M2s. And, you know, at a certain point, it's kind of hard to deny that, you know, this person's doing the job. So that was my promotion story. The mutiny you mentioned is really interesting. How does that surface in practice? Like, how could someone underneath you kind of, you know, usurp you or kind of that mutiny could come in?

I think that the easiest way you'd see that is just in skip level meetings. The managers are describing. They're saying, you know, Jim, he's not helping me out much and doesn't understand my career. You know, Jim's changing our roadmap or our priorities too much. In a lot of ways, people, you know, they grumble about things that are real, but some people grumble about things that are just, you know, reason to try to make their relative comparison between them and their immediate manager. In other places, people can get really sophisticated with this.

I hate to make it sound very political, and maybe we can get into this in a second. But the way that people kind of operate in organizations can get very creative very quickly. I remember having a conversation with my director at one point, and we had two teams in very different organizations with overlapping responsibilities. And to me, this sounded like a great test, right? It's like a scientific experiment. We'll let them run side by side. We'll see who wins. And then, you know, the company gets the better benefit, albeit with, you know, twice as much resources expended.

And he's like, Stefan, you could not be more naive. Let me tell you what's going to happen. And he was absolutely right. these two teams are going to find ways to undercut each other and fight with each other inside the organization that have absolutely nothing to do, you know, with their terminal goal. And the kind of like noise and friction and everything else is going to dwarf any sort of gain that you might get. And you actually might have those teams end up in a worse spot than if you just had one team doing it. That's like not a reason to say you don't ever have redundancy in investments.

But I think as it pertains to large organizations, especially when you're really, leading other leaders or even leading very senior ICs, you have to be cognizant of the gamesmanship that might be happening under the covers. And you can definitely assume good intent. Most people are not doing this because they're evil. But in subtle ways, people want to move. They want to improve and grow. And not all of those things are always aligned with the organization's best interest. And your job as a senior leader is to make sure that you can line those things up, that you can kind of keep people on this path to delivering value. As a manager, especially not just a frontline manager, but more senior manager,

are you saying that there is a secret chess almost where there's a behind the scenes motives that people have, aside from the business motives that are maybe their personal career motives and that can lead to some unusual behaviors or maybe these political behaviors that you're talking about? I don't know if I would use the word secret chess because it seems like much more obvious. Like generally speaking, most people's objective isn't to go and make, you know,

Facebook a higher value company. If you talk with people about their objectives, they're vast. You know, some people they want to get more money. Some people want, you know, certain positions or influence. Some people want to work on really interesting problems. Some people want to work with certain people. The things that people are,

are after are many, and they're very rarely kind of like single-faceted. But in as much as people have different objectives, they're going to do a bunch of interesting things to try to make those things happen. It would almost be foolish to assume that they wouldn't. You know, if there is, for instance, and this would be true for most I sees, an interesting project that you want to do. Most people have seen this play out on a number of occasions. It's kind of like, well, how do I make sure that I'm on that project? Well, I might pair up with other people so that way we can, you know, have a coalition that is making progress on it. I might go cookie lick. I might go to the project and be the first one to go and lay my name on it. I'm going to write a post and tell everyone that I'm at it. So that's hard to pull me away from that project. I might try to go and demonstrate that I'm the best person for it. But maybe the way that I demonstrate I'm the best person for it is by showing why the other people who might be taking that position are in. incompetent or they're not capable. And so you end up with all these behaviors that kind of happen. And if you observe people for enough time, you'll have a catalog of them. But in some sense,

understanding that dimension, kind of like that secret chess, and then making sure that you're cognizant of it as you taking actions is really key to being a senior leader of any large organization. It sounds like a lot of these behaviors are kind of zero-sum behaviors. So I could imagine in a environment of either shrinking company or stagnant company or I guess sub-org of a company, that these would be more prevalent. And am I understanding correctly that if a company or an org is growing a lot, there's just abundance. So there's a lot less of this going on because everyone can get there what they want. Totally. Yeah, I think this is a fantastic call in some sense. The zero-sum intelligence.

usually happens when the winning starts to slow down. The org stops growing. The successes are less obvious. And then, you know, suddenly people are redefining success in different ways. It's kind of like, okay, well, the business isn't doing very good, but our test code coverage is, you know, awesome. That really needs to matter to us now. Well, is that true? You know, who knows? But I think it really points to a couple of things. One is the imperative of winning that I talked about earlier. It's kind of like as a leader, it's your job to make sure that your team is positioned and equipped by you to be winning. And the focus on performance is really kind of like one of the more fundamental focuses that you can have. And a lot of other problems that we're talking about here

are downstream of that. The second thing that's kind of interesting there is that as orgs evolve, different leadership styles are more appropriate. It's kind of like a mature organization that, you know, is maybe relatively flat, requires a different kind of leadership that's more attuned to some of the ways that things are going to go wrong than that early stage where, you know, you can kind of like not pay attention. Like I think a lot of early Facebook leadership was kind of like this. Very, very talented engineering leaders who in some sense rode this tremendous wave of growth. But are those leaders the same ones that are going to do best during a, you know, a period of plateau. Who knows? That's kind of an open question. You mentioned when I asked about

what does mutiny look like, you said that, and I just want to confirm, it was that M1 would go to their skip, so I guess your manager and say, hey, Stefan is thrashing things. Are you sure he's good? Kind of things like that behind the scenes. In meetings you are not present. I mean, yeah, generally speaking, you see it in the same way that like disgruntled teams operate. It's kind of like everybody's making a lot of noise because they're unhappy. And in some sense, the implicit goal for them is to make a change. And the most obvious change is to change people. One of the things that is pretty interesting about being a more senior leader is actually your control over, you know, outcomes is even more diminished. For a lot of people, when they become managers, they get really uncomfortable with the

idea that, you know, generally, they're not the ones writing the code. They're not the ones making the design decision. They need somebody else to do that, but, you know, one of the engineers in their team. If you're a senior leader and one of your managers is underperforming, what are your options? You can't step in and go and do their job for them. That's just not an option. And in that case, that person's going to hate you and that will lead very quickly. You can give them some insights, But if you give them a lot of insights, then they're going to feel like you're trying to do their job or they're going to feel like they're underperforming. And so as you kind of walk up the org chart, the ability for a manager to make an impact on their immediate reports is less and less. It becomes more and more binary action.

It's kind of like, you know, we're obviously going to have conversations or how these are going, blah, blah, blah. But, you know, if Mark has an SVP is just not making the cut, he's going to let them go. he's not knowing to jump in and coach and try to, you know, have all sorts of programs to get them to the right level. Of course, that doesn't apply necessarily at like a senior manager level, but the same sort of trend does apply up and down the org chart. You've got less and less levers that you can pull to kind of turn things around. You mentioned manager underperformance. I'm curious because there were a lot of layoffs in the past. Do you feel like managers have, they're harder to lay off than ICs are. And if so, why? Moving managers around is like inherently

painful. Usually like when you put someone in a manager position, you're accepting that the blast radius of that change is larger. Again, we can extrapolate from if you grow the org. Like if you're going to bring in a new VP, everybody's going to know about it. Like it's going to be a major and intrusive change. So that comes with the territory. Whether like, taking someone out of that position or not is hard is in large part whether they're like load bearing for that position. If they've got a really tight relationship with their team and they know a bunch of like internal domain pieces and their cross-functional team really isn't pulling their weight and they're doing a lot of that, that's incredibly painful. Moving that person out could be very hard.

If on the other hand, you know, their team actually doesn't feel like they're adding a lot of value. their cross-functional team members are complaining about them. You know, they might be doing an okay job. In some cases, it can be invigorating to get someone who's not pulling their way out of that position. It's part of why leadership positions in general get so much attention and why they earn so much money. It is just that ramifications in the org chart are just so large. I think if the assumption is like during layoffs, are you less likely to get layoff if you're a manager, I don't think so. Most companies are going to target a specific ratio of managers to ICs,

and if you let go of a host of ICs, you don't need that many managers. They don't just keep them around. You probably won't see this if you're looking locally just because the likelihood of a manager being laid off is not as high. But we've even seen recently, you know, companies will do what's called a span of control reduction, well, I'll try to say, you know, we want to make sure that managers have 12 reports, or we want to look at the ratio between, I think Amazon did recently between ICs and managers and we want to increase it. And in that case, you know, the managers are the first in the chopping block. So, yeah, I don't think it's necessarily easier or harder, at least in a comparable, leveled IC. Yeah, I think I see the occasional

comment that assumes that managers or, you know, leaders have some special treatment and they, you know, can't be fired or it's harder. But yeah, I agree. I think we've seen that that is not necessarily the case. You mentioned types of leadership per stage of company and they have, there's different effectiveness if the company's smaller or any more scrappy versus like the larger companies. I'm kind of curious about that. What type of leadership do you think is most effective when the company is really small and what type of leadership do you think is most effective and the company is very big? So I think when companies are small, you really need kind of inspirational executors. In some sense, it's all hands on debt to go and deliver this thing.

There's a lot of excitement. People want to work for someone who's impressive, who could do their job, and in a pinch could kind of step in. If you look at kind of company history, there are plenty of examples of this. And generally speaking, you've got these SBPs or directors who are there in the trenches, designing some of the initial features, and that can be kind of so attractive. But I think as companies scale, that becomes harder to pull off. And then those same individuals oftentimes don't have the same sort of organizational aptitude that they need. And so it is like a very different skill set to be able to work in a larger organization where, you know, you're actually not going to have much of an impact by just digging in and getting your hands dirty.

And then there's not going to be a bunch of momentum behind it. It's kind of interesting. If you think about big companies, they focus is like a precious commodity. And it's very hard to achieve. People will talk about this in terms of alignment. But, you know, the biggest opportunities, there are just a few of them for a very large company. But you have this very large organization who can look in 100 different ways and go in 100 different directions. So if you've got those individuals who are go-getters and the go-getters and the,

see an opportunity and they just run at it and they're not able to align and, you know, move information up and down the org chart, they're actually going to get in a way. They're going to siphon off energy that could otherwise be put behind kind of the core initiatives. So I'd say that's at least one way that you might think about what leadership is most appropriate is kind of like, you know, how close to the execution do these people need to be. But, you know, each kind of company is going to transition in different ways. Like, this was fascinating for me watching. So Amazon, the way that they scaled is by basically setting up each team and building really

concrete APIs between each team. One of the early CTOs at Amazon used to call them fitness functions. I think he got fired or let go. But, you know, the idea was basically this team would be responsible for two or three metrics. And they would labor under those metrics and focus on them to the full extent. And the nice thing about this is it meant that the engineering leadership could then just assemble these pieces, kind of like you would assemble a system of APIs. And because each piece was dependable, you know, you can build a pretty tall stack.

And so at Amazon, that worked really well for scaling out the Ord. But it necessarily meant you left a lot of kind of interesting things in organizational seams. So like if two teams draw their lines here, you might be. cutting out a whole lot of value. And also, if these teams need to move to like adapt to a new change, well, they don't know how to. They're going to be focused on that one thing that they've been focused on for a long time. So, you know, leadership has to come in and spin up a new team and that takes a while. They're not very responsive. So that's one style of scaling that Amazon is kind of known for. Meta slash Facebook took a very different approach. The org is very malleable.

engineers move between projects. Teams don't have really strong assignments, or at least they didn't at a point in time. The code was owned communally by everyone. And what that meant is that as Facebook scale, they needed leaders who were able to kind of work the soft alignment throughout that organization without these big boxes that they could draw around them.

Amazon leadership could benefit from engineers who were kind of building an organization on top of these API primitives, meta leaders needed to understand the people that were involved and what they were best at and how to move them and inspire them. And so the kind of person that you need in each situation is going to be very different. So there's a bunch of different dimensions that are going to change, depending upon company dynamics.

But it is somewhat illuminating looking at those two examples, just because they, well, theoretically at the same level, you know, it's two big tech companies, ended up in very different locations from a leadership perspective. And that kind of informs at least my thinking about, you know, how leadership looks like across companies. The caveat that I want to toss onto the table is you can't just staff a company with organizationally savvy people. Like eventually it becomes negative some. At a certain point, you just have a bunch of sharks who are all fighting each other and they're not getting anything done. So there's always a balance that's actually required.

But look at, I think Open AI is kind of a good example. And it's a company that I haven't worked at. So this is observations of their hiring process and then talking to people on the inside. But generally speaking, when Open AI does interviews, they focus a lot on technical achievements at the expense of some of those organizational pieces. So, like, one of the pieces of guidance that we often offer people who are preparing for, like, project retrospectives and more of the behavioral. is to go deep on those things that are just like really impressive technical achievements or hacks. And not as much on I built alignment between six different parties, blah, blah, blah. Now look, Open AI has a ton of politics inside the company.

It is not immune to these forces by any means, but they still kind of paint themselves in that early phase where they need to be driven by these people with these, you know, technical achievements as a means of them attracting the right talent, of achieving kind of their breakout velocity in terms of what they're able to deliver. So lots of different dimensions that are at play. I don't think you can generalize across these to any degree,

but you can kind of notice some trends and in general there is maybe an entropy. As orgs get bigger, you have to have people who know how to navigate. It's just it's not something that you can avoid. When I asked you about the promotion to senior manager, you mentioned the size of your org and that managers were reporting to you. So it sounds like that was a big part of the promotion to have the scope to be a senior manager.

I'm curious about the skill difference between an M1 and an M2 in your opinion. So I'm curious, like if we were to just imagine, I took a random M1 or maybe yourself before you were promoted and you were just a new M1. And I put you in an M2 role and we just said have at it. What are the biggest skill gaps that you would have had? So I think being able to like credibly add value to the people who are reporting to you is probably the major one. I mentioned some ways at which managers have reduced or managers of managers have reduced

kind of options in terms of how they can interact with their teams. And so knowing what those restrictions are and then knowing where to exercise the most important ones is something that's that's hard for like a straight M1 to recognize. So as an example, you know, you might have a new M1. They're feeling really good about their understanding of people. They go set up skip levels with, you know, all of their indirect reports. And they ask them, oh, you know, what do you think of Jim? Does he say anything that, you know, you don't like? Is he touching on all of the important career pieces? And then a week later, Jim's going to walk into your office and go, you know, you talk with James.

and you asked her a bunch of leading questions around whether I was doing my job or not. And now she doesn't feel like I'm supportive enough. Like, why did you do that? And then Jan comes to you and she says, well, you know, I really think that you can help me out a lot with my career because, you know, you seem to have some really good insights that, you know, Jim wasn't able to see. And so in that moment, you've just disintermediated Jim, you've demotivated Jan and you've created a host of problems that you now have to solve. it's like a lot of very small things that you can do as a senior leader have these magnification effects.

And unfortunately, you don't really learn about those or you don't learn maybe the small things until you've either observed them yourself where you can kind of introspect and say, all right, let me think about all the interactions I've had with my senior leadership and where those worked or where they didn't. Or you've got like a good mental model for how these things sort of propagate in an organization. But I think subtle mistakes like that end up being kind of like the easy ways for an M1 and newly in that position to fail. And the expectation in a lot of cases is that they're going to make those mistakes. Just like when you transition someone from an IC to a manager, you're expecting them to make a lot of mistakes just because it's unnatural.

Nobody really knows about this. You can read it in books all you want, but until you practice it, it's a different story. And so, you know, my leadership chain when I was doing the M1 to M2 transition was probably thinking the same thing. Sitting very closely with me, this is part of the promotion panel, like what kind of support are they going to have? Does the person who they are reporting to have enough acumen to be able to bail them out if things start to go awry, that sort of thing? But a bunch of small behavioral things would be the first thing that they would screw up. You know, longer term, you know, there's strategy and org design and a bunch of things. and mistakes that you can make there. But those small things, especially in the first few weeks,

are enough to sink you. It's kind of a scary environment to operate and to be honest. You've experienced I see career growth and manager career growth. I'm curious to compare and contrast, you know, IC versus management, I guess growth paths. What do you think of the differences between the two? And also, I'm curious, do you find that they're both meritocratic? I often hear that there's some, you know, cynical takes on some, you know, one being less. meritocratic than the other, so curious your thoughts. I think at high levels, everything becomes a little bit opaque and fuzzy. One of the things that always kind of like was difficult for me to stomach as a manager

sitting in calibrations was very senior level ICs talked a big game about their accomplishments, but I didn't really see the evidence. It wasn't really obvious whether they were just around for these big initiatives that were clearly valuable initiatives, or they were instrumental in driving them. And the saying can be said of managers across the board. Like that it's really hard to do attribution. And I think over a long run, things are a little bit more obvious. Like if you have a manager sit in a role for four years and they continue to produce success,

it's kind of undeniable. But on a half to half basis, it's pretty dubious. So I could see why people would feel that way. I think for ICs, especially when you're like sixes, maybe sevens, it's a little bit more apparent to an external observer whether they're doing that or not. I think for an M1, you can usually look at their team, if you look at it holistically, if you look at some of their deliverables and make a pretty good assessment. But I don't think someone who's outside of their leadership chain or not involved in that minutia would be able to recognize it as clearly. At higher levels, I think that there is a bit of unaccountability for a lot of management. This is true in the stock market.

It's kind of like hard to assess whether, you know, a leadership team is any good or not. You really don't know until you watch it for a while. And then, you know, somebody might spin up a really great story to say, you know, it was macroeconomic conditions that's not my company. Not, you know, I failed to actually recognize that my customers were slowly walking away from me. That's true, I think, at the high end. levels. And I think it can be quite frustrating for people who are kind of sitting at a spot of limited visibility with a group that is really hard to kind of tie directly to any particular deliverable and go, this is fair. You want it to be as fair as you can. But I think at a certain

level, it is, it's difficult to have the data. I see. So the early promotions are the most easy to verify and fair. And the higher level ones are a little bit more. I mean, I'm sure there are a fair ones as well. But you're just saying it's a lot easier for there to be optics coming into play, narratives and stories that are kind of hard to tell what exactly is going on and who deserves what. Is that right? Yeah, I think it's a good summer. I see. Okay, cool. I think one thing I was curious to dig into is that knowing that you've been at Meta and you've been at Amazon and you had a fair amount of time at both, I thought it would be interesting to kind of ask you the the pros and cons of each or at least your personal experience. I know these companies are very large

and some people have great experiences in a small team and others have bad ones within these companies. But I'm curious, when you think about meta versus Amazon, what are the cultural differences that stand out to you? So I think Amazon is disciplined. And I think this is a major strong point. I felt like in general, if you really wanted to reach the height of very structured engineering design, you probably find that more likely in an Amazon review than you would at meta. I think probably on average, I'd say meta engineers were a bit stronger, but they weren't as disciplined. And that meant that, you know, design reviews and things along those lines were a bit more fuzzy

and kind of hand wavy than they were at Amazon. It also was a place where things were a bit more predictable, partly because the business just moved slower, but partly because you can depend on other teams to kind of meet certain SLAs. And you know, you can page them if they're not doing the thing that you want. Whereas at meta, if somebody's work isn't, isn't, you know, living up, you got to go make that change yourself because he's working on photos now. He hasn't been working in that code for months.

So that can be a little bit frustrating. I find that a lot of people who transition from Amazon to Meta in particular find that unstructured environment that's so endemic of the culture to be pretty paralyzing. They, like, don't even know how to operate. And in some ways, that's good. In some ways, that's bad. At Meta, the main thing that I saw is kind of like a major positive was just how open and collaborative the company is.

I thought it was amazing how engineers on my team were working with orgs that were completely across the company on various things. You know, we might be working with a researcher in Paris on some sort of image model and then, you know, some infra was being built out of London. And for the most part, I as a manager wasn't even involved in setting up these collaboration. People just found each other and they worked together, which I thought was super cool. I also really like how at Meta, there's a very acute focus on people and kind of like empowering people to make decisions.

Amazon has a really very process-oriented mindset. They talk about mechanisms. So like when something fails, they want to try to introduce process to prevent the failure. At meta, it's more likely that someone will go, well, we learned our lesson. You know, what will make sure it doesn't happen again. Now look, that has its downsides. Like a lot of Facebook's privacy issues are in some sense its inability to contend with the same process that Amazon does incredibly well, but it means it holds the culture back in a lot of cases.

Like one of the things that was very surprising to me working in ML at Amazon is how hard it was to get access to data. Data is the lifeblood of ML and AI applications. And in a lot of cases that aren't actually these privacy constraints, especially for public data. But at Amazon, you had to go and build your own data lake and go and pull everything into your Spark data warehouse. At Meta, that data warehouse existed and everyone used the same one. So you didn't even have those same challenges. So there are two companies that I think have very different approaches. I tend to prefer meta's approach, especially as it pertains to leadership.

But Amazon had some things that I definitely missed as I made that transition. And there's clearly reasons way it worked. Like there are some individuals where I talk with them for five or ten minutes and I go, I think Amazon's a better fit for you, you know, accepting all the other externalities of an actual position. I think you're going to like it more than you might, the chaos that's usually a meta execution. Having been a manager at each company, you experience the performance system intimately. What about comparing and contrasting the performance systems at meta and Amazon? I'd say they're pretty close, to be honest.

I think everybody's kind of like descending into the same valley in terms of optimality. what you basically have is like a very public publicized process wherein ratings are established and handed out to reports. This is things that managers will talk about and we'll kind of hit on external pieces. And then you've got a more private, usually restricted to higher levels process wherein you're trying to decide where to make investment. Like at Amazon there's this top tier designation on that meta, there's additional equity or discretionary equity, which is basically, trying to say, who are like the real winchpins in the organization that we want to invest in to make sure that we're successful long term. And I think the important thing for both companies

is to make sure that people feel like the process rewards performance. That is, that perception is like incredibly important. I did an estimate. I went through and I kept time of all the different activities in managers and preparing for PSC and basically said, you know, here's how much we spend per employee on PSC processes. And I think there's one takeaway to this, which is like, this is wasteful. Like, how dare we spend $15,000 per engineer? We should be building products. But I think it's easy to miss the forest for the trees there that the integrity of the performance review process is the whole ballgame. If you get that wrong, and people don't believe the process is going to produce outcomes for them, they're not going to perform. In some sense, you know, the financial

rewards and promotions and everything else, you need to put as much effort, even if it's just a ceremony that doesn't actually do anything behind the scenes, you need to make it very believable and credible to people. Now, I think both companies do do a lot of diligence to try to maintain the integrity of the process. Like, I think it's valid. But I did find that meta was willing to really go to bat for, say, the upper quintile, as opposed to Amazon where I think partially due to frugality and partially due to kind of this fairness, they really were willing to just really double down on top performers. Like there would be engineers and people in my organization who would clear twice as much as their peers just because they had gotten so much additional

investment in equity in part because we knew that they were very important and they were going somewhere. At Amazon, that's pretty uncommon. You don't see that as much. And they would find some way to try to pull that back. They are a very frugal company. Yeah, I remember when I worked at Amazon briefly and one of the leadership principles was frugality and I never, I never liked that one, but nobody does. Yeah, it's a horrible one. You mentioned the additional equity or discretionary equity or is called top tier at Amazon.

How does, how do those conversations work? Is it derived from the performance ratings or these, you know, directors and senior managers kind of get together? How does that decision come to play? Yeah. And this usually gets, it gets driven by like the VPs and directors of an organization and how much they choose to involve the, you know, different managers and making that decision varies. You know, you'll know if you have a lot of trust, if they come to you and go, hey, who deserves this? I was in that position regularly, in part because my ore chain was constantly in flux. But, you know, I might not have been in that position quite as frequently if people were able to actually keep track of my org because they actually had a boss,

you know, who was consistent. But, you know, what they're really trying to do there is just figure out kind of, A, who's got trajectory? Like, who is the rocket ship? Even if you had like a, I wouldn't say niddling, but like a stellar but not exceptional half, but it was obvious that that was going to keep going. That was a criteria. I remember at Amazon, they talked about kind of, I think there was two dimensions. I don't remember the exact ones, but growth was definitely one. of them. And then the second piece, and I think this actually plays a lot, is kind of like, how replaceable who's this person? If they walk away tomorrow, is that going to break our organization? In some sense, getting into those positions can be very lucrative just because, you know,

they're going to, in some sense, try to put those golden handcuffs on you as tightly as they can if the org depends on it. Like the companies, generally speaking, know how to avoid completely embarrassing themselves with attrition, and sometimes the lever that they pull is just financial. But, yeah, most of the time they hope that it's more than that. You know, with some of the layoffs that kind of happened in the past, there was the, there's mentions of low performer quotas. And I'm kind of curious, is that something that you experienced when you're working at these companies? And how does they, how do they work? Yeah, definitely. I think every company is going to have this. Every company that is of

scale. You might not see this at very small companies, but the idea being there is a lot of gaming of performance. And you'll notice this, I'll refer to PSC, so Meta's performance review process, where, you know, suddenly the half that seemed pretty good or maybe okay seems like it was world-shaking, you know, as people were writing their reviews about it, and then every single achievement is just mind-blowing. And there's this inflation that happens in everyone's assessment. And ultimately, that's not true. It just can't be true on average. So a lot of companies will have some sort of overall distribution that they're trying to target. And in order to maintain high performance, they necessarily need to be letting some people go. Managers don't like letting people go.

I don't like letting people go. It is very uncomfortable. And so you have to beat people and make them do it. And it's mostly like a group survival thing. But in most cases, what ends up happening is that, you know, people check out or, you know, they decide that they want to go do something else. And if you're not, you know, reasonable with kind of acting on that, then the team starts to suffer. You notice that that person's not pulling their weight and, you know, you're going to start to check out too because it doesn't seem fair any longer. So quota-wise, the numbers will vary. Like for a lot of companies, it's, you know, somewhere between like seven and 15,

sometimes it can be as high as 20%, where they're going to try to put you in the lower bucket. At Amazon, it was like needs improvement. And at meta, it's like meets some or meets most. And the idea there is that amongst that bucket, they're expecting some of those people to not meet the cut. And that's, again, just statistics. But that's usually when like the PIPs would start to get engaged. and managers would fight aggressively to try to keep their people out of those buckets. And most of this is saving face.

Like, here is the worst scenario for you as a manager. And this ends up being heartbreaking. You work with a team. You guys kick ass. Everybody works really, really hard. And then at the end of the half, after you've told everyone how much ass they've kicked, you get instruction from your director that somebody's got to be in that low bucket. And now you've got to go change your tact.

You've got to go back to that person and say, no, actually, you know, you didn't. kick ass that hard, that wasn't even acceptable. And so those sort of like egg on the face moments are what most managers are afraid of, and they try their damnedest to try to prevent those situations. The reality is a better circumstance would be the manager is aware that somebody may be in the lower quartile and can message it appropriately. That way, they're not surprised. You're not surprised.

The kind of like structure works fairly. But if you've got a lot of immature managers or just relatively new or maybe they just don't see it clearly, then you end up with lots of situations like what I just described where people have to go of Maya Colba with their reports. And honestly, for everyone involved, most of which the actual person who's receiving that news, it can be devastating. So it's pretty bad. You mentioned PIPS. I'm curious, do you think that they work? And, you know, are there any differences between PIPs across the companies? This is based off that Reddit thread. I think someone asked, are they just a formality to create a paper trail or can people actually get out of a PIP?

So people can definitely get out of a PIP. I think PIPs are first and foremost a legal paper trail. But in order to maintain credibility of that legal paper trail, people have to make it through it. If you just create this process wherein you just create a paper trail and nobody makes it out of it, that's not really going to hold up legally. So at some level, it needs to be fair. Most of the time, HR is moderating this, and HR's appetite to advocate on behalf of the employee in these cases is variable. So like at Amazon, at least while I was there, HR really just wanted to make sure that you were checking the boxes. It was a pretty savage culture, to be honest. In, you know, most cases, you're setting expectations with an employee and saying, here's what you need to do. And if they make it, then they can turn it around. and if they don't, then they're gone.

It needed to be reasonable, but the manager held a lot of discretion on, you know, whether they wanted to pull the trigger. Now, again, most managers don't like firing people. So their preference is actually going to be for, you know, someone to go into PIP and then recover. And so in a lot of cases, if you are the person on the other side of the PIP, your manager could legitimately be rooting for you. They're not just lying to your face.

But, you know, whether their hands are tied or not is up to, you know, some other power in some cases. For meta, I noted in a lot of cases that HR really, really, really wanted to make sure that we had exhausted kind of every avenue before letting someone go. This is probably not true of modern meta, but it was true several years back, and in part because they really wanted to protect their reputation as an employer. And so, you know, I've had engineers who just had completely checked out, and HR was asking questions that really didn't make. sense and, you know, in a lot of cases, this person would probably not object to the way that we would summarize their work. Like, it's not always just like a completely crazy occurrence,

but sometimes companies will opt to try to be overly accommodating to the employee. I hate talking about this in some respects because it sounds so like cold and calculating, but the reality is just at the largest level, companies have to reward performance and they have to be, you know, sensitive with how they're making their resources. And as a result, you know, terminations are part of the picture. And it's important that companies do it fairly with sensitivity to the people involved, but they have to do it. Otherwise, the company won't exist for a long. You conducted over 500 interviews across your time in big tech. And you also have Hello interview, which is an excellent service for interview preparation.

and many other resources for people in the industry, which my roommate said it was like the best thing that he used in his prep and he got an offer anthrophic. So every time I'm interviewing you or Evan, he's, he's say, oh, it's those guys, I love their product. But I wanted to ask you about interviewing because I felt like you might have something interesting to say. With the rise of these AI cheating tools and, you know, L-LM assistants, I'm curious, you know, how much do you see that coming up when you're either helping people prepare or maybe you're just in the space thinking about interview prep. It's kind of funny because, like, as it pertains to interview prep, our incentives are mostly aligned. Like, you know, for the candidates, we want to help them to

succeed. And so them cheating at, like, mock interviews, for instance, doesn't make a lot of sense. But surprisingly, we've seen it happen on a few occasions. I guess the situation is probably like they're trying to like test out their setup to see if somebody will notice. So like you'll hear one of our coaches reached out and said the guy's talking to his friend in the background. Like, you know, what do I do in this situation? It doesn't make any sense. Remote interviews have always been a little bit cheatable. I think the existing tools make this horrible. Recruiting teams seem to be modestly aware of it. I think they are overly dependent on some mechanisms that probably aren't completely effective.

So, like, in browser interviews, they're looking at whether the page has focus or whether there's copy and paste activity, which is, like, yeah, the least sophisticated people, you will definitely catch them. And surprisingly, they do. Like, so they're clearly weeding out some people. But to be honest, I feel like a lot of interviews are going to change, in part because the role is shifting. It's like the way that software engineering is going to work in the future is pretty different than how it did, you know, over the past two decades. And as a result,

it seems kind of crazy if the interviewing itself doesn't adapt to it. We see some companies trying things here. So like they will have assignments that allow you to use AI, which is theoretically AI proof, or they'll choose questions that AI routinely gets wrong and You know, try them be robust in that way. But I'm more optimistic in the challenges and assessments evolving than I am in any of the kind of the anti-cheat stuff. Now, the sad part about this is companies are ruthless right now with performance. People who cheat in the interviews might get the role, but like that cheating is not necessarily going to pan out when you actually get the job. So, you know, I don't have any formal accounting of this.

I don't know many cheaters myself, but, you know, there's plenty of people who find themselves on the rough side of their performance review shortly afterward, which I don't think serves anybody's purpose. I'm curious because I imagine a Algo interview is more easy to cheat than a system design one. Do you see any differences in, I don't know, maybe the growth of Algo interview signups is, like, lower than the growth of system design signups or something like that? Anything that might make us infer that cheating has any impact on the future? So I think people are leaning, or companies are leaning more heavily into design interviews.

And that doesn't necessarily mean like system design, which I think is more standardized across big tech, but also like lower level design, being able to reason about, you know, classes and coupling and, you know, various interactions between subsystems. And it's interesting because in some sense, the quality of that design ends up being load-bearing in like an AI-coded world. You being able to come up with good abstractions and reason through them is more important. So definitely are seeing that shift. I wouldn't say I've noticed any really acute departures from coding interviews themselves. People have been calling for the demise of leak code for forever.

It actually serves a pretty useful purpose. It works for companies. As much as people want to say interviewing is broken, I think, you know, it's painful. It's very painful. But Broken is probably a step too far, in part, because it's serving company's needs up until this point. And so I think it's a bit premature to assume that, you know, that's not going to be a part of the interviewing process, at least in the short to midterm. If someone was hell-bent on passing Open AI or Anthropic interviews, what's the optimal game plan from your experience at Hello Interviewing? I think it varies. Those companies are looking for depth. Open AI was notorious for asking the same questions in basically every interview. I do not know why they were doing this. But going deep on kind of the functional areas that they tended to ask around was a pretty effective preparation strategy. That's not to say you could just memorize solutions. The interviewers are far more clever than that. But you can get a step up if you actually knew approximately the area. that they were in. The behavioral and retrospective interviews end up being really important for these companies. They really want to see, like, have you walked a walk? And I think how you

represent yourself and how you talk about that work also ends up being really important. Some of this stuff can be really hard to do introspectively as an individual. Like being able to actually talk to a friend or someone else who can tell you, here's how you came across. Like, here's the vibe that I got from you. It can be really, you. It can be really, helpful in refining your presentation. And in particular, the thing that I mentioned earlier was just moving toward the technical accomplishments and less about how you massage the organization to make things happen. I think for a lot of people, the crowning achievement of their staff engineer career at, you know, big tech is they wrote seven docs and then got six different teams to align,

and then finally wrote five lines of code in addition to like 100,000 that were written by junior engineers. And it's like, that was hard. I know that that worked deeply, but these companies don't look at it the same way. And you have to recognize that in order to really nail it. I see. Coming to the end of the interview, I wanted to ask you some career reflections, things just looking back on everything so far, kind of reflect on some of the things that you've learned. And so I saw that, you know, in your resume, you worked in both of your stints in big tech, you stayed in the roles for quite some time, maybe around four years or longer. And so I'm curious, your thoughts on job hopping quickly, because that is advice that a lot of

people give. What are your thoughts on job hopping? I think if you look at the data for people who are like really ambitious in lower levels, moving around usually has a lot of advantages. It's going to, if you think back and I love to actually hear your reflection, but if you think back in your career, usually those moments of growth are when your most uncomfortable. comfortable. It's like it's a new scenario, new environment. You've got to go and generalize your skills and you're learning a bunch. And so it's not just the hopping itself. It's mostly just immersing yourself in new environment that can lead to that growth. So it's hard to say no to that. I personally have not really subscribed to this in part because the motivating factor for me is going

really deep on something. Like I find that after two years, now I'm at the level where I can actually start to, you know, really make an impact. And those are the parts that are just the most rewarding for me from a career perspective. So it kind of depends on what you're after. Now, at the higher levels, moving around at a high frequency is a pretty bad sign. It's just like, it's very hard for you to get deep enough to have a real impact, to build the relationships, to understand the domain, just to be effective. And so, you know, generally speaking, if people are moving every 18 months or two years and they're in a really senior position. As a hiring manager, I'm second-guessing, and I'm trying to wonder, I'm going to invest for a year just to get you ramped up, and then you're going to go move

again in six months, that can be a tough pill to swallow. For a mid-level hire, that's a pretty decent tenure. But for a staff-level engineer, I'm second-guessing it. So I'd say from a career perspective early on, really makes sense, unless you're just really excited about the work, especially if you're not excited, yeah, go get a new job, man. But as you get more senior, it pays to find some places that you can actually put down roots. And it really helps when people can sense that, that you're here to stay and you're wanting to really make some changes. Definitely. Yeah. And I think what you're saying about job hopping not being as effective later makes a lot of sense too, because, for instance, a lot of what

you talked about in being a successful senior leader, either as an ICE or as a EM came through influence and credibility and your ability to get people to go in a certain direction. And that's one of those things that, I mean, if you just show up somewhere, you can build credibility. You can always rebuild credibility. But it is one of those things that as you have, it's like a snowball. It keeps getting bigger. Your credibility in that organization, you'll be able to move people a lot easier. So, you know, people who are early in their org have a disproportionate amount of influence because of their time in the role and what they've done already and what they know.

Totally. I want to add one thing to that, that there is a trap, which you can have in that snowball. That snowball becomes a shackle for you. There are certainly some very senior engineers who become known for that system that they created. And as much as they try to go and extend or move in new directions, everybody knows. them for that thing and they're stuck there, that can be a real career trap for people. So a good question to ask yourself is how comfortable you are. It's great to feel like your work is rewarding.

But if you don't feel like you're being challenged, even if you're really senior, it may be that it's time to move. And part of it might be that you just got stuck in a hole. Otherwise, that snowball is going to work in your favor. When you think back to your career and when you felt the most growth, on average looking across everything, when would you say is the time that you grew most and why? I'd say it's mostly around kind of those transition periods

where I'm in a new space and learning something and then also applying it. Those are usually the places where you can battle test and stress test your own skill set and know what's actually durable and what was fake. But it's also a place where there's new stuff to learn and adapt and kind of grow. A couple pivotal moments for me,

Moving to Facebook was huge for me, at least for a leadership perspective. It was stretched in ways that it wasn't expecting. There's also a lot of stress in the company at the time, which was interesting. I'd say pivoting into a more ML-focused role was a big shift for me. And I felt like I had a lot to prove. So it brought a lot of external pressure, which I appreciated. And it gave me a chance to really go and kind of shine. And, you know, other career growth happens in like much smaller durations.

Like, it's interesting looking back longitudinally. Like, I feel like a lot of my effectiveness, both as an I see and a manager, is partially due to my ability to write effectively. I learned a lot of my writing at Amazon. Amazon's known for their writing culture. Some of this is actually a complete waste of time. People just nitpicking the most stupid stuff. but it is a company that really does encourage good writing,

which means good thinking at some level. And that has stuck with me. It wouldn't be like a moment that I would notice, but that continued practice was really beneficial for me throughout my career. So those are some of the things that really stand out. On the topic of writing, because I know it's really important, I'm just curious, what would be your top tip if there's some, you know, I see your EM, you're saying, hey, you need to improve your writing?

What would be the thing? My main thing would be learn to be a critic first. Go and figure out what it is you like or dislike about writing. Go read a doc. Figure out what hits you on the head. What doesn't? Go and scan it. See if you can get the big picture in just a few seconds. Go look for points of like imprecision or places where the logical conclusions are well supported. Those are all going to be things that are going to help you, much like I talked about earlier, that generally understanding, you know, what. What separates good from bad helps you to make sure that you're focused on the good. I know when I first wrote some docs at Amazon, I got a bunch of negative feedback. And I thought they were great. I thought they were awesome. It's kind of like it. One of the writing exercises they do is called a PRFAQ, press release and then frequently asked questions.

And the idea is like, get me excited about that thing that we're going to deliver. Go fast forward all the way to the end. And then if you can do that, then everything before it is worthwhile. But if at the end, you can't really sell it to me, then it probably wasn't worthwhile to begin with. And a lot of PRFAQs at Amazon start with, oh, we will have a single pane of glass or like one screen where we can go to to get everything that we need. And nobody's excited about that. They're excited about, you know, 50% reduction in time spent or, you know, being able to go and hire this new person or whatever. And being able to look at yourself and go, wow, that was just boring.

Like what I was explaining, if I wasn't knee deep in it, nobody would be excited is kind of the first step to good writing. I see. So if I'm understanding it's hone your taste as a reader first, and that will let you critically reflect on your own writing and improve it. And then practice. Practice. Practice. I mean, at this point, you've had a lot of success at meta. Most people never grow to the level that you grew to. what motivates you in your career now too?

Because also you left to go to the start off. Yeah, what is your motivation? I really like working on interesting problems. I like working on things that I can tell my kids about and then, you know, them feel like it's meaningful to the world. And I like working on things that I think are kind of setting the stage for the future. And so I always have kind of a tilt toward those objectives and all that I'm working on. I think for me, the relentless march,

up the career ladder is secondary. It's not to say that like money isn't important. It clearly is. Money powers everything. But I had a point in my career where that was, that focus on getting promoted and moving through the ranks was very important. And I think what I realized eventually is just like, okay, you're, you're kind of there or at least you're at a place where, you know, maybe this will be the cap of where you're able to achieve, what's next? And if you can finally ask yourself that question and then work backwards and ask, okay, well, if I want to get to that thing, why not now? What's keeping me? And for me, for the longest time, it was, I want to start a business. I think that would be really fun. I would learn a lot. And it's a great way to impact the world.

And I gave myself all sorts of excuses for more than a decade. And eventually it was like, you're just lying to yourself. You're putting this off. And so that was what was the impetus for me and leaving big tech and building a business, but also as kind of the animating force for me going forward. It's just kind of look to that next piece. What is it that I'm really after here? And then last question, if you could go back to yourself when you had just graduated college and give yourself some advice, what would you say? I think for me, I probably could have been better about finding mentorship. I think I did a lot of it alone.

And ultimately, if I had found someone like myself and, you know, ask them three questions, I probably could have saved myself months of toil. There was a few moments where I put together plans, where I basically said, hey, I'm going to take stock of where I'm at, try to figure out where I want to go, and then, you know, put together a checklist. Like I have one such plan somewhere in my drop-offs from ages ago saying, You know, I want to get into M.O. This is where I want to go. Here is my plan. Those kinds of things have paid like these incredible dividends that continue to be under-emphasized by me even to this

day. Most people don't have that level of agency to kind of like just figure out where they want to go and then go and take it. But the world is very malleable to those kinds of plans. I remember a pretty interesting moment. It was actually shortly after I had gotten promoted to senior manager. And I went to my boss, a director at the time, and I basically said, you know, here are the things that I'm going to get done, you know. And it was a long list of things that I didn't know how to do, to be honest. I was kind of like, this is what I think I probably should be doing now, but I'm going to like figure it out. Like, this is, this is my list. And he recalled later to me, I think shortly after I had left, that that moment was when he knew that I was going to be

successful in this new position. Because for a lot of people, that lack of agency is what holds them back. It's very hard to instill, although I think there are some practices that you could probably go through in order to build up your own agency. But if you just force yourself to come up with a plan and ask yourself, what do you really want and what are the steps to get there? In a lot of cases, that is going to have a huge gradient on your ability to grow. So yeah, I think that would be what I would tell myself out of college. Awesome. Well, thanks so much for your time, Stefan. I was really looking forward to talking to you and kind of digging into all this management stuff. Well, thank you for having me. I guess for Hello interview, if you are at a kind of elite tech company and interested in helping us out

with coaching people through the interview process and basically making the process less painful for engineers, which is generally speaking what we're after, we'd love to hear from you. So if you work at OpenAI or Anthropic or Meta or Google, and you want to help us out by working with candidates. Send us an email. My email is Stefan at hellointerview.com and happy to kind of brief you on what we're building and how you might be able to help.

Hey, thanks for watching the show. I don't sell anything or do sponsorships, but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interviews. So if anyone comes up who you think you really want to hear their career story.

Let me know, and I'll try to reach out to them and get them on the show. Thanks for listening as always, and I'll see you next time.