New Grad to Principal Engineer (IC8) at Meta (Career Story)

Adrien Friggeri went from a new grad to a principal engineer (IC8) at Meta. He is the original TL who started Bento if you’re familiar with that infra at the company. He got to where he was through a series of promotions across different teams and projects. I interviewed him about everything he learned along the way 𝗣𝗼𝗱𝗰𝗮𝘀𝘁 𝗹𝗶𝗻𝗸𝘀: • Transcript: https://www.developing.dev/p/new-grad-to-principal-engineer-ic8 • YouTube: https://youtu.be/2Sjzd9pt6Ts • Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: 00:00 - Intro 00:43 - First team at FB 07:24 - Senior promo /w IG 16:30 - Story behind Bento (Senior staff promo) 25:33 - Taking on perf risk to start the project 29:03 - Learnings from leaving big tech 32:46 - Joining Clubhouse 35:08 - Return to Meta (again) 40:51 - Principal promo (IC8) and tips 51:37 - Maximizing your luck /w people 54:26 - Advice for younger self 55:42 - Outro 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗔𝗱𝗿𝗶𝗲𝗻: • LinkedIn: https://www.linkedin.com/in/friggeri/ • Instagram: https://www.instagram.com/adrien/ • Personal Website: https://friggeri.net/ 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman

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

• 0:00Speaker 00

  Software engineers have power at this company.

• 0:03Ryan Peterman?

  This is Adrian. He grew from a new grad to a principal engineer at Meta and shared the story of how his career grew.

• 0:10Speaker 00

  The first thing I did was like, hey, manager, I'm not going to do what my job is and what the team is doing because I think there's an opportunity there.

• 0:18Ryan Peterman?

  What's your biggest learning from the principal engineer promotion?

• 0:21Speaker 00

  You need to have like the impact in the underlying work, but then it is also way easier to like build the consensus ahead of time.

• 0:28Ryan Peterman?

  The advice he gave could help any tech career. How do you maximize your luck when it comes to people opportunity?

• 0:34Speaker 00

  Oh, so many thoughts. The first one is, you know, like I-

• 0:38Ryan Peterman?

  Here's his full career story.

• 0:43Ryan Peterman?

  Can you tell me a little bit about the first team that you joined and why you picked it?

• 0:47Speaker 00

  So I was actually pre-allocated. I joined what was then called the data science team, which you and I have talked about a little, is a little confusing because what we call data scientists nowadays is very different from what was data science then. In early 2011, 12, there was this emergence of big data and, you know, mainly at LinkedIn and Facebook, teams of statisticians and computer scientists and early machine learning researchers leveraging a lot of data to build better products. So that was like the very early days of doing A/B testing and doing A/B testing at scale, doing measurement and proper measurement

• 1:30Speaker 00

  of things. And so that was that team. I was pre-allocated to that team because, you know, I had a PhD. I was working on social network analysis. So I was joining this like small team of like 20 or so people. For the people who know the Facebook stack, you know, that team had been behind like the whole A/B testing platform for the company, had been behind a lot of like all of the data pipelines that are being used to measure and count everything. We would often joke that, you know, at the end of the day, we were just doing big counting. And so I was pre-allocated to the data science team.

• 2:05Ryan Peterman?

  Did you see yourself more as a data scientist at the time or a software engineer?

• 2:10Speaker 00

  You know, it's very funny. I have this very distinct memory of a conversation, my first one-on-one I had with my manager Cameron Marlowe, who was managing the data science team at the time. We were standing in line about to have lunch and I was kind of, I don't know, I was kind of a little pretentious. I was like, you know, I have a PhD. I'm not like, I'm not a software engineer. And he was like, hey, software engineers have power at this company. You are a software engineer. Don't pigeonhole yourself into like a category or an area that is not like the most important job at the company. You are a software engineer. Software engineers create the products, obviously in partnership with PMs and designers and all of that.

• 2:53Speaker 00

  But software engineering carries a lot of weight. And yeah, since then, like I've always considered myself a software engineer, like that is my primary job. My title has always been software engineer, or you know, my official workday title. I think I was like a research scientist for a while in like the outwardly displayed things. I was a data scientist for a while, but no, always a software engineer. And then like I mentioned to you, around 2014 or so, the role of product analytics got renamed to data scientists across the company. So all of a sudden, we moved from having, you know, 20 data scientists or 30 data scientists, all with PhDs doing data analysis, doing software engineering and stats,

• 3:36Speaker 00

  to having, you know, 500 or so data scientists doing mostly product analytics, which was kind of like a crisis in identity in the team I was on at the time. But, you know, we moved on. Like at the end of the day, the title was not the important part. The important part was the impact of the work we were doing.

• 3:53Ryan Peterman?

  Can you explain the difference between the product analytics and the old data science function? I'm curious, what are things that an old data scientist would do that a data scientist today would not be expected to do?

• 4:07Speaker 00

  Well, one, that was like when we were building, you know, Deltoide and like all of those A/B testing tools. Nowadays, data scientists were like, are mostly users of those tools. They're not the one who have like, define the algorithm, or the sampling strategy, or the double boost strap, or the, sorry, the bootstrapping that you're using to like, compare test groups and whatnot. So it was a lot of like, you know, people like Dean Echols and Aitun Bakshi, like really amazing statisticians who were like building those tools that are now powering the company. So there were the tool builders more than the tool users.

• 4:44Ryan Peterman?

  And those tools allowed the data science function to scale, that people without that deep statistical understanding could go into a tool and understand data much more easily than someone in the past.

• 5:00Speaker 00

  Yeah, there was just another example of the stuff we did at the time. I worked on how rumors spread on social network. That was like my very first project at the company. I worked with amazing researchers, Lada Domich, like she was eventually my manager and a director of data science at the company. But her background was like as an academic doing research on social networks. So with her and Alex Dow and a few others, we spent the first six months I was at the company analyzing how rumors spread on social network. Now, by rumors, I really want to be specific here, like I'm not talking about fake news, which is slightly different flavor. I'm talking about rumors, mostly memes, and you know, the type of stuff that end up on,

• 5:45Speaker 00

  say, Snopes. And the stuff we were looking at was the shape of those cascades, how do they spread? Do they tend to like, you know, spread mostly in long chains? Do they tend to fat out? And it's really dependent on a few things. And they were like fascinating results we found. We found that like, false rumors have a tendency to spread faster than true rumors. And even if you point out that a rumor is false, that doesn't really limit its spread. So that was the type of work we were doing. And like I spent about six, eight months doing that, published maybe two or three papers. I think the impact we had on the company was affecting the weight of reshares in newsfeed.

• 6:28Speaker 00

  We were like, hey, if we continue doing like too many reshares, we're going to lose organic content. But that was the impact. So you know, my manager at the time was like, you know, you wrote three papers, helped tweak newsfeed, meets all, go figure out something impactful for the company.

• 6:44Ryan Peterman?

  It's super interesting, the false rumors spreading faster than true ones. And I mean, it matches intuition. If something's wrong, people are more likely to then reshare because they say this is wrong, which then some percentage of people who agree with it will share it because it's right. Another polarizing set of people will share it again and say this is wrong.

• 7:07Speaker 00

  I think it's more that false rumors tend to be more egregious. And because they're more egregious, they are inherently more shareable or more viral. Like true things tend to be more boring than false things on average.

• 7:24Ryan Peterman?

  I want to go into your, your first promotion story, kind of getting to the senior engineering level. Can you talk about the story behind doing that at Instagram?

• 7:34Speaker 00

  Yeah. So, you know, after like this rumor work, I was very lucky to just meet Mike Krieger, who was, you know, co-founder and CTO at Instagram. Instagram had been acquired in September of 2012. It was a very small team at the time. I started talking to them in like early 2013 ish. And the team was still relatively small, like the core Instagram team at the time was probably 30 people. And then there were like a lot of like Facebook people around helping on the safety side. There were a few people starting to help on the data side. Just to give an idea of like the maturity at the time, this is when the very first data pipelines to count how many users on Instagram were created.

• 8:17Speaker 00

  And I was like, hey, this is like a cool product. So you know, this little photo social network that we've acquired. They don't really do anything with data. There's no personalization. There's an opportunity to do something cool here. And so the first thing I started helping with was the explore tab. The explore tab, you know, circa 2012, 2013 was basically the most popular content on Instagram. And with a few others, we decided to add a little bit of personalization to that and surface, you know, popular content from your friend, content you might be interested in. And so we did that. We started building, you know, like a bunch of like different sources. And then there was this question of like, well, how do we know if it's good or not?

• 9:00Speaker 00

  Now, obviously, it's probably going to be better than only having popular content on the platform. But there was a desire to like, understand the impact of what we're doing. And similarly, I was also like helping out with some people looking at growth and user acquisition. And you're like, can we plug into Facebook and like deep link you into Instagram? Or like promote Instagram within Facebook? How do we measure conversions here? Instagram didn't have any A B testing system. So, you know, as an old IC4, I was like, you know what? I think Instagram needs A B testing. So I talked to like a few P M's and I talked to Krieger and Kevin Systrom. And everyone was like, hey, you know, we have like bigger fish to fry right now. Instagram was in the midst of what we're calling Instagramration,

• 9:44Speaker 00

  which was migrating Instagram from A W S where it was running to the Facebook infra, for cost and all of that. And so they were like, yeah, you know, like your little A B testing ideas. Good, we'll come to that later, but like we have like really important things we need to do now. So please don't bug us. And I was like, I don't know. Let me try and see if I can build that. And so I roped a PM Jeff Cantor to get air cover on what I was doing. And I just kind of hacked something together. Now, Facebook had an A B testing system. So I was like, I want to reuse this as much as possible. But like I said, Instagram was running in a different infrastructure. So how can you plug those things and connect them together?

• 10:28Speaker 00

  I did the dumbest hackiest, probably very expensive thing I could do, which was add a custom Facebook API endpoint that was allowed listed on the Instagram app ID, which was essentially log those things. And so that way you could like log all exposures over the internet, sending that from AWS, using the Facebook API. Now you're logging your exposures. So that's like half of the problem is solved. The other half is like, how do you hash users into the right groups? There's like, you know, 50, 100 lines of code. So replicated that on the Instagram side. And at that point, I just had a system to hash users into buckets,

• 11:09Speaker 00

  log exposures, and we already had some like data in our data warehouse. So I could connect that to the backend delta of our A B testing system. So I had all the different pieces. So at that point, I was like, okay, I can kind of like run some like web experiments. Unfortunately, we don't have a website or it was like very early days of the Instagram website. So I think the first thing I did was like a server side A A test to prove that it worked. And then I found like a mobile engineer who was willing to, you know, help me with like the iOS code and with the Android code. And then we started running like one, two small experiments, like very small things, just to prove that like the system worked and that it was scaling. And it did.

• 11:53Speaker 00

  So that's the story of like how. We brought A B testing to Instagram. Now, obviously, after Instagram, all that, everything has been, like, probably written four or five times since then. But that was the story behind my promotion. I built that thing. By the way, I had no idea that promotions existed at that point. You know, I was like a little IC4 who was completely naive, was just working on things because I was excited about them. I didn't pick that because I thought it would be successful. I picked that because I needed it for this other thing I wanted to build. You know, come PSC season at the end of the year, my manager was like, congratulations, we're promoting you to IC5. I'm like, what does that even mean? What is an IC5?

• 12:33Speaker 00

  Yeah, and then I transitioned that A B testing system to this newly created data gram team, which went on to own and maintain that.

• 12:43Ryan Peterman?

  Interesting. I can already tell in your early career story, there are examples of unusual agency and chasing things down. I mean, it sounds like no one told you to build this. And you have a few examples in that story of you went up to random people, like the CTO Instagram, you went up to a mobile engineer, you said, hey, can you, you want to join in on this initiative? It sounds like that's pretty standout that you had that behavior so early in your career.

• 13:14Speaker 00

  I never really thought about that this way. It was just, I think the early days of Facebook were very, very bottoms up. Everyone kind of operated like that, or at least that's how I understood the world. Right? You need to do something and you can't do it yourself, so you try and find someone to help you with it. You know, the early days of Facebook, I mean, obviously, we still have hackathons nowadays, but there was such a big hackathon culture. In the first six months, I think, I probably did six hackathons once a month, every, like, on a Thursday evening, you would spend the entire night in the office with other people hacking on something that was not related to your day job. And that, to me, was the culture of Facebook.

• 13:57Speaker 00

  And so naturally, when it came to my day job, it's like, of course, I'm going to hack on something. Of course, I'm going to try and figure out how do I achieve the thing I want to achieve.

• 14:05Ryan Peterman?

  Were there cultural differences between the early Instagram team and Facebook at the time?

• 14:10Speaker 00

  So I never officially joined the Instagram team. So on the data science team. We were kind of operating as consultants, helping different teams around the company. And so, you know, we would do like six month, two year stints embedded in a team. But my reporting chain never changed. I was very lucky to have few managers. I know that like a lot of folks have changed managers like every six months. I think in my first two, three years at the company, I had two managers, despite working on very different teams. Not joining Instagram, by the way, officially is probably one of the biggest mistake I've made in my career. Not to say I have any regrets.

• 14:51Speaker 00

  This is more the flavor of like, I didn't buy a bunch of Bitcoin in 2013 type of regret. But I think my career would have been very different if I had decided to join instead of like move on to something else. In terms of culture, Instagram was, it really felt like a very small startup within a startup. You know, Facebook was like 2,000 ish employees. Instagram, like the whole core team, everyone working on Instagram. We all fit in one big conference room. It was like 30, 40 people. And there was such a big focus on design and craft over data. That was very different. But other than that, it was to me like that same like energy of like just creating stuff.

• 15:33Ryan Peterman?

  When you say it was the biggest mistake that you've ever made in your career, what do you mean by that? And where do you think your career would have been if you joined Instagram?

• 15:43Speaker 00

  That is really hard to tell. I think my career growth would have been accelerated. I might have like reached certain levels faster if I had joined that team at the time. You know, if I look at the folks who were working with me in that space at that time, they went on to have really fantastic careers and, you know, hitting like IC sevens, IC eights, IC nines, IC tens, way sooner than I have or probably ever will. Like I said, it's really hard to know where the counterfactual is. And I'm also very happy with where I'm at in my career. It's just, this is like a road not taken.

• 16:21Ryan Peterman?

  You know, after that, I understand that you built some frameworks and you worked on some additional tooling that was highly leveraged at the company. Can you talk about the story behind your IC7 or senior staff promo?

• 16:35Speaker 00

  So like I said, you know, I was kind of like playing around like all those different projects, bringing data to like non-data teams. And I had my hits and then in other cases, it didn't really pan out. So I got roped into this project to count the number of people using one of Facebook's property. I'm not going to spend a lot of time talking about it, but in the process of doing that, that was around 2015 or so, we had to do a bunch of data processing. We had to do a bunch of machine learning and inference. And the tools we had were just icky. They didn't really work well. Like the developer experience was horrible. We would have to like, you know, work within like one data pipelining framework and then move to like another thing to do the machine learning and the inference and then go back and forth.

• 17:20Speaker 00

  And I was like, this is, this is not fun. I'm like wasting so much time just going back and forth. And so I started building this little library that essentially let you do data pipelining within the machine learning orchestration framework. And at first, that was just like me writing a bunch of helper scripts for myself because I didn't want to have to go back and forth. I didn't want to have to like deal with landing code in two different code bases and like synchronizing all of that. I was like, I want my code to live in one thing, do all of my thing in this code base, and then I'll be happy. But in the process of doing that, I just started tinkering a little. And I was like, why is that whenever I need to write a data pipeline, I have to like write the same boilerplate over and over again? It's always the same thing.

• 18:03Speaker 00

  Why can't I set those things to be the defaults? And so, you know, I kind of like whittled away a lot of the boilerplate that you had to write. And so I put together this library where if you were building a data pipeline in the machine learning orchestration framework, if you learn airflow, what would take you, say, 300 lines of code in like the canonical data pipelining system would probably take you 20 lines of code. You had this escape hatch to like add all the configuration, but by default it did the right thing. And at that point, I was hooked. I was like, I am building a thing that can make people's lives easier. Forget about this like counting number of people on Facebook. Other people are going to figure that out. I want to help those people move faster. And so then I started looking at like other things where people were wasting time.

• 18:48Speaker 00

  And at the time, if you were a data scientist, like as a product analyst, if you were a machine learning engineer, the way you worked was by building or setting up your own tools. Half of the company was using Jupiter for notebooks. The other half of the company was using R Studio, which uses this like statistical programming language R. And the way you would set that up is you would look at one of like 10 different wikis that were all outdated and you would have to like set that up either on a desk server or on your machine, a lot of manual steps. And I was like, that's kind of silly. We should just make it so everyone has a Jupiter instance running if they want, and they don't have to configure it. And so I just kind of like started building that.

• 19:33Speaker 00

  I remember telling my manager, you know, it was probably February. And I was like, hey, this is the beginning of the half. I'm going to take two, three months to just hack on this. And if it doesn't pan out come, you know, April, I'll just find another project to like save the half and like, you know, not get it the most. And so I started hacking on this, roped in a couple more people. And we built what eventually became the very first version of Bento, which is the noble platform based on Jupiter that's used all across the company. And at first, Bento was really, really dumb. It was just a script that would set up Jupiter for you. But we had this vision behind it. What if instead of just being this like external tool that you have to set up that doesn't communicate with anything at the company?

• 20:17Speaker 00

  We integrated that better within the rest of the tooling. What if you could just open a browser, type Bento, and now you have a notebook that's running? And you already have the libraries that are built within the company that you can reuse instead of having to like figure out how to do that manually. What if you could have like other programming languages? Eventually, you know, people will start hacking, hack into that. And so over the course of about a year or so, we started like putting this system together. A big thing that I worked on it after that was building Bento on demand, where instead of having a desk server where we would set up The system for you, you could just request an on-demand instance.

• 21:01Speaker 00

  You could work on that and then release it. Because we're doing that for like development environment. And we're like, yeah, that makes a lot of sense. You don't have to maintain a dev server. And so in the process of doing that, I, you know, I helped lead the development of the platform. But more importantly, I put the team together. I transitioned into a tech lead manager role, started building a team. And the way I built the team was hiring people who were very excited about the tooling world. Actually, I just hired a bunch of people who were already building tooling on the side. And there's a pair of time, I was like, hey, do you want this to be your full-time job? Sounds like you like to do this thing. It's super impactful. Do you want to do this full-time? And so, you know, I brought in like a bunch of like amazing people.

• 21:44Speaker 00

  So good team, like six, seven, eight people. And so I got promoted to TLM2, mostly on my IC work and the vision I had for Bento.

• 21:56Ryan Peterman?

  And TLM2, for people who are outside the company, is equivalent to senior manager, which is equivalent to senior staff engineer in the industry. And when you hear these great stories of new infrastructure or tooling that everyone takes for granted today, what I want to know is what is the step-by-step process on how you actually get the tooling from an idea to something that everyone is using?

• 22:20Speaker 00

  So for Bento, the notebook platform, the answer is we didn't really try to get adoption within people's existing workflows. What I did was twofold. One, we targeted Bootcamp and DataCamp. So Bootcamp and DataCamp for non-Facebookers is where you, the thing you go through when you onboard at the company. And we just went to DataCamp and we told everyone who was working with data, this is the way you set up your developer environment. You just use this thing. Or you can also just like go do it manually if you want. But you can also just like type this one word and you have your developer environment. The company was growing like crazy at the time, right?

• 23:05Speaker 00

  And so when you have this like amount of insane growth and, you know, the company is going to say like double in size within like a year or two, you get your growth from like all of those newcomers who don't know the legacy systems. And then you get the stragglers because everyone else around them then use the new system. So that was like a lot of the growth strategy behind Bento. The other thing we did with Bento was provide support and maintenance for the legacy systems. And so, you know, we built trust with users that way. So if you were installing Jupiter by yourself, you could go to that group that was unmonitored before us and we're providing help and we're providing support. And then over time, you know, after building that trust, we started

• 23:50Speaker 00

  encouraging people and be like, yeah, you know, this like thing you want to do, I can give you a recipe that's going to take 25 steps to do that. Or we've actually built that in Bento. It doesn't really change your workflow. It'll just make your life easier. You'll move to that. So to summarize, you know, step one, find an easy way of getting a bunch of users because network effects work. Step two, for the people who are on the legacy systems, just provide value to them.

• 24:17Ryan Peterman?

  That's super interesting because when I think of these developer offerings, I just always assume that you're going to have to influence a group of people that is using something today to switch off of something. In this particular case, in a growing company, there's this whole new user base. It's like all these people coming in, they're deciding from a fresh slate. And it sounds like your offering was a superior product in a sense. So it was a pretty easy sell.

• 24:45Speaker 00

  And then the other thing we did too was go to, you know, Alex Schultz, who's now the CMO of the company, but I was head of analytics at the time and Brady Lauback. And we just told them, hey, we know that there's a lot of pain within your teams. We want to help. We think that this is the first step. And, you know, I remember Brady saying, yeah, this is, this is a good first step. There's like, those like 20 other things you need to go fix. I was like, okay, let's take it one step at a time. And let's, let's start talking more. There was no team at the time really building tools for data science and machine learning. And so this is when I actually ended up leaving the core data science team.

• 25:26Speaker 00

  And I reorged myself into the DevInfor organization to start that team really focused on data developer tools.

• 25:33Ryan Peterman?

  At the beginning of this story, you mentioned you took on some performance system risk. You literally told your manager, hey, I'm going to take on and build something that has a lot of potential, but also it might flop entirely. And then we can scramble to figure out performance so that, you know, you don't get a below meets all rating. I'm curious, because at that time, the industry was not as intense when it comes to churning out short-term results. Do you think that trying to do something like that today would be more difficult? And do you have any advice on more generally, how to take on risk to pursue these higher rewards?

• 26:13Speaker 00

  I think the consequences of underperforming now are more drastic than they were 10 years ago, for sure. I think the strategies when you want to take risk is the same. Make sure you're on the same page with your hierarchy and your manager. At the end of the day, like, you know, we are all evaluated based on our expectations. If you're not aligned on what is expected of you with your manager, then that is a problem. Now, you know, I was on a team whose job was to provide help with data, as data consultant in a way, right? Now, the thing I was building was tooling and infrastructure, not at all data consulting. So the first thing I did was like, hey, manager, I'm not going to do what my job is and what

• 26:57Speaker 00

  the team is doing, because I think there's an opportunity there. Are you okay with me doing this? Can we make it so, you know, we carve out two, three months for me to go explore that and make that part of my expectation? If it pans out, great. If it doesn't pan out, well, I was expected to go explore this. It was a calculated risk. We all agreed as a team, my manager, my skip, myself, that like, that was a thing I was going to do. And at that point, you know, there's an agreement. This is the job you're going to do. Everyone is on the same page. I think it is a lot riskier to go and do your own thing. You know, you, you lock yourself in a room, do your thing for three months, show up and you're like, I did this thing.

• 27:39Speaker 00

  And then everyone's like, yeah, but no one knew that you were doing this thing. Over communicate, I think, is really the strategy I would recommend. And also be ready to hear no. Like, I was very lucky to have a manager that said, yeah, you know, I think that makes, it's risky, but it makes sense. Go do that. I've had, you know, instances later on in my career where I wanted to go do a thing and I tried building that consensus and what I still was, no, don't do that.

• 28:05Ryan Peterman?

  You mentioned that you transitioned to a TLM during this leg of your career as well. What was the thinking behind that transition?

• 28:12Speaker 00

  I was building the team, right? You know, we were building this product. I knew we had to scale and we needed more people. And so then the question was like, do I go hire someone to manage me and the rest of the team? Someone who might come in with like a different vision for the team or a different strategy? Or do I try this management thing? And so to me, it was really driven by a desire to like, just, you know, take this little crew we had assembled and like lead them or support them in building this product we wanted to build. So it was kind of like a natural like evolution. It was not really a thought out, I want to be a manager. I'm going to transition into management and find a role like that.

• 28:55Speaker 00

  It was just, I was tech leading that team. We needed more people. The team needed a manager. I ended up being the manager.

• 29:03Ryan Peterman?

  So after you got this IC7 promotion, I understand that you left Meta with desire to start your own company?

• 29:11Speaker 00

  Yes.

• 29:11Ryan Peterman?

  What was the thinking there and the story behind you leaving? How did that go?

• 29:16Speaker 00

  At that point, I had been at the company for about seven years. That was the only company I had ever worked at. You know, my professional experience before that was, like I said, doing a PhD, working in my own corner, seven years of Facebook and growing tremendously, learning a lot, but also not really knowing what happened in the outside world. And then I think there was also maybe a little bit of hubris. I was like, I built this like platform that's being used by, at that point, sixty percent of all people doing data at the company.

• 29:45Speaker 00

  I was like, I can go build that externally. You know, if Facebook needed this in two thousand eighteen, the world is going to need that in like twenty twenty and I'm going to go build it. So I left and I thought I was going to do a startup. And then I realized that I'm not an entrepreneur, or I wasn't at the time. You know, my change in the future, but at the time that was not who I was. I really enjoyed going deep into technical problems. And I think I had maybe underestimated the amount of work at the time needed for me to like build, rebuild by myself with like, you know, our team of like six had spent two years building on like a very mature infrastructure. I often joke that like I led the company to do a startup and I ended up taking a sabbatical instead. It was wonderful to travel the world.

• 30:30Speaker 00

  I went to like a lot of like wonderful places, but I did not start a startup. I built a few prototypes. You know, I found other people to work with, with whom we had like different ideas. Nothing really crystallized.

• 30:46Ryan Peterman?

  What were the the skill gaps between yourself at the time, successful tech lead and an entrepreneur?

• 30:52Speaker 00

  In order to be a successful entrepreneur, you need to be able to delegate the hard stuff. Right? You scale yourself through others. And to me, at that point, it basically meant that whenever something became interesting, I would have to find someone else to do it. My involvement would have to be superficial. And so, you know, I could hack a prototype together, but like if I wanted to take it to the next step, I would probably need to find like some engineers to go work on that. While I go like, you know, try and figure out how to get people to use the thing in the first place. And I wasn't really into that.

• 31:28Ryan Peterman?

  So after the sabbatical, you boomeranged back to Meta. What was your thinking behind going to Meta?

• 31:35Speaker 00

  So like I said, COVID happened. I was living in New York at the time. And I was stuck in my tiny apartment. And I don't know, on a whim, I decided to buy a house in Denver, so moved to Denver. Bought the house, got a mortgage and I was like, I need like a full-time stable job. I interviewed with a few places. I had a few offers. At the end of the day, the reason I came back to Facebook was James Pierce. James Pierce is a fantastic manager. He was Director of Engineering. He, his claim to fame is, you know, he was the manager behind the open source program at Facebook in the early days. He worked on Portal. He worked on so many amazing things and I always looked up to him.

• 32:18Speaker 00

  And so when it came time to find a new role, I reached out to a few people in my network, including James. And he was like, yeah, I'll, I'll take you. Come work for me. So I entered, you know, I interviewed, I did a behavioral interview because I boom around. And they were like, yeah, you're still, you're still not crazy. You can come back. Got a few other offers, but like at the end of the day, it was really the draw of working with, you know, a few people I really knew and respected.

• 32:46Ryan Peterman?

  And then I understand that you went to Clubhouse after.

• 32:50Speaker 00

  Yeah, this is, yeah, after, you know, so this is the crazy thing. I came back to Facebook in the summer of 2020. Spent about seven months working on data infrastructure.

• 33:03Speaker 00

  Kind of related to the stuff I had done before. And then a buddy of mine just put me in touch with one of the co-founders of Clubhouse. And now, you know, if you remember Clubhouse, it's like went crazy viral and crazy growth in like late 2020, early 2021. And I remember, you know, talking to them at first, not seriously because I was like, I've just been back at Facebook for seven months. I can leave now. But I talked to like the two founders and I was like, oh, this is exciting. Oh my God, Zuck is on Clubhouse and like, there's all of those people, like it was having a moment. It was, you know, all the talk. And, and so, yeah, I decided to join Clubhouse. Well, you know, when I joined Clubhouse, the company was like maybe 10, 11 people. Insane amount of hype around it. A lot of users.

• 33:49Speaker 00

  And yeah, it was a very interesting year I spent there.

• 33:52Ryan Peterman?

  You have any interesting insights or stories that you'd like to share?

• 33:56Speaker 00

  I joined the company to help with the data stack. There was one person working on data when I joined, Kenny D'Amica, who was starting to put together the analytic stack. There was no machine learning at Clubhouse. There was no feed ranking, or at least not machine learned feed ranking. Clubhouse was spamming people with notifications. And so a lot of the work I did in the early days was just building a lot of those systems. You know, like I said, built A B testing for Instagram, built A B testing for Clubhouse because we wanted to be able to measure the stuff we were building. Introduced some machine learning to Clubhouse to filter out the notifications we were sending because it was very spammy.

• 34:39Ryan Peterman?

  What was the internal culture like?

• 34:41Speaker 00

  The the culture was just very hands on. A lot of people were very, very eager, extremely talented pool of engineers. Clubhouse was like this interesting mix where I think, you know, a large fraction of the company was either former Coinbase or former Facebook, pretty much. Yeah, a lot of like very independent, self-driven, hungry engineers who just wanted to build a really, really cool, authentic social network.

• 35:08Ryan Peterman?

  So after Clubhouse, you went back to Meta for a second boomerang?

• 35:14Speaker 00

  For a second boomerang. I guess I had unfinished business at Meta. No, you know, when I decided to leave Clubhouse, I actually did a very thorough job search. I ended up talking to a lot of companies. I had an offer from Apple that I really considered. The reason I decided to go to Meta was twofold. One, a manager, Vincent Hardy, who had been my manager in the past, whom I wanted to work with again. Vincent, at the time, was the manager, the engineering director behind Ray Ban Stories.

• 35:47Speaker 00

  Rayban Stories is this partnership, you know, the classes between Meta and Rayban. And I was like, I've never worked on a product. I've never worked on hardware. I have this connection who is working on that and he's willing to take a chance on me. I kind of want to see what that pivot would look like, being, you know, not being the data guy anymore, but kind of like working on something else.

• 36:12Ryan Peterman?

  Yeah, that was one thing I wanted to know, which was you were entrusted with this Uber TL role, working on, in a very different domain than, than your past experience. And so it sounds like the, the key that got you that role was that you came through a referral, through someone, a trusted past manager.

• 36:34Speaker 00

  No, not entirely. So I, I was not entrusted with like any Uber TL role from the get go. You know, I came back to the company as an IC seven. Rayban Stories had been released in September of 2021. And after, after launch, there were quality issues, there were growth issues. And so when I came in, what I was asked to do was like, hey, can you like look at our growth story? Like you, you know about data. Can you look at like the data stuff a little bit? Make sure like, you know, we're, we're dotting our i's and crossing our t's. And so I spent about eight months a year, uh, working with fantastic leaders and engineers and data people on Rayban Stories to understand like where were things breaking?

• 37:17Speaker 00

  Uh, where did we need to invest more? Where do we need to measure more? And that's how I built the trust with that organization. So it's been about a year doing that. And then there was a reorg at the end of 2022. We merged a bunch of organizations together and people started getting different roles. And, you know, we moved people around and I told my manager at the time, hey, you know, it's been fun to do this, but the reason I joined smart classes in the first place was I wanted to work on smart classes. I didn't want to be the data guy anymore. There is this project, uh, I would really, really like to work on that. I know I don't have experience in hardware and product, but like you've seen, you know, my track record of the last year, I've developed this like product sense. Can I go help with that? And he was like, yeah, you can, you can move on to that project and work on that.

• 38:02Speaker 00

  There was another engineer who was actually the Uber TL and the STO for that entire program. And so I spent the next couple of years essentially like working on that and just kind of like gaining more scope over time. And I ended up, you know, kind of like supervising all experiences across this specific hardware line. I don't go into details because the product is not yet released. But my job was to make sure that like all of the experiences, the user experiences on this specific device were good. And so that meant working with a lot of different teams across smart glasses and eventually what became wearables towards the end to make sure like we were shipping the right set of user experiences.

• 38:48Ryan Peterman?

  Were there any growing pains in switching into this new domain?

• 38:51Speaker 00

  I think there were a lot of growing pains in the organization as the organization was growing and maturing. And so naturally those kind of like rippled onto me. In the early days, I struggled a lot with working or the cadence around working with hardware. You know, I started working in 2022 on something that will be released at some point is currently not released. And so this like extremely long lead time and validation and like, you know, putting things in the hand of users was, was kind of missing. But once I got to a point where at least there was like internal fish fooding and dog fooding within the company.

• 39:33Speaker 00

  And we started getting like some feedback and some signal that made things a little easier.

• 39:37Ryan Peterman?

  Do you have any advice on how to ramp up successfully in like a completely different domain?

• 39:43Speaker 00

  I think it's the same thing as like ramping up in a new company or a different flavor of it. I use the, you know, the boss strategy of doing the social network exploration thing first. Talk to people, ask them who I should be talking to. Don't be afraid to ask dumb questions like you're the noob on the team. Like everyone knows that you don't know anything. I'd rather ask a really silly question now rather than six months from now. Not know what we're talking about and try and get your hands dirty. It's a thing I've always tried to do. Check out the code, even if you're not going to like work on like, I never officially worked on firmware. Right?

• 40:22Speaker 00

  I did check out the code and I did make a few tweaks just to like get a feel for it, get an understanding of it. And then kind of like map things out this way. And then I'd say, the last thing I'd say is pick a hard problem to solve. I learn a lot by doing. And so, you know, this might not translate to other people, but like I learn by doing. So I pick a hard problem to solve where I have kind of like an idea of how to solve the thing. And then I can fill in the blanks as I go. And that's where I learned.

• 40:51Ryan Peterman?

  On this team, this is where you got your IC8 promo or your principal engineer promo. What, I'm curious, what's the story behind that promotion? What is the scope that actually got you promoted?

• 41:03Speaker 00

  Well, so in this case, I was eventually responsible, like I said, for like all experiences on a device. And so I was working across multiple orgs, you know, dozens of teams. I think at some point, like the, the set of PMs I was interacting with was probably like 35 or so PMs. And like, you know, however, many engineering teams are working with that. My job at that point became a lot of like coordination and just like overall architecture. And my responsibility was making sure that we were delivering on our milestones from an experiences perspective.

• 41:41Speaker 00

  The reason I say experiences and on the whole device, by the way, is that the way we were organized is there were teams working on the OS layer. And you know, I would like work a little bit with them and communicate requirements and like poke holes into their story. But there were partners, I was not responsible for like that part of the stack. My responsibility was very specifically on the experiences we were shipping. So if you think about, say, Raybait Meta, for example, which is a product that's in market. The experiences on that would be all of the AI on the device, all of the music listening, the photo capture. And then all of the companion app stuff. So you can imagine something like that for another device. So that was the scope.

• 42:26Speaker 00

  I can go into a little bit of details on like how I actually got the promo because that one was a little bit more work. Like if I think about like my entire, you know, set of promotions from IC5 to IC8. IC5, I had no idea that promo was a thing. It was kind of like a surprise. IC6, I had to like talk to my manager and be like, okay, do you think you can put me out for promo? And my manager was like, yeah, okay. Yeah, I think you're ready. And it went through.

• 42:57Speaker 00

  IC7, it took a couple of cycles where we'd like to like do a few revs. IC8, I went to my manager and my manager at the time had never done an IC8 promo. And we're like, okay, so how do we do this?

• 43:11Speaker 00

  You know, we partnered on writing the promo packet together. I wrote like a substantial amount of the promo packet, obviously with his help. And then, you know, building consensus within the organization, going to like multiple VPs. Early on and be like, you know, this is the work that I've been doing. Do you see the IC8 scope here? Would you be supportive of the promotion? And like building that consensus and seeking that mentorship in some cases, you know, there was a D2 in the organization who I knew would be absolutely critical in. Me getting this promotion. And so I went to him and I was like, you carry a lot of weight in this organization. I'd love to understand how I can make it to that level. Would you mind just having like a, you know, monthly conversation with me, just checking

• 43:56Speaker 00

  in and helping me course correct. And so six months later, when, you know, I went up for promo, uh, he was supportive because like he had been involved in the process the whole time.

• 44:07Ryan Peterman?

  So identifying who the champions are is even more important for the highest level promotions and working with them to kind of understand what your gaps are so that when it comes time for that discussion, it's just a matter of logistics, but everyone is already aligned prior to that room.

• 44:26Speaker 00

  Yes. Now, to be clear, uh, I don't want to make it sound like getting promoted is just a social game. Like you need to have the underlying work too, but you need to have both of those things. You need to have like the impact and the underlying work, but then it is also way easier, at least in my experience, to like build the consensus ahead of time. So that when you go to a, you know, performance calibration session, you don't have to, you don't have a debate in the room. Uh, and so for my IC promo, it took two cycles. Like the first one, we started socializing. My manager even didn't even put me up for promo officially in, in that cycle. He just talked to people around and be like, you know, just feeling the water. And then in the following half, people had

• 45:11Speaker 00

  that context. They're like, oh, we're having this conversation. This is going to happen eventually. Uh, let's see what's missing, what we can do this half. Uh, and then obviously then, you know, with the amount of work I did in that half and the impact I had and that support and mentorship, that's how I ended up getting it.

• 45:28Ryan Peterman?

  When it comes to the scope and the role that got you promoted, it is, it's a role that it, it requires permission from, from those around you to have that role. You know, there's, there's only one uber tech lead on, I mean, you know, relatively, there's one of that role available. It's not like you, kind of like your Bento story, you created a role without permission from others and you kind of built it up into something. When it comes to that first type where there's, there's a limited role and there's probably other people who would like to have that role. Do you have any advice on how to secure that, that scope for yourself or, you know, go, go towards that if that's something you're interested in?

• 46:11Speaker 00

  So funnily enough, that's not exactly the case because in this case, there was an Uber TL for this entire program and he's a fantastic engineer, Jin Sung Yoo. I just identified that there was a lot of work on experiences, specifically on the experiences side, working with product and design that I could help with, where, you know, he could focus on like the broader program and I could just like narrowly tackle that area. And so, you know, over time, he and I built this trust where I just started focusing on that and I started taking that off his plate. He didn't have to worry too much about it. Instead of having to coordinate with like 10 or 12 different engineering teams on experiences

• 46:56Speaker 00

  specifically, he could just go through me. The system stuff, everything else he would do himself, but I ran a very tight ship on experiences and so I made his life easier. And so in a way, I kind of like took that role upon myself. Like there isn't really like an Uber TL for experiences on each product line. I just kind of like, you know, carved that out for myself within that specific program. Now, at some point, you know, I worked with my leadership and I was like, hey, I've been doing this thing and people are asking like, why is Adrian doing that? Do you mind if we just say that like I'm the TL on experiences? That would make my life easier. But it became a post hoc thing, you know, once I was already doing the work and I had

• 47:39Speaker 00

  done the work for about a year at that point, I just asked to be blessed with like a little label so that I could explain who I was in a sentence as opposed to, I'm just this engineer who's like touching all of the experiences. And then the thing I really want to make clear here is that, you know, I've, I've heard a lot of engineers talking about scope as in like stealing scope from other people. That is the wrong way to think about it. You know, taking something off someone's plate doesn't mean that you're stealing from them. Or it is if you're not talking to them about it. So again, I, and this is a constant across everything I've been talking about, over communicate. I went to that engineer, I was like, hey, I am very excited about this space. Do you mind if I like help with this? And he's like, yeah, sure.

• 48:24Speaker 00

  I, you know, I'm swamped. If you want to take that on, take it on. And then, you know, I come back a few weeks later and say, hey, there's this other kind of like belated thing. Is it okay if I talk to them? He's like, yeah, sure. Knock yourself out. And like, you know, in the process, then he can go and like explore other things and broaden his own scope.

• 48:42Ryan Peterman?

  Yeah, in my mind, it's, it's a win win for, for him because, I mean, I imagine you helped him scale himself. So he can, you know, chase some other scope. Maybe he's going for IC nine or something like that. And he has evidence that he grew someone to IC eight or helped. I don't know if that was the case in this, this example, but oftentimes TLs are gracious to give scope so that they can move on to bigger things and help you grow into their role.

• 49:11Speaker 00

  And similarly, I've done that, you know, with like more junior engineers where I had to actually fight with more junior engineers and tell them, hey, can you, can you actually take that and like just own it? Like it's going to be good for you. I also would love to like be able to delegate that to someone.

• 49:26Ryan Peterman?

  So coming to the end of your career story, I, I wanted to do some reflecting across some of the things that, that I saw. One thing I wanted to ask was you have a unique skillset that is very software engineering heavy and also very data heavy from your past experience. And I'm curious, what unique career experiences were only possible through that lens?

• 49:50Speaker 00

  I think all of that.

• 49:53Speaker 00

  I, I think I've always tried to be a well-rounded engineer.

• 49:58Speaker 00

  And you know, in addition to software engineering and like data, I think I've always tried to like develop a strong product sense and a strong design sense. At Facebook, we have like those archetypes, once you reach senior staff and principal. And I've always been a product hybrid. And to me, like this like well-roundedness is where I can add value. Being able to both, you know, have like a deep product conversation with product management leaders. And the next day, go down and like debug some like firmware code.

• 50:35Speaker 00

  Like being a well-rounded person, I think, is one of the things that I've always taken pride in. Robert Heinlein has this quote where he says, like, a competent man should be able to like do all of those things. You know, write a sonnet, diabolically and whatnot, and he finishes and says, specialization is for insects. And it's, it's one of the things that like I've always taken to heart. I, I love learning and I want to try and be good at a lot of different things. And then, you know, bring this like panel of things to the table. And so when I was working in wearables, you know, I would like build little prototypes. You know, like design my own little circuit boards and like hack things together.

• 51:21Speaker 00

  Like obviously not production ready, I'm not a hardware engineer. But like having the ability to do that type of stuff means that you can start a conversation with people. You can go and, you know, talk to a product lead and be like, hey, I have this idea. Here's a thing you can play with.

• 51:37Ryan Peterman?

  One thing you said, and this is evident to me throughout your career. You, you said something that, you know, your career is a series of bumping into the right people. Or you, you mentioned a quote like that. And throughout each leg of your story, there, there tends to be someone who either brought you along or was instrumental in one of the projects that got you promoted. I'm curious, do you have any tips on how to, I guess, maximize your luck when it comes to people opportunity?

• 52:06Speaker 00

  Oh, so many thoughts. The, the first one is, you know, like I, I've been talking a lot about myself for the last like hour now. None of the stuff I've done would have been possible if I was working in a vacuum. Like, everything I've done has been, you know, working on a team, convincing people, getting people to, you know, go in bat for me. Like, some younger software engineers, I had rough edges when I was earlier on in my career. I had, like, very strong opinions about things, and that didn't always work out in my favor. And, and so I learned very quickly that, you know, we're all in this to succeed. And the best way to succeed is to help others succeed.

• 52:47Speaker 00

  Not to want anything in return, but just, you know, fostering success around you, right? A rising tide lifts all boats. And that's the thing that I've been trying to do in my career, probably for the last decade or so. You know, the first, like, two, three years of my career, I was maybe a little selfish. And then I started realizing, hey, we can all succeed together. And so when you build that trust, and, you know, I'm not saying I'm going to be friends with all of my coworkers. When you have relations, relationships of trust and respect with people, that is a really good way of making sure, like, eventually, if you have a need, that person is going to be there for you. Like, you don't do that in order for them to be there for you.

• 53:28Speaker 00

  You're just, you are a good person, you're a trustworthy person, you build trust, and then you will reap the benefits of being a good person eventually. That's one thing. Two, don't be afraid to ask. Every career change I've made, I have never applied for any job on a website. I have always reached out to someone I know. Once you build this relationship of trust with people, and you, you know, you're comfortable asking them, be like, "Hey, there's no pressure, you can say no if you don't want to, but would you mind just giving me, like, doing me a little favor?" So, don't be a dick, essentially, uh, you know? Build a trustworthy relationship with people. Don't be afraid to ask, but also don't be, don't be afraid to hear no or not hear back from people.

• 54:12Speaker 00

  People are busy, that's fine. The way you maximize your luck is you maximize, I was reading something the other day about, like, the surface area for luck. Take more shots. The more shots you take, the more likely you are for one to land.

• 54:26Ryan Peterman?

  And then the last question I'd like to ask you is, um, if you could go back to yourself when you just graduated college in France, and give yourself some advice, knowing what you know today, what would you say?

• 54:38Speaker 00

  Be a good person. Invest in things that are fun. Invest in your relationship with your coworkers. It doesn't, it doesn't really matter at the end of the day, who gets the credit. Everyone is going to get credit for something. I think early on in my career, I was very credit driven. Be patient, you know, I think there were a few times in my career where I was pushing for a promo or when I wasn't ready. My IC seven, like I said, took like a couple of halves to go through. And stay curious and mostly just like enjoy it. You're going to have an amazing adventure.

• 55:13Ryan Peterman?

  Awesome. Well, thanks so much for sharing your career story with us, Adrian. And now if you wanna, you know, share with the audience where people could find you, maybe they can go and I'll put it in the show notes.

• 55:25Speaker 00

  Sure. At this point, I'm mostly just active on LinkedIn. So we can put my LinkedIn in there. And then, yeah, no plugs. I hope that the audience will get something out of this.

• 55:37Ryan Peterman?

  Awesome. Thanks so much for sharing this with the community.

• 55:40Speaker 00

  Thank you so much for having me, Ryan.

• 55:42Ryan Peterman?

  Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you wanna help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you wanna drop a review, that'll be super helpful. And if there's any guests that you wanna 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 wanna hear their career story, let me know and I'll reach out to them.