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

Episode Date: January 19, 2026

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 - Intro00:00:44 - Joining Airbnb and transitioning to EM00:18:29 - Untold rules of calibrations00:23:50 - How to dispute bureaucracy00:29:54 - Airbnb culture00:31:36 - Leaving Airbnb for Meta00:35:56 - Uber TL at Stripe00:42:52 - How to scale yourself00:45:22 - What people get wrong in coaching00:52:58 - Why people get stuck at Senior eng00:57:24 - Most career impacting book00:58:39 - Advice for younger self01: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

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

The key is to be able to identify problems and to then be able to pitch and then solve them. I think when mistake people make consistently in their software engineering career is to not, 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? At the time, I'd been in the industry for a few years. I'd worked at Apple and meta and decided that my...

think 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 again? And so I did that at Facebook and we decided to move to San Francisco. And I had to continue doing my job while taking the bus an hour and a half each way. And so, like, I immediately started a job search. And I picked Airbnb for multiple reasons.

Like, I love the people I 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, like, developer productivity and what was remaining to do. 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 death fraud was starting to be multiple teams. And I think that was like very exciting moment to join. So I understand at Airbnb eventually you transitioned to management. I know you started as an IC working on that test infrastructure team. And I'm curious, why did you transition away from being an IC? 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 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 were 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 and so I started doing that as a tech lead as we grew the team test infrastructure 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 success with more time than what my manager could dedicate. So I went to him and I pitched it to him. I'm like, listen, there's all those people.

They need more support. I can do that. I can try. You can help me, like, be a manager. And he said yes. and it was very kind. 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 actually very unique. Like, when you become a manager of your peers, it presents some interesting challenges. If you were a peer to these people, would there not be some, I guess, power dynamic or some uncomfortable conversations

in making that transition? There were. and we're like very upfront about it. And I will always remember this one guy came to the first one-on-one. And he told me, I'm going to talk to you about a situation. And I want to know how you would react. 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 3 p.m. You've got to talk to them about it. It cannot happen again. What do you do? And so, like, immediately I was like, well, I'm going to ask you what you think about it

and about, like, what happened and the facts and try to understand, like, what actually happened. And he was like, okay, you passed. Because the way you failed this is by just saying, like, you're great. grounded. You did something wrong. You didn't show up to the interview because 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. What percent of managers do you think would fail that test?

when people approach management there is a type of people who think that it's one size fits all that they believe that there's like one strategy to be a manager like I'm going to be a tough manager or I'm going to be a 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 like micro-management, it will work if your whole team is new grad. But it's not going to work if your whole team are like experience engineer.

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 like solve every like coaching situation. You have to try different techniques. I remember you mentioned to me before that you were kind of bored at some point. And so I'm curious, like, after living through that transition, what was the experience like going from an IC to a manager in that regard? Yeah, I think I was bored at multiple times, multiple points in my career. Boredum 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 performance as possible to deliver that big project that I was leading as a tech lead. 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 like how, you know, like how we decide the level of someone that comes in. how do you do promotion, how do you do performance with 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.

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 there's like that report 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 like it would just like be without the hole. 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've 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 adding the highest team half score in the infrastructure group at Airbnb. I was like, how am I going to do that? I am going to just send a big form.

I did a Google form with all the things we do as a team. Like we meet for the stand-up on Tuesday at 9 a.m. Does that work for you? Is it useful? Would you prefer another form? What do you get all of them? it. And so I asked about every process that we have, every way that we work together. It was quite, 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. And so we're spending so much time doing that like very long stand-ups 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.

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 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. 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 works, 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. 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? They did. Like all the secrets I've learned help 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 conversation. So like all those skills then became extremely useful and I became like a lot better at it by being a manager. And then I fostered those skills and then that became

one of the main ways that I was able to contribute through leadership as an IC. One thing that's interesting in your transition to management is I think a lot of people, they do it very differently in that they ask their manager or maybe their manager asks them, but you actually pitched your manager.

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 transition to management. In general, I think one mistake people make consistently in their software engineering career is to not be aligned with their manager on what they want.

They are afraid of saying, like, hey, I want to get promoted next year or I want to be an expert of this technology. A lot of people just go through their career quite passively and then at the end of the year, they just write down what they've done and then present it to the manager and then hope that they're going to get what they want.

And I think that's sad because life is very short. And I think it should be an ongoing conversation and that makes it much easier for the employee and for the manager, which is why I set up a very interesting metric when I was a manager. I called 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? Are you going to get promoted? And roughly like 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. 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 try to drive it to, like, 100%. It never was exactly 100%, but it came pretty close. I could see the value in that because I think a lot of people, obviously, the negative surprises are bad. But also the positive surprises can be bad as well. 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 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. Because if they are good and they don't know, it's like that's something that's coachable. After transitioning to and from management,

I'm kind of curious your thoughts on advising other people on when they should move into management and what the pros and cons are. What are your thoughts on that for ICs? 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, start with an intern. See how it goes. Because it's actually an interesting experience in managing 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 down 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, I see. And it's also only one person that you manage, which gives a huge sampling bias. And so you see management through the land. 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 comes in with their intern thinking, because they've really tried to direct them and coach them, and thinking they are doing so well

because they want their intern to succeed. And everybody who goes to the meeting tends to say, like, oh, my intern exceeds expectation, 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. If that was the right thing to do, that was the right thing to do. So I love that experience of, like,

being an intern manager. So at Airbnb, I ran some of the calibrations for interns with, like, all the intern managers to try to make it less, scary to reduce that bias. You mentioned a little bit about your promotion to becoming a frontline manager going from M0 to M1. 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. I think most of the time I was surprised. And that's not a good side. Because when that happened and then like you're surprised about like something happening, that means you're like you don't have a good read of the situation.

That's a sign that you need to understand the situation better and you need to work on understanding how the system works, what's being valued at a company versus another one. I'm trying to think. I was never surprised by like a promo, but I was surprised by like some ratings sometimes. 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.

So five for a lot of companies. 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 meets, 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 at I stayed as an IC, I would probably have gotten like the promotion to staff. But instead, I was like, okay, well, I'm just going to make it work.

As an M0, I'm going to try to get to M1 as quickly as possible. That is the next challenge, and that's what I'm going to be doing. Ultimately, all of this happened probably because I was not having those conversations with my manager as explicitly as I should have been about my career progression. I should have said what 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. Did that reset your progress on your career progression?

Because you were right about to get promoted. Every company does this differently and does those like untold rules about calibration. Say like, say if someone transitioned a role and they've been there less than two and a half months in the new role, it's automatic meets. Or a new grad cannot get promoted in less than X months because we never had one that we did that. So there are all of those untold rules of calibration. What's interesting about those roles is that they are developed locally. So you have like rules in like specific teams, specific organization. And over time, the organizations mature and like those rules 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 were 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 I sees 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 were 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 what's difficult because as a manager, you represent the interest of the company. You have to put the company first before your report. That's like an untold rule. 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 lied, then it's going to like make you quite sad. I mean, If you have feelings. Yeah. That's something I definitely remember was extraordinary about working with you, is your willingness to dispute the status quo. And I feel like when people don't do that, that's kind of how bureaucracy kind of sets in. There's all these rules and things that people are following that they don't necessarily believe.

I'm kind of curious, like you said you were often successful in disputing. these rules. And I think a lot of people, maybe your frontline manager or an IC, you don't feel agency in the ability to change those rules or maybe it's too much energy. I'm curious if you have any tips on how to dispute these types of things successfully. I think it comes from my interest in psychology and like the study of the different 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 would have about. this process is like, oh, it's unfair. 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 disagreement with like a lot of people at the same time or with someone in front of a group that completely changes the dynamic. It's much, much easier to start having those conversations one-on-one.

Because otherwise, people just get very defensive because they think their reputation is at stake in front of the group, and they're going to get like, so... And that's normal. 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 do people think that those rules had to be there.

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, then you agree. And sometimes it's just like a wrong precedent that was set a long time ago that's no longer valid. What would you say in the example? Let's say you're in your your org and then a VP, someone five levels up says, we're going to start counting the code changes that people submit and they have to have a minimum

or else they get docked in calibrations. It depends what it means to be docked in calibration, but like say if someone, if I worked at a company and someone hire up says like, oh, we will automatically fire the people who do like less than, like the 10% list coding contribution. I think it depends on like what the company

and what it values. It may be a useful metric. In general, it's not because people contribute in many different ways. ways and counting the line of code or number of PR is a very poor metric. So actually, I was in that situation, not as dramatic as what you described, but like when I was at Stripe, I was the tech lead for developer productivity. And we kept wanting to have a measure of the output.

Like, how productive are people? It's like, how do you know if an engineer is productive? So you can ask them, it's like, are you? 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. And so that's what I said to do. Like 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. Like pretty much everybody disliked that metric. Even the people who suggested it. because we all know it's a bad way to evaluate engineering. So instead, what I've done is I looked at the journey of when you make a change, when you go from your branch to merging your change, there's a whole journey. How long does it take?

What do you do in those phases? So first you're thinking, then you're writing your code, then you are sending the code to CI, code review, going back and for a thing 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 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

reframe the question about like 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 like, how fast are they at like when they are like doing code, which is much more objective. And 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 very, very useful signal. Because like maybe they work in a code base. That's horrible. Maybe they use like a process that's very inefficient. Before we leave your experience at Airbnb,

I'm kind of curious if anything struck you about Airbnb's engineering culture. I know prior to that you had experience at Meta and Apple. So what would be? was kind of notable when you got to Airbnb. It was a company that it still is led by designers. So it was harder to explain why the low-level infrastructure things about the code really matter. It also has some upsides because I think that by virtue of like coming from a different trade, they had different ideas.

that were also very good. So, like, one thing that they've done at AirbnbVs that I thought was, like, really amazing is we were having a lot of incidents, a lot of reliability problems. And they said, you know who is really good at solving those things? People were, like, working in emergency situations,

firefighters. People were dealing with, like, actual real disasters. So we're going to hire people from that background. We're, like, super good at, like, the crisis management. and we're going to say, now you're in charge of this thing. And you're going to, like, change the way we do the internet measurement. That was genius because it's like it brought a lot of rigor and interesting practices that then I took at every job I went after that.

It's like it's something that's very important to get right. And I think that that mindset of thinking outside of the box like, hey, we's good at doing that, firefighter. Then that worked. you left Airbnb for META. It was just a boomerang because you had already been at META. I'm curious, what made you want to leave Airbnb and go to META? Well, like I said, I joined in 2016.

It was 2020, four 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, I started to like, by earning potential. started to decrease. And that's generally what happened at like four years, unless you managed to like score a lot of like stock refreshers. So I think part of it was like financially motivated.

Another part was I thought because I worked on tested fraud, 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 look for it for a 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 page 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 reliant. 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 at Instagram, they don't use all of those tools that they use on the Facebook side. And I know because I weren't there.

And so I went and I pitched it. 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 we can dramatically improve the reliability of Instagram. And then that's why I became involved in that project. 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? So basically they paired me with an IC was working on the Facebook side. Her name is Arienne. And she was exceptional at getting disbying on the Facebook side, bringing the right people to the conversation. And she's one of the most remarkable tech lead I've seen and work with in my career. She basically did that.

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 and actually going to her and setting it up. And I'm curious if you could tell that story and what you might recommend for others who want to set up mentorships. 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 make me change my mind on topic

and I would relate to them. And so they don't have to be engineers. 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 Arya and I noticed that like, 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 like analyzing problem 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 a measure for success. It's like, are you able to change your mind as a result of coaching or you just do the same

thing you are doing before? When you went to Stripe, I'm kind of curious. what were your first impressions as engineer there? Everyone, I think that this, 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 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, 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 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.

You mentioned you were at the TL of this dev infra team. And eventually the Scrope 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. 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 let's like the build system, Basel, 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 death fraud that was like the most familiar with. And so initially I was like, I need to gain credibility. Why? Because there's like those 35 engineers, they've 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 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's like belittle the people and like their experience. You need to also not tell people what to do because that's not how you build trust in the team. Like say, imagine you're right 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. 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 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. 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 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. 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. Like, unfortunately, like, when you are, like, say, in charge 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 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, like, 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 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 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 individuals. it could be with 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. I want everything to be like documented, automated

in such way that like sustainability is not a product. I never want to be that guy who knows all the secrets about like the code base and the, 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. 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? 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 17 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 a leadership meeting and then someone asked you like,

hey, what's the progress on this project? 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.

Because if you say something wrong, 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 be. to lose all the respects from your coworkers who 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 moment. 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. And what else works for me? I work with people in Europe. So I shifted my work here. I started my work at like 5.30 a.m. 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. 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? 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. And I experienced that very early on in my career, which was like very helpful. 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 boot camp 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. We're 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 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. 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 who I was in Charlottoff. 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 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 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 approaching. You have to have that internal assessment of like, where am I on that skill that they are trying to do? Where are they? And what approach should I take? And so the idea is that like if someone is 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. 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 going to be able to do it.

And help them with like 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 there's this whole dance that happens for like every skill.

It 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. 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 after doing it for so many years, it becomes natural and you don't even think about it.

And it's like obvious that's like if my mom calls me at 4 a.m. And she says, my phone is reading notification aloud. What do I do? 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 at 4 a.m. 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. And it's, yeah. So like for every situation like this, you can apply that framework. And it's very interesting because like people who 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. 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?

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're like, you would start to be like directive and be like, okay, follow this page, do all those steps to learn those tools. This person had spent a lot of, 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 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. So like 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 like more supporting and 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 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. I remember when we were working together, you actually coached me out of getting stuck as an IC5 or 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. The senior to staff promotion, it's about like a big, a big mindset shift where you have to be completely independently picking problem, solving those problems and 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. It takes, and like when you're a senior staff,

you're just doing the same thing, but with programs 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 you're not autonomous on the whole cycle of the problem discovery, choosing what you get to work on. I think that's really what's the distinction. What would your advice be to someone who's been stuck as a senior engineer for a long time? They're trying to make that jump to staff.

The key is to be able to identify problems and to then be able to pitch and then solve them and to identify bigger problems 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. 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 pro quibTs.

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 manage to 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 you describe like 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. And then after that you identify like the families of problems, we rank them and then you go and solve. of 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? Like 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 how I see it. I think that's like a very effective way to do it. Like for example, imagine you go and you do business travel and you're doing it like 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 like on the 20th travel, you're just like extremely effective at it.

I guess it's like the staff engineer mindset. Is there a book that had the biggest impact on your career? When I started being a manager, I had to have all those conversation 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 how to be a good manager. And she talks about how you build trust in those relationships and like how do you view the manager-employee relationship? And she has a lot of very good point that I have not seen mention in all the 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. 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? 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 applied. 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 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. 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 is HN.orglia.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. 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. Awesome. Well, thank you for your time, Lauren. I really appreciate it. I'll put all the links in the show notes, the stuff that you said. 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