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.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
00:00:44 - Joining Airbnb and transitioning to EM
00:18:29 - Untold rules of calibrations
00:23:50 - How to dispute bureaucracy
00:31:36 - Leaving Airbnb for Meta
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
Transcript
00:00:44 — Joining Airbnb and transitioning to EM
Ryan:
[00:00:44] Here’s the full episode. What’s the story behind you choosing to join Airbnb, and how are you thinking about your career planning at the time?
Laurent:
[00:00:56] At the time, I had 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? 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.
[00:01:27] 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, and I liked where they were at in terms of developer productivity and what was remaining to do. They were, like, very early on, I joined as one of two engineers on test infrastructure. So I was just at the beginning of when dev fraud was starting to be multiple teams.
[00:02:04] And I think that was a very exciting moment to join.
Ryan:
[00:02:09] So I understand at Airbnb, eventually you transition to management. I know you started as an IC working on a test infrastructure team, and I’m curious, why did you transition away from being an ic?
Laurent:
[00:02:21] So the setup was we had one manager was managing, I think, like, three or four different teams, and they were starting to get very, very busy because, like, when you’re a manager and you manage, like, 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.
[00:03:11] And so I started doing that as a tech lead. As we grew, the team test infra was I 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, in their success with more time than what my manager could dedicate.
[00:03:41] So I went to him and I pitched it to him. I’m like, listen, there’s all those people, they need more support. I can do that. I can try. You can help me be a manager. And he said yes. And he was very kind. And so I started as a manager. Initially I had only two reports, and then 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.
Ryan:
[00:04:12] 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?
Laurent:
[00:04:22] There were and were like, very upfront about it. And I will always remember this one guy came to the 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.
[00:05:02] It cannot happen again. What do you do? And so immediately I was like, well, I’m going to ask you what you think about it and about what happened and the facts and try to understand what actually happened. And he was like, okay, you passed. Because the way you fail this is by just saying you’re grounded. Even you did something wrong, you didn’t show up to the interview because you don’t know. It’s possible that they got the wrong name, that they sent the email by mistake.
[00:05:34] 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.
Ryan:
[00:05:46] What percent of Managers do you think would fail that test?
Laurent:
[00:05:51] 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 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 like say if you like micromanagement, it will work if your whole team is new grad, but it’s not going to work if your whole team are experienced engineer.
[00:06:29] 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.
Ryan:
[00:06:44] 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?
Laurent:
[00:06:59] 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 deliver that big project that I was leading as a tech lead.
[00:07:28] And initially it was very intense. Like as a transition to manager, you go through all those trainings where you learn about all the secrets about how, you know, like how we decide the level of someone that comes in, how do you do promotion, how do you do performance, all of those things. So that was very exciting and I was curious about how all of those things worked. But after that, the next challenge was people management.
[00:07:59] 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 try to defrag the calendar so that it would just be without the hole so they could have as much focus time as possible and everybody liked it.
[00:08:43] That was really impactful because then they could do more software engineering and less interruption. The other thing I’d 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 health score in the infrastructure group at Airbnb.
[00:09:18] I was like, how am I going to do that? I am going to just send a big form. I did a Google form with all the things we do as a team. We meet for the stand up on Tuesday at 9:00am 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 fill this out.
[00:09:49] I got the results. I was shocked. It’s like everybody thought the standup was useful for the other people. And so we were spending so much time doing that very long standup that was useful for nobody. And so we changed the format to a form that was useful for people. And then we did that for every process from planning to how we work together, even scheduling when we would review code. And it worked.
[00:10:20] 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 once things were really running well, it was at the time I was getting married and I left for, 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.
[00:10:53] And they had figured out how they were going to 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 with. 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.
[00:11:25] I like the experience of shipping something to production, seeing it work, seeing the graph moves and all those things. It’s very motivating. So I switched to being an IC after that because I was bored.
Ryan:
[00:11:40] You mentioned the secrets that you learned as a manager. And I’m curious if, when you switched back to being an ic, did those make you A better ic, and if.
Laurent:
[00:11:48] 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, 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.
[00:12:27] And then I fostered those skills, and then that became one of the main ways that I was able to contribute through, like, leadership as an ic.
Ryan:
[00:12:38] 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, I’m curious, do you think that’s the best way to, to transition to management in general?
Laurent:
[00:13:02] 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.
[00:13:32] And I think that’s sad because, like, 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. 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?
[00:14:11] Are you going to get promoted? And roughly, like, what, what we’re going to talk about, and 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, 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.
[00:14:41] You don’t want them to be stressed out. Because people who are, like, uncertain or feel like at risk, they are not going to do their best at work. So I use this metric and I tried to drive it to like 100%. It never was exactly 100%, but it came pretty close.
Ryan:
[00:15:01] 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.
Laurent:
[00:15:14] 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’re 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.
[00:15:37] Because, because if they are good and they don’t know, it’s like that’s something that’s coachable.
Ryan:
[00:15:42] After transitioning to and from management, I 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 that for ICs?
Laurent:
[00:15:56] For me the experience was invaluable. So nowadays I tell before, 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.
[00:16:25] But in every failure there’s a lot of things that you can learn. So my advice right now is to say you should all try but first 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 one intern and in general they are much earlier in their career so you’re very much directing their work.
[00:17:07] And so it’s not the same dynamic. Then say like when you’re managing like high level IC and it’s also only one person that you manage which gives a huge something 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 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.
[00:17:46] And they, and everybody who goes to those meetings tends to say, like, oh, my intern exceeds expectation. He’s 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. If that was the right thing to do, that was the right thing to do.
[00:18:08] So I love that experience of like being an intern manager. So at Airbnb, I ran some of the calibrations for interns with like all the intern managers to try to make it less scary, to make it. To reduce that bias.
00:18:29 — Untold rules of calibrations
Ryan:
[00:18:29] You mentioned a little bit about your promotion to becoming a frontline manager going from M0 to M1. 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 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.
Laurent:
[00:18:54] 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. 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.
[00:19:25] I’m trying to think. I was never surprised by like a promo, but I was surprised by like some ratings. Sometimes with the one that surprised you the most is around that time. So I was an IC. Okay, so IC4, I think. I think it depends on the company, like how you like the level below staff, basically.
Ryan:
[00:19:53] So five for a lot of companies.
Laurent:
[00:19:55] Yeah. So I was leading that team, the test infrastructure team, and I was really expecting that I would get to Stephen 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 in the new role for a While it was really difficult because I was like, that’s not right.
[00:20:39] Because had I stayed as an ic, I would probably have gotten the promotion to staff. But instead I was like, okay, well, I’m just gonna make it work as an M0. I’m gonna 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.
[00:21:06] 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 conversations like this. I would have avoided the surprise because it was neither present for me nor present for them.
Ryan:
[00:21:23] Did that reset your progress on your career progression because you were right about to get promoted?
Laurent:
[00:21:28] Every company does this differently. And does those, like, untold rules about calibration? Say, 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 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.
[00:22:02] And 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 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.
[00:22:37] 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. 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, well, like, scheming or doing something that’s, like, objectively unfair or anything like this.
[00:23:12] So for me, it’s like, there needs to be a value alignment for be able to 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 role, but that’s the way it is. So there needs to be very strong value alignment between you and the company. You need to be able to defend those decisions because if you don’t believe them and you just lie, then it’s going to make you quite sad.
[00:23:44] I mean, if you have feelings.
00:23:50 — How to dispute bureaucracy
Ryan:
[00:23:50] Yeah, 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.
[00:24:17] 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. Curious if you have any tips on how to dispute these types of things successfully.
Laurent:
[00:24:33] 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.
[00:25:05] 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. I thought so. There has to be some set of criteria and 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 it’s not very effective to have big disagreements with a lot of people at the same time or with someone in front of a group that completely changes the dynamic.
[00:25:47] 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. And 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.
[00:26:11] People think that those rules had to be there because, like, there’s always a story behind it. And sometimes the story is really telling and really useful and once you hear the story, then you agree. And sometimes it’s just like a wrong precedent that was set a long time ago that’s no longer valid.
Ryan:
[00:26:29] 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.
Laurent:
[00:26:45] 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. I think it depends on 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.
[00:27:19] 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 outputs. 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 and there’s many other things that you can be doing, but it’s hard.
[00:27:55] 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 dislike that metric, even the people who suggested it, because we all know it’s a bad way to evaluate engineering output. 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.
[00:28:29] 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. 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.
[00:29:02] And that gives you a lot of lever to go look into. But why does it take them twice as long? How can you help them? And that reframed 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 at when they are doing code, which is much more objective. And 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.
[00:29:37] 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 very, very useful signal. Because maybe they work in a code base that’s horrible. Maybe they use a process that’s very inefficient.
00:29:54 — Airbnb culture
Ryan:
[00:29:54] 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, it was a.
Laurent:
[00:30:12] 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 like coming from a different trade, they add different ideas that were also very good. So like one thing that 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.
[00:30:49] And they said, you know, who is really good at solving those things? People who are like working in emergency situation firefighters, People who are dealing with like actual real disasters, who are going to hire people from that background who are 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 change the way we do the Internet measurement.
[00:31:14] That was genius because it brought a lot of rigor and interesting practices that then I took at every job I went after that. It’s something that’s very important to get right. And I think that mindset of thinking outside of the box, like, hey, who’s good at doing that Firefighter? Then that worked.
00:31:36 — Leaving Airbnb for Meta
Ryan:
[00:31:36] You left Airbnb for Meta. It was just a boomerang because you’d already been at Meta. I’m curious what made you want to leave Airbnb and go to meta.
Laurent:
[00:31:44] Well, so like I said, I joined in 2016, it was 20, 24 years in. So at that point you were getting four years grant when you work for like those tech companies. So that means I had a cliff of stock. And so at that point they started to like, my earning potential started to decrease. And that’s generally what happened at like four years unless you managed to score a lot of stock refreshers. So I think part of it was financially motivated.
[00:32:18] Another part was I thought because I worked on tested fry, I worked on compute, I worked on databases, I worked all around different industries, infra teams that I wanted to be an infra generalist. I was wrong. But I thought I wanted to be. And so I look for 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.
[00:32:55] And I kept getting paid 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. And I know it’s possible because Facebook solved a lot of those problems before. And when I see people work on the code Instagram, they don’t use all of those tools that they use on the Facebook side.
[00:33:19] And I know because I work there. And so I went and I pitched it, I went to my manager’s manager and 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 we can dramatically improve the reliability of Instagram.
[00:33:49] And then that’s why I became involved in that project.
Ryan:
[00:33:54] 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?
Laurent:
[00:34:03] So basically they, 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 it’s. She’s one of the most remarkable tech leads I’ve seen and work with in my career. She basically did that.
Ryan:
[00:34:26] I remember something interesting you told me before is you’ve wanted to be mentored by her and you made an explicit pitch to her actually I remember you were very. You had a lot of agency in actually going to her and, 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.
Laurent:
[00:34:50] 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 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.
[00:35:21] And so when I met Ariane, I noticed that, yes, 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 analyzing problem and trying to explain in what ways. I was thinking about the problem the wrong way, 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.
[00:35:47] I think that’s like, 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 are doing before.
00:35:56 — Uber TL at Stripe
Ryan:
[00:35:56] When you went to Stripe? I’m kind of curious, what were your first impressions as an engineer there?
Laurent:
[00:36:02] Everyone. I think that 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 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 hunches and intuition.
[00:36:42] Facebook also has that culture of 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 I love metrics. I love being able to measure success and how progress is made. So I felt right at home when I joined Stripe for that reason.
Ryan:
[00:37:08] You mentioned you were the TL of this dev infra team. And eventually the scope grew. It grew from 35 people to 140 people in this organization. And I kind of want to learn more about the story as it grew.
Laurent:
[00:37:22] So I joined as like the tech lead of build, test and tooling. So that was a group of team that were doing the build. So that’s like the build system bazel, 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 dev fraud I was like the most familiar with. And so initially I was like, I need to gain credibility.
[00:37:58] Why? Because it’s like those 35 engineers have been working here, like most of them, a long time, and I’m coming as an outsider. 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 team and a new tech lead joined 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.
[00:38:27] 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 belittled the people and their experience. You need to also not tell people what to do, because that’s not how you build trust in the team. Say, imagine you arrive and be like, oh, I’ve never seen this thing work at any company I worked at. So we’re going to cancel this project.
[00:38:55] That doesn’t work. So I was like, I have a role. My role 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 at Stripe, I never did that. So there’s a couple times when I told people what to do, which was in situation of urgency, when you’re 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, 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.
[00:39:39] 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 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.
[00:40:04] 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 group and I felt like I had a good grasp. And then I was like, but I know less than every individual person about their domain. And that’s what leadership is. Unfortunately, when you are in charge of a large group, you by nature know less than every person about their own domain.
[00:40:36] 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 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 going to work because I have a good hunch for how to solve developer productivity problem.
[00:41:07] I worked on that many, many years and just naturally I always think about how to do things better. So I will just ask good questions and that’s going to work out. And it did. After that, the model shifted a little bit. When the org was like about 40, 50 people, I shifted to a mode of operation where I would be deployed to go work on something for say two to eight weeks and then go. That would not necessarily be with a team.
[00:41:43] It could be with a group of team, could be with one or two individual. It could be with teams outside of Dev 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 bootstrap things, get things started, get things in motion, motivate, and then start the execution and then after that, making it sustainable so that it can operate with R2.
[00:42:14] And that’s something that’s very important for me is that 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. I want everything to be documented, automated in such way that sustainability is not a problem. I never want to be that guy who knows all the secrets about the code base.
[00:42:45] And then you’re supposed to ask, hey, how do you change this file? That’s not how it should be. And that’s one thing I learned as.
00:42:52 — How to scale yourself
Ryan:
[00:42:52] A manager on that topic of scaling yourself. 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.
Laurent:
[00:43:05] 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 70 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 have your contacts in all the different places to be able to gather information quickly. But imagine you’re in the leadership meeting and then someone asks you like, hey, what’s the progress on this project?
[00:43:36] It is possible that you’re not going to 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. 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.
[00:44:02] Because if you say something wrong in a lot of the culture for tech companies, it’s the end of your career. If you claim with confidence something that is wrong, you’re going to lose all the respect from your coworkers who are not going to be able to rely on your word moving forward. And it’s massive, massive problem realm. And so I’ve seen like, it’s not the case for all the industries. That’s interesting, right?
[00:44:26] It’s like, it’s the 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 meet with everyone every week. That’s absolutely impossible. So then I think you have to switch to a model. What worked for me was office hours. 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.
[00:44:55] 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:30am 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 really get to know them, motivate them and influence their work to have some FaceTime and to be able to communicate with them.
00:45:22 — What people get wrong in coaching
Ryan:
[00:45:22] 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?
Laurent:
[00:45:43] 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 work with some people, it may not work with everybody, and it’s going to give you surprisingly bad results.
[00:46:18] And I experienced that very early on in my career, which was, like, very helpful. 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.
[00:46:50] Were doing exactly like what. 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 we’re having those meetings every week when we’re reporting the progress of the people and be like, okay, we’re going to have to change the technique. And then the person leading that program, I think it was Scott Renfro. He took me aside and he said, hey, listen, maybe you should look into this thing called situational leadership.
[00:47:21] I’m like, okay, I’m going to 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 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 the mastery of learning the skill, but there’s also the motivation.
[00:47:48] And that’s very interesting because psychologically, if someone’s trying to learn a new skill, in general, they are quite excited, but with 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 not confident. And over time, both of those climb up and to the right. And so this divides the learning into four phases which are like those things, the situational leadership.
[00:48:23] 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 where am I on that skill that they are trying to do, where are they and what approach should I take.
[00:48:51] And so the idea is that 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 so that they can learn the rope and learn to do the different steps. As someone progresses, you have to switch to being more selling the idea, encouraging. Say, oh yeah, you’re going to be able to do it and help them with the difficult decision, maybe take the high level decision making, but letting them do the individual tasks and then as they progress, you have to empower them to be able to make those decisions themselves.
[00:49:28] You have to just switch to being supporting. And finally you have to be delegating. That means once they know how to do the thing, you have to know to stay out of the way. And, and I think this whole dance that happens for like every skill is very, very important to understand. Because if you don’t understand that and say if 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.
[00:49:58] So you’re only going to be able to catch the people who are in that window and be effective for them, everybody else, it’s gonna 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 if my mom calls me at 4am and she says my phone is reading notification aloud, what do I do?
[00:50:27] I’m not going to start to explain to her all the systems. I’m gonna 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 situational, right? It’s like it’s at 4am, she’s tired. It’s like a situation where you have to be directing. And if instead I’d be like, mom, you’re so good at the iPhone, you know, all the settings Good work.
[00:50:55] Keep trying to. Do you think she’s going to be able to be doing it? No, she’s not. She’s going to be pissed off 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. And. Yeah, so for every situation like this, you can apply that framework. And it’s very interesting because people make mistakes with coaching.
[00:51:19] They think that they know the way, they. They find the technique that works and they pick one of those four and they forget the rest.
Ryan:
[00:51:27] So, yeah, I’m curious, in the specific example with that one boot camper who was not succeeding, where were they in this and where’d you go wrong in the coaching and how’d you fix it?
Laurent:
[00:51:39] I went wrong in thinking that everybody who starts is in the first bucket, which is like high motivated, highly motivated, low skills. And where you will start to be directive and be like, okay, follow this page. Do all those steps to learn those tools. This person had spent a lot of time going and studying all those documentation and things like that, has already internalized a lot of the things and realized that he didn’t know that much and that he was at the point where the motivation was low, the knowledge was higher than the other people.
[00:52:15] But because I was coming and directing, it was interrupting their learning and they were unable to actually perform in that way. So when I was like, okay, what have you done? And then they explained that they’ve read all those things and I switched to being more supporting and actually giving way less advice about what to do than they started to perform. And that felt like magic. And I was like, what’s happening?
[00:52:41] It’s like, why? How Then 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 because like, you know, kids are always learning things and they’re always at different point in the learning skill.
00:52:58 — Why people get stuck at Senior eng
Ryan:
[00:52:58] 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.
Laurent:
[00:53:27] The senior to staff promotion, it’s about like a big, big mindset shift where you have to be completely independently picking problem Solving those problems end to end, explaining how you solve them, and then documenting 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.
[00:54:04] 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.
[00:54:26] 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?
Ryan:
[00:54:38] 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?
Laurent:
[00:54:45] The key is to be able to identify problems and to then be able to pitch and then solve them and to identify bigger problems than the one you currently know about. And the way you find out about problems, at least the way I do, is by channeling my inner frustration, which means I do something and I’m thinking, oh, looks like I had to type all those things on the keyboard and open this window and all.
[00:55:14] It’s like, it took me a while. I don’t want to do that again. I want to do better. And so that works really well for developer productivity. It’s like I can do anything 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 institutionalize for the culture is this idea of a friction log.
[00:55:44] You go through the flow of your product, whatever you’re working on, and you take pictures of the different steps and you describe what you’re doing and you analyze the friction every single steps 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 50 or 60 different things that could be done differently.
[00:56:19] 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. 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, where would I drop off?
[00:56:51] And then try to remove all of those frictions. And that helps you identify the biggest opportunities for impact. That’s how I see it. I think that’s a very effective way to do it. For example, imagine you go and you do business travel and you’re doing it 20 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 on the 20th travel, you’re just extremely effective at it.
[00:57:20] I guess it’s like the staff engineer mindset.
00:57:24 — Most career impacting book
Ryan:
[00:57:24] Is there a book that had the biggest impact on your career?
Laurent:
[00:57:28] 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.
[00:58:03] And she talks about how you build trust in those relationships and like how do you view the manager employee relationship in. 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 season managers are missing. So 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.
00:58:39 — Advice for younger self
Ryan:
[00:58:39] 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?
Laurent:
[00:58:49] 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. So 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 applied Nowadays in 2025, when you interview, you’re like recorded by a camera.
[00:59:19] 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 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. It’s hard to stay on top of everything.
[00:59:50] You’ve got to keep reading the tech news. I really recommend reading Hacker News. If you don’t, there’s a special version that you can rank over the last week. Which one are the most popular? That’s what I use. It’s hn. Algolia. dev I think it’s really effective. 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. It moves so fast.
[01:00:17] 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.
