We're ecstatic to announce our new podcast, The Debrief. In this series, you'll hear insightful conversations with engineers, product managers, co-founders and more, all about the debatable topic of incident management.
We'll discuss tactics and best practices, debrief on real-life response stories (good and bad), and even shed some light into how we run things here at incident.io: from product launches to Game Days and more.
In our inaugural episode, we sit down with Alicia Collymore, Engineering Manager at incident.io, on sensible advice she'd pass along to first time EMs. We discuss:
- Advice for figuring out what type of manager you want to be
- How to navigate the challenges of a report who may not be performing well
- Why it's important to delegate responsibilities you once owned
- Why building genuine relationships with reports is crucial
- ...and more
You can catch The Debrief, every Monday morning on Spotify, Google Podcasts, Amazon Music and Apple Podcasts.
The transcript below has been edited for clarity and may not match the audio exactly.
Luis: Hey, everyone. Thank you for joining us on The Debrief. My name is Luis. I'm your host today. And today I am joined by Alicia, an Engineering Manager here at incident.io. Hi, Alicia.
Alicia: Hi.
Luis: How are you?
Alicia: I'm good. How are you doing today?
Luis: I'm doing good. So the focus of this conversation, is basically going to be around practical advice for engineering managers. As I just mentioned, Alicia is one of two engineering managers here at incident.io, so I figured it would be really helpful for people who are maybe first time engineering managers or engineering managers who are just looking for a little bit more advice for how they should be running things. Alicia's a great person to help pass some of that advice along.
But anyway, I spoiled the plot a little bit by telling you that Alicia is an engineering manager, but I'll let you speak for yourself. Alicia, can you tell us a bit more about yourself, your background, what you do here at incident.io?
Alicia: My background generally is in engineering. I spent a lot of time on the front end side of things before moving into management. I've been a manager now for coming up to four years. Being an EM generally has different shapes in different companies. I tend to lean towards sort of people and delivery rather than a deep technical engineering manager and certainly not a hands on engineering manager.
I haven't written any valuable production code in the last three years, so not something I should be doing. But my main thing is team building, delivery, and people. What are we doing? Why are we doing it? Are you enjoying doing it? And how can we do it better?
Luis: I'm curious, what was your first introduction to engineering management. So I guess another way to ask that is how did you transition from more hands on code writing to being more of a sort of people, engineering manager.
Alicia: I think, like most engineering managers, you kind of get tricked into it. So I was tech lead of a small team. And my manager was like, 'Oh, maybe you should try managing.' And I'm like, 'No, no, no, definitely don't want to do that.' And this is how they get you. They're like, 'Oh, just manage one person. Maybe you'll like it.' So you do that and you manage one person and they give you a good person too, right? So you're like, 'Oh, actually, this is not this bad. I feel like I can do this.' You enjoy it and then you're like, 'Yeah, give me more, give me more.' And the next thing you know, it's three years and you're leading multiple teams and you've worked in many different companies as a manager.
But honestly it is something that I love and I think I honestly prefer the thought and thinking that goes into being a manager versus an engineer. You have to be a little bit more considered. And I think in engineering, of course you have to be considered, but it's very different when you're dealing with people versus code.
Luis: Now that you've seen sort of both sides of this, which do you prefer? Do you prefer more of the hands on delivery or do you prefer people management?
Alicia: See, that's the thing. I think the way that I see an engineering manager is that you are still responsible for delivery. I might not be writing code, but I am hands on. I am involved in what my team are doing. I can tell you exactly what each engineer is currently working on, what projects we have, what projects are coming up. I'm very much involved in delivery. I am just not the person writing the code. That's kind of the way that I look at it.
I prefer being a manager by far. I like the problems I have to think about. How do I stay in a team? How do I scale or grow a person? How do I encourage a person? How do I help a person? These aren't easy things to think about. And that's not to say code is an easy thing to think about, but it's just different. And I think people are different. And every single person you meet is completely different.
Luis: I think you teed up my next question quite well. What are some of these challenges? Like you just alluded to some of them, but I'm just wondering if you could speak to those a little bit more. Because like you said, I think once you're introducing people into the equation, it becomes that much harder because everyone is unique.
Everyone has their own unique needs, their unique skillset, their career goals, so on and so forth. And you're basically the person who's responsible for setting this person up for success long term. Just curious about some of the challenges that you've had to manage over the last few years.
Alicia: Yeah, for sure. I mean, there's so many right? Because each person is different, each person comes to you with a different sort of perspective. So there might be somebody who knows exactly what they want out of their career in life and they tell you that and you sort of help lay out the steps or work with them to lay out the steps to help them get there. Like, 'Oh, I want to be a tech lead in the next two years.' Great, fantastic. What do you think you're strong at? What do you think you're weak at? Let's work towards those things.
And then there's the person that's like, 'I don't know what I want to do in two years.' Like it could be anything. So then it's a different conversation. Then it's like, 'Okay, let's sit down and think about what those possibilities are. Which ones sound exciting to you? Which ones do you want to lean into? Don't worry, like you're not going to do this thing just because we talk about it, but let's talk about it.' So it's kind of like opening up minds to all of the possibilities and opportunities that person has that they might not be able to see. There's also the people that just don't really care. And like they're cool too, right? But there's still improvements that they can make day-to-day and those are the things that we can talk about and progress.
Lastly, there's the people who are underperforming, and those are the difficult ones, right? The people who want to be doing well and aren't. And they're struggling. And you have to sort of try and grok it with them. Those are the difficult problems. Those are the hard ones as a manager. It's not always obvious what the problem is. You can spend a lot of time with that person trying to figure it out. But as long as they're willing, for the most part, it's okay. But I think there are times where it is a lot more challenging, especially when they aren't as willing or maybe they don't care as much. But you do as their manager. You're in a bit of more of a battle. And that's difficult.
Luis: We're going to get into more general advice, but I want to hone in on that a little bit more. Because I can imagine many engineering managers deal with this. You have the one person or a few people who just aren't stepping up as much as you'd like them to. And obviously this can be for many reasons.
But just curious, in your experience, what are ways that you would typically navigate that? Is that maybe spending a little bit more one-on-one time with this person? Hearing them out to listen to what exactly they're struggling with? Is it something personal? Is it something, you know, about the infrastructure that you have in place that's giving them challenges? Just wondering how you navigate that specific problem of somebody who might be underperforming?
Alicia: Yeah, I think it's definitely about understanding where they are at. I think first and foremost, it's feedback. It's delivering feedback to that person to let them know like, 'Hey, I don't think you're doing great here. What do you think?' And have a really open and honest conversation with that person. I think if you've built a good relationship with your reports, then it's a lot easier to have those difficult conversations. So, you know, having a good relationship, being able to bring difficult feedback to somebody and have a conversation about it, I think is really, really important. And then it's a case of, 'Hey, what is going on here? Is there something going on in your personal life?' It's always the first thing. You don't know what people are going through.
I think that's important to take that into consideration and give people time to go through what it is that they need to go through without putting pressure on them that they need to perform better at work. Work is work. It's not the end all, be all of your life at the end of the day. And sometimes there is an end all, be all thing going on that somebody needs to put their time and energy into. And that's okay.
And then there's the people who are sort of missing the mark, but don't really realize they're missing the mark. Maybe they don't have something going on at home, but they're like, 'Ah, actually, like, this feedback is useful. What can I do to improve here?' And being actionable and explicit on what the next steps are. Where they need to focus on. Not giving them a thousand things. It's like, 'Hey, here are ten things, but actually these three things are the most important. Let's work on these. When these are good and we're both feeling happy about these, let's move on to the next one.' So there's definitely a sense of encouragement that you need to be giving with feedback and with people who aren't performing as well as they could be.
Luis: One of the things that you just mentioned now is relationship building. And I think that's something that often gets lost in these conversations. Managers often seem to be focused on managing workloads and tasks and things like that. Managing the relationship that they have with their reports is kind of secondary, maybe even tertiary in all this. So I'm just wondering, what are some things that you do to build relationships with the people that report to you?
Alicia: I don't think I necessarily do anything specific. Like I don't have a build relationship game plan. But I think it's about how I look at the relationship in general. I don't see myself as somebody's boss who is here to tell them what to do. I see myself as somebody who is almost a peer on the very same mission to deliver this thing. To deliver this product, to help this business succeed.
My role is just different in that your role is to ship code. My role is to build people and teams. And I need you, and you need me. So how can we work together to make this thing happen? And I think when you approach it from that place, like this is a partnership. This isn't, you know, a manager report even though these are the terminologies that we use. l see it as a partnership. Like how can I help you? How can you help me and how can we get this thing done? How can we solve this problem together? Not you are the problem. And I think when you approach things like this, it just naturally builds a good relationship. In my very first one-on-one, this is the spiel, so to speak, that I give. I'm opening the door to, 'What can we do here? Let me know. I'll do my best to make it happen, but I expect you to do the same.'
Luis: So letting you in on a secret, I want to be an engineering manager. And you're an engineering manager and I need your help. Give me your three best pieces of advice.
Alicia: I think the first one, especially becoming a new manager is to delegate. Everyone says this and everyone says it because it's true. You're going to want to hold on to things. You're going to want to do things yourself, especially because that's what you're comfortable with. And that's what you know. You know how to do these things. So you sort of tend to lean on 'Let me just ship this one thing. Let me just do this one thing.'
But ultimately, what you end up doing is blocking your team blocking delivery because you don't have time since you're in meetings. So you don't have time to do a ticket or you're trying to do it in between [meetings]. And that doesn't feel good. And then you don't have time to put into your engineers. You're spending time on this ticket when you should be spending time gathering feedback or doing this other thing. And then also you're taking away opportunities from your engineers by taking this thing. And that's not cool anyway as a manager. You're there to multiply and grow people. And if you're taking opportunities because you're not delegating, it's not a great thing. So delegate. Let go. Delegate.
I think the second thing is build that relationship. Figure out what type of manager you want to be and build a relationship based off the back of that and stick to it. Don't be flaky or floppy. Be consistent. Be that consistent person in your team's life, in your reports life. And then, third, find your thing as an EM. Is it career development? Is it people specifically? Is it teams? Is it delivery? Is it being more technical? Because that's cool as well. But different companies have different types of EMs, and it's good for you to understand what type of EM you are. So when you're looking for a new role, and when you're looking for a company that you want to work with, you can find something that suits you.
You can lean into your strengths and actually help people in the way that they need to be helped. Like I said, it's a focus on teams, delivery, and people. If I started running off and doing loads of like weird technical things, people would be like, 'Why are you doing that?' But in another company, maybe that would be the expectation of me. So figure out what it is that you like to do. Figure out what it is that you're good at and lean into it.
