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 self

Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.

Timestamps

(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 self

Transcript

00:59 – Early career at Amazon

Ryan 00:00:59:

Because you were a senior manager in big tech and I thought it would be really interesting for all the ICs out there to go over all of the 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?

Stefan 00:01:33:

Yeah, so for me personally, I was one of those engineers who was 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. Basically leapt at the opportunity. It seemed like a place where 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. I ended up joining the early advertising group. Advertising for Amazon now is a gigantic business. It's one of the most profitable units. It basically makes up for all the retail lack of profitability.

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 Proctor and Gamble, 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, 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 it was within my first week, my manager came down, I think it was at six o'clock. We were all gathered in a conference room and he said, I've got an idea. This is what we're gonna build, and we're gonna work nights and weekends until it happens. And I wanna do it by October.

So he was basically committing us to this death march for about 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 go work in this big tech company and I was committed. I think now if someone had told me that, I wouldn’t have.

But I really leaned into that. 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 gave me a flavor for what Amazon is in kind of its rawest form. And I feel that death march is kind of emblematic of a lot of people's experience, at least on the negative side with Amazon.

Ryan 00:04:16:

You went towards the advertising space. Was that something that you picked or was there was a general pipeline and you were placed somewhere?

Stefan 00:04:26:

Oh, good question. So Amazon at the time wasn't doing any kind of general recruiting. So basically you would get reach outs 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 to have the most growth and most opportunity. The pitch was pretty strong and ultimately was a very important business.

This was the beginning of Amazon ads. So, 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.

Ryan 00:05:04:

And so it looks like it turned out to be a huge grind. And I saw that you stayed there for some time, what was the average work like?

Stefan 00:05:16:

Yeah, I would say that wasn't completely standard throughout my career. There were certainly times where things settled down. I'd say the average was working hard. I think any big tech job it's going to require quite a lot of effort and even more so if you're ambitious and wanna get things done. So, 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.

05:46 – Growth to eng manager at Amazon

Ryan 00:05:46:

I saw that 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 (Software Development Manager)?

Stefan 00:06:03:

Yeah, so that was kind of an interesting transition, in part because my level of ownership and engagement early on meant that in many places I was the de facto lead for the team. I guess tech lead probably would describe my responsibilities pretty well, and I felt in a lot of cases I was acting manager of the team.

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.

And what you don't realize is how far you have to go. But, I was 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, and I'm no different. There's a lot to learn and in some sense, the support structure that you have around you is gonna 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 18 months down the road that I started to really get a knack for things and realize this is actually something that I feel I can do quite a bit better than other people can.

Ryan 00:07:31:

What were those early manager mistakes that make you say it was premature?

Stefan 00:07:36:

I think 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, 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 manager 101 stuff, and maybe it is. I think I realized 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. This was a very elementary mistake as it pertains to management.

Ryan 00:08:45:

I see. You mentioned getting people to reveal their goals. Do you have any tips for that as a new manager?

Stefan 00:08:55:

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 you know, your friend is having a good time or a bad time. What you really wanna know is deeper questions around, 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, when someone else is talking, show your interest. Sometimes people will talk about sub verbals, so you know, “ums” 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 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 gonna just give that up to you. Most people aren't that well-trained.

Ryan 00:10:52:

The API thing makes me laugh a bunch because, when I was really early in my career, my one-on-ones were purely transactional. We're gonna go through this laundry list of things in the most efficient way possible.

And I always remember, there's often this preamble at the beginning of a one-on-one where you say, Hey, you know, how's your weekend? Or, you know, what are you doing tonight or later? Or something, and I always thought that was a waste of time. But now as a manager and just as a more normal person, I see the value in it for sure.

11:31 – Storytelling tips

Ryan 00:11:31:

You mentioned storytelling. For managers there's a 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 in getting buy-in behind things. Do you have any tips on how to improve your storytelling?

Stefan 00:11:51:

That's a good question, and I agree that storytelling is kind of a bedrock essential skillset to develop. I think, part of it is just practice. 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 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.

What story am I telling myself today? I'm going about, you know, getting to work because you know it's gonna 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 gonna get better. And, here's the trajectory that we're headed to.

One of them is gonna 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.

A lot of times 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 team of two 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 gonna 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 mentalities, whether they're getting in bickering matches, or excited about their work.

If you've got a good story and your team feels 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 they're winning, all of those problems are gonna 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 improve.

Ryan 00:14:52:

You've 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?

Stefan 00:15:05:

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 he should have hired other SDMs, I think is 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 he 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 gonna 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, an SDM would be doing things, you know, checking on the team's progress, understanding their career, mentorship, things along those lines. They just weren't quite as important.

Ryan 00:16:00:

So then if you were to survey the sentiment of his org, do you think that people were unhappy with his behavior?

Stefan 00:16:15:

Yeah, we had a lot of people who were pretty upset about the situation. I wouldn't say things were particularly good.

16:28 – Why he left Amazon

Ryan 00:16:28:

Coming to the end of the Amazon leg, what was the thing that made you leave and want to join Meta?

Stefan 00:16:31:

Okay. Amazon is a really special place. I speak to 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 wanna give the impression that Amazon is not a worthwhile company to work for. I think it certainly is. But there were a few things that kind of stuck out to me after I had spent a pretty considerable amount 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 ways, 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've spent your entire career there.

And that started to kind of fester in me. I wasn't sure whether I was just overfitting to this Amazon opportunity and I wasn't sure whether it was growing much. The second thing that kind of bothered me is that Amazon in general, I think, does a better job of maintaining evenness and compensation and talent development, but in some sense, it makes some sacrifices in order to do that.

So 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, 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. It's kinda, 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 pegged me with 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 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, you lower prices, whatnot, but it wasn't the same type of qualitative impact that I could have at another company.

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.

Ryan 00:19:13:

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, that's good for Amazon, but that may not actually be the thing that's for a good engineering leader.

Stefan 00:19:33:

All leadership is trade off. Styles have pros and cons. I don't think that there is one best way and so I don't wanna 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 the ability to work on innovative new approaches. In some sense, your boss needs to be queued into all the things that you're doing. That was one aspect of Amazon's culture that I didn'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 this 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 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 gonna be worth, you know, a hundred x. 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 pings where the benefit that you could have in the best case is a one or 2% improvement, but you have this catastrophic risk that's constantly looming. That's why most companies don't allow employees to just jump onto 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 wanna 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.

Ryan 00:22:50:

Yeah. And at that stage of its growth, I mean, it's a more later stage company, so it kind of makes sense that it's on the later end of that life cycle.

22:59 – Transitioning to AI/ML

Ryan 00:22:59:

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?

Stefan 00:23:13:

I think it always is. ML is pretty different from traditional work in ways that are kind of hard to explain, where, you know, in a typical software 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 a very common occurrence for people that 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 is very scientific, kind of 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. I was participating in Kaggle competitions, I 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 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 a study session. I need to go learn the 101 and the 101 is important, don't get me 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.

Ryan 00:25:01:

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 and intuition. Is that right?

Stefan 00:25:18:

Yeah, and in some sense, I feel the key for me at least, was participating in 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.

Ryan 00:25:34:
Right. What was the motivation for moving into ML?

Stefan 00:25:37:

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 for someone who had spent, and I coded from a pretty early age, early instructing computers on how to do things. This idea that we could just kind of imply basically a program from the data, what was really attractive and it also felt a lot of what was societally important at the time were actually ML applications.

We didn't completely understand what was going on there. You talk about ranking and 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.

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.

27:01 – Senior manager (M2) promo story at Meta

Ryan 00:27:01:

I guess, you know, going back 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?

Stefan 00:27:16:

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 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 how to handle organizational shifts and maintain some momentum there. But when I first joined, I wanted to be useful as quickly as I could, which actually fit very well with what Meta was looking for, for Facebook at the time.

And so I joined the 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 is 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 they know who 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 in the future.

So that was really important. After I kind of established myself and showed the effectiveness of our team. I was eventually given an additional manager who would work with me. 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've sat on the other side. 'cause 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 have impact indirectly, surely layering another manager beneath me is just kind of that same thing, right? It's that same pattern. And the response that I have to that is yes and no. It is nowhere near the same degree of difficulty shift from making that initial transition.

I think if you assume that leading other managers is going to be 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.

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 the 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 was kind of hard to deny that, you know, this person's doing the job. So, that was my promotion story.

31:30 – Mutiny and manager politics

Ryan 00:31:28:

The mutiny you mentioned is really interesting. How does that surface in practice? How, you know, how could someone underneath you kind of usurp you or kind of that mutiny could come in?

Stefan 00:31:45:

I think the easiest way you'd see that is just in skip level meetings.

The managers are just griping. 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 says a scientific experiment, well, 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 is Stefan, you could not be more naive. Lemme tell you what's going to happen. And he was absolutely right.

These two teams are gonna 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 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 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 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 align those things up. That you can kind of keep people on this path to delivering value.

Ryan 00:34:03:

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, that can lead to some unusual behaviors or maybe these political behaviors that you're talking about?

Stefan 00:34:30:

I don't know if I would use the word secret chess because it seems much more obvious. Generally speaking, most people's objective isn't to go and make 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 wanna work on really interesting problems. Some people wanna work with certain people. The things that people are after are many, and they're very rarely kind of single faceted. But as much as people have different objectives, they're gonna 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 ICs, an interesting project that you want to do. Most people have seen this play out on a number of occasions. It's kind of, 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, and I'm gonna write a post and tell everyone that I'm at it so that it'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 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, kinda that secret chess and then making sure that you're cognizant of it as you're taking actions is really key to being a senior leader of any large organization.

Ryan 00:36:23:

It sounds like a lot of these behaviors are kind of zero sum behaviors. So I could imagine in an environment of either a 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, that's just abundance, so there's a lot less of this going on 'cause everyone can get what they want.

Stefan 00:36:51:

Totally. Yeah. I think this is a fantastic call. In some sense, the zero sum mentality 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, okay, well the business isn't doing very good, but our test code coverage is, is, you know, awesome. That really needs to matter to us now. Is that true?

You know, who knows? But I think it really points to a couple things. One is the imperative of winning that I talked about earlier. It's kinda, 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 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 kinda 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 gonna go wrong than that early stage where, you know, you can kind of not pay attention.

I think a lot of early Facebook leadership was kind of 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.

Ryan 00:38:27:

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 your, their skip. So I guess your manager and say, Hey, Stefan is thrashing things. Are you sure he's good? Kind of things behind the scenes when in meetings you are not present.

Stefan 00:38:50:

I mean, yeah, generally speaking you see it in the same way that disgruntled teams operate. It's kind of everybody's making a lot of noise 'cause 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. The, 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 it's just not an option. And in that case, that person's going to hate you and they will lead very quickly.

You can give them some insights, but if you give them a lot of insights, then they're gonna feel you're trying to do their job or they're gonna feel 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.

Less and less, it becomes more and more binary action. We're obviously gonna have conversations or how things are going, blah, blah, blah. But you know, if Mark has an SVP, he's just not making the cut, he's gonna let them go. He's not going to jump in and coach and try to, you know, have all sorts of programs to get them to the right level.

And of course, that doesn't apply necessarily at 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.

40:34 – Are managers harder to layoff?

Ryan 00:40:34:

You mentioned manager under performance. I'm curious because there were a lot of layoffs in the past. Do you feel managers have, they're harder to lay off than ICs are? And if so, why?

Stefan 00:40:49:

Moving managers around is inherently painful. Usually 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, if you're gonna bring in a new VP, everybody's gonna know about it.

It's gonna be a major and intrusive change. So that comes with the territory. Whether taking someone outta that position or not is hard, is in large part whether they're load bearing for that position. If they've got a really tight relationship with their team and they know a bunch of 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.

You know, moving that person out, it could be very hard. If on the other hand, you know, their team actually doesn't feel 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's just that the ramifications in the org chart are just so large. I think if the assumption is during layoffs, are you less likely to get laid off 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. We, they'll try to say, you know, we wanna make sure that managers have 12 reports, or we wanna look at the ratio between, I think Amazon did this recently between ICS and managers and we wanna 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.

Ryan 00:42:55:

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 that mentioned, types of leadership per stage of company, and they have, there's different effectiveness if the company's smaller or a more scrappy versus the larger companies. I'm kind of curious about that. What type of leadership do you think is most effective when the company's really small, and what type of leadership do you think is most effective when the company's very big?

Stefan 00:43:33:

So I think when companies are small, you really need some 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 wanna work for someone who's impressive, who could do their job. And, and a pinch could kind of step in.

If you look at company history, there are plenty of examples of this. And, you know, generally speaking, you've got these SVPs or directors who were 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 a very different skill set to be able to work in a larger organization where, you know, you're actually not gonna have much of an impact by just digging in and getting your hands dirty.

And then you're, there's not gonna be a bunch of momentum behind it. It's kind of interesting if you think about big companies, focus is a precious commodity. 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 a hundred different ways and go in a hundred different directions.

So if you've got those individuals who are go-getters and they 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 gonna get in the way. They're gonna siphon off energy that could otherwise be put behind some of the core initiatives.

So I'd say that's at least one way that you might think about what leadership is most appropriate, you know, how close to the execution do these people need to be? But you know, each company is going to transition in different ways. This was fascinating for me to watch. 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, you know, engineering leadership could then just assemble these pieces. 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 org, but it necessarily meant you left a lot of interesting things in organizational seams. So, if two teams draw their lines here, you might be cutting out a whole lot of value. And also, these teams need to move to 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 at 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 primitive. 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 across companies. The caveat that I wanna toss onto the table is you can't just staff a company with organizationally savvy people. Eventually it becomes negative. 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. I think OpenAI is kind of a good example and it's a company 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 OpenAI does interviews, they focus a lot on technical achievements at the expense of some of those organizational pieces.

So one of the pieces of guidance that we often offer people, who are preparing for Project Retrospectives and more of the behaviorals is to go deep on those things that are just really impressive technical achievements or hacks and not as much on, I built alignment between six different parties, blah, blah, blah.

That look, OpenAI 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 attracting the right talent, of achieving their breakout velocity in terms of what they're able to deliver.

So lots of different dimensions are at play. I don't think you can generalize across these to any degree, but you can kind of notice some trends and, and in general, there is maybe an entropy as orgs get bigger, you have to have people who know how to navigate it. It's just, it's not something that you can avoid.

49:50 – Senior manager (M2) skill gaps

Ryan 00:49:49:

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.

If we were to just imagine I took a random M1 or maybe yourself, and before you were promoted and you were just a new M1 and I, I put you in an M2 role and you just said have at it, what are the biggest skill gaps that you would've had?

Stefan 00:50:25:

So I think being able to credibly add value to the people who are reporting to you is probably the major one.

I mentioned some ways in which managers have reduced, or managers of managers have reduced, 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 hard for 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. You know, what do you think of Jim? Does he say anything that, you know, you don't? Is he touching on all of the important career pieces?

And then a week later, Jim's gonna walk into your office and go, you know, you talked with Jan, and you ask her a bunch of leading questions around whether I was doing my job or not. And now she doesn't feel I'm being, I'm supportive enough. 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. 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 won'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 a good mental model for how these things sort of propagate in an organization. But I think subtle mistakes end up being 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 gonna make those mistakes. Just when you transition someone from an IC to a manager, you're expecting 'em to make a lot of mistakes just because it's unnatural. Nobody really knows about this. So 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. 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. 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 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 in, to be honest.

53:21 – Eng vs manager career growth

Ryan 00:53:21:

You've experienced IC 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 about your thoughts.

Stefan 00:53:46:

I think at high levels everything becomes a little bit opaque and fuzzy. One of the things that always kind of 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 that it's really hard to do attribution. And I think over a long run things are a little bit more obvious.

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 6s, maybe 7s, 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 minutiae would be able to recognize it as clearly at higher levels.

I think that there is, there's a bit of unaccountability for a lot of management. This is true in the stock market. It's kind of 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 sent 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 highest 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 into any particular deliverable and go, this is fair. You, 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.

Ryan 00:55:59:

I see. So the early promotions are the most easy to verify and be fair, and the higher level ones are a little bit more, I mean, I'm sure there are 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?

56:27 – Amazon vs Meta culture

Ryan 00:56:27:

I think one thing I was curious to dig into is that, you know, knowing that you've been at Meta and you've been at Amazon and you, you had a fair amount of time at both, I thought it'd be interesting to kinda ask you the pros and cons of each, or at least your personal experience.

I know these companies are. Very large. And you know, 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?

Stefan 00:56:57:

So I think Amazon is disciplined, and I think this is a major strong point. I felt 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 'cause the business just moves slower. But partly because you can depend on other teams to kind of meet certain SLAs and you know, they're, you can page them if they're not doing the thing that you want. Whereas at Meta, somebody's work isn't, isn't, you know, living up, you gotta go make that change yourself.

'cause he's working on photos now. He hasn't been working on 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 to the culture to be pretty paralyzing.

They 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 as kind of 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 collaborations. 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 kinda empowering people to make decisions. Amazon has a really very process oriented mindset. They talk about mechanisms. So when something fails, they want to try to introduce a process to prevent the failure. At Meta, it's more likely that someone will go, well, we learned our lesson, you know, we'll make sure it doesn't happen again.

Now, look, that has its downsides. A lot of Facebook's privacy issues are, in some sense, inability to contend with the same process that Amazon does incredibly well, but it means it holds. You know, the culture back in a lot of cases, 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 used 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 why it worked. 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 gonna like it more than you might the chaos that's usually a Meta execution.

01:00:34 – Amazon vs Meta performance

Ryan 01:00:34:

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?

Stefan 01:00:47:

I'd say they're pretty close, to be honest. I think everybody's kind of descending into the same valley in terms of optimality. What you basically have is a very public kind of publicized process wherein ratings are established and handed out to reports. This is things that managers will talk about and, and we will 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. At Amazon is this top tier designation on Meta, there's additional equity or discretionary equity, which is basically trying to say, you know, who are the real linchpins 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 the process, rewards, performance. That is, that perception is incredibly important. I did an estimate, I went through and I kept time of all the different activities and managers and preparing for PSC and basically said, you know, here's how much we spend per employee on PSE processes.

And I think there's one takeaway to this, which is, this is wasteful. 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 ball game. If you get that wrong and people don't believe the process is gonna produce outcomes for them, they're not going to perform in, 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 a lot of diligence to try to maintain the integrity of the process, 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 weren't willing to just really double down on top performers.

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. Amazon, that's pretty uncommon. You don't see that as much and they, they would find some way to try to pull that back. They are a very frugal company.

Ryan 01:03:21:

Yeah. I remember when I worked at Amazon briefly and one of the leadership principles was frugality and I, I never, I never liked that one, but, nobody does. Nobody does.

Stefan 01:03:32:

Yeah. It's a horrible one.

Ryan 01:03:34:

You mentioned the additional equity or discretionary equity, or it is called top tier at Amazon. How does, how do those conversations work? Is it derived from the performance ratings or does, you know, directors and senior managers kind of get together? How does that decision come to play?

Stefan 01:03:51: Yeah, and this usually gets driven by the VPs and directors of an organization and how much they choose to involve the, you know, different managers in 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 org 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.

'cause 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 a I wouldn't say niggling, but a stellar but not exceptional half. But it was obvious that that was gonna keep going.

That was a criteria. I remember at Amazon they talked about kind of, I think there were two dimensions. I don't remember the exact ones, but, but growth was definitely one of them. And then the second piece, and I think this actually plays a lot, is kinda, 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. 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, 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.

01:05:24 – Low performer quotas

Ryan 01:05:24:

You know, with some of the layoffs that kind of happened in the past, there's mentions of lower low performer quotas, and I'm kind of curious, is that something that you experienced when you were working at these companies and how do they work?

Stefan 01:05:38:

Yeah, definitely. I think every company's 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.

Suddenly the half that seemed pretty good, or maybe okay, seemed 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, you know, 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 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 acting on that.

Then the team starts to suffer. You notice that that person's not pulling their weight and you know, you're gonna start to check out too, 'cause it doesn't seem fair any longer. So quota wise, the numbers will vary. For a lot of companies it's, you know, somewhere between seven and fifteen.

Sometimes it can be as high as 20% where they're gonna try to put you in the lower bucket. At Amazon it was needs improvement. And at Meta it's 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 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. 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 gotta be in that low bucket, and now you gotta go change your tact. You gotta go back to that person and say, no, actually, you know, you didn't kick ass that hard.

That wasn't even acceptable. Perfect. And so those sort of 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, you know, lower quartile and can message it appropriately.

That way they're not surprised. You're not surprised. The kind of structure works fairly, but if you've got a lot of immature managers are just relatively new or maybe they just don't see it clearly, then you end up with lots of situations what I just described, where people have to go mea culpa 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.

01:08:55 – Can you get out of a PIP?

Ryan 01:08:55:

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?

Stefan 01:09:16:

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 gonna 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 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 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 a 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.

It 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 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. It's not always just 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 cold in 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 long.

Ryan 01:11:49:

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, and many other resources for people in the industry, which, my roommate said it was the best thing that he used in his prep and he got an offer at Anthropic.

So every time I'm interviewing you or Evan, he says, oh, it's those guys that love their product. But I wanted to ask you about interviewing, 'cause I felt you might have something interesting to say.

01:12:23 – AI interview cheating

Ryan 01:12:23:

With the rise of these AI cheating tools and, you know, LLM assistance. 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?

Stefan 01:12:37:

It's kind of funny because as it pertains to interview prep, our incentives are mostly aligned. You know, for the candidates we wanna help them to succeed. And so, them cheating at mock interviews for instance.

Does it make a lot of sense? But surprisingly we've seen it happen on a few occasions. I guess the situation is probably they're trying to test out their setup to see if somebody will notice. So you'll hear, one of our coaches reached out, he said, the guy's talking to his friend in the background, you know, what do, 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're overly dependent on some mechanisms that probably aren't completely effective.

So in browser interviews, they're looking at whether the page has focus or whether there's copy and paste activity, which is, yeah, the least sophisticated people, you will definitely catch them. And surprisingly they do. So they're clearly weeding out some people. But to be honest, I feel a lot of interviews are going to change in part because the role is shifting.

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 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 to be robust in that way.

But I'm more optimistic in the challenges and assessments evolving than I am in any 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 that cheating is not necessarily gonna 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.

Ryan 01:15:02:

I'm curious, 'cause I imagine an 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 lower than the growth of system design signups or something that might make us infer that cheating has any impact on the future?

Stefan 01:15:30:

So I think people are leaning, or companies are leaning more heavily into design interviews, and that doesn't necessarily mean system design, which I think is more, more, standardized across big tech, but also 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 and an AI coded world. You being able to come up with good abstractions and reason through them is more important.

So definitely 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 LeetCode for forever. It actually serves a pretty useful purpose. It works for companies as much as people wanna 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 companies' 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.

01:16:42 – Passing OpenAI & Anthropic interviews

Ryan 01:16:42:

If someone was hell bent on passing OpenAI or Anthropic interviews. What's the optimal game plan from your experience at Hello Interview?

Stefan 01:16:52:

I think it varies. Those companies are looking for doubt. OpenAI 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, you know, a step up if you actually knew approximately the areas that they were in. The behavioral and retrospective interviews end up being really important for these companies.

They really wanna see, have you walked the 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, being able to actually talk to a friend or someone else who can tell you, here's how you came across.

Here's the vibe that I got from you. 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 and make things happen.

I think for a lot of people, the crowning achievement of their, you know, 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 a hundred thousand that were written by junior engineers. And 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.

01:18:33 – Job hopping

Ryan 01:18:33:

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. 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 about your thoughts on job hopping quickly, because that is advice that a lot of people give. What are your thoughts on job hop?

Stefan 01:19:02:

I think if you look at the data for people who are really ambitious in lower levels, moving around usually has a lot of advantages. It's gonna, if you think back, and I'd love to say actually hear your reflection, but if you think back in your career, usually those moments of growth are when you're most uncomfortable, it's a new scenario, new environment.

You've gotta 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 a 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.

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 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 gonna invest for a year just to get you ramped up and then you're gonna 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 moving 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 you're here to stay and you're wanting to really make some changes.

Ryan 01:21:01:

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 IC or as an 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 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.

Stefan 01:21:53:

Totally. I want to add one thing to that, that there is a trap which you can have and 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 your work is rewarding, but if you don't feel 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 gonna work in your favor.

01:22:37 – When he grew the most

Ryan 01:22:37:

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?

Stefan 01:22:47:

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 skillset and know what's actually durable and what was fake.

But it's also a place where, you know, 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 from a leadership perspective. It was stretched in ways that I wasn't expecting. It'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 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 much smaller durations.

It's interesting looking back longitudinally, I feel a lot of my effectiveness, both as an IC 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 it's just 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 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.

01:24:22 – How to write better

Ryan 01:24:22:

On the topic of writing. 'cause I know it's really important. I'm just curious, what would be your top tip? If there's some, you know, I see or em you're saying, Hey, you need to improve your writing. What would be the thing?

Stefan 01:24:34:

My main thing would be to learn to be a critic first. Go and figure out what it is you or dislike about writing. Go read a doc. Figure out what hits you on the head, what doesn't go and scan it. You know, see if you can get the big picture in just a few seconds. Go look for points of imprecision or, you know, places where the logical conclusions are well supported.

Those are all gonna be things that are gonna help you, much I talked about earlier, that, you know, generally understanding, you know, 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 one of the writing exercises they do is called a PR FAQ, a press release and then a frequently asked questions. And the idea is to get me excited about that thing that we're gonna deliver. Go fast forward all the way to the end, and then if you can do that, then everything before it is worthwhile.

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 PR FAQs at Amazon start with, oh, we will have a single pane of glass or one screen where we can go 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. 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.

Ryan 01:26:09:

So if I'm understanding, it's to hone your taste as a reader first and that will let you critically reflect on your own writing and improve it.

Stefan 01:26:15:

And then practice, practice, practice, practice.

01:26:22 – Career motivations past M2

Ryan 01:26:22:

I mean, at this point you've, you 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? 'cause you also left to go to a startup.What is your motivation?

Stefan 01:26:35: I really like working on interesting problems. I like working on things that I can tell my kids about and then, you know, have them feel it's meaningful to the world. And I like working on things that I think are 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, you know, relentless march up the career ladder is secondary. It's not to say that 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, 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 wanna get to that thing, why not now?

What's keeping me? And for me, for the longest time, it was, I wanna 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, you know, more than a decade. And eventually it was, 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 looking at that next piece, you know, what is it that I'm really after here.

01:28:11 – Advice for younger self

Ryan 01:28:11:

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?

Stefan 01:28:22:

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 myself and, you know, asked them three questions, I probably could have saved myself months of coil.

There were a few moments where I put together plans where I basically said, Hey, I'm gonna take stock of where I'm at, try to figure out where I want to go. And then, you know, put together a checklist. I have one such plan somewhere in my Dropbox from ages ago saying, you know, I want to get into ML.

This is where I want to go, here is my plan. Those kinds of things have paid these incredible dividends that continue to be underemphasized by me. Even to this day. Most people don't have that level of agency to kind of 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 and director at the time and I basically said, you know, here are the things that I'm gonna 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, this is what I think I probably should be doing now, but I'm gonna figure it out. This is my list. And he recalled later to me, I think shortly after I had left, that moment was when he knew that I was gonna 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. Yeah, I think that was, that'd be what I would tell myself outta college.

Ryan 01:30:18:

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. So.

Stefan 01:30:26:

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, you know, 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@hellointerview.com. And happy to kind of brief you on what we're building and how you might be able to help.