Peter Stout (Netflix)
The structures of an organization can often be self-reinforcing, and in a changing environment, this becomes a recipe for future vulnerabilities. That is why senior ICs need to play a slightly discordant role at times by alerting teams to issues conventionally outside of their bubble of concern. Peter Stout is a Technical Director at Netflix where he has a cross-functional role at the juncture of business and technology. He joins us on the show today to share some of the finer details around what inhabiting this position in the above manner looks like. We start by hearing Peter describe himself as a generalist, and share how this played out in the broad focus of his college degree as well as in his career pivot from Chemistry into Software Engineering. We discuss the rapid growth of the engineering team at Netflix, how this has led to less tightly-defined roles for junior and senior engineers, and how this factors into the way Peter approaches his place in the organization. Peter talks about the shift he made from technician to technical director and how much of the skills he learned from the former position he brings into the latter. He talks about his tendency to seek out the blank spots in the organization and how he tries to focus on a long-term vision, using that to guide him as he connects the dots between teams and influences decision making. Here Peter considers his role as a disruptor and how he gauges how much pressure to apply while still staying largely in sync. We also have a great conversation about Peter’s approach to mentorship and his philosophy around how he grew into the leadership position he occupies. Tune in today!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that sets staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas and I’m joined by my co host Alex Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest.
Alex: Yeah, Today’s guest is Peter Stout. Peter is a Technical Director at Netflix where he has a cross functional role at the juncture of Business and technology. He started out as a chemist but was drawn to the programming part of his work. So much so he eventually left the chemistry behind and started working as an engineer full time. This was an awesome conversation. I’m stoked for everyone to hear it. Let’s get into it.
David: Much for taking the time to join us today. If we could start by having you kind of just rather than me introduce you, why don’t you introduce you? What’s the story?
Peter: Hi, I’m Peter Stout. I am a Technical Director at Netflix, which is one of the two technical titles we have for ICs. I have a cross functional role there at the junction of business and technology. I report up to the VP of Platform Engineering, but operate across a broad swath of the organization. I’m a generalist by nature. I started out as a chemist as an undergraduate with a sort of a pseudo minor in Medieval history and Math cs. There was a bad course in each of them I didn’t want to take, so that’s why I didn’t actually have more majors or minors in them. After college I moved to Europe for a couple of years and worked doing a mixture of wet lab chemistry, computational chemistry, and computer programming. That led me to come to the realization that while I could do all of those things, I was more interested in having more fun doing the computer programming. So I went to graduate school. The program I ended up in was at the time as much a apprenticeship as it was a research program, and So I spent seven years there, nominally earning my PhD, but learning a lot about the craft of being a software engineer, after which I have spent 25 years in Silicon Valley working at a variety of companies, large and small. I’ve spent most of the last 12 years at Netflix in a variety of roles, so just two job titles while Distributed Systems and infrastructure. My background I have a tendency to aim towards the blank spots in the technical ecosystem at whatever company I’m working for. One of my co workers described me as being a dyke plumber.
Alex: Cool. I’m curious, you know, in your organization at Netflix, you know, are there typical expectations for senior ICs like yourself? Is there?
Peter: There are not. We have largely hidden those roles in the sense that what a senior software engineer is is not particularly well defined. Lauren Hochstein, who you spoke with earlier, talked to some of this. And so what one person does with that title and what I do with my particular title can be very different from other people there. And it’s in some ways one of the challenges that I think we’re facing right now, now that we’re a company of 2,500 engineers or at least 2500 people in engineering. That wasn’t the case when it was a few hundred people and trying to understand how we maintain our culture, but figure out how to make it easier for people to figure out who’s doing what and why is an open challenge for us. Cool.
Alex: So in absence of sort of like expectations for everyone, as a senior ic, you know, what expectations do you have for yourself as a senior IC at Netflix?
Peter: I am trying to connect the dots. Michael Saccati, in describing what he was doing at another company recently in a leadership community that I am in, talked about working on creating the organization that is solving the problems that while seven years ago I came back to work on a major cross functional technical problem, drove the program and the technical strategy for it. Today what I’m really interested in doing is creating a support network for the people who are doing those sorts of things today. That it’s not going to be a separate organization. But how do we create an interstitial fabric so those people can find each other, that the right connections get made, that we don’t miss the gaps due to knowledge or ignorance of something else going on in the organization. And it’s sort of that constantly looking for the gaps, trying to look forward, trying to look across the organization has been how I, in alignment with my boss of the time, have worked to figure out what’s the most valuable thing to do.
Alex: So one of the things that I, from your description is it didn’t sound very technical.
Peter: Well, so that’s one of the things. Well, yes, and that’s sort of one of the challenges that I have a small amount of imposter syndrome here. Am I really still a senior technologist? I mean certainly what I was doing five years ago absolutely will fit in with what Rich Lafferty or Mason Jones is doing today. I start to go, there are ways that I start to look more like a VP of engineering or something that I’m thinking about organizational structure. How do I enable these people to succeed? But I do come at it from a technologist perspective. Hey, I know that there are these business problems. How do we enable the technology and the technologists in our organization to help solve those business problems effectively or more effectively? And so I definitely am coming at this as being a technologist, but am I doing technology on a day to day basis? No. I mean, if I think about the question you like to ask people at the end of the day, at the end of the interview session, how much time are you spending coding? I’m not going to reveal my answer to that just yet, but how much time do I spend doing technology?
David: Even I was going to say spoiler alert.
Peter: Nope, I’ll save that for later. Everything in its own time. But the amount of time that I am doing, really technology versus hey, how are we having the right conversations around technology? That’s much more what I’m spending time on these days. Or it’s mentoring or it’s trying to enable the people who are learning how to do those things to do them more effectively. Cool.
Alex: Do you feel like the people that you manage though, or influencer help, the goal is like good technological outcomes, at least in part, right?
Peter: Absolutely. It’s like, all right, we five or eight years ago, we started creating our own content. Three or four years ago, we started to get serious about building technologies to support creating tens, then hundreds, now thousands of pieces of content a year. Well, that’s different from distributing thousands of pieces of content to people in millions of places. Oh, but wait, if you stand back and look at that pipeline, you can kind of turn it around and creating content looks like you’re running that distribution pipeline backwards. Well, okay. Just like stream processing can be the same or different if you care about real time or not real time. If you stand back far enough, it’s all the same. If you get up closer, you can see really important technical differences about. Well, you maybe don’t want to have one system. So how do we take the valuable pieces of technology that we’ve spent years figuring out how to do really well, bring them over to the content creation side and leverage them there. So that’s the collection of things. How do I get the right pieces of people who think they may be just working on the tools to create content to understand what the people who are building infrastructure to support the delivery of content need to be talking to each other. Or maybe they don’t need to, but the company might have a better outcome if they did. I spend a lot of time thinking about optionality and if you think about the cone of probabilities of where the company is going to go into the future and what business problems it’s going to want to solve, what products it’s going to want to deliver, particularly coming from the infrastructure side of the organization. It’s about what are the things that I need to be thinking about now so that product managers next year can be making choices that aren’t going to take them out of what we’re relatively nimbly going to be able to support because it’s much more expensive for product manager says, hey, I want to go do this thing and you’ve got no building blocks to start with it. It’s like, okay, I can ship that for you in two years. And they’re like, whoa, that’s not going to work. All right, now we’re back to chewing gum and bailing the wire. And.
David: So Peter, I I want to follow that thread, but I have to circle back to something you said earlier, and this is maybe going to sound like a troll question, but it’s entirely sincere. Feel free to skip it if you want, though. What parallels do you see between medieval history and and the kind of work that we do in technology today?
Peter: One thing I would say is that I learned to be the writer that I am by going to school at a liberal arts college, and they didn’t care that I thought I was a computer scientist. You had to learn to write. And the fact that I didn’t even think I wanted to be a computer scientist then. So that ends up being one of the things. But fundamentally I’m curious. And so the way it’s relevant is I don’t exactly know how or why it’s going to show up. I am constantly trying to vacuum up information just because I don’t know what I’m going to do with it. And this actually leads into an interesting intellectual dichotomy or sort of oxymoron for myself between trying to only ask questions where I think it’s going to help move the conversation forward or affect how I choose to solve a problem. That just being that letting out that inner two year old and going why, why, why, why? Isn’t necessarily helpful. There was a manager in the organization who a year or so ago wrote in sort of his weekly update to his team about always trying to move the Conversation forward, think, how do you engage with this, with the expectations the other people trying to do this thing have the best of intentions and how can you help it move forward? So how do you think? Think in that way? And so I want to ask the questions that will help me to understand why I have a different opinion than this other person or whether they see the challenges that I saw or whatever it might be to help that project move forward. But that’s around where I have to understand, I have to take energy and effort from somebody else. If it’s my time I’m spending, I’ll read all sorts of things, I’ll look at all sorts of things where the cost to anybody else is relatively low because I don’t know what I’m going to do with them. And that. Can I tell you chapter and verse of something that I did in my medieval history course? I didn’t forget the question, no. But the, the things that I got out of that, because one of the other things that I did was a course on the history of space exploration and the science behind that. And in some sense that might be the things that’s closer because it got me to start to stitch together my interest in STEM fields with my interest in history. And you can start to say that that becomes valuable in understanding the history of a company, why these things go together, and learning to remember that what you may think about them, reading or studying them years later, gives you some ideas that you can draw conclusions about, but you do not necessarily know what those people were thinking about in those moments. And it’s seldom useful to try to second guess those things. It is useful to figure out what you need to learn from what happened and how it played out afterwards, because they were making decisions in the moment. And to tie this back into technology, in a sense, one of the last major decisions where I got to own the whole technical thing, we’re going to do it this way, not that way, was rebuilding a system that tracked our viewing history. A decade or so ago I made the choice to do it one way and one of the engineers was pushing back and going, eh, I’m not sure this is right. I still think at that moment in time it was the correct decision. The world changed six months later when a whole different collection of load came onto that system and it caused us to have to scale it up in a materially different way and basically broke the assumption that I had. That became a decision point where I in hindsight feel I failed in going, oops, wait, we violated what I had as an implicit assumption in my head. We need to now go back and re architect this now and we never did. We put all sorts of additions onto it and we’re still struggling with that decision six years later. Thankfully, many people no longer realized that I had been the source of it, or they might come cursing me a little more often. But it’s valuable to learn about that. Hey, could I have foreseen that that changed six months out? Because six months was too short. I thought that there was a couple of years. I think in hindsight that it would be stable and viable. And at that time the company, we were turning over lots of system on a couple of year timetable. So let’s not get another service tier. We have to operate right now. But there were lots of things that were different and they made very different choices six years later when they were replacing that system with the next generation of things.
David: Yeah, that makes sense. As a side note, I think it’s funny, sort of the technical decisions we make that come back to haunt us. Things can move so quickly that a decision that you make a year or two ago feels like, feels like a lifetime ago and feels like there’s totally different information, you know, a year or two hence, but so be it. One of the things I wanted to dig into a little bit and we’ve actually sort of organically touched on a couple of them. But sort of going back to your role, I’d be curious to know, you know, concretely what are sort of, you know, to whatever degree you’re able and comfortable to discuss sort of ongoing stuff at Netflix, but more just for the listeners to have context, what would be the sort of project that, that you’d be involved in driving these days?
Peter: Today, that’s an ambiguous question. Netflix is a bit, is in something of a generational shift. Having turned over a bunch of senior leadership in the last year or so and leaning more heavily into product management in a variety of parts of the company where it didn’t exist before. And so exactly what my role is and fit into that is ambiguous at the moment. But a lot of it has grown from seven years ago when I came back to the company driving a project we called at the time Global Cloud, which established the core structure of our operating practices to manage single region outages. At the time, different service tiers did different things to handle traffic. And that led to some very intriguing failure modes. Our European customers were served out of one data center. Our customers in the Americas were served out of a pair of data centers. And we could steer traffic between the two of them and with Europe growing, that wasn’t deemed to be sufficient anymore. And so I drove the effort to be able to serve any customer from any region. And the steering is done at the front door of the ecosystem rather than farther down. And so now services just they get a request, they do the best they can with the data that’s available and they do no steering internally. And that has been the core of the operating practices that we use to deal with either AWS issues, our own self inflicted problems within a region. And where does that go? All right, you’re telling me about what you did seven years ago, Peter? Well, I have been building off of that to think about big cross cutting problems that impact a variety of things. We went to three regions which we were already operating back there and that was partially a cost driven thing. I started laying the groundwork for going, hey, we should be looking at doing more regions for the size of our load in any given region, the ability to consider whether we care about doing N plus 2 rather than N plus 1, et cetera, et cetera, and all the other things that you might think of in those spaces and have been pushing on those conversations articulating. We have a technical strategy session forum, or at least we used to for discussing some of these things. About three years ago I laid out a vision for hey, how I thought we could go about doing this. Decided again at that point in time it wasn’t quite the right thing. Last year or two I’ve been pushing on that topic again with a bunch of seniors leadership and there’s now an engineer within the platform engineering organization who is driving that next thing that is looking to expand into more regions over the next several years. And so it’s those long play, very wide across the organization things that I try to drive. How are we going to do regional resiliency? How are we connecting the dots between seemingly disparate business units, if you will, to actually get leverage from our experience in various different ways? Are we aligned organizationally to achieve those goals? Do we understand how to have those conversations effectively? Are we tying technical decision making to staffing decision making?
Alex: Interesting. A question that sort of occurs to me because I think the experience of a lot of engineers is that we’re always trying to do the best thing, the most valuable thing, you know, but it’s just, it’s really difficult to be sort of right all the time. And I think a lot of people beat themselves up when they don’t necessarily do the right thing. What I’m hearing from you is that you’re trying to do some really big things and lay out some really expansive visions, but they don’t always seem to land or they don’t seem to work or for various reasons. And I’m curious, you know, given, given your attempts, how do you, where do you find success? How do you remain positive about your work?
Peter: Because I work at several different layers. That’s the big picture. What I think is those are the home runs that I think have the or those are the things that I think have the potential to be major game changers for the business over time. And therefore it’s taking me years to get them to happen. But it’s why I keep working on them. At the same time, I spend lots of time being a sounding board for people working on all sorts of different scales of problems, jumping in and being a hands on engineer occasionally. Still, this is now three years ago on a team that was understaffed, trying to deliver some stuff that’s important that then turned into a way of bootstrapping a lot more information about that domain and then I could use that to plug into other projects. It’s mentoring lots of people because growing other people to do the things that I was doing seven years ago when the company was smaller, to do them now when the company is bigger and we need more of them across more places, that becomes the way that I start to feel that I’m delivering value today. I’ve also, using Will Larson’s terminology, spent a lot of my time functioning as a right hand for whatever leader, that archetype and helping them to understand the technical trade offs that were going on in the organization or internally or in peer organizations and how those would interact with other things. And so that’s a lot of the small scale stuff, but it’s this mixture of trying to grow people to do those things, but knowing that there’s this big macro strategy challenges that Netflix is, because of its loosely coupled, highly aligned strategy doesn’t necessarily lean into as much as other companies do, going, hey, we do need to pay attention to these big challenges over here and that’s why I keep doing them. Are there days that I get profoundly frustrated that I am I really doing something useful? Yes. But I think their potential value is high and so I keep trying to do that.
Alex: So switching subjects a little bit, something we like to talk a lot about is like, how do you, as a senior I see who, you know, has sort of like a looser set of expectations than maybe sort of a more junior or less experienced engineer. How do you make sure that the work that you’re doing is aligned with your organization? You know, what does that process look like for you?
Peter: Historically a lot of that has come out of being in that right hand role to some extent. And so spending lots of time collaborating with my peers, lots of time collaborating with my boss to understand what we locally think are the most important things to be doing. Other than that, it’s by being tuned in and attending a bunch of the product strategy discussions, talking to leaders in various other parts of the organization to hear what they are finding as the challenges that they’re having to deal with. Because sometimes companies will say one thing and then actually the action on the ground will be something else. And so sometimes it’s a matter of being able to surface back to the leaders that I’m working with or reporting to that, hey, I know we’re saying that this is a priority over here, but I can watch all the works going in a different direction. If you really want it going to the left, then you’re going to have to make some statements about this and or influence in different ways, trying to set direction, I guess, or sort of collaborate with people to understand where it’s going. I spend an immense amount of my time talking with people one on ones, groups, meetings, etc. Just often, more often these days trying to figure out a, how to make a connection and get myself out of the conversation. So that that’s the way I scale and that’s the way I scale my impact.
Alex: So once you feel like you sort of are headed in that direction and you’re like okay, I think I got this, I think I’m aligned. How are you sort of checking in and making sure that you’re continually in alignment with the organization?
Peter: By seeing where I’m getting pushback, by seeing where the organization is shifting. Because one of the things, because of my habit to go towards the blank spots, I am often a source of incongruence in the organization. And so what is it that happens out of that? Earlier this year read a book called Range by David Epstein and he talks about the importance in robust organization of incongruence that regardless of what strategy you have of highly sort of top down structure or highly diffuse structures, those tend to be self reinforcing in any direction and that will lead you to be more and more effective in that particular style. As long as the world that you’re operating in is relatively stable. If things change and more and more in the tech industry things are changing, that becomes a weakness over time. So Having people or systems that are pushing you in a slightly different direction is important or valuable. And I’ve often been that source. And so what I’m trying to do is walk the space of trying to lead the organization in the direction that I think is valuable for it without getting too far out of sync. There’s a concept in sociology and politics called the Overton Window that describes the range of accepted views that a politician can have to be elected or reelected in that community. And the edges of it are someplace out about acceptable. And then you get into radical or something. There’s a Wikipedia page that shows a picture of this. I think it’s very easy to fall off the edge from acceptable into radical. I think it is much harder to go from radical back to acceptable. And so a lot of what I’m doing because I’m trying to get people to think about things that aren’t necessarily their day job or to consider the ramification of this other team where their product managers are pushing them to deliver this feature. But, okay, you’re going to externalize a bunch of cost to somebody someplace else. How can I help you to have that conversation through the organization to go, well, maybe we shouldn’t do it exactly that way, or we should at least talk about the ramifications of doing that. And what starts to help me to understand if I’m in alignment is how strongly people are reacting. That starts to give me a hint that maybe I’m getting a little far, close to that edge and I need to back up a little bit. The signal that it’s really well aligned is when I start to hear people quoting back to me things that I have written or said in the past, and they don’t always know that they’re telling me things that I have written or noticed. I mean, I loved it when somebody was telling me about this paragraph of prose and explaining what the backstory was. And I was able to that. Huh. I wrote the original document that that was clipped out of because it was lifted wholesale from one place to another. It’s like, okay, cool, I’m doing my job.
David: I think that, like, along the same lines, one of the questions that I have is, and I mean, this is so the challenge that all of us, as we sort of become increasingly senior ICs, is like, you know, we’re expected to lead without being bestowed authority, at least not in the sense of having having direct reports. And it sounds to me like, you know, that ends up being a really big part of your job. So in addition to sort of Making sure you’re aligned with leadership. You also need to make sure that you’re influencing your peers and the engineers in your organization to sort of buy into the vision that you lay out. And what happens when. Well, okay, first of all, so is it correct to say that you don’t have any direct reports?
Peter: It is correct. I have occasionally been an interim manager at Netflix at various times when people needed to have something managed, but.
David: And so in that case, you’ve already outlined a little bit in terms of sort of how you propagate a vision. But I’m curious, sort of, if we get a little more nitty gritty, what happens when, when there’s a discrepancy between sort of your vision and the direction that, that a project is actually going, or between sort of two different teams that are both required to, to get aligned and who aren’t sort of aligned in the right way. Like, what are the tools at your disposal besides sort of like reiterating the document or whatever? Like, how do you do it?
Peter: Well, let me ask the two of you a question first. What’s the difference between context and control?
David: Context has to do with like the information that people have and control has to do with the agency that people have.
Peter: Alex, any thoughts? Does that work for you?
Alex: I think I would agree with everything that David said. I might add that context. So like helping people see the environment that they’re in and sort of see the surroundings that they’re in. They’re both mechanisms by which you can get people to make a decision, I think also.
Peter: Okay, I have spent a bunch of time this year reflecting on this and I have come to the perspective that the difference is not in the first sentence. The difference is in the paragraph that comes afterwards and in the fact that there’s often a question at the end of that paragraph that draws the other person into the journey. And so it was not an engineer any place at Netflix who made the decision, we are going to move out of our data center and deploy our systems in aws. A dozen years ago that was a top down decision, but it was then followed with a whole paragraph about we’re going to do this because we don’t think that there is value. Running our own data center helps us to achieve this business goal, which is what we actually care about as a business, trying to entertain customers around the world or around the US at that point in time. Can you help us figure out how to do this? Because while we know we want to be over there, we have no clue today how we’re going to get from here to there. And so that’s a way of bringing people into the journey, into the conversation. While in some sense, if you will, putting fences around the edge of the playground. We want you to play over here. Please don’t go run into the street. This is why we think that’s dangerous. Well, you don’t want to always have to be telling somebody over and over, don’t run into the street. So putting up a fence over there that says this is where you can play allows more effective or more freedom to play in unencumbered ways most of the time. Coming back to the question of how do I do this? It’s trying to talk about where we’re trying to go as a business, why that matters and offering up ways in which I think they can help to achieve that goal. And then as a bunch of other people have been asking you, start asking questions. So why isn’t this landing on your roadmap to start executing right now or whatever point in time another piece is? I try to go start having conversations with people this quarter about what I’d like them to be thinking about doing next quarter. Because if I can plant the seeds in advance and start to learn about what may be competing initiatives or demands on their time, I can start to get in front of that by finding out who else I need to talk to to adjust the priorities of incentives investments. And so that’s a bunch of the strategy. On the gee, I’d like to do that, but I’ve got these other things that are pulling on me and that’s how I deal with that. On the I think we should do it this way. Well, and some other team thinks we should do it another way. The longer I’ve been in this industry, the less convinced I am that there are really right answers to pretty much anything. And I am coming more and more about getting aligned answers. And one of the things I’ve been thinking about in some sense by listening through some of the recent podcasts preparing to do this interview is about little Endian versus Big Endian number representations in computers. And I spent more than a little time earlier in my career having to care about those things and going back and forth. I used to know a bunch of the arguments for why one was better than the other. I couldn’t recite any of them to you anymore with any confidence, but I don’t really think there is a fundamental truth that this one is better than that one, certainly under all circumstances. And at the point that you add that on how do you bring them together? It’s like, okay, how do we make a decision that allows us to effectively move forward? The comment that Nell made in the podcast that just dropped episode that dropped yesterday about the conversation with an NSA person where somebody pulled them aside and said, look, they just got to use that thing. It doesn’t matter whether you think yours is better or not. It is not constructive to do that. Well, how do we dig into why? Let’s just pick one and move forward in an aligned direction. If it’s my one opinion versus a whole team that may differ in a different thing, I’m awfully inclined to go, fine, you’re going to be doing the coding. You’re going to be making this happen. Let’s just go do it your way. We’ll move on. Will we have a retrospective perhaps later on to figure out? Did it play out the way they expected? Did it play out the way I expected? Someplace in between? How do we learn from it? Cool. One is two different teams that have different beliefs or perhaps different mental models for how to approach a design problem that gets to be a lot harder. And I don’t have as good a set of strategies for doing that. I think the idealist in me goes, I’d like to have the questions and ask why do you care so much about this and all of that? But sometimes at the end of the day, the answer ends up just being that they do. And I don’t really have a better answer than you have to pick one eventually, or you have a persistent dysfunction in your organization and you are trading off one challenge for another. And I wish I could give a better, more satisfying answer because I don’t really like that answer, but that is the lived reality that I’ve experienced.
Alex: Do you feel like this goes back to your previous statement about sort of incongruence? It’s like sometimes you sort of give everyone context. Maybe you even give some decision making. Eventually they’re going to make a decision, and if it’s different than your own, it’s almost like it’s a good thing because that means that we’re going to learn something by someone doing something different than I might have done it.
Peter: About a year ago, I read a blog post on Andy Grove’s book about Leading intel. And the blog post asserts, and I haven’t read the original book, so I’m a little hesitant, but I believe basically that Andy felt that as an executive did not have the responsibility to make a decision. They had the responsibility to set values and ensure that decisions were made. And more and more as I move up in the ladder, I have come to the view that, no, I’m not the one who should be making the decisions. I need to make sure that decisions are made, that they’re made soundly and effectively, that we think about them again afterwards. But no, and I had this as I was talking about the global cloud effort earlier and the fact that we’re finally starting to think about how to expand into more regions. This is a thing where somebody else needs to lead it today that they are closer to the conversations that are happening that will drive the nuances. They have more time to pay attention to those details than I do. I need to engage with them to make sure that they’re aware of the other things going on that it may touch on. Because there are more ripple effects on other parts of the ecosystem that we need to have debates and discussions about. Do we couple these two efforts? Do we leave them apart? Why? Well, if we’re making a multi year bet, is that even realistic? Or maybe we can ignore each other today, but by the end of next year we’re going to be stepping on each other’s toes. How do we plan for that reality? And so it’s much more of that stuff around it that, that I’m paying attention to. This is one of the things shows up both for people, leaders and technology. You have to learn to let go as you move up. First it’s letting go of writing a piece of code. Then it’s learning to let go of that piece of code that you wrote before that. Now some other people are taking in different directions. And in time it becomes about making the decisions about that product or piece of code that you used to be involved in or would have been really excited to have been involved in. If you were at a different point in your career, you’re not there anymore. So give other people space and grace to do those things.
Alex: Cool. Changing subject real quick. You said that mentoring is a big part of your job nowadays and I’m curious, do you have like an approach that you take to mentoring?
Peter: One of the things is I have the belief that I often get as much out of mentoring the other person does. Even when there are nominally significant differences in place on a career path that I will learn things either potentially out of the storytelling that I’m doing in the course of the mentoring or by the questions that they ask or whatever topics that they bring to the table, I’ll learn something out of it. A tangible example cropped up just yesterday. I was had a Virtual mentoring session with somebody I was introduced to by a mutual friend. And they’re just starting to sort of make the transition between senior engineer and staff engineer, doing it at a small startup. And had a bunch of questions around that. And I shared a whole bunch of perspective out of my career that I thought was relevant. They took lots of notes, was really excited about it, and I could tell by the end of the sort of half hour that we were chatting that there was a little bit of deer in the headlights, information overload, if you will. And it allowed me to go, okay, let me step back here and say, here are the things that I think are important for you today. Take the rest of those as being things that you’ll sort of noodle on. Come back to those notes some days. Here are the two things that I think are relevant for you right now. And I think that will help me to have a more effective mentoring conversation with the next person in their shoes that comes along. So learning and reflecting, seeing when you get an opportunity. Because some people might not have been quite as comfortable as that person was in revealing their sense of, geez, I’m overwhelmed. This is all really good, but nah, I. You’re teaching me to fish, but you’ve dropped a whole bunch of equipment on my table, and I don’t know which one to pick up first. And so it’s like that one and that one. Now go forth. We’ll either push the rest aside, you’ll get to that. But it’s a lot. It’s about conversation. Where are they trying to go? Asking questions to help them, to figure out they’re not having my journey, they’re going to have their journey, helping them to be comfortable in their own shoes and figuring out what is important to them. And it’s often about being a sounding board. My father many years ago asked me, have you thought about being a rabbi? What? I identify as being Jewish, but I have never been what I thought of as being particularly religious. And I was like, no. And years later, I ended up meeting a rabbi who, if I’d known them, they’re probably about my age, so maybe more. If I’d known who’d been ever was their inspiration and mentor, maybe I could have been a rabbi, because their way of doing it just sort of. I could see that. But I’ve also come to realize that a bunch of what I do these days is kind of like some of the aspects of being a rabbi that I will give somebody a safe space to have a conversation about what they’re interested in what they’re afraid of, what they’re challenged by, and then help them to think about how they would go about doing that for themselves. So maybe that’s the form and structure of how I mentor. It’s not to say here’s the list of things you must do, but here are the things that I encourage you to think about to figure out what will work for you.
Alex: Cool. That’s a really interesting analogy. How many people at any given point in time do you feel like you’re, you’re mentoring?
Peter: That’s hard for me to count in the sense that I am always telling managers my calendar is public to everybody at Netflix. I try to keep it not too dense. That doesn’t always work, but it’s open to anybody. I’m telling managers that they can point people in my direction, so I’ll have one off. So with all sorts of people, maybe five to 20 in a quarter, I don’t know, it’s really variable. And then there’s a group of people that I am both collaborating with and mentoring on an ongoing basis, sometimes tied to projects, sometimes just checking in as part of my gathering information for other things. But part of our one on one conversations would be, hey, what’s going on? How do I, oh, what about thinking about this thing this way? Or did you know about this other thing over there? Which are aspects of mentoring in connecting and exposing them to other things or giving feedback. And that’s probably 10 to 15 people fall into that bucket. And then there’s probably handful or two who I’m more regularly meeting with in one form or another. Probably only a handful of those at any given time, which really feels like more of explicitly a mentorship relationship. But again, because I see them often as being valuable to me, differentiating who I have one on ones with from who I have mentoring relationships with is where I’m a little fuzzy up.
David: I want to switch gears a little bit, seems to me, you know, I understand Netflix doesn’t have any titles except for two, and definitely doesn’t correspond to sort of staff, senior staff, principal, etc. But from what you’re describing, if you were to be teleported into a company that did provide these levels, I think you’d be sort of in the, in the upper echelons of sort of the technical IC leadership track. And I’m curious sort of what the path to getting there looked like in terms of maybe a chronology and also sort of maybe if someone were to ask you, someone who’s a senior engineer or you know, A staff engineer and aspiring to sort of move up to higher impact levels, sort of what your advice would be or how you might.
Peter: Guide someone in that direction. I found Rich Lafferty’s comments in your interview with him about how he writes his documents to be just so relevant to me. I sit down in front. I started a career 20 years ago. I’ve gotten to where I am today. My inclination towards doing things that are valuable for the company and aiming towards blank spots is really how I’ve created this career. Very seldom have I explicitly been trying to move up some ladder that I understood. And it’s the first job I had in the Valley was at a company called General Magic and I started moving into technical pre sales as part of what I was doing there. And that was the first place I started getting exposed to the business side. Well no, not even that was as an employee. That was the first time I started to get exposed to the business side of technology. And at the time I very much remember having the reaction they’ll pry my keyboard out of my cold dead fingers. I wasn’t ready to let go of being a coder at that point in time. And writing specs to give to customers to explain how our products would help them solve things was not the right thing for me. And so my next job, next couple of jobs were just purely hands on engineers building things one at a really large company. And then at the first startup I went to and there it was just picking up the interesting problems that were important to the business and learning and watching what was going on around me but entirely about doing the things that were important to the business, trying to watch and reflect what worked well, what didn’t work well. I’m fairly introspective and so I reflect on what I’ve done and not done a lot. The other piece is during the dot com bust I interviewed a startup and had a conversation with the CEO in an interview segment with the CEO and he asked me the common question of sort of what do you want to be when you grow up? And as I was doing at the time, I said with great confidence and a fair lack of understanding of what it is really, really was I want to be a cto. And he gave me some really profound advice at that point in time which is don’t aim so carefully for a particular goal. Be open to a broad collection of experiences that may lead you to there but will allow you to see some other things along the way that will help you to be more effective with you get there and I had a conversation with a woman from Netflix who started out at Netflix as a senior software engineer, became a manager, became a director, and was leaving the company earlier this year to go be the founder of a startup. And because I have concerns about our lack of having an IC ladder at Netflix, and I was doing some quasi exit interviews of people who I respected who’d gone into management but had been technologists before, and asking them, would you have done things differently if we had a technical ladder? Would you have stayed in that? And she gave me what I found to be an unexpected but profoundly thoughtful answer of yes, I probably would have still done this, but I’d been more thoughtful about it. And so I think that this ties back to what that CEO was doing, is that if you’re looking around at those other things, what does that product manager doing next to you doing? What is that program manager that you’re engaging with sometimes doing? What is that people leader doing? You will have ideas that will be both allow you to figure out what’s the role that you want to be going after and how to engage with them. How I think it might have been rich, maybe it was Mason Jones was talking about doing code switching and how you have those conversations with different people. If you’re trying to be effective and move forward, those are the Being able to reach people where they are will help you to be more effective. And I think those skills also help you to move up. The more that you can come to people where they are will help them to understand and perceive your value in some sense. And so is it managing up? Is it politics? Is it just being a caring, engaging human being? You can interpret it different ways. Interesting.
David: I mean, I think that makes sense. I think that matches some of the feedback we had from other folks on the show, which is basically like it’s not that helpful to aim specifically for one target, but it’s more useful to sort of point yourself in a direction and then reevaluate as you move along.
Peter: Think about how we do software. We try to do experiments and do incremental development. We’ve moved away from waterfalls. So ultimately saying you’re going to be that one particular thing, a form of waterfall development. So how do you get to be agile in what you do for your career?
David: That’s a fascinating analogy. I hadn’t thought of it that way. So we’re getting close to time. You alluded to the questions that we ask every guest. The first one is what are the resources? Whether that’s books, blogs, podcasts, a hymn, or anything else that you might refer folks toward if they want to sort of learn to be to be a better technical leader.
Peter: I love listening to this podcast. I found the collection and diversity of perspectives. I can listen to people and go, oh yeah, that’s familiar. Oh, that’s dinner. I need to think about how that would play out to be valuable.
David: I was fishing for that a little bit, but I do appreciate it.
Peter: I understand that. I wouldn’t have gone there if I hadn’t believed it. I find Rand’s leadership slack to be really valuable, particularly for me as someone who spent most of the last or more than the last decade at Netflix. And so that gives a bit of a monoculture for how to do be a senior leader. I mean I had a bunch of experience other places before that, but that ages out a bit. And seeing the way other people having more people to chat with for me, I found range to be profound Valuable by David Epstein I also think this was the book I was recommending the new leader or the person just early on in their career yesterday to read is go read the Leadership Pipeline by Ram Charan C H A R A N and in particular the first couple of chapters of it that talk about the transition from being an IC to a manager of ICs. Yes, the exact form of it will be different for a people leader than for a technologist, but this idea about that you have to be thinking about different things as you progress up this ladder is important to being a senior IC or a senior technologist. And I’m crappy about reading other things. I sort of hoover up whatever articles people at work point at me and then sort of absorb the pieces of information and forget exactly what it was that it came from shortly thereafter.
David: Fair enough. So it looks like we’ve lost Alex, but there’s one other question that we always ask, and this is the one you alluded to earlier. So how much time do you still spend coding?
Peter: I spend no time at work coding. The last piece of code that I wrote that landed in production was probably three years ago. I do spend time running my own server and doing sysadmin sorts of coding at home for myself, but as various other people have commented, that’s not where I get my leverage from. It’s getting other people to do it. Do I miss it? Yeah, but because I care about business value, that’s While I was uncomfortable with doing that 20 years ago, I’m absolutely comfortable doing it now.
David: Cool. Well, Peter, thank you so much for taking the time to chat with us today.
Peter: My pleasure. I really enjoyed it. Thank you for doing the podcast. As I said before, I really appreciate it.
David: That’s it. Thanks so much for listening to Staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcatcher of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website, podcast.staffenge.com the website also has our contact info. Please don’t be shy.
Peter: Sam.