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

Laurent Charignon was a Staff engineer at Stripe, Airbnb, and Instagram with some experience in management as well. We discussed the unspoken rules you learn as a manager, how he transitioned, what good mentorship looks like, and advice for senior engineers who are stuck looking to grow to Staff. 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀: • Transcript: https://www.developing.dev/p/airbnb-staff-eng-on-how-to-not-get • YouTube: https://youtu.be/cgQY_1Uz2b8 • Apple: https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: 00:00:00 - Intro 00:00:44 - Joining Airbnb and transitioning to EM 00:18:29 - Untold rules of calibrations 00:23:50 - How to dispute bureaucracy 00:29:54 - Airbnb culture 00:31:36 - Leaving Airbnb for Meta 00:35:56 - Uber TL at Stripe 00:42:52 - How to scale yourself 00:45:22 - What people get wrong in coaching 00:52:58 - Why people get stuck at Senior eng 00:57:24 - Most career impacting book 00:58:39 - Advice for younger self 01:00:27 - Outro 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗟𝗮𝘂𝗿𝗲𝗻𝘁: • LinkedIn: https://www.linkedin.com/in/laurentcharignon/ • Personal Website: https://blog.laurentcharignon.com/ • Twitter/X: https://x.com/lc2817 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  That's probably one of the meetings where people cry the most.

• 0:03Ryan Peterman?

  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.

• 0:12Ryan Peterman?

  You mentioned the secrets that you learned as a manager.

• 0:15Speaker 00

  Every company does this differently and there's those untold rules about calibration.

• 0:21Ryan Peterman?

  He also mentored me at Instagram and helped me reach staff.

• 0:24Ryan Peterman?

  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.

• 0:30Speaker 00

  The key is to be able to identify problems and to then be able to pitch and then solve them. I think one mistake people make consistently in their software engineering career is to not...

• 0:44Ryan Peterman?

  Here's the full episode.

• 0:50Ryan Peterman?

  What's the story behind you choosing to join Airbnb? And how are you thinking about your career planning at the time?

• 0:56Speaker 00

  At the time, I'd been in the industry for a few years. I'd 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.

• 1:22Speaker 00

  And I had to continue doing my job while taking the bus an hour and a half each way. And so like I immediately started a job search. And I picked Airbnb for multiple reasons. Like I love the people that interviewed me there. It was close by, I could just like walk to the office.

• 1:46Speaker 00

  And I liked where they were at in terms of like developer productivity and what was remaining to do. It was, they were like... Very early on, I joined as one of two engineer on test infrastructure. So I was just at like the beginning of like when DevFra was starting to be multiple teams. And I think that was like very exciting moment to join.

• 2:09Ryan Peterman?

  So I understand at Airbnb, eventually you transition 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:21Speaker 00

  So the setup was, we had one manager was managing, I think like three or four different teams. And it was starting to get very, very busy because like when you're a manager and you manage like more than fifteen 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

• 2:51Speaker 00

  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, in the industry. And I think they needed a lot of that support. And 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,

• 3:37Speaker 00

  in their success with more time than what my manager could dedicate. So I, 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, and he said, yes. And he was very kind. And 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, it's actually very unique. Like when you become a manager of your peers, it presents some interesting challenges.

• 4:12Ryan Peterman?

  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?

• 4:22Speaker 00

  There were and were 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. And 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 3pm. You've got to talk to them about it, it cannot happen again. What do you do?

• 5:04Speaker 00

  And so like immediately I was like, wow, I'm going to ask you what you think about it and about like what happened and the facts and try to understand like what actually happened. And he was like, okay, you passed. Because the way you fail this is by just saying like, you're grounded. You did something wrong. 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 and 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.

• 5:46Ryan Peterman?

  What percent of managers do you think would fail that test?

• 5:51Speaker 00

  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 micro manager 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. Like say if you're, if you're, if you like micro management, 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.

• 6:36Speaker 00

  To solve the problem and one way to like solve every like coaching situation, you have to try different techniques.

• 6:44Ryan Peterman?

  I remember you mentioned to me before that you were kind of bored at some point. And so I'm curious, like, after living through that transition, what was the experience like going from an IC to a manager in that regard?

• 6:58Speaker 00

  Ah, yeah, I think I was bored at multiple times, multiple points in my career. Boredom 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. Like, as I transitioned to manager, you go through all those trainings where you learn about all the secrets, about like how, you know, like how we decide the level of someone that comes in. How do you do promotion?

• 7:43Speaker 00

  How do you do performance with you, all of those things?

• 7:48Speaker 00

  So that was very exciting and I was curious about how all of those things worked.

• 7:54Speaker 00

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

• 8:38Speaker 00

  without the holes, so 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 were happy at work. Perform well, 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 gonna do that?

• 9:20Speaker 00

  I am going to just send a big form, I did a Google form, with like all the things we do as a team, like we meet for the stand up on Tuesday at 9am. 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 stand up was useful for the other people.

• 9:59Speaker 00

  And so we're spending so much time doing that, like very long stand up that was useful for nobody. And so we changed the format to like a form that was useful for people. And then we did that for every process, from like planning to how we work together, even scheduling, like when we would like review code. And it worked, like then the team like 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.

• 10:43Speaker 00

  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? It's like, I'm getting bored, this is so easy. And I have nothing to do.

• 11:08Speaker 00

  And so then the next step, I discussed with 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 like 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.

• 11:40Ryan Peterman?

  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 and if so, how?

• 11:51Speaker 00

  They did. Like all the secrets I've learned

• 11:55Speaker 00

  helped me become a better IC and especially everything around

• 12:04Speaker 00

  career progression, around framing your career, around the performance review and the rating, then 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

• 12:32Speaker 00

  one of the main ways that I was able to contribute to like leadership as an IC.

• 12:38Ryan Peterman?

  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. You 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 to transition to management?

• 13:01Speaker 00

  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 are going to get what they want. And I think that's sad because like life is very short and I think it should be an ongoing conversation.

• 13:39Speaker 00

  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, the promotion. Write on a piece of paper, what is your expected rating? Are you gonna get promoted? And roughly like what what we're gonna talk about? And I do the same. We put the paper in the middle on the table. We opened the papers at the same time.

• 14:25Speaker 00

  If it matches, it's a pass. If it doesn't match, it's a fail. Because like you want to minimize the surprise. Like 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 are like uncertain or feel like

• 14:49Speaker 00

  at risk, they are not gonna do their best at work. So I I I use this metric and I try to drive it to like a hundred percent. I it never was exactly a hundred percent, but it came pretty close.

• 15:01Ryan Peterman?

  I I could see the value in that because I I think a lot of people, obviously, the negative surprises are bad. But also the positive surprises can be bad as well.

• 15:14Speaker 00

  Yeah, the positive surprises are bad. Like say if someone does not expect, doesn't think they're doing well. Okay, and then you think that 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 gonna 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 if they are good and they don't know, it's like that's something that's coachable.

• 15:42Ryan Peterman?

  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. What are your thoughts on that for ICs?

• 15:56Speaker 00

  For me, the experience was invaluable. So nowadays, I tell before, if you think you should, 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,

• 16:39Speaker 00

  start with an intern. See how it goes. Because it's actually an interesting experience to manage an intern. It's not quite like being a full-time manager because you get very attached to your little intern because you have like one intern. And in general, they're much earlier in their career. So 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 ICs. And it's also only one person that you manage, which gives a huge sampling bias. And so you see management

• 17:22Speaker 00

  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 they all, everybody, everybody comes in with their intern thinking, because they've really tried to like direct them and coach them, thinking they are doing so well because they want their intern to succeed. And they, and everybody who goes to the meeting tends to say like, oh, my intern exceeds expectation, is doing so well, they need a return offer, all of this. And 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.

• 18:05Speaker 00

  If that was the right thing to do, that was the right thing to do. So I love, I love that experience of like, uh, being an intern manager. So at Airbnb, I ran, um, some of the calibrations for interns, interns with like all the intern managers to try to make it, uh, less scary, to make it like, to reduce that bias.

• 18:29Ryan Peterman?

  You mentioned a little bit about your promotion to becoming a frontline manager, going from M zero to M one. I'm kind of curious, if you look over your promos, because we talked about that surprise metric, for yourself going through those promos, were you surprised, uh, 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.

• 18:53Speaker 00

  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 your surprise about like, uh, something happening, that means you're like, you don't have a good read of the situation. You, 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.

• 19:25Speaker 00

  I'm trying to think. I was never surprised by like a promo, but I was surprised by like some ratings sometimes.

• 19:35Speaker 00

  The one that surprised you the most is around that time. So I was, I was an IC. Okay, so IC four, I think. I don't, I think it depends on the company, like how you, like the level below staff, basically.

• 19:53Ryan Peterman?

  So five for a lot of companies.

• 19:55Speaker 00

  Yeah, 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's 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

• 20:40Speaker 00

  as an IC, I would probably have gotten like the, the promotion to staff. But instead I was like, okay, well, I'm just gonna make it work. As an M zero, I'm gonna try to get to M one 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 happened 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:23Ryan Peterman?

  Did that reset your progress on your career progression? Because you were right about to get promoted.

• 21:28Speaker 00

  Every company does this differently and there's 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 meet. 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 roles of calibration. What's interesting about those roles is that they are developed locally. So you have like roles in like specific teams, specific organization.

• 22:02Speaker 00

  And over time, the organizations mature and like those roles like change, get codified, get communicated to the IC. 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 is not motivating because 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 org about like

• 22:46Speaker 00

  what really happens in calibration and I was able to be very transparent about what happened in that room. And 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 be able to like do that job. And that's, that's what's difficult because as a manager, you represent the interest of the company.

• 23:23Speaker 00

  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. You need to like be able to defend those decisions because if you don't believe them and you just lied, then it's going to like make you quite sad.

• 23:46Speaker 00

  If you have feelings.

• 23:50Speaker 00

  Yeah.

• 23:51Ryan Peterman?

  That's something I definitely remember was extraordinary about working with you is your 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 you're a frontline manager or an IC, you don't feel agency in the ability to change those rules, or maybe it's too much energy. Curious if you have any tips on how to dispute these types of things successfully?

• 24:33Speaker 00

  I think it comes from my interest in psychology and like the study of the different kind of biases that can creep into those processes and how they can negatively like they can make us, you know, make suboptimal decisions. So I think I always start from that place of like trying to understand from a psychological standpoint, like 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 will have about this process is like, oh, it's unfair.

• 25:16Speaker 00

  I 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 disagreements 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

• 25:56Speaker 00

  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.

• 26:06Speaker 00

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

• 26:29Ryan Peterman?

  What would you say in the example? Let's say you're in your, 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.

• 26:46Speaker 00

  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 who do like less than like the 10% least coding contribution.

• 27:04Speaker 00

  I think it depends on like what the company and what it values. It may, 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, I was in that situation, not as dramatic as what you described. But like, when I was at Stripe, I was the tech lead for developer productivity. And we kept wanting to have a measure of the outputs. 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:49Speaker 00

  And there's many other things that you can be doing, but it's hard. And so that's what I said to do, like when I, when I worked at Stripe. It's like, I was unhappy with people considering that as a potential metric. And I was the only one, like pretty much everybody disliked that metric, even the people who suggested it. Because we all know it's, 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?

• 28:32Speaker 00

  What do you do in those phases? It's like, 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. And so, once you start to look at this and you start to look at the journey of like the changes, you'll notice that you get a lot more interesting data than if you just look at the number of like 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 like go look into about like, why does it take them twice as long? How can you help them? And that reframed the question about like measuring the output,

• 29:13Speaker 00

  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 like, how fast are they at like when they are like doing code, which is much more objective. And I'm not, I'm not saying that if you're fast at like 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 like, maybe they work in a codebase that's horrible. Maybe they use like a process that's very inefficient.

• 29:54Ryan Peterman?

  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. So what was kind of notable when you got to Airbnb?

• 30:12Speaker 00

  It was a company that it still is led by designers. So it was harder to explain.

• 30:22Speaker 00

  Why the low level infrastructure thing about the code really matter? It also has some upsides because I think that by virtue of like 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 we're having a lot of incidents, a lot of reliability problems. And they said, you know, who is really good at solving those things? People were like working in emergency situation, firefighters. People were dealing with like actual real disasters. We're going to hire people from that background.

• 31:05Speaker 00

  We're like super good at like the crisis management and we're gonna say, now you're in charge of this thing. And you're going to like change the way we do the internet management. That was genius because it's like, uh, 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, it's something that's very important to, 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.

• 31:36Ryan Peterman?

  You left Airbnb for Meta, which is a boomerang because you'd already been at Meta. I'm curious, what made you want to leave Airbnb and go to Meta?

• 31:44Speaker 00

  Well, uh, so like I said, I joined in 2016. It was 2020, four years in. So at that point, uh, you were getting four years grants when you work for like those tech companies. So that means I had, um, a cliff of stock. And so at that point, I started to like, uh, my earning potential started to decrease.

• 32:08Speaker 00

  And that's generally what happened at like, at like four years, unless you manage to like score a lot of like stock refreshers. So I think part of it was like financially motivated. Another part was I.

• 32:21Speaker 00

  Thought, because I worked on test infra, I worked on compute, I worked on databases, I worked on all around like different infra teams, that I wanted to be an infra generalist. I was wrong, but I thought I wanted to be. And so I looked for a infra generalist job and that's how I landed the job at Instagram. I got to be on call for the 4th of July for Instagram. And I remember I was trying to like go hang out with my neighbors as we moved to a new place and I kept getting paged and kept going back home across the street to like go and figure out like what didn't work. And I was like, I am going to do everything I can to make Instagram as reliable as possible.

• 33:06Speaker 00

  And I know it's possible because Facebook solved a lot of those problems before. And when I see people work on the code at Instagram, they don't use all of those tools that they use on the Facebook side. And I know because I worked there. And so I went and I pitched it.

• 33:24Speaker 00

  I went to my manager's manager and I say, look, we have all those incidents. There's all those tools that at Facebook, they've been using for years and solve all of those patterns of incidents. We are not using any of those things. It is time that we partner with them and we onboard some of those tools that can dramatically improve the reliability of Instagram. And then that's why I became involved in that project.

• 33:54Ryan Peterman?

  How'd you find out who on the Facebook side to talk to to get the buy-in for such a large adoption of their tools?

• 34:03Speaker 00

  So basically, they paired me with an IC was working on the Facebook side. Her name is Ariane and she was exceptional at getting this buying on the Facebook side, bringing the right people to the conversation. And she is one of the most remarkable tech lead I've seen and worked with in my career. She basically did that.

• 34:26Ryan Peterman?

  I remember something interesting you told me before is you've wanted to be mentored by her and you

• 34:36Ryan Peterman?

  Made an explicit pitch to her, actually. I remember you were very, you had a lot of agency in actually going to her and setting it up. And I'm curious if you could tell that story and, you know, what you might recommend for others who want to set up mentorships.

• 34:50Speaker 00

  So there's several people that I met in my career. And then when I met them, I'm like, this person's able to be thoughtful, to challenge me, and also seems to be a very, they would just work well with me. They would be able to like make me change my mind on topic and I would relate to them. And so they don't have to be engineers. There's people I met like even outside of like software engineering, like my current coach, for example, she has all of those qualities. And so when I met Aria and I noticed that like, yeah, she had all of those qualities. I'm like, I really want to work with this person because she was very direct, very helpful, thoughtful, really excellent at like analyzing problem

• 35:35Speaker 00

  and trying to explain like in what ways I was thinking about the problem the wrong way. I'm like trying to get me to change my mind. She got me to change my mind about a lot of things. And so does my coach. I think that's like, that's, that's a measure for success is like, are you able to, do you change your mind as a result of coaching? Or you just do the same thing you were doing before?

• 35:56Ryan Peterman?

  When you went to Stripe, I'm kind of curious, what were your first impressions as an engineer there?

• 36:02Speaker 00

  Everyone was, I think that's like at every job I had the impression, like I often have the impression that I work with very bright people because that's the case, like at like every job in this, in the Silicon Valley. At Stripe specifically, I like that everyone was very much focused on making decisions based on data. And there was like a big culture around data, collecting data, analyzing data and making decision really using rigor and science rather than like.

• 36:40Speaker 00

  You know, hunches and intuition. Facebook also has that culture of like the experimentation. But Stripe has it to an even bigger extent, in my opinion. And there is such a strong culture around metrics. And I love that because like I love metrics. I love like being able to measure success and how progress is made. So I felt right at home when I joined Stripe for that return.

• 37:08Ryan Peterman?

  You mentioned you were the TL of this dev in front team. And eventually the scope grew. It grew from thirty five people to one hundred and forty people in this organization. And I kind of want to learn more about the story as it grew.

• 37:22Speaker 00

  So I joined as like the tech lead of build, test and tuning. So that was a group of team that were doing the build. So that's like the build system, Basil, the remote building, the code management internal, GitHub, code review, testing infrastructure, testing data. That was the group of team. And that was great for me because that's like the areas of DevFro that I was like the most familiar with. And so initially I was like, I need to gain credibility. Why? Because it's like those thirty five engineers have been working here, like most of them a long time. And I'm coming as an outsider.

• 38:04Speaker 00

  I want to be able to lead them and I want to be able to do a good job. So I looked back at when I was in that situation, when I was in one of those teams and a new tech lead join in and think about like, what is it that they've done right and wrong? And the thing that I came up with was, I think you're doing it wrong if you use your past experience all the time to justify what to do. You're like, oh, it worked at Facebook, so it must work here because it like belittled the people and like their, their experience.

• 38:41Speaker 00

  You need to also not tell people what to do because that's not how you build

• 38:47Speaker 00

  trust in the team. Like say, imagine your eye and be like, oh, I've never seen this thing work at any company I worked at. So we're gonna cancel this project. That that doesn't work. So I was like, I have a rule. My rule is I will not tell people what to do. I will not reject the design outright. I will never do that in my whole time. And that's right, I never did that. So there's a couple of time when I told people what to do, which was in situation of like urgency, when you're like solving an incident and you're like, yeah, you have to do this, you have to do that. But otherwise, I managed to do all of my work and all the influence and all the change of direction by asking questions.

• 39:29Speaker 00

  Simply asking questions and getting people to change their mind themselves as opposed to just telling them like, hey, we have to do this or we have to do that. So that was my style coming in. That's what I wanted to do. And I'm like, in order to build credibility, I need to need the engineers to know me, to know my style. So I'm going to embed in the different teams. So I embedded in the teams.

• 39:52Speaker 00

  And started to work with the people on like, say, I would embed in a team to go work on a specific project for like a month. Just to see what the rhythm is like, how people work together. And so after a year, I'd met everyone in person multiple times. I had like embedded in like pretty much all the different parts of the the group. And I felt like I had a good grasp. And then I was like,

• 40:20Speaker 00

  but I know less than every individual person about their domain. And that's what leadership is like. Unfortunately, like when you are like saying, child of like a large group, you by nature know less than every person about their own domain. And you have to accept that. And it's very, very different than what happens, say, when you're the tech lead of a team, where you're the person who knows the most. So there's that that transition. And I was able to navigate that transition by just changing my mindset and thinking. People are experts. I'm supposed to guide, I'm supposed to ask questions. And that's how we're going to get there. And it's gonna work because I have a good hunch for like,

• 41:05Speaker 00

  how to solve developer productivity problem. I worked on that many, many years. And just naturally, I always think about like, how to do things better. So I will just ask good question and that's gonna work out. And it did. After that, the model shifted a little bit. When the org was like about forty, fifty people, I shifted to a mode of operation where I would be deployed to go work on something for like, say, two to eight weeks. And then go, that would not necessarily be with a team. It could be with like a group of team, could be with like one or two individual.

• 41:47Speaker 00

  It could be like teams outside of their prod to just go solve problems. And that's basically the mode of operation that I really, really enjoyed. Because then you just get to like bootstrap thing, get things started, get things in motion, motivate, and then start the execution. And then after that, making it sustainable. So that like it can operate without you. And that's something that's very important for me is that like at every of those assignments, I always think about sustainability first. What happens if I want to go on vacation next week? Will they have to call me? Will they have to ask me anything? I want this to never be the case.

• 42:32Speaker 00

  I want everything to be like documented, automated in such way that like sustainability is not a problem. I never want to be that guy who knows all the secrets about like the code base. And then you're supposed to ask like, hey, how do you change this file? That's not how it should be. And that's one thing I learned as a manager.

• 42:53Ryan Peterman?

  On that topic of scaling yourself, I mean, if the group grew to so many people, I'm curious, do you have any tips on how you scaled yourself across such a large group of engineers?

• 43:05Speaker 00

  I have a lot of tips about that. So one very important one is in terms of the own expectation about what you can do. When you're leading a group of seventeen engineers, you cannot possibly know what everyone's working on at any point in time. You have rough idea and you have to be ready to like have your contacts in all the different places to be able to gather information quickly. But imagine you're in a leadership meeting and then someone asks you like, hey, what's the progress on this project? It is possible that you're not gonna know because there's so many projects across so many engineers. And you have to be okay with saying like, I don't know, I will be checking on this and get back to you by that date.

• 43:49Speaker 00

  And it's okay to say, I don't know, even if it's uncomfortable because you think that you're like appear not competent by saying, I don't know. But that's quite the opposite. It's much better to say, I don't know than to say something wrong because if you say something wrong.

• 44:05Speaker 00

  In a lot of the culture for tech companies, it's the end of your career. Like if you claim with confidence something that is wrong, you're going to lose all the respects from your coworkers. We are not going to be able to rely on your word moving forward and it's a massive, massive problem. And so I've seen like, it's not the case for all the industries. That's interesting, right? It's like, it's a case for software engineering. And so you have to say that and then you have to scale yourself. So that means you can't know everyone in great detail. You can't like meet with everyone every week. That's absolutely like impossible. So then I think you have to switch to a model. What worked for me was office hours.

• 44:47Speaker 00

  You set a block and be like, you can book time with me to chat and you need to have enough office hours so people can always chat with you like the week off. And what else worked for me? I work with people in Europe, so I shifted my work here. I started my work at like 5:30 AM up to noon. And this way I had like overlap with the people in Europe and then overlap with the people in the United States. But like half of the group was in Europe. So I think it was important in order to like really get to know them, motivate them and influence their work to have some face time and to be able to like communicate with them.

• 45:22Ryan Peterman?

  You've done so much coaching throughout your career and you said that was a big part of your experience at Stripe as well. Is some of the topics on how to coach well? And one thing that I want to go over is what are some of the things that you see people who are coaching software engineers or people in tech? What are they commonly getting wrong?

• 45:44Speaker 00

  Ah, when you hear someone say, oh, I'm hands off. Or I like to tell people what to do and to give a lot of details or I just like to give little hints. Basically, that's just one way to coach. And the reality is when you're coaching people, you have to adapt to your audience and you have to change your style. And if you use your one way that worked with some people, it may not work with everybody. And it's going to give you surprisingly bad results. And I experienced that very early on in my career, which was like very helpful.

• 46:25Speaker 00

  It's I joined, when I joined Facebook in 2014, I became an onboarding buddy. And I was asked to help several people through the bootcamp at Facebook. So the first few weeks to know like to teach them like how to use the tools and how to like be an engineer at Facebook, basically. And three out of four of my mentees were doing well, were doing exactly like what you typically see. And then the last one, no progress. And so the people in charge of the program were starting to get a little nervous. And you know, we're having those meetings every week when we're reporting the progress of like the people and be like, okay, we're gonna have to change the technique.

• 47:07Speaker 00

  And then the person leading that program, I think it was Scott Renfro, he took me aside.

• 47:16Speaker 00

  And he said, hey, listen, maybe you should look into this thing called situational leadership. I'm like, okay, I'm gonna look it up. And situational leadership is a very interesting model and that unlocked that situation with that individual and turned them into like the most effective of the four.

• 47:34Speaker 00

  I was in charge of. And so the way it works is when someone's learning new skills, they progress along multiple axes. It's not just a mastery of like learning the skill, but there's also the motivation. And that's very interesting because psychologically, like if someone's trying to like learn a new skill in general, they are like quite excited, but with like low mastery of the skill. And then as their mastery grows, they start to realize that they don't know. And their mastery grows and they still think that they don't know and they are like not confident. And over time, both of those like climb up and to the right.

• 48:13Speaker 00

  And so this divides the learning into four phases, which are like those things, the situational leadership. And depending on where someone's at, you do the approach very differently. And that applies to every situation. It could be like my mom trying to do something on an iPhone, my daughter trying to figure out a game controller or a software engineer trying to figure out what technology to use for their project. You have to have that internal assessment of like, where am I on that skill that they're trying to do? Where are they? And what approach should I take? And so the idea is that like, if someone's learning at the beginning, you have to be very directing. You have to say, oh, you have to do this, you have to do that.

• 48:57Speaker 00

  And so that they can learn the rope and like learn to do the different steps. As someone progresses, you have to switch to being like more selling the idea, encouraging, say, oh yeah, you're gonna be able to do it and help them with like the the difficult decision. Maybe like take the high level decision making, but letting them do like the individual task. And then as they progress, you have to empower them to like be able to like make those decisions themselves. You have to just switch to being supporting. And finally, you have to be delegating. I mean, it's like, once they know how to do the thing, you have to know to stay out of the way. And I think this is whole dance that happens for like every skill.

• 49:45Speaker 00

  It's very, very important to understand because if you don't understand that and say if like your approach is you're going to just tell people like good work, keep going. Then you're going to be doing just the supporting one. So you're only going to be able to catch the people who are in that window and be effective for them. Everybody else is going to be counterproductive to do that. So you have to understand. And so like after doing it for like so many years, it becomes natural and like you don't even think about it. And it's like obvious that's like.

• 50:16Speaker 00

  If my mom calls me at 4am and she says, my phone is reading notification aloud. What do I do?

• 50:27Speaker 00

  I'm not going to start to explain to her all the systems. I'm going to be like, share your screen, click this button, click this button, click this button, done. And I'm not going to go into the detail about anything. And it's not, it's like, it's situational, right? It's like it's at 4am, she's tired. It's like a situation where you have to be directing. And like if instead I'd be like, mom, you're so good at the iPhone. You know, all the settings, good work, keep trying. Do you think she's going to be able to be doing it? No, she's not. She's going to be pissed off like if I do that. And if I say like, oh, bye bye. I know you can do it. You've proven times and times again that you can do it. That would be delegating. That would not work.

• 51:10Speaker 00

  And then if it's the, yeah, so like for every situation like this, you can apply that framework and it's very interesting because like people will make mistakes with coaching. They think that they know the way they find the technique that works and they pick one of those four and they forget the rest.

• 51:27Ryan Peterman?

  So yeah, I'm curious in the, in the specific example with that one boot camper who is not succeeding. Where were they in this? And where'd you go wrong in the coaching and how'd you fix it?

• 51:39Speaker 00

  I went wrong in thinking that everybody who starts is in the first bucket, which is like high motivated, highly motivated, low skills. And we are like, you will start to be like directive and be like, okay, follow this page. Do all those steps to learn those tools. This person. I'd spent a lot of time going and studying all those documentation and things like that. I've already internalized a lot of the things and realized that he didn't know that much. And that it was at the point where like the motivation was low. The knowledge was higher than the other people. But because I was coming and directing, it was like interrupting their learning. And they were like unable to actually like perform in that way.

• 52:23Speaker 00

  So like when I was like, okay, uh, what have you done? And then they explained that they've read all those things. And I switched to being like more supporting and like actually giving like way less advice. About what to do, then they started to perform. And that felt like magic. And I was like, what's happening? It's like, why, how? Then I've, I've, I've learned this and then I've applied it to so many situations. And it's a very useful skill, even as a parent. Cause like, you know, kids are always learning things and they're always at different point in the learning scale.

• 52:58Ryan Peterman?

  I remember when we were working together, you actually coached me out of getting stuck as an IC5 or a senior engineer. I remember you said something to me, you said, actually, the promo from senior to staff is actually harder than the one from staff to senior staff. Because of some specific reasons. And I'm curious if you could share those reasons and also some advice for people to get unstuck from that senior promotion.

• 53:27Speaker 00

  The senior to staff promotion, it's about like a big, a big mindset shift where you have to be a completely independently picking problem. Solving those problems and to explaining how you solve them and then documenting like what you've done. It's like the whole cycle of finding problem to solve pitching problem, solving problem. You have to be able to do that to be a staff engineer. And that's hard.

• 54:04Speaker 00

  It takes and like when you're a senior staff, you're just doing the same thing, but with forums are like higher scope and like when you're like principal engineer, I think it's the same thing, but like higher and higher scope. That's kind of like how it goes. But when you are a senior engineer, you're in general like working on other people's problem that they've identified. And then they ask you to design a solution and then you solve it. But like you're not autonomous on like the whole cycle of the problem discovery, choosing what you get to work on. I think that's really what's what's the distinction.

• 54:38Ryan Peterman?

  What would your advice be to someone who's been stuck as a senior engineer for a long time and they're trying to make that jump to staff?

• 54:45Speaker 00

  The key is to be able to identify problems and to then be able to pitch and then solve them and to identify bigger problem than the one you currently know about. And the way you find out about problems, that is the way I do, is by channeling my inner frustration. Which means I do something and I'm thinking, oh, it looks like I had to type all those things on the keyboard and open this window and all of it's like it took me a while. I don't want to do that again. I want to do better. And so that that works really well for like developer priorities. Like I can do anything.

• 55:24Speaker 00

  And I can be able to find all of the friction, all of the little parts that are not ideal. Oh, and that's one thing that Stripe does extremely well. And that they managed to like institutionalize for the culture is this idea of a friction log. You go through the flow of your product, whatever you're working on. And you take pictures of the different steps and describe like what you're doing.

• 55:55Speaker 00

  And you analyze the friction, every single step that you have to do. Why do you have to do it? Why did it have to be a new window? Why did it have a loading screen? How long did it spend to load? All those things. And so I've gotten really good at that because I practiced a lot at Stripe, where I would just go and make a code change and I could find fifty or sixty different things that could be done differently. And then after that, you identify like the families of problem, you rank them and then you go and solve them. So it's like the same for any role. You just use your products. You really use it like from first principle. Take pictures of your experience and channel your inner frustration.

• 56:38Speaker 00

  Try to think if I was very, very tired and I was going to do these things, where would I fail? Where would I get stuck? Like where, uh, where would like I drop off? And then try to remove all of those frictions. And that helps you identify like the biggest opportunities for impact. That's, that's how I see it. I think that's like a very effective way to, to do it. Like, for example, imagine you go and you do business travel and you're doing it like twenty times in a year. I think it's useful every time to learn something new, refine your process and get better at it. So that like on the twentieth travel, you're just like extremely effective at it. I guess it's like the staff engineer mindset.

• 57:24Ryan Peterman?

  Is there a book that had the biggest impact on your career?

• 57:28Speaker 00

  When I started being a manager, I had to have all those conversations that were not very easy with the people in my team. And in order to be effective at it, to build trust and to be able to effectively motivate and coach, I found that Radical Candor was the book that really gave me that. It's written by Kim Scott, who used to help managers at Apple, like as part of their training, figure out like how to be a good manager. And she talks about.

• 58:06Speaker 00

  How you build trust in those relationships? And like, how do you view the manager employee relationship?

• 58:17Speaker 00

  And she has a lot of very good points that I've not seen mentioned in other books and some ideas that like, quite frankly, a lot of like companies and seasoned managers are missing. So it's it's a great book. She also has like a TED talk on YouTube where she talks about it. And I think it's, in my opinion, it's been like one of the most influential thing I read.

• 58:39Ryan Peterman?

  Last question for you is if you could go back in time to when you had just entered the industry and give yourself some advice, what would you say?

• 58:49Speaker 00

  It's moving even faster than you think. So you have to always stay on top of it because software engineering is evolving so much. Like when I entered the industry, Google was asking people, how many golf ball can you put in a 747? And that was like the interview, literally. There was like a book called Cracking the Coding Interview, where they tell you about all those problems that are like weird and that you have to like estimate. And that's how you apply it. Nowadays, in 2025, when you interview, you're like recorded by a camera. Your screen is being recorded to make sure you're not using the AI. And you have to explain what you're doing and it has to be about coding. And it's very, very like uh

• 59:29Speaker 00

  technical. So everything changes so fast. The whole career changes. Being a software engineer today is not at all what being a software engineer in 2012 was. It doesn't take the same skills. It doesn't take the same.

• 59:49Speaker 00

  It's hard to stay on top of everything. You you've got to keep reading like the tech news. I really recommend reading Hacker News if you don't. There's a special version that like you can rank over the last week, which one are the most popular? That's what I use is h n dot algolia dot dev, I think. It's it's really effective. Like I read everything that's been popular in the last week and I've done that my whole career. And that's how you stay on top of it. And it moves so fast. It is not the same to be a software engineer now than it was 10 years ago or 20 years ago. And I know that in five years, it will be very, very different.

• 1:00:27Ryan Peterman?

  Awesome, Vol. Thank you for your time, Laurent. I really appreciate it. I'll put all the links in the show notes, the stuff that you said.

• 1:00:33Ryan Peterman?

  Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you want to help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you want to drop a review, that'll be super helpful. And if there's any guests that you want to bring on to, please let me know. I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you want to hear their career story, let me know and I'll reach out to them.