You need to be very open and receptive to feedback. You need to accept when you need to tell somebody something that they're not going to like. You also need to accept that you know when somebody is going to say something you don't like and you just need to deal with it. Welcome to the Ladybug podcast. I'm Kelly.

And I'm Emma. And we're debugging the tech industry.

Emma.

Kelly.

It's been a while.

October 2021 was the last time we talked.

Was it really?

It really was. I was looking at our last episode that we published. It was October of 2021.

That is a very long time.

Now we're three and a half years.

Older and not three and a half.

Years wiser, but not by any means. What have you been up to?

You know what I, the biggest change is I left my startup and shut down my agency and joined another company. I became like a real life employee for my first quote, unquote, real job.

Yeah. How is it being a grownup? Being a grown up?

By grown up, I mean working for.

People that aren't yourself.

No, actually I've been loving it. You know, I, I, when I made this change, at first a lot of people were like, oh, you're totally going to go back into like starting your own company. And I'm like, you know what, I'm good. Like, I don't have to run literally everything now. So why, why do that?

You don't miss it?

I don't, I don't, I don't, I don't. Like, I still dabble in side projects. I've kind of reinvented my world. That is now, you know, engineering leadership as opposed to entrepreneurship or really anything with software engineering. I don't write code anymore.

Yeah, me either. I don't miss that though. We can get into that.

Yeah, that's a, that's a change. What have you been up to?

Oh, my goodness. I've had one and a half children so far. I say half because the second one is going to be due at the end of April, which is exciting. And I switched careers still within Spotify. So I was an engineer at Spotify last we talked. But yeah, now I'm an engineering engineering manager and I have been for over two years and I'm loving it still in Sweden.

Been that long?

I know it's been a long time, but I guess that's what kind of sparked this idea to do a seasonal engineering leadership. Because you've been my mentor for two years.

That's true. We've been talking about these. These topics for quite some time and now we're actually, you know, talking about it with the world, so that'll be fun.

Yeah.

So what are we talking about today? What are we doing today?

We're talking about engineering management and I think just a brief introduction to the field and what it entails and why you may or may not be interested in it.

I think that's a great idea. I like, I like starting with this introduction because it feels like it would be very obvious, like what engineering management is. Well, you're a manager of a team, of course. Like, that's clear. But engineering management shows up so differently across every single organization. Even, you know, at my own company, we. We're a smaller company still, but we. We have three engineering leaders. We have four engineering people in engineering management, and all four of us have a slightly different role.

Mm. Yeah, it very. I mean, this is the only company I've been an engineering manager at, but I have to presume that different companies, it's just so. I don't want to say so polarizing. There are going to be things that are very similar, but I would say the scope of the role will change drastically depending on the type of company, how large it is, how many reports you have, things like that. But I think something that's maybe a common misconception is that management and leadership are the same thing. So I'm curious what your take on is between the like as it pertains to the intersection between leadership and management, where they differ. Because we're here to talk about engineering leadership as a whole, but this episode specifically on management.

Yeah. I take engineering management as the, like, the tactical actions you're taking to say I am a leader of people. I am focusing on the delivery of projects and making sure those projects get done by the people on my team. Whereas leadership is how you show up. Leadership is, you know, how are you communicating with your team? How are you handling conflict? How are you growing your team members? How are you growing as well? And what, you know, what impact are you having in the organization within your role? You know, I do a. I have a course on getting into engineering or getting into leadership in general. It's not just purely for engineering management. And there is a. There's a whole component of that where you don't actually have to be a manager to be a leader. And that distinction is really, really important because anybody can be a leader without having to have direct reports.

It is. It's more about influence. And leadership is not being A leader is not something that you can force, in my opinion. It's something that. Oh, I don't know how to explain this in my mind. It's something that you are seen as. As a direct result of your actions and how you interact with people. And management is like a finite position. Like you said, it's more the tactical role itself. So, yeah, I guess the question is, why are we qualified to discuss this? And I'm curious what your, like, team makeup looks like, how long you've been in management, and then I can give you an overview to mine as well.

I have been in management for going on 10 years, so a while. And I've done this in various facets of my life. When I was running my agency, the Tap Room, I had everybody reporting to me, obviously as CEO. So it wasn't just manager, it was just. Wasn't just engineers. It was, you know, sales. It was our account managers. Like, everybody was reporting to me. Now, my current team makeup is. I'm trying to figure out how to. How to describe this. My current team makeup is nine engineers. I'm essentially a frontline manager right now, just based on where we're at with the company. I've had managers in the past that have come and gone for various reasons. By the time this episode rolls out, this will be different because I will have one manager, an org of about 6, 7 total, and also two product managers reporting to me as well.

Oh, wow.

So very different role.

Yeah, yeah, yeah. Can you explain what a frontline manager is before, just in case?

Yeah, yeah. Good call. Frontline manager is you, you know, you are one level above individual contributor, frontline managers. You are. You are literally at the front lines. You're in the action. You're, you know, that thousand, like the ground level, you know, what's happening across every project. You're able to talk very detailed about that. That information about whatever, you know, whatever it is you're working on. Whereas as you move up, then you kind of get into middle management and that's when you become like a manager of managers.

Indeed. Nice. Yeah. So I am also a frontline, frontline manager. First side manager. I have seven engineers and we build the desktop and web player app for Spotify, which is extremely cool. That's. It's the same team that I was an engineer on. I just. During my parental leave in 2022, when I was off with my D daughter for nine months, the position became available. I interviewed for it and was really grateful to have gotten the. The role. So that's another Thing is, how do you transition into managing your friends or coworkers? That's a whole other topic. But yeah, so I managed a team of about seven engineers. Additionally, we do this thing called Embeds where we have people come sit with our team for an extended period of time, whether it's two months, one month, six months generally is what we would like to see. So technically I have nine engine right now. And the seniority, the technical seniority ranges from like an engineer to, to senior engineer. So not on the staff level. So yeah, that's kind of the makeup of mine and it's been. Yeah, a little bit over two years now.

Okay, so here's a question for you.

Yeah.

You mentioned earlier you don't code. Did you, when you transitioned into this engineering management role, did you immediately stop coding altogether for your team or did you still take on some engineering work?

I stopped coding when my parental leave started. So essentially I had nine month break and then immediately picked up the management role. So I hadn't coded since it was January of 2021. So the thing is I could, I could absolutely be coding. I could be picking up tasks. It's something that I have ongoing conversations with my team about, but it's also something that I am a little bit weary to get back into because my primary focus, in my opinion, should be on my, my team, what they need, understanding the technical direction and our roadmap and all these things, working with product. So should I get back into coding, I worry that the opportunity cost there wouldn't necessarily be in their favor. Right. So they don't need me to pick things up. What they, where I need to excel is the technical competence of like our limitations. Where, where are we struggling, how are we building things, how do we interact with our partner teams? So I don't think coding will solve that. However, I'm more than welcome to. I just for me, I'd rather learn more about the architecture and things like that.

Yeah, that's, that's pretty similar to my role. I have opened one pull request in the almost three years that I've been at this company.

Yeah.

And that pull request was to rename Microsoft 365 to Office 365.

Oh, that's good.

So yeah, that's the extent of it. There is a, there is a repo that we have that I built that's basically like a basic Shopify storefront for something that we did, which is obviously very much my, my wheelhouse given my background. But what was interesting about it is given that it's Shopify. It's like vanilla JavaScript, basic HTML and CSS, which, you know, most people are not using for building web apps these days or whatever it is they're building. And so, you know, it was. It was a fun little side project. But I have no interest in coding at this point, especially, like, with the size of my team now. I will jump into technical problems. Technical problems, no problem. It's a weird thing to say, but basically, like my. I'm still deeply technical, where I can go, you know, and help troubleshoot an API issue, or I can look at our code base and say, this is this, you know, this is kind of what we're looking at. Let's debug this together. And I'll pair with my team sometimes, but I am no longer, and I haven't been for a very long time. If I was ever the best engineer in the room and I should not be taking on tasks, right?

Yeah, I wasn't very passionate about it, to be honest. I kind of lost. I don't know if I was ever super passionate about coding. I enjoyed it, I was decently good at it, but I was never again the best engineer in the room. Never really wanted to be. That being said, yeah, I think being technical does not directly correlate with coding. So for me, I'd much prefer to write technical strategies. So right now I'm working on an evaluation of our testing strategies strategy to see where it's effective, where it's maybe not effective, what are the metrics we want to measure productivity against, and then to come up with an RFC or a request for comments discussing what the strategy should be and where we should focus. So you need to stay technical as an engineering manager, but it doesn't necessarily mean you have to be coding. Like, I have a partner. We have a partner, like desktop team and their em. She's highly technical. Like, she was a senior engineer before transitioning, and she still picks tickets up, and she's really great at that. So it's definitely. You can pick and choose how you stay technical, but for me, I'd rather do it from a more theoretical perspective.

Yeah. And this kind of, you know, this is a good segue into, you know, what ems are responsible for, because this, again, this shows up differently from team to team, from organization to organization. But what's most important is you're responsible for the success of your people to deliver the projects that are assigned to your team. That might be, as you move up in an organization that is defining the roadmap. And then delivering against that roadmap. But what I've seen other engineering managers, a mistake they make in the past is they love being technical and they'll be like, well, I, you know, I, I want to, I want to still be coding. And I'm like, that's fine. But you cannot be taking critical path projects because you need to be available to address the people and process issues that come up. And if you take a critical path project, you're going to find you're going to have probably substantially less time to actually write code.

Yeah.

And then you're slowing down delivery.

I also feel maybe I've just had a bad experience in a previous company, but I had a manager. I've had, like, two prior managers that were, like, polar opposites, where one was not technical in the least. So, like, she was not able to grow my career. She didn't understand the contributions I was making. It was pretty stressful. And the second he was really missing coding, like, he was an IC or an independent contributor or software engineer on a team prior to becoming a manager, and he had a lot of trouble letting go of coding. And I remember I would have personnel issues with another colleague and he was just not available. He did not want to hear me out. He was, he never wanted to meet with me to help troubleshoot it. Like, your primary goal is. Yes. It's half between, like, managing people, their careers conflict on the team, et cetera, with, like, team health, and then partially, like, yeah, ensuring that the things that you've committed to get delivered and are held to the standard of your technical strategy. So it is a slippery slope.

Yeah. Yeah. Okay. So how would you differentiate an engineering manager from a team lead?

A team lead is someone in my opinion, who is going to be responsible for solving these complex problems and developing different solutions based on limitations or what is important to prioritize, whether that's performance or, I don't know, other things.

And would you, would you differentiate between tech lead and team lead, or do you treat them one of the same?

It's. I think this is a very Americanized question, and I say that because in.

The US this is why we're talking about it.

Yeah, it's so tricky because in the us like, I had so many experiences where titles were incredibly important and if you, like, didn't respect the titles, you were called out immediately. I had this happen when I was over at IBM and it was a really, like, traumatizing experience for me because I got moved onto a design team and I asked, like, is my title still front end engineer or is it software engine? Like, what is my job title now? And I got reamed out for it by the design lead. Like, titles are super important. Hierarchy is very important. Right. However, in Sweden and in Germany, like from my experience, it's a lot less title focused and more on. Yeah. So it's tricky in my eyes. Like when I hear tech lead versus team lead. I don't know, it's tricky. Like when we have different work streams that our team is committed to. We are on six month launch periods, we're planned for six months, and then we have different work streams for things we've contributed to. I call the road manager, the engineer who's responsible for seeing through the success of the work stream. I call them the tech lead. Other people call them road managers. Others might call them team lead for that project.

So for me, that's.

The title itself is not the most important thing. It's more like what is the responsibility? But I'm curious what your take is.

Yeah. The reason why I asked this is because this is one of those things that are, they're, they're phrases that are often used interchangeably and they're also defined differently at different organizations.

This is true.

In, in my opinion there is a difference between them. Where a tech lead is exactly what you said. They're responsible for the delivery of a project, the architectural design, for example, for making sure they get point A to point B to point C on that roadmap and actually get that project delivered. Yeah. At that, at that high quality level you expect. Whereas a team lead is where you start to see some level of people management come in.

Oh yeah, okay, that makes sense.

You might have like one or two people reporting to you, but you're still, you're still coding. I find the reason why, and I honestly, like, this might be a spicy take, but I don't like the role of team lead because I think it sits halfway between being an individual contributor and being a manager. In a way, it feels like you're not committing to either path. And so you're, you're not delivering fully on one way or the other. And I know, like I said, that that is a very opinionated take on the idea of a team lead. I think it's a good stepping stone, but it should not be a permanent role.

I don't know if I've ever interacted with a team lead and I've never been in a company there where there was a team lead. It's always been engineers were managed by a people Manager.

Yeah. And to me, that's the way it should be.

Yeah. Yeah. Huh.

So there we go. It took less than 15ish minutes for me to break, you know, give my first spicy take. Did.

That's about as spicy as like a black pepper.

I know. It's not very spicy at all, I'm sure. You know, we'll see, we'll see what happens. It's fine. Yeah. So you know, with that, you know, the whole purpose, like the, your whole responsibility as a manager is the people on your team. It is, are your, are your team, is your team able to deliver on the projects that are assigned to them? Are you supporting them in their career journey? Are you giving them the context they need from a business perspective to be able to do their best work? And are you empowering your team to deliver?

Yeah, I always say this and maybe I should stop saying this, but if I have made myself redundant, I've done a good job because it means that they are empowered and able to do their jobs without me. That's kind of how I feel approaching like a six month parental leave right now. I'm like, I feel that I've put a lot of effort into like sustaining a healthy team culture and preparing the roadmap and ensuring that while I'm gone, whoever steps in for me has all of the resources they need to do my job. And like, so if I'm making myself redundant, that's like, that's how I know we've reached a pretty good cadence.

Yeah. And that's, honestly, that's the goal. Like my, my team is very self managed. They know what they're working on, they deliver on it. They, you know, I continuously get updates on what they're, they're working on. If they need help with something, I'm obviously there to help them with it. If they have questions around prioritization, we have an escalation come up. One's more important, the escalation or the actual roadmap work? I'm still useful in that regard because I feel like I'm playing traffic cop in a way. But my goal was to make my team self managed. You know, that's the empowerment piece. That is the way that like they feel like they can, they're determining their, their own career path and they're able to really grasp onto that and feel proud of the work they're doing and feel that ownership over the work.

Yeah, that's important. I'm going to ask you a spicy question now, which is where do you think you fall short as A manager. Is there an area of management that you find that you struggle with the most?

There are times when I feel like I should be more technical than I currently am. And as my role continues to evolve and as I continue to move more, you know, I'm a director of engineering, I'm not an engineering manager. So I've, you know, been that manager of managers. I become less technical and there are times when I fear that we're making the wrong decision because I can't confidently speak on a particular topic. I say this as a, a problem because it shouldn't be a problem. This is, again, this is expected in where I'm at in my career and I have a fantastic team to lean on. And also if we don't choose the right path, then we go back to the drawing board and choose, you know, figure out, you know, plan A didn't work. Let's try plan B now. What would you say?

Literally the same exact thing. Except I'm not a director of engineering, I'm still a first line manager. I struggle with how to stay technical. It's really hard when I'm looking at things from like almost a project manager type of view, making sure that we're on track and we don't have any blockers. But like the day to day I'm still in all the standups and I try to go to as many like, meetings, technical meetings as I can, but at the end of the day I just struggle to like, get back into that technical confidence, I guess. Did I ever really have it though? That's my question. I never, I never remember a part of my career where I was like, yeah, I'm super technically confident. Except maybe like my first week out of college.

Wasn'T that a great time when you're like, you could do anything because you didn't know anything or you didn't know what you didn't know.

Ignorance is bliss. But this is an ongoing conversation I have with other engineering managers in our organization is how do you stay technical or how do you become technical if you were never technical to begin with? Which is also fine because it's not that simple. Like a lot of companies have proprietary tools and technologies they're using. So it's not a simple, like Google search on a technology, right? And then even if you do something that I struggle with, is piecing it all together. Over the past like three and a half years since we've talked, I've come to realize that I have adhd, which explains so much about how I learn and function. As a human being, it also means that I can absorb information and then immediately forget it or absorb information and not understand how it all fits together. So I am simultaneously on this mental health journey to figure this out while also trying to stay technical and find ways to do that without losing it, like losing the information I'm consuming. So yeah, same for me.

The real question then becomes, does it matter? Yeah, like how much information do you actually need to retain?

I've come up with like strategies for staying up to date on stuff. Like I have a document that the whole team has access to on like the status of every project, like our blockers, our dependencies, when we're going to start it, blah, blah, blah, which is really more for myself. But it is helpful to them. I think it's important because I want to be able to have discussions with my senior engineers who are the smartest people I've ever met in my life and not feel like I'm like bothering them by asking the same questions over and over or asking them to take time to explain something to me, although I know that that's a personal problem I have to get over because they would much rather have a manager who cares enough to ask than someone who like pretends to have all the answers and they don't. So it's really more of like a personal thing. But I am fortunate to work with people that do not have egos, that have been working on the product for 12 years. I mean, what, three or four of them had been at the company for 10 to 12 years? Like this is nuts.

A long time. So yeah, Ashley and what was once a startup. Yeah.

So is it a problem? For me personally it is because I want to feel like I'm doing them justice, but they never make me feel like it's a problem.

So that's good. That's good.

Yeah.

So what other, what other skills do you believe are important for an engineering manager?

Well, we've touched on the technical competence side of things. So just to recap, like having an understanding of trade offs and different solutions being built and the integrations that your team has with different parts of the company and things like that. Like that. The second piece I would say is more into leadership and people management. So a big part of that is conflict resolution. That was something I was worried about getting into. This is I'm a people pleaser. Am I going to be able to have these tough conversations with people and be so honest with them when it's uncomfortable for everybody involved? Right. So conflict resolution is a big One. And I have thoughts on that. I think with. I don't know if we have an episode coming up on that this season, but we should, because it's important.

I'm also a trained therapist, so I have thoughts on this topic.

Oh, this is like an hour of free therapy for me. This is great.

Exactly. It's perfect.

Also, I think understanding the difference between empathy and compassion was a big skill I needed to acquire, because previously, in the beginning of this role, I would take on other people's emotions as my own, and it would really drag me down into not so great mental space. And then I come to find the difference between, like, empathy and compassion. Being compassionate is. You can sit with them, but you don't necessarily take on all the things that they're going through. You can. You can say, hey, like, this is a hard situation for you, like, I'm here for you. But also stay removed a little bit. Yeah, yeah.

You can't get deeply involved. And it's also the difference between being friends with your team and being friendly with your team. And that sounds cold, but it's really not, because you're responsible for the success of your team, but you're responsible for executing towards the business goals. And if there's a disconnect there, if one of your team members is not doing well, they're not performing at the. At a. You know, at a level they should be. For whatever reason, you need to be able to have a conversation with them. Even if some. This is somebody you really like, and there are times when you're going to have to part ways with somebody you really like.

Yeah.

And it's never fun. Like, firing people is never fun, but it never honestly gets that much easier. Every time I do it, it's. It's another one of one of those. Just like, I'm not prepared for this. Oh, I know I'm prepared for it. Yeah, it's. It's tough. It's very tough.

Yeah. Something I've had to come to terms with is, like, two things can be true at once. Like, you can like someone and have all the compassion in the world for their situation, but you also have to make the hard call that they are not performing to the level that they need to be. I will say, though, and, yeah, maybe this is, like, a fine time to just mention this. Like, I was friends, like, good friends with, like, some of the people that I now manage, and I remember thinking, like, is this gonna be weird or hard? And I remember messaging, like, one of my friends, and I was like, hey, how do you feel about this? Like, how do you feel about me managing you? My whole take on this has been you need to have boundaries. This is something that I've had to like. I had a lot of conversations with my own manager about how to maintain boundaries with folks that I'm friends with and still have a professional relationship. Right. So like no gossiping about anything going on at work. You have to maintain like very, very like proper boundaries. I would say though that I am good friends with many of the people that I manage, but also on the sister team that we have. And yeah, it can be tricky, but I will say it's never once held me back from being honest with someone about their performance or if they're not meeting expectations or if I need something different from or whatever it is. It's just a very slippery slope. So it's definitely not for everyone. I think in the US it's more common maybe not to be so close with your manager because like I mentioned, there's this hierarchical nature in the culture. Whereas in many European countries the managers seem more at like the same level as the engineers. Right. So there's not as big of a power difference. I don't want to say power dynamic. Yes. So it is tricky. You will not be perfect at it, but it's just something to just be mindful of as you progress.

But that is exactly what I would call out. That's very, very important for engineering managers to embrace. And this is a good quality of a leader, not even a manager. But it really shows up when there's some level of authority or power dynamic in there. And that is you need to be very open and receptive to feedback. You need to accept when you need to tell somebody something that they're not going to. You also need to accept that you know when somebody is going to say something you don't like and you just need to deal with it. You're not going to make people happy all the time. I make a lot of people very unhappy for obvious reasons because, you know, I'm deprioritizing the work that they wanted me to do for them or I'm pulling them off a project they wanted, you know, they were really excited to work on. This is life. Like this is business. And I don't mean for it to like sound cold, but you know, you have a responsibility to the company as much as your team, which is very.

Hard because as a first line manager you're like right there with the people and in many cases you're the last one to find out about reorgs or layoffs or whatever comes through the pipeline. So it's actually very tricky to be a first line manager, but it's something that you navigate as you go. I will say too, actually, I don't know what I was gonna say. I think where like, if I think about the values that I have as a manager, they've always been. I don't see myself as above you in any sense. I see myself as your equal, but doing a different job than you. And it just comes with different responsibilities which inherently, yes, they do come with maybe higher stakes responsibilities because everything you do has an impact on someone. But I tell them like, I don't see myself as any better than you. I'm just here like to help with your career, to help like with the delivery of this team. So yeah, I would say that's kind of been my biggest value as a manager. Value, like a value that I hold close to me.

Yeah, no, that makes complete sense. I think it's important because we often put, especially in certain cultures, this is, this is 100% true. Where we will put managers or anybody in a role above us up on a pedestal with that. They're, they're, they're better than us and they're more important than us because they hold that.

Yeah.

Higher, you know, higher scope, higher stakes role. It's a different role, you know, and some people, they're going to bring more experience, different experience to the table when you're having a conversation and you know, I think we need to do it an episode entirely on how to manage up as an individual contributor. Because this is something that I think a lot of people struggle with, myself included. And I've been doing it for a long time but, but it's, it becomes like, how do you communicate with people who are above, you know, above you and rank below you and rank not, you know, there's a dotted line to how you work with them and there's no connection whatsoever.

Right.

And as like showing up as a manager and this is kind of looping back around to the idea of having influence. The ability to have conversations with anybody across the organization is where you're going to really succeed as a manager. If your team is getting more, getting their work done, you're going to be able to have more influence on the roadmap. You're going to be able to have more influence on the company direction, the company's culture as a whole. If your team is performing well.

Absolutely. And just one last thing I thought of under this Umbrella is bias. Checking your bias, being aware of it, ensuring. And this goes kind of hand in hand with, you know, having, I would say I have like, friendships to different degrees with like everybody on my team. Right. Because you get to know about them, their lives, their mental health issues will come up at some point if they have them. Which, like, honestly, like, don't we all, at some point. I mean, we all go through things in our lives. Right. You're going to be there for like the highs and the lows of their lives. Bias is so important to be mindful of specifically as it relates to aspects of this job, like compensation review, performance review, things like that. Making sure that you're not giving opportunities to the people that are. You're around the most, the people that you are most similar to, the people you have close friendships with, things like that. It's very important.

Absolutely. And, and you're going to encounter so many challenges like these, you know, throughout your career that are going to show up differently. You know, we've talked about the, the management, like the managing your team dynamics, for example, dealing with conflict on your team, the performance piece of it can be really, really challenging. And learning how to do that, you know, balancing being technical enough but not having to be too technical, you know, all of these things become really, really important. And I think the last thing that I don't think we really touched on as far as like a responsibility for being an engineering manager, but is absolutely critical is the work prioritization, the work delivery side of things, like being a project manager. We don't have project managers on, like at our company, the engineering manager is the project manager.

Yeah, yeah, agree. Like we have a product manager that we partner with and a designer, but I am solely responsible for taking all of the incoming requests from the company during planning season, which it could be upwards of 50 for a team of seven. Sifting through what are dependencies, can we even do this, et cetera, identifying the capacity of how many engineering days we have available based on vacation, sick days, hack days, holidays, like you name it. Whether someone is an embed or not means how well, like how much they'll contribute in a given period. Like, you take all of this in, you come up with a formula. I've become very good at spreadsheets, I will tell you that. And oh yes, mapping based on priority and then sequencing that work to align with your dependencies. It's a ton of work. And finally, almost three years in, I've, I've figured it out on how to do it, but it's not easy.

It's not. And then you have to be able to balance the fact that product is going to bring feature work to you and engineering. We see all this kind of like tech debt that we need to address and it is a constant battle of like, which one are we going to be prioritizing given that we only have so much time available in the day. And you know, I use, I use the, you know, the term resources for my team and I know some people don't like that, but it's just, you know, there it's, that is, it's a resource. You know, resources are finite in general, you know, and, and we need to think about like what, what can we feasibly do? We don't want to overload our roadmap and then not deliver on most of it. And we want to make sure there's a balance between making sure we're, you know, we're balancing feature work that's going to say drive revenue, for example, with customer needs. If you have any kind of customer commits that come in that you absolutely have to deliver against versus any kind of technical debt, like you have certain things that are hitting end of life that you have to work on versus the. This is really painful like from a developer experience perspective. And we at some point need to refactor this or else, you know, every time some, another engineer touches this, they're going to get really frustrated. That's the reality of it. And it is a hard thing to balance that.

Yeah.

And then you try to say, here's our quarterly roadmap. Here are all the things you're going to work on and then a month, then you're like, oh, look at this thing that came up. Oh, here's another issue that came up. Now we have this escalation and then you look at your roadmap and you're like, like we're not going to deliver on most of it.

Yeah.

And that's why I, I'm much more confident in delivering a six week roadmap than delivering a quarterly roadmap. We have an idea of what we want to work on for the next quarter as well as the, you know, next six or so months. But we're looking at six weeks at a time.

Yeah, it's tricky. I think that could warrant an entire episode and probably should.

It probably should. So I think, you know, as we're, as we're thinking through, we've got a, we've got a great season ahead of us. Like I'm super excited for the episodes that we've got lined up for this. This is going to be an ongoing conversation that we're going to have throughout this season and honestly into next season. And so I encourage our lovely listeners. If there's a specific topic that you do want us to talk about, let us know because, you know, we want this to be valuable for you. If you're an individual contributor considering move into engineering management. If you're an early engineering manager and you want to become a better em, if you are a very technical em and you struggle with the. The I hate the word soft skills, like the communication.

The human side of it.

Exactly. Then you know, this, this. That's what this. The whole season is meant to be. Yeah. And so I'm really hoping that, you know, we can. We can help craft this season to what everybody wants to hear.

I hope so too. With the caveat that we're just two human beings doing the best that we can. So we're also on this learning journey together. We're just choosing to learn in public. So, yeah, I think that's all I had to say on that.

Perfect. Do you want to talk about our new segment that is our favorite resource for the week. This is actually not a new segment whatsoever. We did this for a very long time. Yes.

I have read many a management and leadership and can meet communication books. In my two years, I think I've read maybe like 15 of these books. One of my favorites that really stuck with me was the Making of a Manager by Julie. Oh, my goodness. Do you know how to pronounce her name properly? Is it Shu?

I'm not sure.

I'm going to look it up because I don't want to do her any injustice. Pronunciation.

Let's look it up.

Julie show. Julie's show is what I'm seeing.

Okay.

However, if you know the answer and I am mispronouncing it, please correct me because it's important to get people's names right. The making of a manager was really impactful to me. I thought it had a lot of really key takeaways that were easy to digest. It was written in a very accessible format for me. It is US focused, though, so it resonates with me to a certain extent as, you know, American. But I've been outside the US since 2018 and I've worked on many multicultural teams. So I think if you're not working in a U.S. company or with people from the U.S. it could be a little bit specific. But I think there's still some really great takeaways. There.

Yeah. I would just say, like a lot of management and leadership books are written from. Written by a US author.

Yeah.

So this, this goes kind of across the board that they're going to be cultural distinctions that are. It's impossible to cover every possibility. But there's something you can take out of any of these books.

Totally. How about you? What's yours?

So I talk about this book non stop with literally everybody, and it doesn't have actually anything to do specifically with management, but it's Crucial Conversations. And I'm going to apa format the author list and just say it's Joseph Greaney et al. Because they're like five of them. And Crucial Conversations is such a great book. If you struggle with or want to improve the way that you handle conflict, this is something that covers in, you know, in your professional life, in your personal life. It helps you kind of to take that step back and understand what is actually at stake here. This conversation is getting heated. How do I walk through having a very productive conversation at a time when I feel like everything is on fire? And I actually my. I gave this or I told my sister that she should read this book. And my sister is not in engineering, management or in engineering at all. And I. She was like maybe four chapters and she's like this. This book is life changing. And this is why I continuously recommend it to everybody.

It's one of my favorite books I've ever read. I love that book so much. It helped me in my relationship and helped me with banishment.

Exactly.

Yeah. I like any book that touches the intersection between psychology of human beings, but also tactical skills. You can use. I do recommend as well.

All right, so what do you say we close out episode number one?

Episode one of many.

Yes. So we are excited to be back. We know it's been a very long time since we have run a season of the Ladybug podcast. And Emma and I couldn't be more excited to be learning in public with all of you on the topic of engineering management. Engineering leadership. So you can find this podcast now on every podcasting platform that you can imagine. But also we do video too, so you can check us out on YouTube, you can check us out on, you know, all our little shorts and everything that we're doing on. On TikTok and YouTube shorts as well. And of course find us on social media too.

Absolutely. We'll see you next week.