The Peterman Pod - Instagram Staff (IC6) Promo Despite 10 Team Switches in 9 Years (Career Story)

Episode Date: August 8, 2025

Sash Zats grew to be a Staff Engineer (IC6) at IG despite switching teams 10 times in 9 years. His career journey was a series of jumps to exciting projects and letting career growth happen as a byproduct. I interviewed him to show you how team switches can play out. We discussed:• How 10 team switches in 9 years affected his career• The story behind the Instagram blockchain initiative• His 2 diff in 6 month performance review• What working on Instagram Threads was like pre-launch• The value of prototypingTimestamps:(00:00) Intro(00:49) First team: iOS on Newsfeed Delight(05:30) What makes a good designer partner? (08:30) Joining a hardware team (12:08) 2 diffs in 6 months (15:03) Joining the Instagram blockchain team(21:37) Joining Instagram Threads pre-launch (28:53) Working with an exceptional engineer (Peter)(33:02) Working on AI prototyping teams(37:15) Reflecting on team switching’s impact on career growth (44:35) Why leave Meta (46:15) Advice for younger self (47:53) Outro Where to find Sash:• LinkedIn: https://www.linkedin.com/in/sashzats/• X/Twitter: https://x.com/zatsWhere to find Ryan:• 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

When Musk was acquiring Twitter, there was recognition that there is this window of opportunity. This is Sash. He grew to staff at META despite switching teams 10 times in nine years. Two diffs in six months. What was your performance review like in that half? I wanted to share this conversation so you could learn about how switching teams can affect your career. What was your thinking behind wanting to shift to such a different domain? Android is like terrifying for anyone who builds for iOS.

They're like, God forbid, you have a good. there. Eventually you went to a series of teams that I'm really interested in. For viewers at home, Instagram used to have a blockchain team. You started working on a very experimental, interesting project. For a while we had this as a secret inside of Instagram. Well, let's start at the beginning of the story. So how did you pick the first team? And what was the story behind that? Well, my first pick was this team based in London. And they're like, oh yeah, we're going to work remote and it's going to be fine. but the code review times with London they would take like days. And so I ended up sort of deciding against that.

And I chatted with this one guy, he's also still in the company. And he saw my sort of resume or whatever. And he saw that some sort of like a weird hybrid of like design and engineering and like everything is kind of poorly defined. And he was like, listen, how about this? We're going to build a team that takes all the design prototypes. the designers always have like stacked up in their desk but never shipped, right? And we're just going to build them.

And no metrics, no nothing. And it was inside of newsfeed, Facebook news feed. I mean, now if I would look back and I would hear newsfeed, no metrics, I would be like, oh, yeah, this team is going to survive half a year. And it survives half a year. But it was so much fun. It was a lot of fun. And like the value prop was just so fun to me because it was like, oh, let's build the right

thing and not worry about metrics. And the things that we built, later we found some metrics, So like to associate with that, again, it didn't survive long-term scrutiny. But it was a lot of fun. It was all sort of really joyful projects. The team was called News Feed Delight. And yeah, I was just building all sort of like fun visual animations, the facts that's like sort of what people usually call Easter eggs in the apps.

We were building that and it was so much fun because again, every designer dreams of that. But then every engineer looks at it through lens of impact and they're like, I'm not touching this with it. Like, you know. Yeah. And like the other theme through my career was that, I'm just not thinking about impact too well.

And that allows me to pick the teams that are completely irrational and high risk. And like, God knows if there is even reward. I saw those teams that you worked on initially, the design ones. And I was thinking how do you measure success or how do you prove that this prototype was a good idea? Yeah. If there's kind of going off a vibe. So I'm curious, like what is a successful project even look like in a space? So I think in the spaces like that,

now I can rationalize how it's done in a company like meta, right? So you have some executive sponsor with some sort of theory that like they justify to someone and that's basically how those teams survive. So Facebook used to have this metric called cow cares about user. And this metric was literally a survey issued in a news feed that would ask you like some broad question of like, oh, do you feel like Facebook cares about you? And this highly subjective metric that like I'm not even sure if you can like, if everyone understands it in the same way.

was what a lot of teams were orienting towards. And so this kind of laddered into that, I guess, to some degree. Especially in today's world where you want everything to be highly efficient and there is not too much time to focus on this like moments of delight and joy. Yeah, it's sort of like harder to justify existence of those kind of teams, I feel like. You mentioned you weren't optimizing for impact at that point. And it sounds like throughout your career, that's a common thing. What were you optimizing for in that team choice?

Fun, you know, just like pure fun. I'm sort of, I often end up in the situations where looking back, I'm like, oh, that was lucky, that was cool. And you just meet people and you explore some opportunities. And later, again, sort of like looking back, they all make sense, mostly because productively you don't know what's going to happen. But also you end up building, you know, accumulating this toolbox, skills, people, connections, you know, like all those. things and that you can build upon later. And so, yeah, I feel like I'm joining a team because I have some intuition of like, oh, this might be fun slash interesting slash whatever. Later in career, I became a bit more intentional, but still sort of optimizing for this risky-ish space, like zero-to-one

space. I think that's what I noticed early on and there was again sort of coming from startup days is that a lot of people are sort of uncomfortable with ambiguity. They're uncomfortable with poorly defined spaces, you know, sort of like ambiguous spaces, no product definition, no direction. And a lot of people, they're really good engineers, but they need this sort of like, oh, like, this is what we need. This is the diagram. This is the mock, whatever. Where maybe because of the design past, maybe whatever, I would always be like, oh, yeah, we can kind of yolo it as we go, right? And sooner rather than later, you realize that it's an asset, you know, when you can be effective in this environment that's sort of challenging or ambiguous to others, it's an asset

that you can use. And then that is a question of, yeah, like, how do you measure this effectiveness? You had a lot of opportunities to work with different designers. I'm kind of curious, from an engineer's perspective, what makes the best designers to work with? I think it's just the collaboration sort of process. So the most fun I have is with, and it's not just designers, but designers in your context specifically is that you have people who are readily sort of jam with you. They don't just come up with this idea in the vacuum because oftentimes for better and for worse, it's not informed with real world constraints, nor should it be. But then when you have this design, initial design, it's like, oh, but what happens when your

network fails or what happens when users doesn't have this field in their day, whatever? So like, you need this constant dance between like, here's this idea that we want to to achieve and here is the real world inputs. Oftentimes, what I would find even more fun is when you show designers, oh, like, look at all those cool capabilities that we can actually use in your design. So, like, what if we, like, at the time,

like, I don't know, what if you use some sort of, like, location to inform how this looks, or if you use accelerometer of the device to move the shadows a different way? It's like all the stuff that not every designer necessarily knows or remembers off top of their head

is a fun way to sort of to inform their creations, but then also the saturation loop. Like, in my experience, the tighter you can get the saturation loop, the better. And I had a few projects on some unreleased pieces of hardware where the whole thing was for me to build a hockey version of Figma 2 unreleased device rendering pipeline so the designers can just, like, see their Figma's on an release device as quickly as possible, and just like move stuff around and like immediately see it being reflected. So like all the saturation loops, the shorter they are, the better, and the more both partners, engineers, designers, who have Ellison's involved are ready to hear each other and like sort of internalize the constraints and sort of talk about it, the stronger products come out.

So if I'm understanding correctly, you mentioned the short iteration loop, but also it's kind of like this bidirectional communication. Like engineering might propose something that design doesn't know. Design does the same. Yeah. The end result is a much better product. Yeah, for sure. I also find it really helpful when you just start the project to, like, not involve technical constraints too much and just be like, okay, cool, yeah, we're going to build this crazy thing that you want. And then you sort of, then you can trim it down to meet the world where the world is, right? So like if it's hardware, well, what is the, I don't know, like thermal envelope that you have to work against? Well, maybe device is just going to blow up if it runs so for so long. Or, you know, maybe, yeah, like processing power is not there. So it cannot be as real time as designer. So like, you know, all sort of real life constraints. that will get in the way anyway. But yeah, it definitely helps to start with a pretty, you know, sort of like everything is going to be working the way you want and then sort of like inform each other and sort of bounce of each other. And like this definitely builds a stronger product. So I think like that first leg of your career you were working on like traditional iOS kind of things, very design oriented. And I understand that you pivoted at some point more towards a completely different domain. You switch teams, uh, multisional. multiple times even within iOS, but then you switch to an entirely different domain in hardware

and prototyping, experimental hardware. What was your thinking behind wanting to shift to such a different domain? I was just looking for a new sort of team. And I started by looking at your iOS teams, we have this internal jobs tool. I was looking for something in New York. And I just couldn't find anything that was sort of appealing enough. But then there was this one of the postings who was like, oh, we're like starting this new hardware team. And there was not really that much information. Like at the time, the internal job tool was like sort of like semi-updated once in the blue moon. I think now it's like more rigorous.

But yeah, and so I reached out and turns out that they were looking for people to work on hardware based off of Android, open source OSP. So like aOSP, it's like pretty standard practice. I think right now if you're like building new device, you just start with this AOSP sort of OS. I think I sort of just switched to it because like, oh, there is nothing more fun in New York for me right now. Why not? Obviously, zero experience with hardware or Android. Android is like terrifying for anyone who builds for iOS. They're like, God forbid you never go there. It's like going to the dark side. But yeah, so I ended up switching and that team was a lot of fun. It was like, it's like sort of like this Alice in Wonderland. Like once you plunge, you know, into the rabbit's hole, you're kind of like, oh, this is really fun. And so, yeah, I sort of switched to that team. First half, a year, I think I committed like maybe two diffs in the entire time. Yeah, yeah. Because there was basically no, it was all prototyping. It was all like, okay, first we need to, to begin with, we needed to figure out like what hardware do we even need to source? What kind of processors? What's kind of whatever? And it's like, you have a bunch of like

mobile engineers like sourcing hardware. That's fun. Yeah, in the meantime, we also needed to understand how this hardware would interact with sort of like existent hardware ecosystem. So all your phones, all your whatever. To me being sort of aware of iPhones and iOS sort of ecosystem and loving reverse engineering stuff, I started looking into how Apple builds their messaging stack and sort of how they communicate. So there is this protocol that allows, you know, whenever you get into a car that doesn't have Apple car or like Google car, you end up connecting your phone and you see like your

messages or your calls in this like really old school dashboard. So there is a protocol that allows you to do that via Bluetooth. And obviously, Apple had to build their own extensions of this protocol that's not really public. And so it was a fun little project where I got Raspberry Pi off of somewhere and I started installing software on it to pretend that it's a car and pair it with my phone. And eventually I started tracing the packets instead of like some information is publicly available on the internet, some information you just need to like sort of reverse engineer.

But it was, yeah, the reason why I didn't commit any. of this code is because it's a trash code. And like, you don't need it in the repository. And it was just done basically to inform what's the upper bound experience that you can get using this protocol. So like what can we hope to achieve once we productionalize this? And this end up being a pretty common theme, I think, in my career from there on is like, yeah, sort of what is this upper bound experience like unbounded by any sort of constraints?

And then, yeah, like how can we productionalize it? Yeah, I'm curious because you said two diffs in six months. and it sounds like there's a lot of risk and you are doing a lot of things that may not be easy to measure or prove the impact. I think a lot of people would be scared of switching teams to, especially to a risky area like that. They worry their PSC would look bad or something.

What was your performance review like in that half? Yeah, I think that it was sort of in the job title where people who were hired on that team this early on, it was sort of implied that, you know, they get reviewed based on on derisking a lot of directions and not necessarily like lending code. We also, again, it's like the team that was sort of seated with like bunch of senior people. And so there was mutual understanding that like it's going to be taken care of. I think that this is the way big tech sort of creates incentives for people to come in into those risky projects where you're not guaranteed a promo, but you're at least protected from the downside, right?

because you want people who are interested in taking risks to feel safe. And this is a lot of changes that happened in the PSE cycles of a year, where, like, if first was sort of optimized for half a year, because you kind of want to balance, like, feedback that you get often, but also you don't want to make sure that people sort of feel safe, taking on the riskier bets that, like, last, you know, maybe multiple halves. And so, like, it's a delicate dance. I understand that everyone hates this process,

but, like, I don't think there is a good process per se that can be, like, good for everyone. I'm kind of curious because you, I'm, you know, mostly software engineering initially and still like software, but in the hardware team. What's the biggest difference you see between hardware teams and software teams? The timelines for sure. It's this fun sort of concept when, you know, back in a day, if you remember when software would be still shipped on CDs and in boxes, so you literally have to put some bytes on the CD and seal it and send it to people, right? And so with hardware, it is still the case that at some point, when you want to release your Gen 1 device, something has to go to the factory to flush it on the device, right? And so this is why the

deadlines in the hardware projects are so much more ruthless. You cannot push them by one month. Everything falls apart. And so it feels like this is probably one of the key aspects. And then, yeah, you can have like zero-day update when you're like, you know, this annoying thing when you just bought a new device, you plug it in and it's like, oh, sorry, I will take 20 hours to update now. So like, you can have that. It's not a great experience, but you can have it. it, but something has to go into the box. And so this is the key difference, especially in the company like META, where you have this continuous software cycle that you don't even think about, you know, you push something

to dub, dub, dub, and it's instantly, you know, within like three hours, it's available to like billions of people or like iOS within a week, all this stuff. Hardware makes you think in a very different terms. And it's like pretty chill at the beginning, but then towards the end there is a crunch time when like you have to get it done by certain date and that's quite different. So you had the hardware teams. and it sounds like that was a lot of fun. And then eventually you went to a series of teams

that I'm really interested in because they were cutting-edge prototypes on products that we know that launched. So I want to hear the stories behind that. What made you shift from hardware back into these software teams specifically focused on these rapid prototypes? So the time has come for me to try to live outside of the US again for a bit.

And again, matter has this wonderful sort of flexibility of as long as there is a business need, you know, in engineering in another office, you can just move and sort of like work from there. And so I really wanted to try to live in London for a bit. And I was trying really hard to stay on the same team, the control apps team, because it was just so much fun and people were wonderful and technology was so cool. But it's hardware. It's, you know, especially having people living abroad means that you have all sort of potentially regulations with and release technology, like all sort of stuff that you, like, I don't even know if that's the case here, but I imagine that there is a lot of complexity.

And so I realized that it's not going to be an option. And so I needed to find a team in London that would be happy to have me. And as I learned, Instagram was just about to open the office in London. And so not just any Instagram, it was Instagram blockchain team. So for viewers at home, Instagram used to have a blockchain team. And for that brief but glorious period of time, we were building all sort of technologies. So people might remember that there was this whole crypto currency effort that Meta tried to take off the ground. That eventually branched out into its own sort of separate company.

But then we had all the talent and technology built in house to deal with blockchain and crypto and all that. and we basically thought about exploring those directions within Instagram being creator first, creator forward sort of product. Other products also, other sort of apps later joined as well. But yeah, basically this team was opening up in London and they were looking for people to join and sort of built out a bunch of stuff. So I moved to London, joined this team, and we shipped sort of fewer vanilla and if type of product within Instagram where you can upload your NFTs.

They would have this like beautiful shimmering effect and all that stuff. Eventually you were able to create NFTs from Instagram. Just like looking back at it now like, wow, that's... We used to have this group internally called Facebook Does What. And it was this internal group where people posted screenshots of like products they found inside of Facebook app. And it was like food delivery, movie tickets ordering, like all sort of things that people are Facebook does what now?

And so this is like, to me, looking back, you know, it was such a fun, crazy moment. But yeah, so I helped to ship the NFT product. But the actual thing that I was working on that was really fun and interesting to me. So at some point, Adam Messer, the CEO of Instagram gave this TED talk that was talking about how the future of creators is decentralized. And it was sort of building on this idea how right now as a creator, you're sort of bound to certain platform to their, you know, sort of policies to their whatever kind of. contractual obligations, but then if for some reason you fall out to grace with this platform, you're banned all your livelihood, like if you build some sort of followership, it's all gone. So Maser gave this talk where he was exploring this idea of like, oh, what if this notion of

following your creator exists outside of any given platform and platforms are there just to recognize it? They can choose not to recognize it, but they can't choose to recognize it. And so what exactly does it mean for Instagram? What exactly does it mean for creators, for followers? And so I was one of the people who was tasked to just understand, okay, we have this TED talk. What does it mean as a product? And so we found that basically we need to build a product that, you know, in order for it to be successful, we wanted to be recognized by some other key players.

And so this is how I found myself being embedded deep into partnership team and working with people from Google, Spotify, Shopify, Nike. all sort of companies. And so we had a pretty, like, I think that that exercise was super interesting because not only I was sort of prototyping the tech side of the story of like, okay, like, what does it exactly mean? How would Instagram, like, what is my experience of I'm a creator? I'm onboarding onto Instagram. I'm a follower. I'm coming to Instagram and there is a creator that I already follow on like, I don't know, TikTok or elsewhere. Like, how does it actually happen that like, do I connect my wallet? And then like we see some sort of like token in there and we're like all sort of open questions from from technology's standpoint. But even more interestingly,

there were a lot of questions about sort of business side of the story where you have meta whose business is predicated on ads. You have, let's say, I don't know, Spotify whose business is subscriptions. You have Shopify whose businesses, I guess they charge merchants for selling stuff. And also like they're all different incentives that all those companies have. And so how do you create a product that they all are interested in? considering their different business incentives. And that was just really, you know, as an engineer, I think you get to think about it, either if you're on your own startup or if you're pretty senior.

I was neither of those things. And like, it was so fun to just go and sort of play with it. And yeah, just like meeting people from other companies, making a case for like, oh, this thing should exist. And like, it is a really fun exercise in seeing how you can convince people that a product should exist pretty much from scratch in the vacuum, you know, like there is nothing. And then you're like, oh, yeah, yeah, it makes sense for you business-wise. And, you know, we got to various degrees of success with different companies and then crypto-winter hit and we had to shut down the entire

project. But while it lasted, I think that it sort of gave me a really fun insight into this side of the story where technology is important. But it's so rare that companies sort of fall apart. Well, I don't know if it's rare, but I feel like it's more often than not. the companies fall apart not because of technology. And so there is this whole other aspect of building a product that I think as an engineer, engineers we don't often get involved into, but it's still a really fun problem space to think about. Okay, so then crypto winter happened. You switched off that team and you started work on a very experimental, interesting project,

Instagram threads prior to its launch. I'm curious, like, how did you get recruited to that team? because that's a really, you know, cool, interesting zero to one project. It was sort of the writing was on the wall that the whole like crypto efforts, blockchain efforts will be no more. And so sort of foreseeing that I ended up helping people to ship some pretty traditional Instagram products for a bit still from London. And then a couple of people reached out over Christmas break as far as I remember.

And they asked if I was familiar with sort of activity pub, this protocol behind Mastodon. so decentralized social networking. Up to this day, I'm not 100% sure why. I think that, like, you know, you sort of end up building some sort of credibility for pro-typing, for like posting, you know, internally all things that you do, yada yada. And so they reached out, they asked about it. And I was like, oh, yeah, I'm kind of familiar with that.

I wasn't really big on Mastodon at any point, but I was aware that it's happening. I was sort of new enough about it. And then it was Christmas break when I didn't really have anything to do. And I was in London. and what I did, I spun off internal instance of Instagram server, and I started looking into, okay, if I send up Mastodon instance next to it within the internal sort of network, on Mastodon, you can search and it finds users from any other decentralized Mastodon instance.

So they have this protocol that they talk to each other, and they sort of resolve all those names. And so I spun off both of those instances, and I wrote a really simple and really horrible code that was basically allowing internally to resolve Instagram users, losers from Mastodon. That was the first taste of like, cool, we can actually get this stuff. We can get them talking to each other. And, you know, it's not technically that hard, let's be honest. But what I found, that this is probably another one of those lessons where it's not

about technical complexity oftentimes. It's about having a concrete thing that you can point at. You can give people to play with it, you know, and they can actually see it with their own eyes. And it creates so much momentum in the project, especially early on. when it's like, yeah, you can have like 500 decks or you can have like one prototype that works and people can play with. And it just creates excitement and all of a sudden people jump on the project and like whatever. So that was the very first thing. Again, it didn't really de-risk or move us anywhere because it was obvious that it's possible. But it just showed maybe the direction that like, oh, I'm interested in the project and I showed it to the folks who reached out.

And then, so the very next step would be, okay, cool, now we need a mobile app. And I knew Instagram codebase at that point relatively well because I worked on Instagram blockchain team for a bit. And so what I did, I started stripping down the images from Instagram app and just blowing up the actual caption text to be pretty massive. And just hitting the same internal Instagram server. And so it would just show all the like my feed without images and just with text. And I was like, oh, cool, that kind of like, you know, you can squint and see it. And then I worked with this super talented guy, senior engineer, Peter Cottle from Instagram. And yeah, like the way he sort of knows backhand, I feel like is sort of back of his hand.

And so we had so much fun when he was just building out the back end stuff because he's way, way better at this obviously than I am. And I was just sort of like, cool. Now I'll start querying this new feed source that you created that's going to have only this special text post type. And so we started like chiseling out the mobile experience from Instagram app and from the back end. So we sort of started with this, here's Instagram the way it exists today. Let's start seeing how it can actually turn into threads. Yeah. And so for a while we had this as a secret sort of feature gated to employees only inside of Instagram.

And it was, yeah, I think it was like a pretty closed off project at the beginning. So it was like gated just to the team. We had this special composer where you can type text. because in Instagram you cannot share a post without an image, so we needed a way to share a post without an image. And like, backend should survive, you know, this post that doesn't have an image and not freak out and crash everywhere. So, like, that's where Peter really helped early on quite a bit.

And yeah, we sort of started chisling this out. And then I ended up being this, like, iOS engineer based in London when the rest of the team started building up in New York and NSF. and yeah it was sort of a fun journey from there from there on i was so london is what like i don't know eight hours ahead or five hours like some number of hours ahead of new york let's say and so wow i'm like terrible at times but you wake up in london time and it's super early and because our builds were sort of separate builds from instagram up they would constantly be broken because they were not part of any continuous integration yet and so like i would wake up all the builds are broken

I need to figure out why is that? Someone would lend some code, doesn't include, like, our code, pass, whatever. So first three, four hours, you just fix all the stuff, you get it to working. And then team in the US wakes up a bit later and they can start working with it. And then you build out a bunch of features as well. And so, yeah, it was a really fun process. We started hiring a bunch of people from across the company. It was a really fun sort of project where it was just around the time when Musk was acquiring Twitter. And so there was a recognition that there is this sort of window of opportunity if there

is some sort of chaotic moment in the Twitter, then, you know, META can come up with its own product. And so we needed to build it in the way that at some point was ready to release. And then we sort of built on it so that, you know, you have some usable version of it. And you just make sure that that doesn't fall apart. Yeah. And so I think it got built in like five or six months, if I remember, right, from this first prototype to releasing it to public. And it was, yeah, It was like one of those projects where it is, it was a top-down incentive, sort of initiative from the leadership to get it working. And because of that, all the red tape, there would like magically people would appear and they would be like, let me solve this for you. And you're like, yes, yes, please.

And you just get to work on the stuff that you care about. It was so much fun. And also it attracts a lot of really talented people from like all sort of design, products, all sort of stuff. And yeah, it was just really, really good collaboration. people that worked on that initial team, they were really stellar. And then, yeah, there would be surges of like, oh, we need to figure out integrity or privacy or whatever performance. You would just sort of bring some people on board.

They would like help you to figure out some stuff. It was a tremendous effort. I think that became sort of a poster child of a team at META to show how little you can, you know, how little you need to ship a great product. Granted, we built it on Instagram. So like we had super high level primitives, scalable sort of, you know, battle tests and all that. So, but yeah, it was it was something that meta sort of, I think, tried to evangelize later on. So this is how we can build products in this new environment.

You mentioned working with Peter, super senior engineer at Instagram. What is the thing that made him so great when you worked with him? I think that he worked on it for so long. he was familiar with all the corners of the code and he sort of knew well the consequence. Like what's the fastest way to get post working without an image, right? What's how to create a new feed. How to like all those things. He just sort of as if had answers to all of that.

And so it ended up being this sort of like conversation between us to early on and with more people later where it's like, oh, cool. Like now we need to figure out this piece. And we just have this conversation with code where we like quickly landed. I can test against his back end, and it just works. And this is, I mentioned it before, this is something that's super, super helpful when you want to move fast, whether it's pro-typing or shipping products,

familiarity with code gets you a long way. And so meta is great because it has this incredibly high-level primitives. So even when I would go and work in the backend, like, Dab-Dub-Dub or Instagram or whatever, the size of the primitives is so massive that you, it's so easy for you to be efficient. I need to create a new entity, and I don't even need to know how privacy works.

It just gets the right default, and it sort of ensures that nothing bad happens. And then, you know, then there is a way to customize it. But yeah, people like Peter, they just know stuff so well. They know their code base so well that, like at this point, I guess, like with all the AI advancements and all that, you can see a future where you just have a conversation with your copilot type of AI, and it sort of does it for you.

But it was roughly before all of the CIA craze happened and sort of like became a norm. And so, yeah, Peter is like a copilot. An incredible co-pilot. Okay, so he knows the company so well that it's almost like you prompt him. But he doesn't hallucinate, and that's important. Yeah.

I think one thing that's really interesting to me in the story, how you got this opportunity, because this is a really cool team that you joined, very kind of like cutting edge is it sounds like you were already known as someone that had these visible prototypes. So they came to you. But then not only that, you just took some initiative to just instantly start. It doesn't sound like they asked you to prototype.

You just, you replied with here's it working with Macedon. And also here's another idea of like a, you know, bare bones like iOS app that's kind of showing the vision. Yeah. So I feel like that's pretty interesting takeaway. And it sounds like your prototypes, too. They must not live in a vacuum. It's not like you build it. It's kind of like your curiosity. Sounds like you build it and you share it. And a lot of people get excited about it. And you're already known as like a prototyping person. Would you say that's true? Yeah. I think, you know, it's hard for me to know for a fact reputation that I had at the time. But maybe it was around the same time with all the sort of GPT, early GPT sort of like was coming out. So I was building a lot of those. So I was building a lot of those. things and sort of sharing them on workplace. When you build something that uses internal technology, you cannot really post on Twitter, right? And so you have to sort of do that internally. But, you know, in exchange, it creates this perception of, you know, even if you don't get like too high on your internal posts, people see them popping up and like eventually they sort of build this mental model of like, oh, yeah, like if you want someone like for like Quicken

Dorio, like whatever, like pro typing, that's the person to reach out. And then yeah, I think responding with prototypes instead of like, oh, yeah, let me put this on my, you know, to-do list. There's just a way that shows the attitude, like early on in all those projects, you want people who are not, who's self-directed, I think. That's what I would be looking for at least. Yeah, and in the corporate world, there is so much alignment and, you know, like meetings and all that.

I think that it always stands out when you have someone taken, you know, initiative and sort of like moving on in the ambiguity. And then after threads, it sounds like you mentioned that you worked on a string of AI-related prototypes and transitioned away from that and started working on, you know, meta-AI and stuff like that. Is there a, you know, favorite prototype or maybe a story in there that you think would be worth talking about? Yeah, I think early on, there was one really fun, fun, it's like a big word for it, but I built

this prototype that took all our public FAQ about account. safety and sort of like all sort of things related to Facebook accounts that you can find like in Facebook.com slash help or whatever. And so we took all of this and sort of rugged over it. So like did retrieval augmented generation over this information. And so you can you can you don't have to search for the specific answer. You can actually like just have a conversation with this like AI was like I think it was GPT3 time. And so you can actually have a conversation with it and it would hallucinate like crazy. But you can also like see how. it's getting there where you can ground it in some sort of concrete data. And I posted it internally.

And that was the only time when I got number of reachouts from people from all over the company that I never seen before. It was like probably like probably below 100, but about 50. And it was people from all over the place that I recognized it like cool. Like all of a sudden support is sort of like solved. Not really solved, but like you know, you can see how it's moving into direction where you can have customer support being done way more efficiently. And fast forward, you can see so many companies in the public right now building those kind of products, right? So, and again, it's not that I was first or anything like that, but it's just, again,

it's to the point where when you're in your corporate sort of environment, you're grounded in your internal technology so much, so much so that you're not even aware of what's happening in the industry and showing, you know, like pulling in those pieces of industry and grounding them in your internal data, technology, tools, whatever. it really helps to bring awareness within your organization, within your company, too. And you'll be surprised, or maybe not even surprised, how often people, you know, people have their lives and they don't care to read Twitter every day. And so, like, they don't know what's like, that like, oh, here's this latest, coolest thing that, like, you know, you can easily just

bring in those pieces of what's possible right now into your corporate environment and just keep people up to date. You know, when people talk about visibility, you know, it's like, oh, write up that says you move this metric, which is good too. But it sounds to me like a good prototype about the right idea. It connects with people in a way that writing can't, which is like someone can click into it. Someone can really see it's such a high throughput thing rather than just text. You got the whole thing in front of you.

It sounds like that is a really good tool for driving imagination of the future direction, alignment, it sounds like on, hey, this is a good idea. 100%. Yeah, I think it goes back to the fidelity, right? So you can write text and then it relies on both of us being able to reconstruct what I meant in your head and making sure that we actually align on what I meant, that you build the same mental model. You can draw an image and then it's a bit easier.

Video, even easier, prototype is probably the highest fidelity when there is, like, the less ambiguity you leave to, you know, for someone to interpret. the better. And then you can actually ground your conversation in like, oh, cool, like, I actually want this specific interaction to be a bit better or different or whatever. And you probably saw that yourself so many times when you're in the meeting and 20 minutes in, you realized that you were talking about completely different products. That's like you, you thought it's building together with this partner or whatever. So it definitely helps a lot to speed up those ambiguous days of the project. Okay. Well, coming to the end, I think there's

So many interesting reflections we can have over this career. Because I think your career is so unique in that I remember you had written something or said something like you got promoted despite your best efforts not to. And like it was clearly not your intent to focus on career growth, more about focusing on things you're building and other circumstances. So I'm kind of curious, like when it comes to career growth, like looking back, if I recall correctly, you were hired as an IC4. I hired as IC4 and then we're eventually promoted to IC6, even though it was not something you really even thought too much about. What are your thoughts on your career growth and also in switching teams as you go about it? There was one friend who was on the first news feed team that I joined who's been there before I joined and who stayed there throughout my entire time at matter. He just left like maybe a year ago.

And so it's definitely way, way easier to level when you're in the same space. You build connections, you build goodwill, you build expertise, all those things that help to propel your career upwards. I think that, yeah, I just always found it a bit boring. I think coming from startups, coming from outside of the US, my mentality was just so not about that, that I just, it took me a while to conceptualize what PSC is and like, what is it because like you're at a startup you get continuous feedback every day right but here it was sort of a bit different i don't view this as necessarily an advice that you can scale and give to other people that's

like oh do this thing and it's going to be fun no like it really depends on what you're optimizing for and like what kind of career in life you want to have i do find that for myself breaths is just a way to set yourself up for those you know connections that you build in the future So it's going to like you set yourself up with all the connections, all the technology, all the people. And eventually some of them come through. And, you know, maybe you will take a few wrong turns. But as long as for me personally, as long as I enjoyed the projects that I was working on. And this is what I was optimizing for the most.

I sort of wanted to work on projects that I feel passionate about. I end up working a lot. I used to work long hours. And to do that sustainably, I needed to enjoy what I'm doing. And for me, this joy was coming definitely from fun more than leveling and career growth. I mean, it sounds like the breath paid off as well. Like there were many of the opportunities that you got were because you were kind of shooting shots everywhere. And people had seen that.

So you cast the wide net. Yeah, it definitely ends up building some sort of persona for better and for worse. I know that I have a few really good friends on Infra teams. And we have this like ongoing jokes about number of selves that I caused them and like all the grief that I caused them. But we're still friends, and whenever they need to know how something is done in this completely different corner of the app or in a different app, they come and ask, right? And it's helpful. Well, not anymore, but they used to. You know, when it comes to career advice, it's anecdotal.

And we can't really tell what would have happened if you did something differently. We just kind of interpret the dots looking back. But one thing I was just thinking that might be interesting is that boot camp class that you joined. for some reason everyone stayed at the company the entire time. And they're completely different people. And it's also a low sample size. But I'm curious, I don't know how much tabs you kept on, you know, what they're doing and how. But when you compare your career to theirs in terms of like what they worked on and how

there's went, you know, do you notice any differences? Yeah. Yeah. I know that a couple start as I sees became managers, worked in roughly. the same space, definitely within the same apps. The other person moved to reality labs and I think stay there for the entire time. I think still an IC. Yeah, I think they all are doing well, but they definitely are kind of people who prefer growing vertically rather than just spreading themselves all over the place. So when I was living meta, I felt that I have to find someone to

take over my spot on the team. My last team was like almost exclusively built around prototyping within that AI. And it was hard. And I'm not saying it to like pat myself on the back, but I think that this is something that large corporate environments, they sort of dis-scentivize against. You know, they sort of like they don't make you want to join to prototype, to explore. And I think that this is how you build resilience in bigger companies where majority of people focus. on your impact and, you know, all the, all the right stuff. But then you need someone who is sort of like, oh, I'm just going to take a risk and, like, see how that plays out for no, like, you know, not expecting anything particular to happen.

It also kind of reminds me of, like, the discussion of metrics versus, I guess, vibes for lack of a better word, is that there's a lot of merit to that hyper-optimized way of thinking. But it also is the trap of, like, you know, local maximums and like, you want, if you want to monotonically increasing number, it's not going to, if you're not willing to take the down, you might not unlock like some, you know, step change. Yeah, I think that there is definitely something to be said about the good heart law that the second you choose something, you elect this number to be a metric, it ends up being a bad

thing because people end up sort of gaming it. And so it stops being a good metric, right? And so, and that is even before you sort of think about the fact that many things are not even measurable, right? And so you have to rely on the taste. You have to rely on like whatever else to build, you know, good products to make sure that, yeah, you're not getting trapped in a local maxima. It is hard. It is hard. Especially it's hard to make a framework out of it. I feel like for and large companies need frameworks because nothing else scales. You did 10 teams in nine years. I'm curious, looking back on all of them. Is there any of them that you, the team switch, you kind of regretted or maybe it's like a team switch where you thought, oh, actually that one,

looking back maybe not ideal. I think that there were some that didn't pay off as much as I was hoping to. But I think in reality, you sort of learn from all of them. You learn something. So that's, yeah, going forward, you at least try to avoid those sort of lessons again. And in most cases, again, you're sort of like, if you're a decent person, you work and you try your best. you end up just building at least good relationship with people and going forward. Those people can, you know, bring you on to the next project or you bring them or, you know,

you just sort of end up building a massive, massive network. This is something that I really only truly appreciated once I left Meadow is how many people reached out and asked if they can introduce me to people, asked what am I doing, a bunch of people reached out and asked if I can hire them into this thing that I'm doing, which I don't know what it is yet. It is definitely a really, really fun adventure, and you get to meet so many cool people that it's just hard to overestimate, yeah. Yeah, I had never worked directly with you, but I knew of you. So clearly what you had done cast a very wild.

Yeah, it's wild to me. When people reach out, they used to reach out on work chat, and they would be like, oh, hey, we like talked in 2020. And my memory is also horrible. And so I just rarely remember things that happened like more than a year ago. I always feel terrible, but I also feel so humbled by like, oh, oh my God, people know. This is so cool. It's really fun. Now you've left Meadow.

What was the rationale for leaving Meadow rather than doing another team switch? Yeah, I think that's, well, it's been a really long time. And I started in startups, and I felt like I wanted to go back to the space where, you know, pace at which I prefer to move is the natural pace. So, you know, you end up taking on far more risk. Financially makes no sense. Practically makes no sense. But right now, I have few ideas that I'm exploring, you know,

and I'm sort of like passionate about. And at this point, there is no meeting. There is no partner team that I can blame on the failure. It's like you're so close to the wire that you just, you try it out and you see if it works. And then again, it's a big tech. You know, you can always come back and like be hired into the next big tech company and it's all going to be fine, hopefully. but it is definitely a fun experiment to see how much, what is your actual worth, you know,

what are your ideas and all those things that you thought you can deliver on, like, can you actually do that? So I think it's going to be an interesting exercise. We'll see. So it sounds like you laughed because you wanted to go even deeper into like prototyping and like doing your own thing and being unbounded. And it's a two-way door, not a one-way door. You can always crack.

Yeah, that's the way. It's a really good framework that someone mentioned before, that you need to think really carefully when you enter one-way door. When it's a two-way door, or at least it looks like one, you need to be concerned and like sort of careful, but also take a risk while you can. Yeah, and I'm sort of like still in the place in my life where I'm lucky enough to be able to take some risks.

And then last thing is looking back on your career, and if you were to talk to yourself when you had just entered the industry and you could give yourself some advice, what would that thing be that you tell yourself? Yeah, I think that's one thing that one of my managers told me, and I think it's coming from one of the consultancy frameworks where, you know, at first I honestly thought that I need to fix all my shortcomings, fix all the things that I'm sort of like softer at. And my manager told me, you want to make sure that they don't get on your way,

but you really want to focus on your strengths. And so I think that that was a relatively high-opening, as obvious as it is, it was a relatively eye-opening sort of advice. You want to position yourself where you can showcase your strength and where your weaknesses are not getting in your way. I think that whatever that means in your case, this is probably how you're going to be the most successful long-term. Yeah, that reminds me of something that a VP had written early Facebook.

And he said something like one of the big learnings was that the value in where the real impact come from is not from taking something that's poor and bringing it to passable, but taking something that's great and making it excellent. Thanks for taking the time. I was really looking forward to it. And is there anything you want to say to the audience?

No, I think you can find me on Twitter. I'll probably be sharing more about stuff that I'm building on there. And yeah, thanks so much for inviting and having over. It's been a lot of fun to chat. reflect on all this stuff. Hey, thanks for watching the show. I don't sell anything or do sponsorships,

but if you want to support, you can subscribe on YouTube or you can leave a review on Spotify. And I'm always looking for new guests to interview. So if anyone comes up who you think you really want to hear their career story, let me know, and I'll try to reach out to them

and get them on the show. Thanks for listening, as always, and I'll see you next time.