I've been really focused on making sure my engineers are very product oriented. They're very product focused and what I mean by that is they know how to think about the product the customers back. Like think customer backwards and understand not. You're not just like shipping a feature like building a, you know, completing a task and moving on to the next one. Like how will customers interface with this? Welcome to the Ladybug podcast. I'm Kelly.

And I'm Emma.

And we're debugging bugging.

The tech industry.

AI is evolving at an incredible pace but knowing how to apply it effectively is the real challenge. How do you design agentic systems that actually deliver at nodes 2025 pioneers in AI engineering and machine learning will show you how they're using graph technology to give AI the context it needs. Powering agentic workflows, improving retrieval and enhancing knowledge Graphs at scale. This free online conference on November 6 features over 140 technical talks from developers, data scientists and engineers solving real world problems with graph powered AI. See the full agenda and [email protected] nodes.

Hello and welcome to another week of the Ladybug podcast. I am your co host Kelly. We don't have a to really this.

The intros and conclusions are so hard for me because of someone very socially awkward. I don't know how to start and end conversations. Um, but yeah, today we are talking about something that kind of relates to last week's episode because last week we talked about project management as an engineering manager and how to work with prod product management, didn't we? A little bit.

We, we talked about it a little bit. Yeah, because it was, it was mostly about project management and we started it out by saying that there was a difference between project managers and product managers. Um, it's always interesting when you're hiring for product and you get a lot of applications from people who are project managers. Two very, very different skills.

I didn't actually know there was a difference in my until like my second job out of college. But to be fair, like I don't remember having product managers. I'm sure we probably did. We had project managers for certain. But yeah, I feel like maybe they could have chosen different words that were not the same letters and acronyms.

I don't know.

In any case, what are we talking about today?

So we're going to break down some of the most common cross functional relationships you have to maintain as an engineering manager. How to work with them and common like pain points or pitfalls you might have with these particular individuals. Because it really differs from like working with design to working with product. Like you are an expert in your space, they're an expert in their space and you don't always think about problems the same exact way. And it can cause, you know, strife in your relationship, in your working relationship if you aren't able to come kind of come to a resolution well enough or without the help of other people.

I think we forget too, like all these other functions have their own agendas and I don't mean that in like a really shady way, but like everybody has their set, own set of goals for their role that they need to achieve and they don't always coincide with your own objectives and goals.

Exactly, exactly.

So a role that I interface with the most probably is my product manager. He and I are a very good team. Like at least in Spotify, like we're, we're meant to be like a, a pair of leads on a team and we talk every single day. He's probably like the person that I work the most closely with in general outside of my engineers. So yeah, I don't know. What is your relationship like with your product manager? How, how often do you meet and talk and. Yeah, all those things.

I mean, I think like I've, I've been through multiple product managers for various reasons. I've worked with multiple product managers for, you know, across orgs in and out of the company. And I mean I interface with my PM multiple times per week, sometimes multiple times per day. We end up on same calls a lot. I think product is one of the most diffic jobs you can do at a company.

I also, I would agree it's. I actually was hit my PM stand in when he went on vacation for like a few weeks and I immediately knew this was not a role I wanted to do ever again. It is so mentally taxing to have to remember all the moving pieces and requirements of different projects and who all the stakeholders are. And it's mostly about the politics that I, I wasn't so keen on the political side of things, having to like push back on people. And I think the PM shields even the ME as an EM as well as a team from a lot of political conversations. And I'm so grateful for him. It's a hard role and frankly, I don't know if you can even get a degree that directly coincides with the role that a product manager is going to be doing. Like it's something that you grow into from experience. Like they don't really do, like they're.

They'Re like boot camps that exist to be become a pm because there, I mean there are a lot of like from. I've, I've, I've played both roles before. I've been, you know, I've been a product manager. Not in the like writing PRDs kind of way, but I played the role of product manager while also being an engineering leader. And I've been a product leader where I'm setting the strategic vision and there are product who are executing on that vision. And it's, it's one of those things that's like, I love it. Like, I find it to be a really fun challenge because I do like customers and I like, I like, I like kind of sitting in between those like sales and engineering at times. I just happen to be also very technical as like having an engineering background. So I don't know. I think it's. I've worked with a lot of different product managers over time. I know what works well and what doesn't. I know what works well and what doesn't with me. And I am somebody who has a very strong personality. And so I need a product manager who also has a strong personality or I will steamroll them. I learned this over time. And it's, it's not like it's always intentional. I mean, never shouldn't be intentional. But like, I've had a product manager before who every time I push back on him for some reason they, they would just say, okay, yeah, that's fine. I'm like, do you, do you agree with me or are you just saying that you want to move on? I've also had product managers who have overstepped into engineering, like saying, okay, these engineers are going to work on this. Or this shouldn't take you a lot of time. Be like, hold up, you're not an engineer. This is not your space to be saying, to be telling the engineers what to be doing. That is my job. Let me do my job. So I've seen it both ways. I, I still like, I'm fascinated by like the product like path and the product roadmap and, and how much work is required to sit in between sales and marketing and engineering and really, as you said, like understand everything that's going on and all the stakeholders that are involved. It is a lot of work.

It is. And it is, in my opinion, a much harder job. As I like for me, it would be a much harder job than it is to be an engineering manager. I think the biggest. Not friction. Yeah, maybe friction I've had with My PM is having to balance like when I do engineering capacity during planning, which we talked about in the last episode, if you haven't listened, I create like this big spreadsheet that informs how many engineering days we have available to work on things. And I think from the product perspective it's like okay, how many product asks can we deliver on? Right. However, I need to be able to balance that with like hey, but we also have all these tech initiatives that have to get done or like shit's gonna hit the fan. So and, and for the most part I don't really have to convince him. It's kind of one of those things where if I explain why, which was my resource last week, start with why by Simon Sinek. If I explain why this needs to get done and it's not just like a miscellaneous piece of work that I would like to do, he doesn't typically ever push back on me. And I will say like if we get asked that, come in. He's very good at protecting the team's capacity and he'll always tag me in a conversation and let me speak on the engineering side of things. So I'm very fortunate to have you.

Have a good pm.

I do and I don't take him for granted, but I do recognize like it's not always going to be this harmonious. So sure, yeah.

I mean there are pain points and every anytime you have to sell or make time for technical debt, it becomes a game of how do I spin technical debt to be a business risk? And this is one of those things where I think is an important skill for senior engineers and engineering managers to learn is how does technical debt affect the business from like a revenue standpoint? And it can be a tough thing to like you just need to upgrade like you need time to upgrade a package. How could this possibly be tied to revenue? Right. But like even in that case, if you don't update this package, you're at risk of vulnerabilities which will in Fact impact your SOC2 status. If these vulnerabilities cannot be resolved, it leads to, to possible security issues. It leads to you have bugs that are, that are currently in. In like you know, your code base that you can't resolve without upgrading this to. We can increase our engineering velocity to get more work done in less time if we upgrade this package because it has really critical upgrades that'll make our lives infinitely easier.

Yeah. And this goes back to the note what your counterparts agenda is. If you understand what they're goals are, you can better tailor Your needs to align with their goals.

Yep.

Yeah. The second type of role. I don't know if you feel like we covered that one pretty good or.

Yeah, yeah. We talked about product last week as well, so. Yeah.

Yeah, for sure. Design is the second stakeholder that I work every single day with. So, like, our. We call it our, like, leadership team of our engineering team. It's product design epd. Oh, my God. That's so cute. It sounds like a band name.

We use EPD all the time.

That's actually adorable. Yeah. The three of us, like, we're constantly in communication. I adore my designer. Absolutely. Fantastic. I think the biggest pain point that we've had is that we get asked to do so much work because obviously, like, we have a lot of work to do. Like, our product is. Is very well loved and used and of course there's always going to be stuff you want to work on. But with our designer at least, like, it's really tough for him to be one of the only designers for our team because there's a lot of pressure on him to come in and provide us what we need before we can get started building. And so maybe the. The biggest friction that we have is, like, how do I balance engineering priorities and, like, getting started on a project if we have to wait for design? And I, of course, don't want to stress our designer out either. Right. Because I care about him as a human being. So I think that's our biggest friction. But I think we've been able to kind of combat that a bit just by talking about things early and often.

Yeah. So I have a unique one that you don't encounter because you have a design system, and that is elements change. There are a lot of changes that our designers want to make from, like, a UI and a UX perspective. As far as, like, let's say we have this date time picker and we want to change this as we're building, or the designers want to change this as we're building this new. We're updating our, like, clip trimming ability. For example, if they design a new date time picker, we then need to build and replace the date time picker across the entire dashboard anywhere you have one. Otherwise you're going to have a different experience on one page versus an error that adds to the scope. And that could be something that is. I understand how frustrating it can be as a designer to be like, I don't want to keep on using and building on top of this. That we need to make time to do this. And then, you know, when you're going into roadmap planning, this then needs to be taken into consideration. Like, it's not just the product and engineering. You know, wish list design has a wish list too. And they want to make sure they have a seat at the table and that they have their, you know, they're being heard as well. And like, at startups, this is, this is very common. If you do not have a design system, which a lot of startups don't have, because you don't have time to actually spend building a design system out. So I think that's one of the most challenging things. And then of course you're going to have just some, like, is this design technically feasible? And sometimes it's not. Or sometimes, like, is technically feasible. Yes. But is it worth, is the ROA worth the amount of time that the engineer is going to have to spend to make something happen versus a more simplified design?

Yeah, yeah, those are all totally valid. I think I hit more of those issues in my previous company because it was a smaller company. So while we do have a design system here, I will say, like, our use cases vary. Like, we're trying out, like, new formats and new feature sets and the design system is not providing us with everything that we need. So many times we have to go and customize a lot of these things. So. But I can't remember a time when, like, our designers ever came in and said they wanted to change an entire, like, component across the entire client. Like, that definitely would be a time suck. I will, I will say though, like, our designer is very ingrained into the planning process. So in our big planning sheet, when we get like, these incoming asks, we always ask him, hey, does this require design support? If so, how long do you think it's going to take? And then often we encounter situations where, like, there's work that we need to do that he just doesn't have time for. So what we will do is our. Our engineers will build something and then just do a review with him and say, what do you want changed? And that seems to work quite well. But yeah, design is, it's tough, but it's. I will say, like, I don't think we. That's not true. We do design kickoffs where they'll walk us through like a figma file with different solutions. And something that I noticed our designer did really well is like, he would walk us through his thought process on things like, hey, here are all the iterations I explored. This is like the path I took to get to the solution I'm presenting as what we should build. And I just remember being like, wow. I've never had a designer, like, show their thought process, show how they got to the solution. And that helped my engineers so much. Like, I haven't encountered a situation where we severely pushed back on a solution that was proposed by a design ever. Because he's so good at explaining, like, how he got to where he is. But that's not like the commons.

No, yeah, exactly. Yeah.

And.

And, you know, that is something that you're not going to see in most organizations. And one way that I've, you know, designers have a lot of work to do. And engineers, engineers in particular, like, we're very logical in the way that we build. And we, you know, while we are terrible at setting time estimates and there is a level of creativity to the work that we do, of course, is a. It is a. It's different from the level of creativity that designers need to come up with something. It is different. And it's hard for us to empathize somehow sometimes with designers of, like, just how difficult it is to actually come up with, like, you know, some new design that, like, they. And especially if you have to. If you need a designer to design something technical, because then they also have to understand it in the. A lot of designers are not technical by nature. Like, they're. They're two different sides of your brain. And so that can be. That can be really challenging at times. And so I think having empathy for design is important. And then the other thing that I've done with my team is I've been really focused on making sure my engineers are very product oriented. They're very product focused. And what I mean by that is they know how to think about the product. The customers back, like, think customer backwards and understand you're not just like, shipping a feature, like building a, you know, completing a task and moving on to the next one. Like, how will customers interface with this? What are going to be the ripple effects of the work that you're doing here on other engineering teams who are going to also interact with, you know, the code that you're writing or customers? How might customers use this? We, we can. We can, you know, spend all day trying to think about how our customer is going to actually interact with something, and they'll always find a way to break it or use it in a way that you never intended it to be used. Like, that is the nature. That's human nature. And so if you can train your engineers to kind of think about, think about it in this way. When designers are particularly bogged down and you're, you're blocked because you don't have designs, my engineers are able to come up with something scrapp, like a, like a low fidelity kind of design just to say, okay, this gives me something to work with so I can continue to work until we get the high fidelity designs.

Yeah, yeah, yeah, that's, that's great. Same with like API design. Can you give me like a mockup that can fill off of until we're ready?

Give me a sample payload. Yeah, like, I don't need you to build the APIs yet.

Yeah. And I was thinking about like, because we just talked about product and now design and those are like my two core like stakeholders that I interface with. And I'm thinking like, wow, I said our team has such a good relationship with both of them. And I think frankly it comes down to the fact that both product and designer, in every standup, every retro, all the team building activities, we're like, we're all three there like every day. So I think building those personal connections and like seeing your designer and your product manager as being accessible and ingrained in what you're doing every day makes a huge difference. So that when you hit these frictions, like, it's not a big deal and you're much more easily able to resolve them.

Exactly, exactly. Yeah. Other stakeholders that I interact with a lot. So our, we have three engineering teams, like three pro, three business units at Spot, and each business unit has an engineering team. And so there are two other engineering directors that I work closely with, each that have their own product director as well. And so I have to interact with them, like I have to interface with them all the time because they're, you know, we're building on a monolith. And so you can never really fully separate your work, like your work stream out and there are going to be, you know, ripple effects of any kind of work that you do. And so I often have to look at like, what's on your roadmap. You, you know, this project we, and we just reorg into these three business units. And so we're feeling the pain of it a little bit. Where some projects were previously owned by one team that are, say now owned by me, and I need to finish up projects I didn't start. And so that can be challenging from like a planning perspective. Like there are things that were done at the outset that I wouldn't have done my way or I wouldn't have done it if this was my way to do it. And as a result I'm just kind of like, okay, we're going to have to figure this out and there's going to have to be some negotiation around. Like I need more of your one of your engineers time. Like as you do the embedding. We need to do something similar less officially, I suppose.

Yeah, yeah. I'm trying to think like other stakeholders that I have to interface with are usually just like managers of other teams. I feel like I don't interface with too many additional stakeholders above like my leadership chain. Like we have product area leads that are like responsible for our product area and the success of the initiatives ongoing there. But outside of our product area, I don't typically interface with stakeholders too much outside of planning. Like if I do, it's for a piece of company led work or an initiative at a company level that they're always going to be like a tech POC or point of contact. There's always a project manager for the whole initiative and sometimes they will reach out to ask about the status of a project. Maybe I'll reach out to an engineering manager for a team we have a dependency on just to see how it's going. But apart from that, I think those are really my only other stakeholders that I interface with.

Mine's very different. Yeah, I mean outside of the, you know, the technical stakeholders from product and engineering, again smaller company, I interface with support customer success. Our sales leadership occasionally interface with marketing, product marketing. Go like the go to market team in general you have like I have to stay in lockstep with them because now like I overseer video management system and that means that I have to make sure like the support tickets, the escalation tickets that are coming in from our support team are getting addressed and how are we prioritizing those like fixing some of these things against the other roadmap items that we have customer success. They have an expansion deal that's blocked because of this particular issue or because they want this particular feature. And we need to either agree to build that in a certain time frame or fix an issue or say we're not going to do this. And so I constantly having to meet with them regularly. And this is again, this is a side effect of having a very like a much smaller organization. It is flatter in that regard. And so you have to, you have to interface with a lot more people. Yeah, I know basically everybody at the company. Like I kind of have to. That's very different. Again, I only have to know like 100 people versus however many employees Spotify has now.

Yeah, but let's talk about. So we've talked about the types of stakeholders you might interface with, but how do you actually build strong relationships with these folks?

Communication number one. Yeah, this, this kind of goes across the board no matter who you're, who you're interfacing with. Like, you have to have a level of trust built with them where you can openly communicate. This is being able to negotiate those trade offs. This is making sure they're informed of, you know, changes that are happening on the roadmap or people that are going to be out or, you know, you need to move new, move some engineers around to different projects, different teams, what have you. Like, communication number one has to be there or everything is going to fall apart. Because the last thing you want, I think, you know, just to give an example, you might think people have the context you have when they don't, and vice versa. I remember I had a situation with one of our product managers where we were literally like, we could not agree with each other on anything. And we never butt heads. And it got to the point where, where we just, like, we both took the gloves off. We're like, what is going on here? Like, we never, we never actually deal with this. And it turns out she had 50% of the context and I had the other 50% of the context. And so like, in just talking to each other, we're like, okay, we actually are working towards the same business goal. We were just completely, you know, out of sync in terms of how you want to get to this business goal. It gets avoided if you just like, keep each other up to date.

I think this goes back to, I think it was episode one where you recommended Crucial Conversations as your resource. And I think a key takeaway from that book for me was like, hey, we're both on the same page. Like, in the sense of, like, we have the same ultimate goal, which is to shift this thing. Apart from that, we have other, like, goals. Like, I need to make sure my engineers are mentally okay and not overworked and we balance it with our other priorities and, you know, you need to make sure this project gets delivered. But our ultimate goal is the same. Same. And I think if we can set the stage with that, like, hey, we're on the same team, let's figure out a way to get there and like, problem solve together, I think that can solve a lot of issues preemptively.

Yeah. And speaking of preemptive, I'm actually going to pull my resource of the week now, because this is a, this is something I learned from this book. It's called Inspired by Marty Kagan. He has a series, I think of like four books on like those Inspired, Empowered. There are a couple of this. This one is particularly about building tech products and is such a fantastic read. One of the things that it talks about early on is, you know, we often think about the way that we're structuring a project where product will, you know, get an idea and validate an idea, talking with customers, data science team, getting analytics, whatever, building, like forming a hypothesis and saying, okay, this is what we want to build. They then bring the engineering leader and say, this is what we want to build. Let's have a conversation around it. I'm going to write a PRD so you know what to expect. And then let's, let's meet. And then you're going to build the, the ERD to say, like, hey, this is how we're going to build this. And now we're going to pull in design and say, okay, here's what we want to build. Can you design this? And basically what you've done is you've spent a lot of time kind of going, step one, step two, step three, step four, when a lot of this could have been done concurrently by just getting product engineering and design all in the room at the same time at the very beginning. And I'm not just saying leadership. Like, if, you know, you have an individual contributor who's going to be leading a particular project, bring them in as well because they're going to bring a different perspective. They're the ones who are deep in the code and have a much deeper understanding of what's coming, happening under the hood. And by doing so, you're able to start the collaboration that like the very, like on day one, your, you know, product might, might come in with an idea that they validated to a degree or they're, they're, you know, part of the validation process is making sure engineering and design are getting their questions answered as well. And so I love that early collaboration because it's going to cut down on rework. And rework takes so much time and energy and resources. And it's one of those things that really ruin the morale of your team if they spend a lot of time working on something. Let's say you got a sample payload, but nothing was really defined at the time. And then by the time you actually get what you actually have, things have fundamentally changed so much that you literally have to just like scrap what you did go back to the drawing board and rebuild it. And you've added so much time to your execution roadmap and you've also just made the day of your engineer really bad. Like having to do that as well. Do you encounter that?

No, not so much. Like maybe there's one instance of a feature that we built and spent a lot of time on that based on like user feedback we've decided is not the right approach. And now we're facing like how do we not roll it back but like make adjustments to it. So it is kind of like redoing a lot of the work, but it's not coming from our immediate like product lead or designer. So.

But that's normal. Like that is, that is why you. And that's the whole point of an MVP as well is you get that, that early feedback so you can iterate on it.

Yeah.

That whatever you ship is not going to necessarily be final.

Yeah. But now think of a time where really like had any massive miscommunications. But then again, we've established really great collaboration communication processes early and often. So maybe that's part of why.

Yeah.

But another like tool for working with design in particular is to meet them where they are. And often they are in tools like Figma and Storybook. Things of that nature get on their platforms. Right. Same with product. Like get into Jira or Asana or wherever they're doing their work. It'll just make collaboration a lot easier if, if you know where to go.

Yep. And, and also I, I touched on this earlier but like don't make expectations that they understand from a technical perspective what's involved. And one of the best things you can do is learn how to break down technical concepts into a non technical or like for a non technical audience. And this isn't to say that your PM or your designer are not technical, but you tend to forget. And this is just general advice. Not even, not even for specifically engineering management or those relationships. But when you've been doing something for so long, you don't remember what it's like to not know how to do that thing. It's just, it's second nature to you. You know, if you were to get into a car to go drive somewhere, like there was once a time when you were nervous about getting behind the wheel of a car because you didn't know really what you were doing. It's, it's. Or like learning how to ride a bike. You know, it's one of those things that it becomes second nature to you and you forget that it's second nature to you, but it's not to other people.

Yeah.

And so, like, being able to break things down into a technical perspective without being like, demeaning is, is a really important skill to build because I've seen it happen before where, like, I've had an engineer not realize just how technical I am, and they try to, like, overly complicate the way they're explaining why something's going to take so long. And I'm like, dude, I know exactly what you're trying to do. Like, you're trying to get out of doing something. And I'm like, this is. You're over complicating this. Like, I know, I know what needs to be done. And so you want to make sure that you handle that, that conversation, that communication carefully as well.

I encourage my engineers to be the ones to have those discussions with product and design so that they build that relationship. They get practice, like curating those skills of explaining these concepts. And, and frankly, I don't have to have a lot of those discussions from like a technical, maybe with our product area leads if I have to explain why something is delayed or what the blocker is. But in general, I'd say I. My engineers are the ones having those conversations with product and design and other stakeholders, which I think is really good because it's, it's forcing them to become good communicators. But it's maybe not so good for me because maybe I'm missing in context as well.

That's true, Soldiers. You're included at some degree. Yeah, the other, the other part of communication. And this is, again, this is one of those things where if you get super focused on your particular area, you, you miss the business case or you forget the business case. And the better you can relate whatever you're doing back to whatever the goals of the business are, the easier the communication becomes. Because again, like, you're working in your, with the context that you have. They're working with the context that they have. But what you have in common is the same business goal. You know, you're working towards a very specific goal and you might be going up about it differently to get there based on your expertise and your, you know, his, like, your history. But if you can relate whatever you're doing back to the business goal, when you do have disagreements that come up, you can understand like, okay, we're both working towards this. What makes the most sense? Where are we getting blocked? And how can we kind of, you know, find our path back towards that Business goal.

Yeah.

And then for other stakeholders, specifically for leadership. One of the things that I highly, highly recommend, and I don't think we're doing a, a topic on managing up this season, but one of the things that I definitely recommend doing is learning how to communicate status updates to senior management. And the most important thing here is don't lead with the details, lead with the big point. Because I don't, I don't need you to set a stage for me. Like, I don't need you to say like, okay, well this, I was thinking about this and then this is the other thing that I was working on. And then ultimately I'm like, what is the point of this conversation? Like, what is your ask? What is your update? And then if I want more details, I will ask for more details. And it's not that I don't want to know the details of whatever's happening, but sometimes I don't have time to just, I don't have the mental capacity to think about those. And I just need that bigger point. The higher up you go in an organization, the higher like the 30,000 foot view, the 60,000 foot view becomes. And you don't have time to really grasp every intricate detail of everything. You shouldn't, they shouldn't be asking for every intricate detail. Some of them, some leaders have a harder time stepping back out of the day to day than others. It's just a nature of, you know, new leadership, for example. But like, there's a level of trust that has to be there, of course. And so the best thing you can do in managing up and managing those expectations and communicating changes is just like, get to the point. And then if they want details, give them the details.

I'm giggling because I made this exact mistake when I started where of like my director of engineering who's like my fifth line manager, came and asked a question about the status of something and it was very technically like complex. And I like wrote a big paragraph explaining like what the status was and why it was taking so long or what the implications were. And my em was like, she doesn't need all that context. Like give her, give her like the tlvr and if she has questions she'll ask, but like it's too much for her. And I'm like, oh, well, nobody told me that.

Yep. You don't learn it.

No, it's. But it's something that like we should be taught.

It should be. It should be. Yeah. And again, it's one of those things like you make the mistake once and you typically, like, if somebody corrects you, you're like, oh, okay, got it. But it is a different way of communicating and we, we also are proud of the work that we do. And also if we're like feeling like we're falling behind on something, we want to defend ourselves. Yeah. Especially to somebody more senior than us.

Well, I think the intentions are good, but yeah, the impact is that they have way too much context and not enough time to or exactly care for it.

Yeah, exactly. Anything else to talk about with other stakeholders?

No, I don't think so. I think it's, it's clear that like between companies and the higher up you go, like, you're going to have different spheres of influence with people. So just, yeah, communicate early, collaborate often get on the same page about like, who's responsible for what, perhaps so you don't have like those domain, like people overstepping their boundaries in terms of who's doing what. Like you had mentioned previously with a product manager in the past. And I've also encountered issues not knowing whose job is what. But yeah, I think, I think that covers it.

Cool. Well, I already gave my resource of the week inspired by Marty Kagan. So what is yours?

Mine is a podcast that I have been listening to every day on my Hot Mom Walks. Hot Mom Walk. My Hot Mom Walks. That's definitely going to be my number one podcast on Spotify. Wrapped this year, it's the Mel Robbins podcast. And I had seen like a clip from her on Tick Tock where she was discussing her let them theory, which essentially is like, I think, I don't know, there's this celebrity talking about like, her husband and people are like, aren't you worried he's going to cheat on you? And she's like, let him. Like, if someone can take him from me, like, let them. Like, I can't control other people's actions. I'm not going to waste time worrying about it. It came from Mel Robbins and her daughter who co authored a book called the Let Them Theory, which came out the end of last year. Just talking about like, yeah, if someone's gonna do something, they're gonna do it right? Just let em do it. Like, you have no control. Why waste time stressing about it? But her podcast is great. She brings in experts from health and finance and wellbeing. And I just adore every one of her episodes.

I love that if I ever start commuting again, it's not 13 steps upstairs. I will start listening to that on commute.

As you should. It is great. But let us know what other podcasts, if you're listening to this, let us know what other podcasts that you recommend. Because I'm always looking for new shows to listen to that better me as a human being, a manager, you know, just a mother. So leave your recommendations as well because I have trouble finding good podcasts.

Yeah, I have kind of fallen off the podcast wagon as well, especially when we stopped recording this one and stopped listening to podcasts. But hey, we are officially halfway through this season.

Yes, we are. But I think honestly the second half is going to be very intriguing and we're going to touch on a lot of hard hitting subjects.

Yeah, it's going to get, we're kind of moving out of the like, introduction, engineering, management, and stakeholder management to like going to be talking about hiring and firing. We're going to be talking about performance. We're going to be talking about just like the difficult parts of engineering management.

The spicy stuff you all want to know about. And by spicy, I mean like black pepper level spicy. Like we're not Adobo or Chipotle peppermint.

We're not getting. We're not getting too spicy. Yes. No. Awesome. So thanks again for tuning in. Catch us on your favorite podcasting platform. Catch us on YouTube if you want to see the videos as well. Tell your friends, subscribe. Like, leave us reviews. Good reviews, positive reviews. We like, we like. Nice comments.

I might cry if anything mean happens because I am 32 weeks pregnant. So let me live.

Let me live. All right, we'll see you next week. See you.