An extremely important job that is not for every engineer.
In this episode, we talk about engineering management with Alex Karp, engineering manager at Twitter.
Ben Halpern is co-founder and webmaster of DEV/Forem.
Ridhwana Khan is a senior software engineer at DEV
Alex Karp is an #ActuallyAutistic Engineering Manager at Twitter who loves to bring new people into tech and grow leaders. He is in the process of publishing a book called Running Start: How to get a job in tech, keep that job, and thrive.
[00:00:00] AK: It is one of the most difficult conversations. Honestly, I would even say, for me, it’s more difficult than having a conversation about a termination.
[00:00:22] BH: Welcome to DevDiscuss, the show where we cover the burning topics that impact all of our lives as developers. I’m Ben Halpern, a co-founder of Forem.
[00:00:30] RK: And I'm Ridhwana Khan, Lead Engineer at Forem. Today, we’re talking about engineering management with Alex Karp, Engineering Manager at Twitter. Thank you so much for being here, Alex.
[00:00:41] AK: Yeah. Thank you for having me.
[00:00:43] BH: So Alex, really, really excited to talk to you about this topic. I think it’s going to be really valuable for all of our listeners, but let’s start off with your background, everything that led up to where you are now.
[00:00:55] AK: Yeah. So let’s see. So I started out as an iOS developer. And when I was working at Wayfair, I kind of got shoved into engineering management, the normal sort of story where there’s a need for leadership and I was a solid engineer. So obviously, that meant that I would make a good manager. So I started out doing some tech lead responsibilities and pretty quickly that became full on people management. And it’s crazy to me because if you’d asked me five years ago if I had had any interest in going into management, I would have said, “Absolutely not.” But it’s actually something that I found that I really enjoy.
[00:01:39] RK: I feel like there are many variations of like the responsibilities that engineering managers have. What are some of the responsibilities that you have as an engineering major at Twitter? What does your job look like?
[00:01:53] AK: Yeah. I feel like it differs a lot based on your company, but also based on how you view management. So I would say my job at Twitter, a significant portion of that is people management. So I’m spending a lot of my day in one-on-ones with my team. There was a time where I would meet with everybody on my team weekly for an hour, but then 12 direct reports really put a stop to that. But I definitely spend I would say a significant portion of my time talking to my team, working on helping them grow as developers, helping them work through problems, that sort of thing. In addition to that, there is kind of general technical leadership, very high level kind of architectural decisions like that sort of thing. I’m usually not the one making the decisions, because if I’m making those decisions, something’s very wrong. But I’m definitely there to help facilitate discussion and that sort of thing.
[00:02:51] BH: What are the biggest differences between your current role and past roles as an engineering manager? Specifically, what sort of details of your job just completely differ from what you’ve done in the past right now?
[00:03:05] AK: On the whole, I would say, they’re actually very similar because I went from managing mobile development teams to managing a full stack team that is effectively three different teams. So a lot of that has had to be the same, basically. I mean, I suppose a lot of that comes down to different company culture and processes that have taken some time to get used to and some time to understand kind of why things are done a certain way, usually for historical reasons.
[00:03:36] RK: When you first started your career, you mentioned that you were kind of shoved into management. So what did that feel like? And was it something that you just grew to love over time or did you resist it at first?
[00:03:52] AK: I don’t think I resisted it. It was one of those things where, I mean, I say that I was shoved, but really I was pushed inch by inch into it. So by the time that I realized that was happening, it was already too late because, yeah, I started out with just a team of me and another person working on a specific project and that project grew in size. We needed to have more people join that team, and then the company as a whole was growing incredibly quickly. And so the person that was managing all of the mobile development had way too many direct reports. And so I kind of became the de facto manager of the team even without the title. And then it was really at that point when I realized, “I’m already kind of doing this job, I may as well at least call myself a manager and feel like I’m actually playing the part.” But I think for me, also, realizing that I was already doing one-on-ones with people and I realized that I really liked helping people grow. It’s different than engineering where if you’re writing code, there’s like the immediate satisfaction of seeing something compile, seeing something work. But with people, it’s different. You spend six months working with somebody on something and you see them leading a meeting with confidence and really owning things. And you’re like, “Wow! That feels amazing.” But it’s difficult because it takes a long time to get there.
[00:05:28] BH: So you’ve described feeling like you came into this role pretty organically, but then you felt like it really was for you. What about folks who may be thinking that if they want to move up in their career, the inevitable path is management? It seems like you thought about it a lot and you seem to like it. But what about the scenario where you sort of feel like you went that way, but you just thought that was the only option or it really wasn’t for you? What about that path?
[00:05:58] AK: Yeah, I’ve absolutely seen people go through that and realize that they preferred the individual contributor side of things. Or, I mean, I’ve also seen people who really liked management, but then decide they want to go back to writing code for a while, and I think that’s awesome too. I think there’s been a trend more recently at companies where they’re having more fleshed out paths for individual contributors beyond just like senior engineer or a staff engineer. At Twitter, we have roles that go all the way up to what is basically a VP that are still technically individual contributor roles. I think that as managers, we need to be talking to the people on our teams about what these paths look like and really giving them all of the information that they need to make that decision. But it’s also like I tell my team, “Nothing you decided ever set in stone. It’s not so much a career ladder as it is a career jungle gym.” That was a good piece of advice that I got. And so you can go back and forth, you can try out management, realize it’s not for you, and kind of go back to that. There’s nothing final about deciding that you want to become a manager.
[00:07:22] RK: Was there ever a point in your career where you were doing half IC and half management? How did that look for you and what were some of the challenges of that?
[00:07:35] AK: Ah, yes, the bad times. Yeah, definitely. As I was in that transition period between IC and manager when I was at Wayfair, I was still doing a lot of hands-on development and that was really, really difficult, especially since I basically had two separate teams that I was leading. So I had to not only keep an eye on both of these teams and make sure everything’s going okay, but then I also had to sit down and write my own code. And it was something that I talked to my manager and director at the time about frequently. There was this expectation that I would still be doing, I don’t know, 30 to 50 percent of my time as engineering. And there wasn’t enough for me to go around. Especially as my team grew to three or six people, there wasn’t enough time to really feel like I was having meaningful relationships with the people on my team and writing code. Ever since, I’ve really shied away from the idea of like hands-on managers or manager doers. It’s this sort of thing where it’s great to have managers that are able to get their hands dirty if they need to. But once you start expecting them to do that as part of their job, there are just so many conflicting interests that it makes it really hard to do I think a good job as a manager.
[00:09:04] RK: I have recently moved into a lead engineering role, which has some sort of management responsibilities where I do one-on-ones with folks, but I also manage a team and I’m also an individual contributor. And I came to the realization that I enjoy the management part of things maybe about sometime last year, but the most difficult part is knowing whether I’ll ever be ready to let go of like coding in my day-to-day job and whether that’s a path I want to go down to. And I feel like that’s not just my personal struggle. I feel like a lot of developers who move into management have that same feel of letting go of the code they’re writing. Another aspect to it is as a woman in tech, throughout my career, I also need to like prove myself and to be able to show my peers that I am a hardcore coder. And then moving into a more management track makes me feel very confused about the entire situation and it just leaves me with feelings of overwhelm and trying to balance out those feelings that I’ve accumulated over the years and moving past them.
[00:10:31] AK: That’s something that I totally sympathize with, even as somebody who hasn’t really felt the need to kind of prove my skills as a developer as much. The point between going from doing a little bit of development to just like straight management was really difficult, if nothing else, because as an IC, you look at your output in a certain way that doesn’t really match with what you’re trying to do as a manager. And so if you’re trying to measure yourself as a manager with the ruler of an IC, it’s always going to feel wrong. That’s part of why I decided that I kind of needed to go into the straight management side. It was absolutely a difficult decision. I do still miss doing development and I still do a little bit here and there on my own, but it is something that I do miss.
[00:11:27] RK: I think it’s a really tough decision to make. I mean, I’ve seen lots of tweets out there on Twitter, asking for advice or people reaching out to each other to ask whether moving into an engineering management track is the right thing for their career. What do you think are good reasons for people to move that way? So if I’m really struggling to code, does that mean that I probably shouldn’t move in that direction? Or do you think that just that initial phase, that initial hump that you get over and then you realize that you get better?
[00:12:11] AK: I would say if you’re struggling to give up code, that is completely normal and in no way an indication that you shouldn’t get more heavily into engineering management if that’s something that you’re interested in. I think that that’s something that almost everybody goes through as they make that transition. And in terms of what are good reasons to know that you want to get into management, I think if you want to get into management because you want to help your team be the best engineers that they can be and help them solve problems and put out a great product, that is a very good reason why you want to go into management. If you are going into management because you think that’s kind of like the next step and you want to continue your career, that is not necessarily the right reason to go in.
[00:13:08] RK: That transition sounds like a really difficult period and something that one really has to adjust to.
[00:13:16] AK: Yeah. It’s something that you can’t just kind of jump into. There is a big transition period. Something that I’ve really learned, especially helping to grow new managers, is my initial thought was, “Okay, I’m going to try to train this person up as much as I can, try to teach them everything that they need to know so that when they get to the point of having direct reports, everything will be great kind of in contrast to the way that I learned,” which was by reading lots of books, talking to lots of people. There wasn’t much formal training for me, but just kind of realizing that honestly the best way to learn about management is to jump in and do it. You learn what questions you need to be asking. That practical experience is really, really valuable. And so if you have somebody that’s going into management, there are ways that you can try to minimize those risks, keeping that feedback loop really short, being really honest about this person who’s trying to take on this responsibility. And I think that gives them a lot better of an opportunity to learn and to grow rather than trying to teach them everything they’ll ever need to know about management because you’ll never get there.
[00:14:33] RK: What are some of the skills that you look for in new managers that help you identify that this person will probably be a really good manager?
[00:14:45] AK: I’m looking at the people who are mentoring people on the team or mentoring people on other teams. I’m looking at the people who are facilitating discussions on the team and making sure that everybody at the table gets to be heard. I’m also looking at the people who are reaching out to other teams and making sure that we have relationships with those teams. Those to me are all really good indicators. People who provide really thorough and thoughtful feedback are also a good fit, but I also try to avoid pushing somebody into management. I will happily tell somebody that I think that they’re a good fit, but I think there’s a danger in trying to convince people that they have the skills to be a manager. It’s very possible they do, but not everybody wants to go down that path. And so it could be really easy to push that on somebody when that might not be what they want.
[00:16:12] BH: So anybody sufficiently experienced in software development building on a team will speak to the notion that eventually it’s more people problems than code problems most of the time and then the code is just the outcome of successful working with people. As a manager, how do you feel about your empowerment to kind of really solve for some of these problems? If you are the IC, you also kind of have to work through people problems, getting decisions made, if you have an opinion about some direction in the code or thereabouts, but as a manager, what’s the sense of your capacity to really solve for some of the people problems and help it be more about the challenge at hand than the capacity to agree and things like that?
[00:17:01] AK: Yeah, it’s an interesting question. What I tell people is that as a manager, I think that it’s my job to support my team. And if I support my team, they’ll take care of almost everything else. If I’m removing roadblocks or just kind of like helping them do what they do best, then that’s how things get done. It’s also why for a lot of my career as a manager I’ve really stuck to the philosophy of, “If you give somebody a task, tell them that you’ll be there to support them. If they need help and then just get out of their way.” I have been constantly amazed by how much people are actually able to accomplish under those conditions. So yeah, I do think that there is a lot that I can do as a manager to really create the sort of environment that is conducive to really productive and inspired work, but that is something that you don’t necessarily get for free and there’s a lot of work that goes into that.
[00:18:11] RK: What are some of the actionable things that you do to support your team?
[00:18:17] AK: A lot of it comes down to things like process. I know that for a lot of engineers process is kind of a four-letter word, but a lot of it comes down to making sure that there are processes in place that really enable people to do more rather than slow people down. So it’s things like making sure that we have regular touch points, regular stand-ups, sprint planning, these sorts of things, making sure that we have mechanisms in place to hold ourselves accountable to the work that we think that we’re going to do. But then again, in terms of holding ourselves accountable, that we’re holding ourselves accountable in a way that doesn’t place blame on anybody, really creating feedback loops there to say, “Oh, we didn’t get this project finished this sprint. What can we learn from this?” So the next time we can estimate this better. Ideally, creating an environment where there is the psychological safety for people to take a look at what’s going on, think critically, and feel comfortable saying something and kind of effecting change on their own I think are some of the biggest things that like as a manager I can do to help my team.
[00:19:35] RK: I’d like to dive a little bit deeper into the processes and methodologies that you follow when you provide the support, what kind of systems have you created that you found really work for engineering teams and what hasn’t worked thus far?
[00:19:53] AK: I mean, for me, the biggest thing that’s worked is the emphasis that I place on one-on-ones. Like I said, for the longest time I would by default schedule one-on-ones for weekly for an hour. I mean, if anybody felt really strongly about it, we would use a different cadence, but I liked the idea of having an hour of my time that is blocked off for them to talk about whatever it is they want to talk about, whether that’s status updates or they’re thinking about a promotion or they’re having trouble with somebody on the team or anything that really comes to mind. Because for me, when I would do them for half an hour, I would always get to the end and be like, “Oh, I wish just like five more minutes. Right? Let’s talk about something.” And I realized that I’d much rather give back time than kind of wish that I had more time to give. The nice thing about that too is that since the time’s already blocked off, it allows for more just kind of informal chatting, not even like work-related chatting, but I think that’s really big for helping to develop rapport between you and your team and making them feel comfortable reaching out to you about things and really kind of humanizing the both of you. Though, like I said, it’s not a solution that works for large teams, but it is one of the big things for me. And then also particularly in my case where I’ve had either actually separate teams or a team that kind of acts as three separate teams is making sure that there is at least one person on each of those teams who is kind of keeping an eye on things and is coming to me if they have any problems or anything like that. But I honestly would not be able to manage the team at all if I did not have people on each of these platforms that look the day-to-day stuff because that just kind of frees me up to look at things as a whole.
[00:22:02] RK: I feel like the engineering management role can sometimes seem like a hidden superpower and often I feel like the engineering management role doesn’t get appreciated as much as it should be because you do a lot of things behind the scenes to enable others to be able to carry on their daily work. And so it’s like being an invisible superhero.
[00:22:32] AK: Yeah. I talk about it in terms of like the many different hats that I wear. I have my therapist hat that I wear, what I call my bartender hat, which is very similar to the therapist hat, it’s me just kind of like listening to somebody. But I was also telling somebody recently that I think one of the more difficult parts of management is that anything that isn’t explicitly done by somebody else tends to fall onto your plate. So it really does require you to be adaptable and just look at what needs to be done and do it. It definitely makes the day-to-day kind of different based on what’s going on.
[00:23:30] BH: Have you ever had any particular difficult periods as a manager? I imagine some of the details are private, but how have you worked through some of these challenges and just speak to like the difficulties and overcoming them in any particular period?
[00:23:47] AK: The thing that comes to mind for me is that, I mean, and this is going to sound like one of those what are your weaknesses clichés, but I care a lot about my team and usually that’s a very good thing, but the way that that ends up playing out is that I get very caught up in trying to do what’s best for them. And that can be really difficult in a number of ways whether it’s fighting for somebody’s promotion who I think really, really deserves it or making sure people are paid fairly. Or even if I’m going down to performance management or helping somebody, it’s so important for me to approach that with compassion and empathy. And so that process for me tends to take longer than I think it would have been to other managers because I’m spending so much of my time and energy trying to make things work. And that can be really draining. I honestly wouldn’t change it for anything in the world, but there have absolutely been nights and weeks and even months’ times where I’ve, at the end of every day, just been completely mentally and sometimes even physically drained from the day and from really giving my team everything that I have, and that can be difficult.
[00:25:12] RK: What are some of the strategies that you use to help yourself disconnect slightly?
[00:25:20] AK: Well, I mean, therapy is always a good tool, but I would say a lot of it for me, especially more recently, has been being honest with myself about what I can and can’t control, what it is that I’m able to do to help, and really just getting to a point where I’m happy that even if something ends up being kind of suboptimal for somebody on the team that I can be happy that I did everything that I could and that they know that and they feel that support. That’s been big for me. I’ve also recently been coming to terms with the idea that sometimes what’s best for a person isn’t necessarily what you might think is best. So really, I guess, being open-minded to a person and their needs, what is the best pathway forward for them.
[00:26:18] BH: What’s been the most challenging type of feedback you’ve ever had to give as a manager?
[00:26:25] AK: I’m not sure if this will answer your question, but what comes to mind to me is the discussion where you’re telling somebody who you’ve put up promotion that their promotion didn’t go through. It is one of the most difficult conversations. Honestly, I would even say, for me, it’s more difficult than having a conversation about a termination, especially for somebody like me who literally puts in everything to try to make this happen. I have to go back to somebody and say, “I still think that you’re operating at this next level, but we couldn’t prove that to the promotion committee or whomever it is that we couldn’t do that.” And being able to take that and turn that into, “This is the feedback that we got. This is where we think that the opportunity areas are,” and then working that into, “Okay, now we’ve got these very concrete things that they feel like we’re missing and we can work on these things.” But it’s just a devastating conversation for a manager and it’s also not fun as the person who’s being told.
[00:27:39] RK: I haven’t even had that conversation, but just hearing you talk about it gives me like this heavy feeling. It sounds like a really difficult conversation. And I didn’t think about it in that aspect.
[00:27:52] AK: Yeah. And I think for me, especially with the way that I handle things like promotions is that I believe that they should be as transparent as possible, like I have the person working with me on writing up the promotion packet, like they’re there with me answering questions and doing all of these things as we try to prove that they’re ready. And so they know that I think that they’re ready and I know some managers try to keep that closer to their chests, not necessarily giving people too much hope in a way of trying to come shield them from that. But honestly, I definitely think it’s better to have them along for the ride so that they understand what’s going on. Otherwise, it’s really easy to feel like they have no agency over their career. Right? They get to see how everything works, then they realize, “Okay, yeah, I’ve got a lot of agency. I really can drive my career and this is how.”
[00:28:53] RK: Have you worked as an engineering manager both in asynchronous and synchronous teams?
[00:29:00] AK: Yeah. When I was at Wayfair, we had a team that was split between two offices, one in Boston and one in Berlin. But for the most part, everybody on my team was working out of the Boston office. We would occasionally go over to Berlin and work more closely with them, but it was very in-person and then coming to Twitter, especially during the pandemic, where like it or not, everything had to be virtual became really interesting. And it was also a really interesting time to onboard as a manager. You take for granted your ability to just kind of like walk over to an area of the office and like meet everybody on the team. A lot of the impromptu interactions you have with people that you just completely miss out on when everything is very intentional. Like if you have a meeting, you have a meeting and talk about a certain thing, like you have to schedule that in advance. So yeah, I would say overall, my team in Twitter as a whole has been doing a really good job with handling working remotely, but also kind of working across locations in general. My team used to be mostly Boston-based. Now we’re spread out across the US, but we’ve worked very closely with teams in London, Seattle, San Francisco. So we’ve been able to really take advantage of not only having meetings that are inclusive of people in different locations, but really pushing towards what needs to be an actual synchronous meeting, what can be done asynchronously or maybe it’s a little of both. Maybe there are some pre-reads and you have a discussion that starts asynchronously and then you get together and just like have those final discussions. It’s been a really interesting experience. I didn’t realize how much I kind of value being in the office and being with other people and that sort of thing. So that part honestly has been a little more difficult for me, but I do really enjoy being able to work with people in different locations and not necessarily having to restrict ourselves to just the people who are around our office.
[00:31:20] BH: Why don’t we go around and offer some final thoughts on this broad subject of engineering management and then we’ll let you go, Alex? So why don’t we start with you, Alex?
[00:31:33] AK: Engineering management is a huge responsibility, but it’s something that if you really care about growing people and about helping people be the best engineers that they can be, it’s something that’s incredibly fulfilling.
[00:31:55] RK: This conversation has been really fruitful for me in terms of being able to understand that I’m not alone in feeling like it’s difficult to let go of coding. I think that being able to spread that message is really powerful. I also want to encourage other folks out there, especially women in tech, who like myself have at some point felt the need to prove themselves and have found it difficult to move into management because of the way they’ve had to prove their IC capabilities in the past, I want to encourage you then that if they feel it’s a good fit for them, we shouldn’t let other people’s perceptions overcome what our ambitions are.
[00:32:56] BH: I will send us off with a book recommendation that comes to mind, which is not about management, but there’s this book called Creative Selection, which is a memoir about someone who worked on the original iPhone. And it’s not strictly about this topic. But the first quarter of the book is a lot about this person’s career. They were engineers. They moved into management and then they wound up not really liking it, moving back into more IC stuff, like high level technical individual contributor driven work. And I thought the book’s purpose was really to kind of tell stories about what building the iPhone keyboard was like and what Steve Jobs was like. But it was very authentic and that the author set the story of just like, “Well, I was an important role-player, the natural path was management, really wasn’t quite for me and it was difficult.” Yeah, I found that that book to be like realistic. You don’t see a lot of memoirs from people whose story is that like management wasn’t for me, but I was around something interesting enough to be a book. So something I felt like bringing up based on where the conversation went. And thanks for joining us.
[00:34:10] RK: Yeah. I’ve been nodding vigorously the entire session. It’s been very disruptive to audio as well. If you hear any tiny crackles in this podcast, it means that I was nodding vigorously and I wear a hijab over my headphones, which keeps crackling.
[00:34:32] AK: Thank you both for having me. This was a lot of fun.
[00:34:44] BH: This show is produced and mixed by Levi Sharpe. Editorial oversight by Jess Lee, Peter Frank, and Saron Yitbarek. Our theme song is by Slow Biz. If you have any questions or comments, email [email protected] and make sure to join us for our DevDiscuss Twitter chats every Tuesday at 9:00 PM US Eastern Time. Or if you want to start your own discussion, write a post on DEV using the #discuss. Please rate and subscribe to this show on Apple Podcasts.