Airbnb Staff Eng on How To Not Get Stuck at Senior and Untold Rules of Calibrations

0:00Laurent Charignon:That's probably one of the meetings where people cry the most. This is Laurent, staff engineer and manager with experience at Stripe, Airbnb and Instagram. And he shared the unspoken rules he learned from these companies. You mentioned the secrets that you learned as a manager. Every company does this differently and does those like untold rules about calibration. He also mentored me at Instagram and helped me reach staff. What would your advice be to someone who's been stuck as a senior engineer for a long time? They're trying to make that jump to staff. The key is to be able to identify problems and to then be able to pitch and then solve them.

0:38I think one mistake people make consistently in their software engineering career is to not. Here's the full episode.

0:50What's the story behind you choosing to join Airbnb? And how are you thinking about your career planning at the time? At the time, I'd been in the industry for a few years. I had worked at Apple and Meta and decided that my thing was developer productivity. That is like, how do you make people as productive as possible, as effective as they can be? Like software engineer, like how can they write code as effectively as they can? And so I did that at Facebook and we decided to move to San Francisco. And I had to continue doing my job while taking the bus an hour and a half each way. And so I immediately started a job search and I picked Airbnb for multiple reasons.

1:36I love the people that interviewed me there. It was close by. I could just walk to the office and I liked where they were at in terms of developer productivity and what was remaining to do. They were very early on. I joined as one of two engineers on test infrastructure. So I was just at the beginning of when DevFraud was starting to be multiple teams. And I think that was a very exciting moment to join. So I understand at Airbnb, eventually you transitioned to management. I know you started as an IC working on that test infrastructure team. And I'm curious, why did you transition away from being an IC?

2:21So the setup was, we had one manager who was managing, I think, like three or four different teams. And it was starting to get very, very busy. Because when you're a manager and you manage more than 15 people, then you don't have much time to do anything else but the people management tasks. and I felt like it would be more effective if we took the team in, if you had like a more supportive structure for the team and if we're able to like spend more time in growing people in the team because like the team was, a lot of people were like quite new in the industry and I think they needed a lot of that support.

3:11And so I started doing that as a tech lead as we grew the team, test infra was, I don't know, like six, seven, eight people after a year. And then I was like, the natural path forward is for me to become the manager of that team and to be able to continue growing these people, continue growing their career, being very invested in their success with more time than what my manager could dedicate. So I went to him and I pitched it to him. I'm like, listen, there's all those people. They need like more support. I can do that. I can try. You can help me like be a manager. And he said, yes. And it was very kind.

3:55And so like I started as a manager, like initially, like I had only two reports and then like the whole team reported to me. It was a wonderful experience. It's actually very unique. Like when you become a manager of your peers, it presents some interesting challenges. If you were a peer to these people, would there not be some, I guess, power dynamic or some uncomfortable conversations in making that transition? There were, and we're like very upfront about it. And I will always remember this one guy came to the first one-on-one and he told me, I'm going to talk to you about a situation. and I want to know how you would react.

4:37And based on how you're going to answer that, I'm going to know if you're a good manager or if I don't want to work with you. And here's the situation. You're at work, you open your laptop and then you look at your email and you have an email from recruiting saying, your employee missed the interview that he was scheduled to do yesterday at 3 p.m. You've got to talk to them about it. It cannot happen again. what do you do and so like immediately i was like well i'm going to ask you what you think about it and about like what happened and the facts and try to understand like uh what actually happened and he was like okay you passed because the way you failed this is by just saying like you're grounded you did something wrong uh you didn't show up to the interview because like you don't know like it's possible that they got the wrong name that they sent the email by mistake And it's like, there's always two sides to a story.

5:36And it's very, very important. If you want to be successful in a job with other people, that you hear all the sides of the stories. What percent of managers do you think would fill that test? When people approach management, there is a type of people who think that it's one size fits all. that they believe that there's like one strategy to be a manager, like I'm going to be a tough manager, or I'm going to be a micromanager, or I'm going to just be hands-off and just let people do whatever they want. I think if you think in that way, then you lack flexibility. And a lot of the situation, it could work.

6:20Like say, if you like micromanagement, it will work if your whole team is new grads. But it's not going to work if your whole team are like experienced engineers. So I think it's about flexibility. It's about knowing that there's not one way to solve the problem and one way to solve every coaching situation. You have to try different techniques. I remember you mentioned to me before that you were kind of bored at some point. And so I'm curious, after living through that transition, what was the experience like going from an IC to a manager in that regard? Yeah, I think I was bored at multiple times, multiple points in my career.

7:03Boredom is a very interesting signal to watch out for. Like if you feel bored in a job, something's not right. And that means you've got to do something about it. And so I transitioned to manager because I felt like that was how we could make the team as performant as possible to like deliver that big project that I was leading as a tech lead. and initially it was very intense. As a transition to manager, you go through all those trainings where you learn about all the secrets, about how we decide the level of someone that comes in, how do you do promotion, how do you do performance, all of those things.

7:48So that was very exciting, and I was curious about how all of those things worked. but after that the next challenge was people management how do you like establish a rapport with the individual in the team how do you plan their career with them and how do you like best represent their interests so this is like that rapport building second phase and then And while that was like well on the way, then I started to work on optimizing because that's what I do. I always optimize everything I do. And so like I built a tool that looked at all of my reports calendar and my calendar and tried to defrag the calendar so that like it would just like be without the whole.

8:39So they could have as much focus time as possible. And everybody liked it. That was like really impactful because then they could do more software engineering and less interruption. The other thing I done after that is I decided to work on team health because I think that people like people who are happy at work perform well or at least perform to the best of what they can do, the best of their ability. And in order to do that, I tried to set the goal of having the highest team half score in the infrastructure group at Airbnb. I was like, how am I going to do that? I am going to just send a big form.

9:25I did a Google form with like all the things we do as a team. Like we meet for the standup on Tuesday at 9 a.m. Does that work for you? Is it useful? Would you prefer another form? What do you get out of it? And so I asked about every process that we have, every way that we work together. It was quite complicated. It was like 20, 25 minutes to like fill this out. I got the results. I was shocked. It's like everybody thought the standup was useful for the other people. And so we're spending so much time doing that like very long standup that was useful for nobody. And so we changed the format to a form that was useful for people.

10:09And then we did that for every process, from planning to how we work together, even scheduling when we would review code. And it worked. Then the team became a lot more engaged, effective, and started to be able to do a lot by even spending less time working. and so that's kind of what happened because like once things were really running well it was at the time I was getting married and I left for three weeks for my wedding I came back they had planned the whole next quarter with like the algorithm that we decided for doing the project planning and they had figured out how they were gonna work together all the project assignment and I was like, what am I doing here?

11:01It's like, I'm getting bored. This is so easy and I have nothing to do. And so then the next step, I discussed my manager. I got to M1 at that point. It was to become a manager of manager. I was like, I don't think I'm ready for that yet. I kind of want to do a lot more coding because I like writing code. I liked the experience of shipping something to production, seeing it work, seeing the graph move and all those things. It's very motivating. So I switched to being an IC after that because I was bored. You mentioned the secrets that you learned as a manager. And I'm curious if when you switch back to being an IC, did those make you a better IC?

11:48And if so, how? They did. Like all the secrets I've learned helped me become a better IC. And especially everything around career progression, around framing your career, around the performance review and the rating and the promotion and things like this. But also everything about coaching and having difficult conversations. So like all those skills then became extremely useful and I became like a lot better at it by being a manager. And then I fostered those skills and then that became one of the main ways that I was able to contribute to like leadership as an IC. One thing that's interesting in your transition to management is I think a lot of people, they do it very differently in that they ask their manager or maybe their manager asks them, but you actually pitched your manager.

12:51You actually had a, here's the value for you if I become a manager. And I'm curious, do you think that's the best way to transition to management? In general, I think one mistake people make consistently in their software engineering career is to not be aligned with their manager on what they want. They are afraid of saying like, hey, I want to get promoted next year or I want to be an expert of this technology. A lot of people just go through their career quite passively. And then at the end of the year, they just write down what they've done and then present it to the manager and then hope that they're going to get what they want.

13:32And I think that's sad because life is very short. And I think it should be an ongoing conversation. And that makes it much easier for the employee and for the manager, which is why I set up a very interesting metric when I was a manager. I call it the surprise factor. So we're working in person, it was at Airbnb. And for the performance review, I went into the room and I asked them, before I delivered the performance review, which was like a paper with like the rating, the promotion or promotion, write on a piece of paper, what is your expected rating? Are you going to get promoted? And roughly, like what we're going to talk about.

14:17and I do the same. We put the paper in the middle on the table. We open the papers at the same time. If it matches, it's a pass. If it doesn't match, it's a fail because you want to minimize the surprise. If you're a good manager, you don't want people to have surprise at performance review time. You don't want them to be stressed out because people who are uncertain or feel like at risk, they're not going to do their best at work. So I use this metric and I try to drive it to like 100%. It never was exactly 100%, but it came pretty close. I could see the value in that because I think a lot of people, obviously the negative surprises are bad, but also the positive surprises can be bad as well.

15:14Yeah, the positive surprises are bad. Like say if someone does not expect, doesn't think they're doing well, okay? And then you think as a manager that they are doing very well, you put them up for promotion, but you don't even talk to them about it. Then that's going to be a very weird, positive experience. And really what you should have done is try to like coach them before so they take more risk and that they can accelerate their career. Because if they are good and they don't know, it's like that's something that's coachable. After transitioning to and from management, I'm kind of curious your thoughts on advising other people on when they should move into management and what the pros and cons are.

15:52What are your thoughts on that for ICs? For me, the experience was invaluable. So nowadays, I tell people, if you think you're considering it, then just do it. you need to have that experience because it's a different job and you're going to learn so much by being exposed to a different set of skills different experience and you'll see if it's for you or if it's not for you like worst case scenario it's not for you and you do very poorly and then you learn something about yourself but in every failure there's a lot of things that you can learn it's so my advice right now is to say like you should all try but first start with an intern see how it goes because it it's uh actually an interesting experience to managing intern it's not quite like being a full-time um manager because you get very attached to your little intern because you have like one intern and in general you're they are much earlier in their career.

17:01So you're very much directing their work. And so it's not the same dynamic than say like when you're managing like high level IC. And it's also only one person that you manage, which gives a huge sampling bias. And so you see management through the lenses of like that one intern that you have. That means if you go to intern calibration, that's probably one of the meetings where people cry the most. Why? Because everybody comes in with their intern thinking, because they've really tried to direct them and coach them, thinking they are doing so well because they want their intern to succeed. And everybody who goes to the meeting tends to say like, oh, my intern exceeds expectation, he's doing so well, they need a return offer, all of this.

17:55And they think their own performance is going to be tied to that when that's wrong. Because like you can be very successful as an intern manager if your intern does not get a return offer. If that was the right thing to do, that was the right thing to do. So I love that experience of like being an intern manager. So at Airbnb, I ran some of the calibrations for interns with all the intern managers to try to make it less scary to reduce that bias. You mentioned a little bit about your promotion to becoming a frontline manager, going from M0 to M1. And I'm kind of curious, if you look over your promos, because we talked about that surprise metric for yourself going through those promos.

18:45Were you surprised as you had your promos happen or were you and your manager on the same page? I know they happen at different companies and things, but still. That's a good question. I think most of the time I was surprised. And that's not a good sign. Because when that happened and then like you're surprised about like something happening, that means you're like, you don't have a good read of the situation. That's a sign that you need to understand the situation better and you need to work on understanding how the system works, what's being valued at a company versus another one. I'm trying to think.

19:26I was never surprised by a promo, but I was surprised by some ratings sometimes. The one that surprised me the most is around that time. So I was an IC4, I think. I think it depends on the company, like the level below staff, basically. So five for a lot of companies. So I was leading that team, the test infrastructure team, and I was really expecting that I would get to staff. At the end of the year, I was like, I'm doing great while delivering that project. And I'm going to transition into management where I'm basically going to be doing the same kind of thing, but more people oriented. what happened at that performance review is I got I think I got a meet expectation because it's like you change roles in the middle of the cycle therefore you get an automatic meet because you have not been the new role for a while it was really difficult because I was like that's not right because like had I stayed as an IC I would probably have gotten like the the promotion to staff.

20:47But instead I was like, okay, well, I'm just going to make it work as an M0. I'm going to try to get to M1 as quickly as possible. That is the next challenge. And that's what I'm going to be doing. Ultimately, all of this happened probably because I was not having those conversations with my manager as explicitly as I should have been about my career progression. I should have said what happens at the end of the year, if I change role like two months before the end of the year. What will the performance rating be? Can you check? And I should have had probably more open conversation like this. I would have avoided the surprise because it was neither pleasant for me, nor pleasant for them.

21:23Did that reset your progress on your career progression? Because you were right about to get promoted. Every company does this differently and does those like untold rules about calibration. So like, say if someone transitions a role and they've been there less than two and a half months in the new role, it's automatic meets. Or a new grad cannot get promoted in less than X months because we never had one that we did that. So there are all of those untold rules of calibration. What's interesting about those rules is that they are developed locally. So you have like rules in like specific teams, specific organization.

22:02and over time the organizations mature and like those roles like change get codified get communicated to the IT if there was a role I didn't agree with or I didn't like I challenged it as a manager and I disputed it I was like this not this is not uh motivating because blah blah blah blah or that's why I think and ultimately I was always very aligned with the roles at every company I worked at even if that meant changing or editing some of those things at Airbnb I then led a session for like all the ICs in the in the org about like what really happens in calibration and I was able to be very transparent about what happened in that room.

22:54And my bar was if you teleport anybody in that room at any point in time and they see what's happening, they would be proud of the work we're doing. And they would not think that we're like scheming or doing something that's like objectively unfair or anything like this. So for me, it's like there needs to be a value alignment for being able to like do that job. And that's what's difficult because as a manager, you represent the interest of the company. You have to put the company first before your report. That's like an untold rule, but that's the way it is. So there needs to be very strong value alignment between you and the company.

23:33You need to be able to defend those decisions because if you don't believe them and you just lied, then it's going to make you quite sad. And I mean, if you have feelings, yeah. That's something I definitely remember was extraordinary about working with you is your willingness to dispute the status quo. And I feel like when people don't do that, that's kind of how bureaucracy kind of sets in. There's all these rules and things that people are following that they don't necessarily believe. I'm kind of curious, like you said you were often successful in disputing these rules. And I think a lot of people, maybe your frontline manager or an IC, you don't feel agency in the ability to change those rules, or maybe it's too much energy.

24:28Curious if you have any tips on how to dispute these types of things successfully. I think it comes from my interest in psychology and like the study of the different kinds of biases that can creep into those processes and how they can negatively make suboptimal decisions. So I think I always start from that place of trying to understand from a psychological standpoint, what is objectively something that is going to be helpful in evaluating employees? because I think that like I have bias, everybody has bias and you want to minimize that when you evaluate because you want the process to be fair because the main complaint people would have about this process is like, oh, it's unfair.

25:16I thought, so there has to be some set of like criteria and like values that are holding true. In terms of how do you dispute it? How do you go about it? Don't do it in the room necessarily because it's like as often if like it's not very effective to have big disagreement with like a lot of people at the same time or with someone in front of a group that completely changes the dynamic it's much much easier to start having those conversations one-on-one because otherwise people just get very defensive because they think their reputation is at stake in front of the group and they're gonna get like so and that's normal that's like that's what it means to be human So gather evidence, make your case, but take the time to understand why the rules are there and why the person, people think that those rules had to be there.

26:14Because like, there's always a story behind it. And sometimes the story is like really telling and really useful. And like, once you hear the stories and you agree, and sometimes it's just like a wrong precedent that was set a long time ago, that's no longer valid. What would you say in the example? Let's say you're in your org and then, a VP, someone five levels up says, we're going to start counting the code changes that people submit and they have to have a minimum or else they get docked in calibrations. It depends what it means to be docked in calibration. But like, say if someone, if I worked at a company and someone high up says like, oh, we will automatically fire the people would do like less than like the 10 % least coding contribution.

27:03I think it depends on like what the company and what it values. It may be a useful metric. In general, it's not because people contribute in many different ways and counting the line of code or number of PR is a very poor metric. So actually I was in that situation. Not as dramatic as what you described, but when I was at Stripe, I was the tech lead for developer productivity. And we kept wanting to have a measure of the output. Like, how productive are people? It's like, how do you know if an engineer is productive? So you can ask them, it's like, are you productive? You can count how much they produce, like the lines of code.

27:51And there's many other things that you can be doing. But it's hard. And so that's what I said to do when I worked at Stripe. It's like I was unhappy with people considering that as a potential metric. And I was not the only one. Pretty much everybody disliked that metric, even the people who suggested it. Because we all know it's a bad way to evaluate engineering. So instead, what I've done is I looked at the journey of when you make a change, when you go from your branch to merging your change, there's a whole journey. How long does it take? What do you do in those phases? So first you're thinking, then you're writing your code, then you are sending the code to CI, code review, going back and forth, things like this.

28:42And so once you start to look at this and you start to look at the journey of the changes, you'll notice that you get a lot more interesting data than if you just look at the number of lines of code or PR. You can see that, say, in an organization, it takes them twice as long to make a code change than in another organization. And that gives you a lot of lever to go look into about why does it take them twice as long? How can you help them? And that reframes the question about measuring the output, which should ultimately be the manager assesses all the work that someone's doing, regardless of if it's code or not, to the question about how fast are they when they are doing code, which is much more objective.

29:27And I'm not saying that if you're fast at shipping code, that means you're very productive and that the people who are slow at shipping code are not productive. I'm saying if someone is slow at shipping code and everyone else is fast, then you have to look into why the person is slow because that's a very, very useful signal because maybe they work in a code base that's horrible. Maybe they use like a process that's very inefficient. Before we leave your experience at Airbnb, I'm kind of curious if anything struck you about Airbnb's engineering culture. I know prior to that, you had experience at Meta and Apple.

30:07So what was kind of notable when you got to Airbnb? It was a company that it still is led by designers. So it was harder to explain why the low-level infrastructure things about the code really matter. It also has some upsides because I think that by virtue of coming from a different trade, they had different ideas that were also very good. So like one thing that they've done at Airbnb that I thought was like really amazing is we were having a lot of incidents, a lot of reliability problems. And they said, you know who is really good at solving those things? People who are like working in emergency situations, firefighters.

30:58People who are dealing with like actual real disasters. We're going to hire people from that background. We're like super good at like the crisis management. And we're going to say, now you're in charge of this. thing. And you're going to like change the way we do the internet measurement. That was genius because it's like, it brought a lot of rigor and interesting practices that then I took at every job I went after that. It's like, it's something that's very important to get right. And I think that that mindset of thinking outside of the box, like, hey, who's good at doing that, firefighter, then that worked.