[00:00:01] JC: So I'm going to start today's recording with a callback to the first season where we talked with Lauren Tan about engineering management. Because this episode is also focused on that. So if you haven't already heard that really wonderful episode with Lauren Tan, go back and take a listen before you listen to this one.
So today I am sitting down with Dana Jones. She is an engineering manager at Netflix Studio. She's been in leadership for about seven plus years. And she's been in engineering for 20 plus years. And I asked her to sit down with me and talk about how managers help their reports grow. What are managers doing behind the scenes to help you as an engineer? What kind of conversations can you have with your manager about what your growth is going to look like and what you want to do? So that's what we talked about today.
[INTERVIEW]
[00:01:05] JC: Hi, Dana. Welcome to the podcast. Thank you for joining me.
[00:01:08] DJ: Thanks, Jenn. It's great to be here. Thanks for inviting me.
[00:01:10] JC: Of course. I wanted a very specific sort of outlook from an engineering manager on the topic that we're going to be discussing today. But to kick it off, tell me a little bit about how you got into engineering management and why you've sort of made it your career path.
[00:01:26] DJ: Yeah, sure. So I didn't actually set out to join engineering as a career or engineering management as a career. I sort of stumbled into both of them if I'm honest. So when I first met my husband, he was a software developer and I had been in tech support, but we didn't work together. And then when we got married, I noticed that he was tech editing a book. I had no idea what that meant. I was unemployed for the first time after having relocated from Texas to Washington. And so I asked him what he was doing. And he said, “Well, I basically just read the book. Do what it says. And when it doesn't work, I put a note down.” And I said, “Well, I could do that.” So he got me a gig as a tech editor. That book turned into me taking over as the reviser on the book, so that I had to hurry up and learn enough coding to at least revise the book.
So I sort of fell into development. It took off from there, but it wasn't something that was like deliberate. I wasn't one of those people that was hacking away at codes, like, computers, when I was eight-years-old. It wasn't this long-life aspiration. It was just something that circumstances turned it into a career.
And then similarly, when I started becoming more and more confident as a developer and taking on different kinds of projects for different companies in different spaces, I started noticing vacuums in different teams. So there might not be somebody to lead a meeting, or there might not be someone advocating for coding standards. And so I just kind of started taking up that responsibility, and then realized over time that I was a little better at building teams and growing people that I was developing code, and that I had more passion for it, too.
I think, parenting – I'm a mom of four. I think parenting gave me some skills that I could draw in that realm to patience, and understanding, and empathy. And all of those were made stronger by being a parent. So I think it all just kind of worked out that way.
[00:03:24] JC: I love that that strengthened that role for you. And you talked about growing people, which is actually the subject that we're going to be talking about, because I realize it's something I don't have any sort of formal knowledge or understanding of. And I assume other engineers don't as well, which is what steps your manager takes to grow you and then what you yourself can do. So that's a very broad topic. And we'll break it down. But starting off, like, what's your philosophy around growing people?
[00:03:55] DJ: I think that a manager's responsibility when it comes to growth for people on their team is to find and communicate the overlap between opportunities that the company or the role present and the aspirations of the individual contributor. And that starts with getting to know your staff really well. Understanding what motivates them, what their aspirations are, what their strengths are, where they want to grow, where they find joy, what the demands are on their personal lives. All of those things come into play and understanding the people. And then identifying just a few areas that they want to focus on.
So you can't hit every target if you're trying to shoot in multiple different directions all at same time. So it's finding those few areas that they want to focus on. And then really keeping an eye out, keeping an ear to the ground, keeping all the organs engaged, to find opportunities that line up with what those folks want, and then really helping prepare them for when those opportunities come up.
A common move is from an engineer to a manager. But those roles don't come up very often. There's a lot of different skills that go into being a manager versus being an engineer. So I think there's a lot of ground that can be covered in getting somebody ready for when that opportunity does come up.
[00:05:14] JC: I love that you talk about all these factors that can go into getting to know the person and what would drive them, or motivate them, or even be a hindrance, that they have life pressures that are going on that maybe keep them from moving forward. How do you go about developing those relationships? I'm sure a lot of our listeners, just like me, have had an experience of a manager that didn't really want to get to know you that well as a person. What does that look like for you?
00:05:40 [] DJ: Yeah, that's a good point. I think that your path to growth – No matter what role you're in, I think your path to growth is really a joint partnership between you and your manager. And if your manager doesn't see that as part of their responsibility, it can be really tough, right? Because it's almost like they're not meeting you at the table that you're already at. And so you kind of have to find creative ways to pull them in.
So you asked, how does that relationship start? How does that trust start? Really, it’s those one-on-ones. I have weekly one-on-ones with my with my team. I never ever canceled them unless I'm sick or on vacation. I may move them. I mean, calendars are what they are. Move them around sometimes. But I never ever cancel them. They're the last meetings that I cancel. I also communicate from the first moment that I'm with a new team that if they need something, they just need to reach out to me and we'll find time for it. If face-to-face conversations are not the way forward, then maybe we communicate through Slack, or we have a Huddle, or we use some other kind of less synchronous technological way to connect. But it starts with availability and asking questions, being curious.
I can't keep details in my head, as well as some other people. So I take copious notes, too. I write down the names and ages of children that they may have. If I hear anything about their spouses or their interests. I think that kind of personal connection builds a degree of trust, or at least it starts the building of that trust. So yeah, I think it just starts with one-on-ones. And then not over-promising. And communicating information to your team as early as you possibly can. So that they know that you're giving them the context that they need to be effective in their roles. But also, you're not inundating them with every little piece of information you may hear.
[00:07:28] JC: Those personal details, I'd remember like when managers would remember something about my life, and it was like, “Oh, my God! Like, you actually were paying attention?” And it was so – It did build that like sense of trust.
[00:07:41] DJ: Yeah.
[00:07:42] JC: Definitely. And then I think I made a mistake as an IC maybe earlier in my career where I did cancel one-on-ones with my boss, because I was like, “Oh, I have nothing to bring up this week.” And then many years later, I had a manager who was like, “Well, let's just talk like people. Let's go get coffee. Let's just hang out.” And I was like, “What? We can do that? I didn't know.”
[00:08:05] DJ: Yeah. I tell my team, they can cancel the one-on-ones with me if they want to. Because I get it. I mean, when you get in the groove, and you're flowing on something that's really tough and you see that there's a 30-minute call coming up with your manager, maybe you don't have anything pressing, and you'd rather stay in your workspace. That's fine. I'm totally open to that, because it's their meeting. I see one-on-ones as their meeting. I'm not one of those that splits the meeting apart and says the first 10 minutes we talk about the project. And the next 10 minutes – I always start the conversation with what's on your mind.
I may have a note or two to share. And if time allows, I may communicate that to them. But I always start with what's on your mind. And I love the one-on-ones because you just never know where they're going to go. I've had folks that wanted to talk about their work. They want to talk specifics about projects. I've had other folks that wanted to talk about interpersonal concerns that they had with people on their team. I had an engineer one time that just always wanted to talk about her cats. So I'm good with whatever comes up. I find them to be the most invigorating conversations that I have all week long.
[00:09:09] JC: I would definitely want to talk about my cat and my dog. I do. I mean, they're usually like somewhere around me. It’s almost like, “Let me tell you about this weird animal that I'm in charge of and love.”
[00:09:19] DJ: Right? When you open the door like that, and you say what's on your mind, you're really giving somebody the opportunity to tell you what's most important to them. And if it's your cats, great, then I'm definitely going to ask about your cats frequently. Because for one, I'm interested in cats, too. For two, I think it signals that I see you, right? Like, I see what's important to you, and I know what you care about, and I know this is on your mind. And maybe you have some news to share. I don't know. The social lubricant side of it is really, really important as well.
[00:09:50] JC: It's really hard to know that when you're pretty early in your career and you start to first have one-on-ones with your manager, because I did think that they were for project status updates. And so if someone had asked me, “What's on your mind?” I’ve been like, “Oh, I'm supposed to talk about the project.” It was only later that I figured out I could talk about actually what was on my mind.
[00:10:12] DJ: Sure.
[00:10:13] JC: I also needed like a degree of trust with my manager to talk about how to grow in different ways. Because I think it's easy to go to your manager and say, “I want to learn X new tech.” And it's very different to say, “I want to get better at written communication.” Or I want to get better at getting people on board with my ideas. That's a very different, I think, conversation to have.
[00:10:38] DJ: Yeah. I think it comes down to who your manager is, what they prioritize. Because to be fair, there are some managers who treat one-on-ones as project check-ins. So if you're on the reportour, like if we have a manager report relationship, if you're the report, then if you know that there's an expectation your manager has for you for a conversation, you want to meet that.
So I don't want to put the blame or burden on past you, for example, for not being the one to broach those conversations, because that may have been your manager's expectation. And like I said, there are some folks that come to me, and that's what they want to talk about. They're not so keen to talk about personal things, especially in the beginning.
I'm a new unknown person that came in. I'm just a blob with hair, as far as they know. They have no reason to trust me. They have no reason to be vulnerable. Or like to your point, to admit that maybe I'm not great at written communication. To even admit that you want to improve on something is to admit that you recognize you're not great at it. You're not as great as you could be at it. And there's always this fear, I think, sometimes, in the back of our mind where it's like if I admit that I have a flaw, then I'm giving them the chink in my armor. I’m giving them a reason to edge me out if that comes to bare.
So what I think is incumbent on managers then is to normalize that by exposing their own flaws early, often and loudly. So when you mess something up, when you make a mistake, or a misstep, or you're not good at something, not trying to pretend that you are, but just saying, “Hey, look, I've really, really misunderstood you this last time, and I made a bad choice based on it. Can you help me understand this area better?” So I think leading with your own vulnerabilities enables everybody on your team to be more vulnerable as well.
[00:12:36] JC: And it’s such a key piece of combating imposter syndrome. Because part of the reason that you don't want to admit that you're not good at something is that you probably already feel that imposter syndrome of, especially if you are an underrepresented or a minoritized group in tech, especially then, you don't want to give anyone the actual, like, I don't belong here information. You think that's what you're doing when you're admitting that you have some room to grow. And I've definitely felt like I don't want to tell people that I need help, because then they'll know. Know I wasn't supposed to be here.
[00:13:15] DJ: Yeah, exactly. I don't want to give them excuses to reinforce that stereotype. And so that – I don't know if this is a hot take or not. I think that makes it even more important for those of us who are underrepresented categories in leadership to normalize risk taking, mistake making. I mean, a mistake is just an opportunity to learn. It isn't the mistake that matters. It's how you react to a mistake, or deficiency, a fault, or failing, whatever negative, negative sounding word we want to throw at it. Those are the opportunities.
If I stay where I'm comfortable and I just keep doing what I'm great at all the time, then I would still be tech editing books. And I wouldn't have grown. I wouldn't have made the mistakes that it took me to learn to get to this point. So I think if we as leaders, acknowledge, especially, like I said, underrepresented category leaders, I think if we acknowledge, “Hey, we're allowed to make mistakes and grow just like everybody else around us. And here's the mistake that I made. And here's how I grew from it or how I plan to grow from it.” Then that makes it safer for everybody else to be vulnerable on the team. Can they also be in one of those categories?
[00:14:25] JC: Yeah, I need that to like, kind of come out of my imposter syndrome sometimes, as someone being like, “I made a mistake.” And I'm like, “Oh, okay. That's all right. I can admit that. It's totally going to be fine. It's going to be okay. You can do it.” Also, this like getting new grooves in your brain about patterns that you, like, need to do is really hard. Your brain just wants – It wants to do what it's always done.
[00:14:49] DJ: Sure. Yeah. And let me hasten to say I have not solved the imposter syndrome quandary. I still feel imposter syndrome all the time. I think, though, one thing that was pivotal for me, and I wish I could remember where I had heard it, but I heard someone at some point said that imposter syndrome is not something that's ever felt by imposters. So I try to dredge that up whenever I'm kicking myself for feeling like I don't actually – I haven't actually earned the seat at whatever table I'm at in the moment.
[00:15:24] JC: It does make me feel better when I know that if you're experiencing imposter syndrome, you're likely, like, very good at actually what you do. That people who get imposter syndrome are actually like really high-performing individuals. And if I ever – Sometimes that has opposite, where I'm like, “I'm not getting imposter syndrome. Oh, no. Have I gone the opposite way?”
[00:15:46] DJ: Yeah. And let's flip it a little bit, right? Because you feel imposter syndrome when you feel like you're out of your depth. That's really what it boils down to, is you're out of your depth. That's actually a strong, good signal, because it means you're at the leading edge of your capacity. And that means you're growing. So if you take a growth mindset to your life, or your career, and you have those moments where you're like, “I'm not sure that I can do this, and I belong here,” you're right on the cusp of the capacity to learn something, which is super – It's scary, right? It's super scary. But it's also super exciting.
[00:16:19] JC: So speaking of that, in particular, like, when someone comes to you, one of your reports, and they say, “I want to grow in X way.” How do you make sure that their plan for their growth is challenging enough and then also reasonable enough? Because I imagine it could go both ways.
[00:16:41] DJ: Yeah, it's a good question. I mean, it's conversations. So for one, it's I want to grow in this way because. The why matters a lot. Is it because you want to eventually move into people management? Do you want to move in a greater degree of project management or of technical difficulties? So like, what's the ultimate goal? And then this particular vector that you've identified, is it really leading you to that way? So let's start that conversation first.
And then that's where you get a sense of – If you don't already, just from your reporting relationship, that's where you get a sense of, “Is this the right next step for this person? Or are there precursors that need to come?” And then is this the right length of step? So is this step too ambitious? Is it too conservative? And do I know of opportunities that already exist for this person to take this step? How can I coach them? So I wish I had a better like blanket answer for that. But there are so many different ways that a person can grow in so many different kinds of opportunities that make up.
So when I started at Netflix, one thing that I had to adjust to was the absence of levels. We don't – Really? You know. You know. So it’s a very flat organization. So we don't have what some other companies have this career ladder, which can be a really great coaching tool.
If I'm at E2, I need to be able to do these 20 things. And then to move to an E3, I can see what the expectations are. So then I have a clear list of either skills, or experiences, or however you want to phrase it that can help me get there. Without that, it's a little murkier. It's a little harder to coach.
So sometime last year, I think it was the middle of last year, I drafted essentially a coaching tool like that, that provided that kind of clarity, but that didn't have levels. It just said, “For an engineer, here are all the different ways you can grow.” So there's communication, leadership, vision, strategy, technical architecture, like all kinds of recruitment, all different kinds of ways.
And I started having conversations with members of my team and I said, “Look, I don't expect anybody to be able to grow in all these different ways. There're just too many skillsets here to effectively become an expert in all of them. So let's see where you're at first of all. Do a self-assessment. Go through and say – Indicate your current degree of proficiency and all these different things. So have you architected a service from the ground-up? Have you gone to a recruitment event and recruited people from a group different than the one that you represent? Have you done public speaking before?
And then after you do the self-assessment, indicate what you want to focus on. Though, some people may never want to go to those recruitment events or they may never want to do public speaking. They want to do something else. So it gives a foundation to start having those conversations and then say, “Okay, I see that you think that you're poor at –” Tracking back to earlier in this conversation, to written communication. I haven't seen that to be the case, though. So let's look at some of your written communication and see what areas really need beefing up and which ones don't.
[00:19:58] JC: Right, because you could have not a true sense of what you're good at.
[00:20:04] DJ: Yeah.
[00:20:05] JC: You could like be like, “Oh, I'm terrible at written communication.” And like, you're actually not. It’s something else that's actually affecting that. Just fascinating.
[00:20:14] DJ: Yes, those conversations have happened before where I've had ICs come to me and say, “I really don't feel like I'm a very good verbal communicator. I don't know that people are getting my message.” And it's like, “Really? Because two one-on-ones ago with somebody else on your team, they told me the exact opposite. They felt like they got a lot of clarity out of your presentation.” So it's almost like when you hear a recording of your own voice.
[00:20:36] JC: Oh, God. With this, I have to hear my voice a lot.
[00:20:39] DJ: Yeah. I mean, you probably hear a lot with podcasting. It’s like, “That’s what I sound like? That's not what I thought I sounded like.” So it's a little bit of the same thing.
[00:20:49] JC: Yeah. And I think that's a good lesson for ICs, that when you go to your manager with like what you think you need to improve on, it may not be actually the thing you need to improve on. So keep an open mind. And then you brought up that you knew that that was not what they needed, because you had feedback from someone else. And that's really important, too. I think maybe not enough managers that I worked previously had enough feedback from other people, either on the team or in the organization. How do you get that?
[00:21:21] DJ: Again, it's one-on-ones. I think having regular consistent one-on-ones, steady growing trust, having real conversations about the dynamics of what's happening on the team. It's happened to me just this week. I had a newer member of my team who is looking for new growth opportunities. And the dynamics and the staffing is changing on my team such that that's becoming more possible.
And so I think it really is important for you to hear feedback, if not directly from your peers, then at least indirectly from your peers. So I communicate it to this individual. I've heard from to other of your peers that they see you as a strong leader. I've also heard from one of my peers that they believe you to be a strong leader, because they saw you engage in XY and Z. And just kind of like playing telephone operator a little bit for all of that, which I think is a huge part of engineering management, or maybe management in general, is collecting all of the various and diverse signals and making sure that they get refracted where they need to go. Because there's too many different signals to sift through for any one person who's actually generating code and delivering software to pay attention to all of that and funneled through it. So I see that as a huge part of my role to say, “Hey, person A, I heard information from person B in a different part of the organization who manages person C that you worked with? So let me try angulate this for you. [inaudible 00:22:51].”
[00:22:50] JC: Put a graph.
[00:22:52] DJ: Exactly. Exactly.
[00:22:53] JC: Put a graph. Put a graph.
[00:22:54] DJ: Yeah.
[00:22:54] JC: Wow! Yeah. So, admittedly, like – So before, I don't know, a couple of years ago, I actually didn't really know what managers did all the time. And actually, like, last season on this podcast, like specifically had that conversation of like what do managers do? Because it can be a little opaque to the reports what they do. But knowing that you're like going and getting these things. I love that idea of like refactoring the light, like pushing it out to where it like needs to be is I think really important.
On the levels thing, by the way. So as an IC at Netflix, I love that I will never have to go and do promo stuff. It is, I think, a double-edged sword of, one, if you were trying to go from one level to another, that career ladder would have very clear indicators for you. Sometimes those, though, aren't what you want to do. They're not what you want to focus on.
I know someone right now who's going for a promotion at his place. And to do that, he's going to have to do some work that he actually doesn't want to do. But it's like a project that doesn't interest him that much. But he has to do it to get the promotion. How have you had to deal with that in the past?
[00:24:06] DJ: Well, it's an interesting – I'm going to approach answering that question from the point of view of that requirement, because I haven't ever really worked somewhere that had that kind of gauntlet that you had to go through in order to get there. But I have heard of places. I think some of our sister organizations in the fame space go through that. And my take on that is one of two things is happening in that situation. Either the person is up for a promotion to a role they're not going to like when they get there, because the work is representative of what they will have to do in that role. Or their work is not representative, and there's a flaw in the promotion system.
So if I know that I'm going to have to learn to, for example, give budget presentations to move up to director level, which I imagine is part of what's expected of a director, is that they have to manage budgets. I don't know that I'd like that. And so going through – If that's a real representation, if the exercise is a real representation of what you need to do, then it can be a forcing function for you to really evaluate if that's the right promotion for you or not. So I don't think that it's necessarily negative.
But if the person is dreading that work that much, it may be that they're on the wrong track in terms of their career growth. And, I mean, there's really only one way to find out if that's the case, unfortunately, is to go to the exercise and see if they like it. Or I suppose they could talk to somebody who already has that role, and say, “Does this project represent what you do day-to-day?”
But you pointed out something a little earlier that I had to chuckle up, because you said you had no idea what managers did in the same boat. And I tweet about this a lot actually is, before I was a manager, I didn't know what my manager did either, because I didn't see him. He, she, they would go into rooms with other people who I didn't know what they did, either. And then they would come out and there would be a roadmap. That's all I knew. I didn't know what their day-to-day looked like. I didn't always have one-on-ones with my managers coming up. So I wasn't really sure what the job entailed.
And I have found now that I'm doing a lot more formal mentorship. When I'm talking to people who think they want to go into management, the very first question, or at least one of the first two is always, “But what do you do? What do you do? Like, I look at your calendar, I see you're talking a lot. I see you talk a whole lot. But what do you do?”
[00:26:35] JC: Yeah. Your calendar is really packed.
[00:26:37] DJ: Yes. Yes. And the answer is, “Well, it's something different every day.” Like, there isn't a typical day as a manager, because there's so much – Right now, there's open headcount on my team. So a big chunk of my day is taken up in trying to find the right candidate go through interviews, make sure that my team is – Or the interviewers on the panel are prepped on what I'm looking for. Refreshing my understanding of diversity and anti-bias mindset and going in. I mean, so that's taken a lot of my time right now.
But our roadmap will be announced pretty shortly. And then it will be stakeholder management and communicating all of that information. So there isn't a typical day. And hopefully, if I'm effective at my job, then the folks on my team have the context that they need to do their work really well. They understand the connection between what they're doing day-to-day, what the long-term vision is for our team and for our company. And the stakeholders and partners that I work with don't feel like they're in the dark.
[00:27:46] JC: It's very different work is different work.
[00:27:48] DJ: It is very different work.
[00:27:50] JC: I remember someone when they first told me that becoming an engineering manager is not a promotion, it is shifting into a new role.
[00:27:56] DJ: Absolutely. Yeah. And it's not for everybody. There's a lot of people that make that shift and need to shift right back. Because it's a completely different skill set. That's why I said once I finally understood what people management was, I recognize I was better at that, than at technical delivery.
I was always an adequate engineer. And I was better at stakeholder management than I was at the actual coding part of it. I was never as invigorated by that as I was when I would say lead an internship program. So it's a hugely different skill set. It’s a lot more people touch. It requires a lot more emotional “EQ”, higher EQ, at least more regularly, because so much more of your time is spent building and working on relationships and communication than it is on something that's mechanical and intangible. But it can be a different kind of burdening stress, too.
So it's not a promotion in any sense. I think it's a definite career trajectory switch. It's a track switch. It's almost like going from being a plumber to an electrician. Like you know a little bit about houses are put together. And you've probably bumped up against people that are doing that work during the course of your work. But it's not a promotion.
[00:29:22] JC: No, it's not the same work at all. We're both working in the house, but a completely different thing.
[00:29:27] DJ: Yeah. Yeah, exactly. Now, that said, I think that having been an engineer for a long time – I mean, I'm 20 plus years now in this business. So having been an engineer for a long time does give me strengths as a manager of engineers. That would be very hard, although I'll say not impossible, to replicate if I had had some other discipline before this.
For example, I understand the need for flow, and focus time, and the cost of context switching. I was never a Java engineer, but I manage a team full of Java engineers. So there's no world in which I'm going to get in and actually create code in their code bases. But I can go in and review code. I can ask questions. And I can understand what's being written. But having not come from that particular language background, I would never jump in in their code bases and kind of take something over. I think that's demoralizing, anyway, when your manager steps in and takes work over from you.
[00:30:31] JC: Oh, it is – You feel so under-valued, under-appreciated, dismissed, when that happens. Also, not even your manager, but like technical leads, when a technical lead comes in and just takes over your project or tells you exactly how to do it. Where was the opportunity for you to grow, technically, with that project? It just got taken completely – Woosh! Right from under you. Someone just pulled the rug out from under your, right? That's not how you set someone up for growth.
[00:31:02] DJ: Yeah. And Jen, speaking of growth, since that's what this whole conversation is about, it's very interesting when you are coaching people that are at different points in their career, because coaching somebody who is that, like, say, an architect level, comes down to very different topics than coaching somebody who is brand new in their career. And I've managed both. I've managed a whole lot of mid-level engineers. I've managed exceedingly senior engineers, and I've managed people who are just graduated. And the topics you have to go over are really different.
So a lot of times when you're coaching somebody who's an architect level, especially if they're working with people who are much more junior, it's really on the people side of their work, less than on the technical side of the work, and reminding them of what it was like when they were new, and trying to get them to see interactions from the perspective of the other person, and use that to know how to move forward in a functional, empowering way. Because I don't think people ever – I think it's rare that people really seek to disempower each other. I think that effect happens incidentally when we're blind or unaware of how our actions may disempower other people who are at a different point in their careers.
[00:32:16] JC: I have, unfortunately, dealt with that in the past where I had – I guess, he actually was my manager, who would tell me how to do things, very specific technical things that he wanted me to do. I was very displeased with this. And what I sort of figured out about the situation seemed to be that he did not want to give up some measure of control. That giving away that control felt to him like he wasn't doing his job, which is not true at all.
[00:32:55] DJ: Yeah. You know, it's cliche, I say it a lot. And I know that it's tricky to kind of oversimplify something. But I think most workplaces conflict, when you really boil it down to its essence, comes down to a lack of clarity around responsibilities for different people who are working in the same space. So you understood that you were responsible up to a certain point with the work that you were doing. He understood his responsibilities to be a certain amount of work, and there was overlap. You had this area – And without even knowing the details of what you're talking about. I've heard this kind of situation called so many times. There was some element of working in that code base that you both understood to be your responsibility. And that lack of alignment and understanding on shared code bases and individual responsibilities is, I think, where most friction comes up.
So when those interactions happen, and I'm involved in helping smooth things out, or a party to one of those, I try to bring the conversation back to responsibilities, not the interactions that happen, not that specific pull request, or this feature, or that feature. It's like, “Who is responsible for greenlighting a release? Who is responsible for authorizing PR? Who is responsible for making sure that testing happens?” And have that conversation as an abstract topic, rather than coupled to whatever the latest interaction is sometimes, not always, but sometimes can lead to better outcomes and longer term established norms, as long as people approach it from a positive, well-intended perspective.
[00:34:41] JC: Yeah, I've had the experience of like a role being very unclear to me. And that sort of friction happening because I was not sure what I was responsible for. I was not sure what other people in the code base were responsible for. That did not end well. But that's besides the point.
[00:34:59] DJ: And that's a good point, though, because that's really kind of a part of a company's culture. Both of us work at Netflix. We know that our culture, when it comes to responsibility, is really different from a lot of other companies. I came from a string of startups before this, where responsibilities were a lot more delineated by role in particular. The PMs do this. The EMs do this. The engineers do this. The test engineers do this other thing. And here, it's a whole lot more fluid. I struggled with that a little bit, because again, my understanding of responsibilities in my historical context didn't line up with my current reality.
So I think one takeaway from that for managers who may hear this in the future is, as you hire new people into your team, make that understanding be part of your onboarding. Make sure that you're spending a lot of time clarifying for new hires what your companies and your team's culture is around responsibilities and who does what.
[00:35:59] JC: How does that affect when you're coaching an engineer and they want to grow in a certain way and it might have like overlapping responsibilities with something else? Or, again, like at Netflix, we just don't have the same structures. So how does that affect your coaching?
[00:36:14] DJ: Netflix is such a peculiar space, that there are some teams that have PMS, and the PMs more or less own the product division. There are other teams that don't have PMS at all. And so the EMs own that space. And then there are other teams where it's kind of shared. So I would say within Netflix, you can find almost any configuration of responsibilities, separate or shared, that you want.
And so let's take a specific example to make this conversation a little easier to kind of digest. Let's say that I had an engineer on my team who was interested in moving into product management specifically. So they wanted to do more user research. They wanted to understand impact and cost – So, ROI, return on investment for work that they were talking about doing and how to think about that from a product-minded point of view.
So long-term, if my team is very split on like product managers do product manager things, engineers do engineer things, then long-term, they might have to move out of my team to be able to achieve that kind of impact. But within their time on my team, I can still give the groundwork for that. Like, I can still encourage them to set up one-on-ones with PM and understand how do you go about your work? What tools do you use? How do you calculate impact? What users do you talk to? I feel like there's never a reason to block engineer access to the users of their products, especially when those users are internal, like, how they are on the studio side at Netflix.
So you can still lay some groundwork for understanding and, again, prepare for the opportunity, even if the opportunity is not immediate or not available on your team to help them grow and get that context for a future opportunity. A horizon window that comes up.
[00:38:05] JC: So I was going to actually ask, too, about engineers moving off of your team. Like, when that is actually the best way for them to grow up. I have a feeling this will eventually happen to me. It actually is a very prominent pattern at Netflix that you want to stay with Netflix, but you just move to a different team to take on new challenges or new responsibilities. I feel like I'm going to be terrified to have that conversation, even though I know I shouldn't. But it's a scary thing to come to your manager and be like, “I think it might be time to explore something new.”
[00:38:40] DJ: So, I get that. And I've seen this go a bunch of different ways, not just at Netflix, but at other companies as well. I have actually had this happen twice on my team in the last three months, including once just yesterday. So it's very timely. And I get that it's scary to go to your manager and say, “I'm looking for something new or something different.” Because the risk is that, in your mind, you might be thinking, “My manager might be imagining that I think this is a judgment on them, or a judgment on the team, or some other kind of bigger threat than what it is.
And I can't say that there aren't managers who wouldn't take it that way. But in my experience, especially here, that hasn't been the mindset. If somebody is looking for a new challenge, that's a good thing. That means that they're growing. That means that especially if they've invested well on your team, that means that they've grown, they've become a better, more solid, more capable contributor and they're looking to be able to exercise some new muscles.
The truth is, if you don't find them in other space within your company, they will eventually find themselves in other space outside of your company. Once you reach the point in your thinking of, “I want something new.” Like, that's a switch that's hard to unclip. Once you get to the point of imagining the future outside of your current team, it's hard to walk that back.
So in my instance, we just went – I'll talk about both of them. And maybe that'll shed some light on how those conversations have gone. So the first one, we had a team reorg. Just shuffled people around so that we could focus on new areas. I brought on two new engineers. As a result of that, two engineers mustered off of my team. And one of those engineers had been in this domain space, which is for my team production finance. So they had been in production finance for a couple of years, and they wanted something different.
And they came to me first, which I took as a – Especially given this was a new direct report, I took that as a huge sign of faith and trust. And I helped them identify roles that were open. So I said, “Well, there happened to be within our org –” I think there were three other open headcount at the time that they would qualify. So there's these three. These are the hiring managers. Go and talk to them. See if they think that it's a fit. And so that particular switch was made in a matter of three weeks.
The second one, the one that just got announced yesterday, there's a very senior engineer on my team who was working on something foundational for our org. So a new development framework that we're going to be adopting as part of conforming all of our financial data together. And I had a quarter to adjust to that. I kind of could see the writing on the wall that engineer had been at Netflix a long time and had a long career and, frankly, was ready for something bigger. And I'm excited about that.
I think as a as a people manager, as a servant leader, which I take – I know that phrase has had some stigma over the years attached to it. I really take it to heart. I think that I serve my team. And it's my responsibility to help them grow and to prepare for eventual futures, hopefully, on my team, if not that, hopefully, in whatever organization I'm part of, or whatever company I'm part of. But if not, whatever future comes for them.
So if you approach leadership from a mindset of, “I want to grow my team. I want them to be stronger and better when they leave their time with me than when they started their time with me.” You'll have no trouble attracting strong talent in an ongoing kind of way. So your well will never be dry.
[00:42:25] JC: And to follow up on that, I mean, you kind of adjusted a little bit with them. Being happy wherever their future might take them. Because I also come from a string of very small startups. I'd never worked anywhere as big as this. And when I was like, “I'm ready for something new,” the opportunity to move around in the company just wasn't there sometimes. So it did mean like I was going to have to leave. I've never told a manager before I had an offer in hand. Is that the best way to go about it? Is there any time that you do want to like have the chat with your manager before you have – Like, you've done the interviewing an you're giving your two weeks’ notice?
[00:43:09] DJ: Well, it's funny you should say that, because I'm always the opposite every time I've left a role, mostly because when I've tried to do – The last like four or five role changes that I've had, I've put my notice in before I had an offer in hand, mostly because I'm not able to give due diligence to a job that I'm at and the job of finding a job.
And so when I was looking to leave a company for a new role, it was different than when I was looking to leave a team and move to another team within the same organization. That was really never an option for me. The companies that I work at were so small, that wasn't really a possibility. So whatever was driving me to leave would still be in play at whatever another team would be on the same team.
But I don't know. I think it comes down to your own situation. There's no one size fits all answer to that. I was blessed to have financial stability and be in a housing market that was pretty cheap. I could afford to be without work for a little while. I've always worked remotely. So I've never lived in the Bay and had the pressures of the financial weight that comes from living in that area. I had a second earner in my household that we were able to rely on their income.
So I don't want to say that you should or you shouldn't. It really comes down to your own specific role. But I think that when you're talking about moving from one team to another within the same company, assuming that there's no ill will, there haven't been any performance problems or no major personality problems. Your manager should accommodate your need for growth. And if they can't accommodate that need on your team, then they should seek out accommodation for that need on another team. That's our responsibility. So my responsibility is not just to my products that we're building. It's primarily to the team and I'm building. The product is what y'all are building. I'm building a team. You all are building the product.
[00:45:08] JC: I love that. And that's like the perfect note, because our time together has come to a close. But that's like such a perfect, like, little ending clip. And is there anything else you want whoever's listening to this to know about management career growth?
[00:45:26] DJ: I think I'll just leave maybe with the thought that your managers responsibility is to make sure that you are thriving and growing in ways that are important to you. And try to reach a point of trust with your manager so that you can have fruitful conversations about that. And then for the managers that are listening, really lean into empathy and compassion and trying to understand where your reports are interested in going, and be a partner to them in that growth.
[00:45:58] JC: Amazing. All right. Thank you, Dana, for joining me.
[00:46:01] DJ: Thanks so much, Jen. It was a pleasure.
[OUTRO]
[00:46:09] JC: Thanks always for listening, y'all. And again, thank you to Dana Jones for coming on the podcast. I'm going to put some links in the show notes to some resources that I really enjoy for engineering management. And I will see you next week.
[END]
Top comments (0)