Instagram Staff (IC6) Promo Despite 10 Team Switches in 9 Years (Career Story)

0:00When 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? 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 never go there. Eventually you went to a series of teams that I'm really interested in.

0:34For 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.

0:48Well, 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 I'm sort of like a weird hybrid of like design and engineering and like everything is kind of poorly defined.

1:22And he was like, listen, how about this? we're gonna build a team that takes all the design prototypes that designers always have like stacked up in their desk but never shipped right and we're just gonna build them and no metrics no nothing and it was inside of newsfeed uh facebook newsfeed i mean now if i would look back and i would hear newsfeed no metrics i would be like oh yeah this team is gonna survive half a year and it survived half a year uh but it was so much fun it was a lot of fun and like the 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.

1:56And the things that we built later, we found some metrics to 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, effects, 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 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 like high risk and like god knows if there is even rewards in there i saw those teams that you worked on initially the design ones and i was thinking how 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 of vibe so i'm curious like what does a successful project even look like in a space so i think in 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 and that's basically how those teams survive.

3:10So Facebook used to have this metric called cow cares about user. And this metric was literally a survey issued in a newsfeed that would ask you like some some broad question of like, how 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 on this like moment of delight and joy uh yeah it's sort of like harder to 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 i'm 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 you explore some opportunities and later again sort of like looking back they all make sense mostly because practically 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.

4:37Later 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 that 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?

5:15And 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.

5:55They don't just come up with this idea in a 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 don't have this field in their data? Whatever. So, like, you need this constant dance between, like, here is this idea that we want to achieve and here is the real-world inputs. But oftentimes, what I would find even more fun is when you show designers, oh, look at all those cool capabilities that we can actually use in your design.

6:27So what if we, at the time, I don't know, what if you use some sort of 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 the top of their head is a fun way to inform their creations. But then also the saturation loop. Like in my experience, the tighter you can get this iteration 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 hacky version of Figma 2 unreleased device rendering pipeline.

7:04So the designers can just like see their Figma's on unreleased device as quickly as possible and just like move stuff around and like immediately see it being reflected. so like all those iteration loops the shorter they are the better and the more both partners engineers designers who have else's involved are ready to 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 uh you mentioned the short the short iteration loop but also it's kind of like this bi-directional 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 yeah 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 gonna build this crazy thing that you want and then you sort of then you can trim it down to 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 the device is just gonna blow up if it runs so so for so long or you know maybe Maybe, yeah, like processing power is not there.

8:10So 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 off 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.

8:42You switched teams multiple times, even within iOS. But then you switched 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, you know, 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 was like, oh, we like starting this new hardware team. And there was not really that much information.

9:19Like 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 OS. So like AOSP, it's like pretty standard practice. I think right now if you're like building a 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.

9:55they'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 once you plunge you know into the rabbit hole you're kind of like oh this is this is really fun and so yeah i sort of switched to the team first half a year i think i committed like maybe two diffs in the entire time yeah six months yeah yeah because 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?

10:28What kind of processors? What 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 like all your phones, all your whatever. So 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.

11:12So 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 like eventually I started like tracing the packets and sort 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 like it's a trash code and like you don't need it in the repository.

11:45And it was just done basically to inform what's the upper bound experience that you can get using this protocol, right? So like what can we hope to achieve once we productionalize this? And this ended up being a pretty common theme, I think, in my career from there on. It's 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.

12:18I 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? 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 they get reviewed based on de-risking a lot of directions and not necessarily lending code. Again, it's like the team that was sort of seated with a bunch of senior people. And so there was mutual understanding that 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 into those risky projects where you're not guaranteed a promo, but you're at least protected from the downside, right?

13:07Because you want people who are interested in taking risks to feel safe. And this is a lot of changes that's happened in the PSE cycles of a year where like it 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 I'm mostly software engineering initially and still like software, but in the hardware team.

13:45What'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 flash it onto the device. And so this is why the deadlines in the hardware projects are so much more ruthless. You cannot push them by one month.

14:21Everything falls apart. And so it feels like this is probably one of the key aspects. And yeah, you can have like zero day updates when you're like, you know, this annoying thing when you just bought a new device, you plug it in. 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, 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.

14:54Hardware makes you think in 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?

15:25So the time has come for me to try to live outside of the US again for a bit. And again, Meta 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 unreleased technology, like all sort of stuff that you like, I don't even know if that's the case here.

16:08But 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 cryptocurrency effort that Meta tried to take off the ground that eventually branched out into its own sort of separate company.

16:50But then we had all the talent and technology built in-house to sort of 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 build out a bunch of stuff. So I moved to London, joined this team and we shipped sort of your vanilla NFT type product within Instagram where you can upload your NFTs. They would have this like beautiful shimmering effect and all that stuff.

17:38Eventually 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 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 uh to ship the nft product but the actual thing that i was working on that was really fun and interesting to me.

18:13So at some point, Adam Masseri, 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 a certain platform, to their, you know, sort of policies, to their whatever contractual obligations. But then if for some reason you fall out of grace with this platform, you're banned, all your livelihood, like if you build some sort of followership, it's all gone. So Masseri 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?

18:49They can choose not to recognize it, but they can 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.

19:28And 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 this 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 this 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 technology's standpoint.

19:58But 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 business is, I guess, they charge merchants for selling stuff. And all sort of 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, you, 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.

20:36And 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.

21:19Well, 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 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 working on a very experimental, interesting project, Instagram threads. prior to its launch. I'm curious, how did you get recruited to that team? Because that's a really cool, interesting zero-to-one project. The writing was on the wall that the whole crypto efforts, blockchain efforts will be no more.

22:00And 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 ActivityPub, 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 prototyping, 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.

22:37I 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 like 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 from Mastodon.

23:19That 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, and 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.

23:57So 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, 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 code base 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.

24:30And 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 that kind of like you know you can squint and see it and then I worked with this super talented guy senior engineer uh Peter Kotl uh from Instagram and yeah like the way he sort of knows back end I feel like is sort of back of his hand um 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 we'll start querying this new feed source that you created, that's going to have only this special text post type.

25:11And like, and so we started like, sort of chiseling out the mobile experience from Instagram app, and from the backend. 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.

25:44So 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 like crash everywhere. So like that's where Peter really helped early on quite a bit. And yeah, we sort of started chiseling this out. And then I ended up being this 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 on. 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 time zones.