The Unexpected Way To Get Promotions as a Software Engineer (Director of Engineering at Netflix)

I think A/B testing is a great way of getting some kind of directional information about how it's going to play out, but there's also A/B tests that win that actually are still bad for the user. Right, so at some point you have to have a vision and conviction around what you're building and why you're building it.

[Music]

Host of the Coach of Code podcast, where we invite experienced and successful software engineers and engineering leaders to come on and share their journey and what they've learned in their career. In today's episode, we have Nash Rogan, director of engineering at Netflix. Nash spent the early part of his career in consumer hardware, working on companies like Palm and HP. And then one thing you learn about this experience at these companies was that consumer hardware is a very competitive space. Since then, he's moved into companies like LinkedIn, where he spent seven years working at Lynda.com, which is now LinkedIn Learning, and then learned a lot about distributed systems and cloud computing. And has now transitioned to where he's at currently, which is at Netflix as part of their Studio engineering organization. Welcome, Nash.

Thanks, Felix. Thank you for having me. It's exciting to be here.

Yeah, excited to have you here. So first of all, you have an amazing two-decade journey, starting at Palm, not Netflix, and you mentioned transitioning from spending a lot of time in consumer hardware now into into companies like LinkedIn and Netflix. How difficult was it to make this transition from one industry to another?

Yeah, it's a great question. You know, when I was doing consumer hardware, it was all about bits and bytes, and it was all about the constraints that the hardware would provide. Uh, and now when you think about uh, and actually even on computational um, uh photography when we were doing processing on the desktop, was about what CPU cycles you could gain out of the processor. Uh, and then when you go to cloud computing, all of a sudden it's like nobody really thinks about the bits and bytes anymore, and everything's about CPU cycles. Um, and so it's been um, it was a really different kind of trajectory because I realized it wasn't about um what the hardware was limiting you to; it was really about what you could achieve with all of these kind of centralized data stores, if you will, right, where you had all this data at your fingertips. Forget about how many cycles you were using; what could you get out of it? And so it became more of a an interesting transition from like, how do I operate within limitations to how do I operate without limitations, and what things could I generate and provide? Uh, because as you know, scaling cloud systems are pretty easy—just throw a bunch of hardware at it, and just it, you know, you vertically or horizontally expand. So um, yeah, it was a really interesting kind of transition.

Yeah, I think it's important that when the constraints change, your—you kind of have to think differently, maybe maybe bigger. I'm not sure if that's the the right adjective to use here, but how did you make sure not to kind of uh, I don't know, scope down your your creative thinking once you've not hit this point where the sky's the limit to some degree when you're moving into more of these kind of cloud computing spaces?

Yeah, I remember one of the first—so when I joined LinkedIn, I actually joined as a staff engineer. I didn't want to join as a manager, just to see like what it was like to be on the ground and also kind of experience kind of engineering again, you know, it's kind of one of the things that go back and forth on about. And I remember writing some software, and I was like really concerned about every bit and byte that I was doing at the time. It was really early on in my career at LinkedIn, and uh, I remember doing a code review; I was like, I think I can save a couple kilobytes if I do this differently. And they were like, they're like, what? Like, why do you care about that? And uh, I was like, I don't know. And they're like, well, what about like what features are you delivering on? I was like, well, I can do this and I can maybe do this if I had like, you know, a couple hundred megabytes. And they're like, dude, you have gigs on the server; go for it. And so it was that moment where it kind of clicked for me. I very vividly remember doing this code review, and I was like, oh, like why am I worried about every bit and byte and every cycle? And and that kind of inverted my brain a little to think about like, if I didn't have to worry about that, like what could I deliver on? I think that was pretty critical for my like um, path of evolution. People now—that's not to say we should be worried about bits and bytes and facts. Uh, I think all great engineers are worried about those things, and they think about them thoughtfully, but it's an interesting transition to think about like what can you do without thinking about the limitations first, because on every piece of hardware, and it is true even on iPhone, Android today, even though they're pretty incredible devices, that you think about the limitations of hardware first before you think about what you actually can generate and build.

Yeah, and speaking of building these kind of habits where you are thinking about everything down to how do you save kilobytes of data or storage, how do you recommend people that are kind of bringing habits from career to career, and maybe some of them are bad habits? How do you make sure that you are maybe introspective enough or recognize that I'm actually bringing some bad practices from one company to the next, or maybe from year to year in your career?

I don't think you know it's a bad practice until somebody calls it out. You know, it's one of those things where you do it, and you do it a lot, and then somebody goes, "Are you sure you should be doing that?" You know, I was um, in this this kilobyte example, I remember somebody was like, "Why are you even worried about that?" And like, it didn't dawn on me. So I think having a sense of—of, especially when you transition careers or if you change companies, the things that you learned in a previous company or previous career may not be applicable to the new thing that you're doing. And so I think it's it's really wise to keep open ears and eyes open and reflect on: Are my actions or my behavior like, is it because I'm doing in the past, or am I doing it because this is the way it's defined in the future? And be open to feedback and be open to like how people are maybe responding to you or critiquing you. And so um, I remember even joining Netflix, there was an example where uh, somebody got up on stage and they acknowledged a bunch of teams, but they forgot to acknowledge my team. And so I was talking to my bosses like, "Man, I really wish I could tell this person that they should have called out my team." Uh, and uh, he's like, "Well, this is part of our feedback culture; you should just do it." And I was like, "Oh, oh, okay, yeah, absolutely." And so, you know, is um, it doesn't matter how how senior you are in your career; there's always an opportunity to keep learning and keep keep uh, being aware of of your surroundings, being self-aware, and getting feedback. And so I think um, I do it to this day, and I'm sure the next career, the next company I ever worked for, same thing—that's going to go through it again. So just um, be open to feedback.

Yeah, speaking of being open to feedback and adapting to your different environments, you've been involved in a lot of product reboots through your career, both at Palm and then at LinkedIn. First of all, what does a product reboot—what's involved in it?

Yeah, so a product reboot, in my definition, is when uh, you've got this existing product that's got a user base for it, but it's not actually—it's not ideal in the way it's solving its problem, or you're pivoting to change a slight—solve a different slightly different problem. And so uh, reboot is generally like you're going to transition this thing from one one direction to another, or from one UI to another, uh, where you're going to solve problems maybe a little more elegantly, or you're going to solve different problems. And the catch with a reboot as opposed to a product build or a new feature, a new product, is that you've got an existing customer base, right, and you don't want to burn your existing customers as you're transitioning to this new product. And so um, every product I've been at—most products, I should say—I've been part of reboots. Um, the one that comes to mind is probably like the the one is the LinkedIn Messenger reboot that I was a part of, where we changed LinkedIn emails to chat-like features. So now everybody uses it; it's pretty standard, but there was a time prior to LinkedIn uh, sorry, prior to the chat features where LinkedIn was just—everything was email, kind of sort of. It was like we called inmail emails. Um, and it wasn't an ideal situation where it fostered like really collaborative discussions, and it wasn't very um engaging. You know, it was kind of like really uh, boring and old. And so um, but the reality was—I remember talking to Jeff, who's a CEO at the time, and he was concerned that like, hey, like inmail does generate revenue for the business, and was this have a negative impact on on our revenue if we transitioned it too hard? And so we did some very uh, delicate tests, if you will. We tested our way into this theory, and it turned out that it was not just highly engaging—double-digit percentages of engagement were lifted as a result of this. And so um, but the fear is that when you reboot a product, you burn your existing customer base, and that's the worst thing that could happen because at the end of the day, you're there for a reason; you're there because of that customer base, so you want to make sure that you're meeting their needs, but also uh, evolving it to a way that made sense. So, for example, um, when we when we rebuilt the LinkedIn Messenger app, or the LinkedIn Messenger feature, I should say, um, we still enabled you to reply through email because we know people's common uh, workflow was email engagement, right? It wasn't through chat. Then eventually we deprecated that, but this this whole concept of like, hey, how do we blend email and message and eventually move them over to messaging and chat was a big deal. Um, so that's that's kind of the um, the difficulty of product reboots.

Yeah, and I think you mentioned that you kind of tested your way into this, and that I think that's important in bringing up because usually when something is working, especially when it's bringing in revenue—maybe millions of dollars—people just don't want to touch it; it's working, like let's not let's not tinker with it. How do you kind of get buy-in, especially when someone that's maybe not a senior—maybe you're working on a smaller feature, but it's still something significant and involves again buying for management to to test out—how do you recommend they go about uh, encouraging or convincing the team to change something that again is already working to some degree?

Yeah, this is actually something that I can appreciate; it's very different in spaces because of my career. So, for example, in the hardware space, let's say you want to add some of the hardware; there wasn't a test that you could do. It's either it was going in there, and it was going to the manufacturing lines, and you've got to have some little conviction that's going to work, otherwise you're burning tens of millions of dollars, whatever it is, and your manufacturing lines and your manufacturing process. So you got to get it right when you're going to manufacturing. Uh, now if you if you compare that with uh, cloud software, for example, you can do things like A/B tests, right? You can actually roll a specific feature and go into a specific set of users or a cohort and say, "Oh, okay, this looks like it's going to work, or maybe not; maybe we need to tweak it." And so um, I think A/B testing is a great way of getting some kind of directional information about how it's going to play out, but there's also A/B tests that win that actually are still bad for the user. Right, so at some point you have to have a vision and conviction around what you're building, why you're building it. And I think, you know, when you talk about influence, there's a couple things that that really need to have: One is you need to be have vision and conviction around the thing that you're building and why you're building it—be very clear about the problem that you're solving and why you're doing that. Um, and then two is I think you need somebody who believes in that idea as well. So, especially on the ground level, it's really hard to influence, especially executive teams. And so having a VP or a director or somebody who can kind of say like, "This is actually not a bad idea; let's go pitch this," and going around and talking about it is really helpful. And then three, if you can roll it out in a way that minimizes impact on the business, I think that's critical. And in the sense that like uh, A/B tests are phenomenally cool because you can test it out in a small cohort of users and then determine whether it's something you actually want to roll out and impact the business or not, right? And there are some changes where—so, for example, I was doing uh, the home page, and it was really hard to test some of these features because as they went out, it would impact your ads revenue, for example. Um, and so you want to be really thoughtful about your rollout strategy to minimize impact so that way when you influence people and telling them, "Hey, trust me, this is going to work," the the trust doesn't have to be like you're either going to make or break the company; the trust has to be like, "Can you design it in such a way and roll it out in such a way that it's not going to have minimal impact as you're testing it," right? And so I think that that's the the key strategy—of how much information can you get without wrecking the business before you can kind of improve that idea and get to a point where it's actually gonna have positive um, uptake, if you will.

Yeah, I like how you you mentioned that where trust is not about "Trust me as a person," but trust that this process of how I'm rolling out, how I'm testing it is something that we can we can live with—that is not going to break things, and it can actually give us the results that we want.

Yeah, I think that's super critical, you know, and this is the coolest thing about cloud computing and like this cloud software is you can say like, "Hey, I'm gonna go test this out in like a country market or for specific types of users that fit this demographic, or I'm just going to test this on 100 people," or whatever it is, but you can confine and control that stuff. And so um, it's not something that existed on hardware back in the day; it was—you you got it right, and if you're lucky you can get signals back from like, you know, end-user or CSAT surveys or NPS surveys, but nothing really gave you the level of real-time feedback like you're getting in cloud systems today. And when you think about this from a career standpoint, I think a lot of listeners out there might be thinking about this is that reboots might not seem as like glamorous, right? Because most people are focused on launching new products to grow their career; you want to make a big splash—like a new product is just sexier—that is just has a a bigger headline maybe than a reboot. How do—how do you think reboots still have—have helped you create—how have they impacted your career?

Oh, man, I uh, you know what's funny is I think about it the other way around. So I've done reboots, and I've done new products, and the catch with a new product is you have to prove product-market fit, and you have to prove a growth strategy, right? So it's not like you come up with this new product like, "Hey, cool, look, I built this"—like, for example, I helped build the first Lytro camera. Does anybody know what that thing is? Nope, right? Like nobody knows what it is because it didn't catch, right? And so there's probably a couple thousand people out there that own these cameras, but at the end of the day, nobody knows about the first light-field consumer camera because it didn't really catch. And so it's cool; it was fun, but it didn't have the impact on the world that I wanted to. But when I think about an existing product and a reboot, I get to play with an existing customer base and improve what they're already using. So I get immediate feedback and ideas about—"I'm using it this way, but if you just did this one thing, man, I would use it so much more." And being able to see these lifts uh, over time is is is I think more um exciting, specifically because you get to prove that there's value, and there was value in the things that I was building from the ground up, but it's really hard to prove it without growth, you know, like a whole story, and the whole world knows and acknowledges it. In this case, people know it already; people already love it; you're just making it even more awesome for them, and I think that's pretty rewarding.

Yeah, and I think there's a lot of emphasis—especially again, people that are listening want to learn about how to advance a career, how to grow their career, and one of the most important things you hear about is having an impact—having an impact in your organization, your team, in in the business. When you think about the word "impact," though, is it about business impact where again, especially we're talking about like—and I see someone that is, you know, mid-level, junior, or senior engineer—is it about business impact where they are actually, you know, driving more revenue—like how—how much of that is their responsibility versus like what do you consider the work impact to—to me—like what responsibility does an engineer have uh, when it comes to impact?

Yeah, it's—oh, man, it's such a great question, and I'm smiling here because the word "impact" in itself is probably the most overloaded term uh, and today it's so overloaded, right? It's um, and it changes depending on the position you are in the company, and as you grow uh, and evolve to more senior positions, like the types of impact you have are going to be very different. Like um, you know, when you start off as an engineer, especially a junior engineer, your impact is probably about like um, how much you can impact the product or a feature or a bug, and then eventually it evolves to like how much can you impact the process or the team, and then it goes to how much can you impact the culture, and eventually it gets like how much you impact on the bottom line of the business, but that takes time to get there. Uh, and so I think this word "impact" is really a double-edged sword. In one sense, you want to be thoughtful about your impact because a lot of times that's what you're measured on as how well you're doing in your career—how much impact are you generating? The flip side of that problem is that uh, the impact definition changes over time. Like if I if I was to like write my resume today and say like, "Hey, you know, I fixed three bugs yesterday, and I was crushing it on impact," people be like, "Dude, what are you doing? Like, that's not what you're supposed to be doing." Uh, and conversely, if you know, we had a junior engineer saying like, "I tried to increase revenue by 10 million dollars," and be like, "That's impressive, but I don't—I wouldn't expect a junior engineer to be able to do that." And so I think it starts with the most fundamental issues about like how we're developing products in terms of what we're doing, how we're doing it—so bugs, features, and then process, culture, and then it evolves to like more business strategy stuff. But I would say for the junior folks, focus on the thing you're building and and ask questions about: Is the—is this the best way I could be building it? And then eventually you'll build enough context to say, "Is this the thing I should be building?" Right? And then you'll have a more context to say, "Is this the right thing we should be going after? Right? Is this the right market we should be going after?" So um, I think it evolves over time, but

I don't know if that that answers your impact question. There. No, it definitely does. I think it evolves over time, as like the the kind of key takeaway from here. And you mentioned too about let's say a junior engineer was like, "I did something to to generate or save 20 million dollars." Like you wouldn't expect them to do that, but could it be? Is it harmful if they focus to maybe at an impact level that's like multiple levels up in there? Or like is there is there a harm in trying to save a copy 20 million dollars? Like you should do it differently. I think I think any manager, leader of the company would be crazy to say like, "Oh, you can save me 10 million dollars. No, no, don't do that. Just go fix the bug." Right? Like I don't think it's harmful. I think it's hard, and I think it also varies on the size and the state of a company. So like if you're at a startup, or you're at a small Stage Company or a smaller size company I should say, where there's a lot of direct contributions, like you build a feature and it results in in huge amounts of subscriptions or growth or purchases, that's great, and and that's absolutely what you should be focused on. But as you get in a larger and larger scale companies, what you realize is that it becomes a lot harder to impact the bottom line of the business, and so what you end up doing is trying to connect the dots between what you're doing and how to drive that like bottom line, and it becomes more and more and more indirect. And so at some point, like if somebody joined Netflix as a junior engineer, let's say as an intern, I was like, "Hey, I want to improve the company's Revenue by 40 million dollars," I would be like, "That's great, but that might be really hard to do," right? Uh, only because the opportunities that have direct lines to that values is actually uh very difficult to draw.

Yeah, and you you said that it the the impact or the maybe the the um the outcome or or maybe more directed the feedback Cycles as you go up or get longer and longer. How do you make decisions then when the feedback Cycles are are so long, especially as you are kind of using a, you know, you you're at a level where a decision you make just doesn't play out for a very long time? There's really two things, maybe three things that um causes to happen. I think the first is um confidence and direction, right? And confidence and direction is not blind confidence; it's informed confidence in the sense of you have enough context about the business, you have enough context about your competitors, and you have enough context about your product to be able to make an informed decision around your confidence level about what direction you want to take it. The second is [Music] um directional data, and and I think um data is a double-edged sword too, because it'll sometimes tell you what you want to hear even though that's not the right the truth, you know. And this directional data could be forms of A/B test, it could be MPS or CSAT surveys, it could be anything that tells you that like directionally um you're going in the right direction. Uh, and the last one I think is purely these are lagging indicators, but they're they're um they're like business metric related in the sense that you could say like, "Hey, I was able to save 10 million or optimize 30 minutes of every engineer's time," or something like that, which is in theory good, but the problem is like you don't realize the impact of that and the value it's brought to the business until later on, right? So like there I guess it's directional guidance, but it's more of a a business line guidance than anything else, where it's like you can tangibly say that you've had this value or direct a meeting impact. The long-term impacts can also be negative, and that's the catch that you have to always be aware of. And so this is where this informed confidence in this context is really helpful. It's like you know enough about the business of a long tail to say, "I think if we do this, here's where we could go. Here are some other options that maybe not as good, but here's where we could go," and keep guiding in that direction. And so a lot of it is really about how much confidence you have, how well informed you are, and the directional data that tells you, "Yeah, that's probably the right direction to go."

Got it. So we took a little bit of a detour here, but going back to this idea of the how impactful a reboot can be to your career, um if someone out there is bought into it, like they're okay, they're going to stop focusing on trying to grab new projects, new product launches, and go and try to fix and prove something that already exists with the existing user base, how do you find those opportunities? How do you not only find them but then make sure that you're top of mind when it comes to having like a lead to work on a reboot for a product? Yeah. Um, I was fortunate enough in most of my career to have strong Advocates, of people that were always thinking about me, um and uh I would say, you know, in my earlier days that Palm it was folks like Vashiloco, it was uh and then it was Karen Prasad, and then at LinkedIn Karen brought me over to LinkedIn, uh and then it was Adam who brought me over to Lytro, and that was Sam who brought me over to Netflix. And so like at each one of these moments in time, I would say I had a strong advocate for me. And so the thing that I would say is I think a lot of life is based on relationships, and a lot of career even like you could say it's part of uh your personal aspect of of the world, but it's also your professional aspect as well, in the sense that um if you don't have careers in Connect, or sorry, if you don't have relationships and connections with people, uh you miss out on opportunities, and I think that's true regardless of what industry you're in. And so my advice, and this may be biased to my experiences by the way, I'm sure everything I've said is biased to my experiences, but um I would say make sure you're connecting with people, that you're spending time with people, you're talking to people that like, even though you're an engineer and your job is to produce code, at the end of the day we're working in this like crazy Universe of connected Souls that I'll have to talk to each other and interact with each other in order to get stuff done. And so uh in order for us to be successful, it's going to require strong relationships, and I believe the stronger relationships you have with your managers and your directors and those who are like having these opportunities come to them, they'll think about you. Especially as you have those, and by the way, strong relationships don't mean like, "Hey, let's grab a beer," whatever you want it is, have you had an opportunity to share your thoughts and ideas about stuff too? Have you riffed with them? Have they given you feedback on those ideas? Have you expressed interest and passion around things so that that way when things come up they're like, "Oh, I knew who's passionate about this; it's this guy or this girl." And so I would say the relationship aspect is often under looked, um and at LinkedIn we used to have one of our main cultural townships, "Relationships Matter," and I couldn't agree more. Relationships do matter.

Yeah, speaking of you mentioned that uh someone brought you over, I think you said Sam brought you over to Netflix, and but between the joining Netflix and LinkedIn it took some time off, several months maybe. You referred along your career, so it might not be as impactful, but I think some Engineers out there might be thinking about taking a much-needed break in between jobs but worried about how that might impact their career. Any advice on here? What was your experience with taking that break? Uh, oh man, this is a great question. I I think it was a pretty profound uh time for me. I think it was a great time to reset and recalibrate, and um I would say, you know, what I I it doesn't really matter who looks, anybody who looks at your resume goes, "Oh, you took three months off; that's not okay." It's like that's probably not a place you want to work for anyways, right? Like any anybody who who is a human and recognizes the value of time off will appreciate and go, "That was really cool. I'm glad you got a chance to take that time off, and I'm glad you're looking again." Um, and I think the earlier on and I've said this actually about uh startups and stuff is the earlier on you are in your life in your career, the more kind of flexible you are to um to to like Financial kind of instability. So like you don't have to worry about a mortgage, you don't have to worry about a family, you don't have to worry about kids, you don't have to worry about college, all that stuff is kind of behind you, and so you have an opportunity to be a little more flexible. And so I'd say like if you're thinking about taking time off or doing a startup or joining a startup earlier in your career and in your life phase is kind of like a better time to do it than as you get further on. You still do it; it just comes with a lot of costs you have to be really thoughtful about in terms of like, "Okay, I'm gonna get paid a lot less and get Equity, but uh do I want to do this for my family, for example?" Right? Or is this the right choice that I have to take on just the right risk I'm willing to take. And so um but I would say absolutely take the time off and go explore it, and um I'm I'm a little of an odd duck when I say this, but I feel like life is so much more than just about work, and I think if you can't find the joys in life outside of work, then I think you're doing it wrong, man. I think you really need to be able to find happiness all around, at work, in work, outside of work, all that good stuff.

Yeah, it totally makes sense. Um, when speaking of finding Joy at work, one thing that you recognize at Netflix was their unique coaching and how it was a lot different than your experience in other places. What what is the Netflix coaching? What do you like about it? Yeah, so Netflix culture uh is really all about um enabling autonomy, I believe is the best way I can put it. There's Concepts like freedom and responsibility, context not control, people over process; all of these are saying we TR we hire great people, when we trust them and make great decisions, so let's enable those decisions that happen at the lowest level possible. Um, and I think it's a very empowering thing to do, and it's actually really great because at the lowest level, even at my level, I'm not allowed to say like, "We should do this." My responsibility, my job is to go out to my engineers and say, "Hey, here's some context about what's happening the business; how do you think it is the best way to solve it?" And they'll come up with multiple ideas, and we'll kind of Riff on them and choose one, but it's not other unlike other companies, which is what I would call um in quotes a tops down kind of driven company, is the VPs, the directors, whatever, they would make decisions about what direction want to go, and they Cascade it down, say, "We're going this way; follow me," right? Um, and while that is um it's an easy way to make quick pivots and maybe move fast, what it does is it removes the ability for your smartest and most intelligent folks to have an opinion, right? And so I think the one thing that Netflix does a really good job at is soliciting ideas and opinions from folks across the organization, say, "Hey, what's the best way we can do this?" And what's the best way to achieve this objective, not the solution, but the problem, how do we solve the problem the best way? Um, and so this level of autonomy, this level of like enabling the kind of lowest level of the organization possible to make the strongest decision, I think is actually it's a pretty profound way of of thinking and executing that I've never really appreciated or thought about. So I got here uh so at Netflix you are building software, your specific role, your specific team, you're building software for partners, and that comes with unique challenges compared to building software let's say for like end consumers. What is unique about the challenges with building software for partners?

Yeah, that's a that's a great question. So there's a there's kind of two halves of software development if you really think about it; it's they're really over generalized, and so there's kind of a lot of gray area here, but if you think about the two halves, there's consumer and there's Enterprise. And so what consumer means is you're designing products that are meant to go to end users and be used and just used and consumed by hopefully millions of people, right? The enterprise software is where it's designed to be used by people who are getting their jobs done, so they're not like Bob sitting at home on his couch; it's more about like Joanne at our desk at work trying to get work done, how do we help her out, right? And so when I um when I think about Enterprise versus consumer software, I was mostly in the consumer software space, even in the hardware side I was mostly consumer, and then when I uh when I would joined Linda uh I was doing both consumer and Enterprise, but what was an interesting kind of tidbit was that Enterprise was uh was generating a significant amount of Revenue but didn't have the Equitable amount of Engagement, which meant people were willing to spend a lot of money in Enterprise for very little or lower engagement than you expect for Consumer. Um, so the good news is there's money in Enterprise, but the bad news is uh nobody really tells you how good the product is and that's really the the biggest or how bad the product is I should say, and that's kind of the biggest kind of conundrum is you know when you've got millions of users using your product, you're able to do A/B test pretty easily, right? You can say like, "Oh, I'm just going to roll this out to this 10 of people; it's fine," but what if you have 50 people using your product? How do you know that? And by the way, all 50 people are required to use your product to get their job done. So first of all, doing an A/B test of statsig is really tough, right? So like and maybe they're only using it once a week, but that's an absolute job until they have to get done. So 100 engagement, you have 50 potential users, they're all using it, cool, 100 engagement, awesome; are they all getting are they all clicking that button? Yep, they're all clicking that button. So like the data doesn't really tell you that you're actually doing a great job at the tool, and it doesn't even tell you and by the way maybe you want them to spend more time in the tool than other places instead of like, you know, spreadsheets or whatnot. So increased usage might actually be a good thing, but maybe that means that the workflows are really slow; maybe you want to get them out of it; maybe just because they pressed that button doesn't mean that the tool everybody loves it, right? And so like this a concept of A/B testing, this concept of like your customers love it becomes a much more difficult problem to solve. And so this is where um I'm fortunate enough to work and create software that serves both external partners and internal partners and customers. And so um in the studio space I I work with a lot of internal partners that create software that does things like dubbing or or storage for Media or whatnot, and so uh they all have to use these products to get their job, but there's no option. And so if you ask anybody like, "Do you like this tool?" It's like, "I mean, yeah, that's what that's what I use, but it's the alternative," right? Um, and so the opportunity to be able to identify where can we improve and what's better for the product requires a lot of like engagement from our Product Managers, from our designers, and from our Engineers to say, "Hey, how do you like to say what can we build to make this better for you?" And oftentimes you would be able to A/B test in a consumer rule, but in this place you've only got 50 people, maybe they use it once a week, it doesn't really tell you enough; it's not stat saying, it's not fast enough. And so I think that's the catch.

Zooming out a bit, looking at the kind of the entire length of your career, what would you say was it one of the bigger or biggest myths or misconceptions that you had at these different career transitions, either from level to level or from company to company? And then what was the truth that you found out about it? Yeah, I I'll tell you one misconception from level to level, which is really uh kind of interesting, is that I I kind of assumed when I became when I went from an engineer to a manager that I was just doing my work but just being able to leverage more people to get it done, right? It was kind of like I've got two arms, but now I've got four arms, and now I've got six owners, like how do I do more stuff with just like the same brain and attitude and capacity? Nobody ever told me that being a manager or a leader in an organization is 100 different, night and day between that and and being an engineer. And so in success of of being an engineering manager or a leader in an organization or a company looks vastly different in terms of the things you're doing on a daily basis and the types of things you're impacting versus what you would be doing as an engineer. And so the beginning of my career I went back and forth; I still kind of want to go back and forth a lot, right? So there's there's days where I'm like, "I'm in code; I'm looking at it; I'm like, 'Oh, man, I really wish I would write some code.'" And then the other days I'm like, "Oh, man, I really wish I was like leading this team to help them figure out a better strategy for this going forward." And so um and you'll see as part of my career I was I went into management at Palm; I joined Lytro as an IC; I went into management again; I joined LinkedIn as an IC; I wanted a management again; and then I was finally like, "You know what? I gotta stop going back and forth; I'm gonna go straight into management at Netflix," and um I I think by the time I was uh by the time I got enough list I was kind of aware of my path, but the LinkedIn kind of era was really important for me because I never really appreciated the difference in moving from engineer to manager. I think that was the probably the biggest surprise for me that I'm uh I've learned to appreciate.

Yeah, and because it's such a vastly different job, like you're saying, and it's not just like a natural progression or transition that just obviously makes sense, how do you help a a employee, a report of yours that comes to you and asks, "Is management right for me?" I I love this question because um it's a very common thing, right? So especially when you're you're a senior engineer and you're you're making this choice about like, "Do I want to manage people or do I want to keep going down my IC path?" It's a very very very common question, and um the thing that I always tell my managers to look out for and when they have these conversations with their ICs and their Engineers is what's the motivation, right? So ask like oftentimes what I'll hear is like, "Oh, well, I want to get promoted, or I want to make more money, or I want to like do something different." Those are all fine answers, but they're not good reasons why you should get into management, right? And what you want to look for is like, "I want to grow people, or I want to have more strategic conversations at a product or a business level, or I want to interact more with my product Partners," or like those kinds of things kind of warrants like a discussion about like, "Okay, does it make sense for you to transition to management?" And when you do, setting those expectations about what happens. So by the way, a lot of your time is going to be in

Conversations you're going to be enabling; coaching others. You're not going to be on the on the on the ground actually coding or doing the work. At some point in success, you won't be talking about code at all. You won't be talking about like technical stuff at all. What we're talking about is how do we do these things, and what's the most effective way to get it done? And so making sure that they have the right motivations, and then making sure that they're aware of the success of the role is exciting to them. I think that's critical.

Thank you so much, Nash, director of engineering at Netflix. Thank you so much for coming on and sharing all your experience with us.

It's a pleasure, Felix. Thanks for having me.

Thank you so much, and that's all the time we have this week. Come and hang out with us next time on Post Your Code again. I'm finished here. Take care. [Music]