
Technically Leadership · 2025-07-24 · 32 min
Key moments - from our scoring
Substance score
25 / 100
Five dimensions, 20 points each
This episode tackles two practical leadership challenges through a mailbag format. The host explores the common dilemma of saying yes versus no to opportunities, particularly in startup environments where risk-taking is valued. He advises requesting time to think before committing, framing rejections around business risks and trade-offs rather than personal preference, and considering whether opportunities align with your desired career trajectory. The discussion emphasizes that saying no doesn't require a flat refusal - instead, leaders should ask curious questions that help their manager see potential risks, like project failure or team burnout. On mid-year evaluations, the host shares a documentation system including daily reflections, weekly status reports tracking project progress and help needed, and a CYA folder for important communications. This practice helps identify trends in strengths, weaknesses, and growth areas. The key insight is that evaluations aren't just for your manager; they go to HR, so frame concerns around skill development rather than personal conflicts with team members.
Request time to think it through, then frame your answer around business trade-offs and risks rather than personal capability. Show curiosity about why they want to move you, ask what would happen to your current work, and optionally suggest a better-fit person. This approach helps them see the risk is yours, not a reflection of your courage or competence.
Keep a daily document with a few sentences on what went well and what didn't, maintain weekly status reports for your manager covering project status and help needed, save important communications and kudos in a CYA folder, and track metrics or important dates. These create a record of trends that feed directly into evaluation strengths and weaknesses.
No - evaluations are reviewed by HR, so focus on the skill you're developing (like 'working on interpersonal relationships') rather than naming specific conflicts or people. This keeps the evaluation professional and prevents HR red flags.
Plan to spend about 50% of your time just getting up to speed before you can show impact, so honestly assess whether you have the 'spoons' (energy and capacity) to learn while maintaining your current work.
A brief snapshot of time spent on projects and discussions, a 'Help Needed' section for things to escalate upward, notes on initiatives tried, and metrics or important upcoming dates - this becomes a resource for both your evaluation and identifying trends.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode offers a handful of genuinely practical tactics - asking for time before answering, framing a 'no' as a trade-off conversation, and keeping daily/weekly notes for review prep - but these are surrounded by substantial throat-clearing, hedging, and self-contradiction. The density of actionable ideas per minute is low for a 32-minute runtime.
That's a way of also saying no without exactly saying no because you're more worried about, I need to balance my time. I can't overwork myself to the point of burnout.
I have a daily, ah, document that I keep that is kind of a, just a very short what went well? What didn't go well?
The core frameworks - saying no diplomatically, keeping a CYA folder, framing weaknesses in evaluations - are well-worn career advice tropes. The 'make it their idea' reframe and spoon theory reference add mild texture but nothing genuinely contrarian or first-principles.
how do you make this their idea?
Do you have enough spoons? For those of you who have heard of spoon theory?
This is a solo host episode with no guest whatsoever. The host draws on personal anecdote but provides little evidence of deep, at-scale practitioner experience in technical leadership; the advice stays surface-level throughout.
Today is another mailbag episode.
I can certainly talk more on saying yes, saying no. I can give you a lot of examples and history of my own where I've done these things and been successful and not so successful
The host explicitly avoids specifics to protect the question-asker, resulting in deliberately vague hypotheticals with no real companies, metrics, timelines, or dollar figures cited. The weekly report format is the only semi-concrete element.
forgive me if my example is a little all over the place, mostly because again, I didn't really want to accidentally reveal the person who asked me this question
Super vague. I'm sorry.
This is an unstructured solo monologue with no guest, no follow-up questions, and no productive tension. The host frequently loses the thread mid-sentence and relies on rhetorical questions directed at no one, producing a rambling rather than craft-driven delivery.
I thought this would be a really interesting one
And thinking that through usually is it can be a little hard. It can be a little difficult.
Computed from the transcript - who did the talking, and the words that came up most.
Laura Santamaria opens the listener mailbag to answer questions, including how to say yes or no to leadership opportunities without tanking your career or trashing your work-life balance. She also explores the mid-year review process and offers tips for successful self-evaluation and paths to self-growth. Episode Links: The Line Between Management and IC Leadership - ... Read more
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign. Thanks so much for listening to this episode of Technically Leadership. Feedback is a gift that I treasure, so please find me on LinkedIn, BlueSky, Mastodon, or the packet pusher Slack. Or you can send feedback through the form@packetpushers.net fu by the way, that stands for follow up. Links to all of those spots are in the description and show notes. Share this episode with your friends and colleagues and let me know if you have someone you think I should talk with about leadership. For now though, go lead. All right, and we're back for another episode of Technically Leadership. Today is another mailbag episode. Um, I wanted to address a question that I got recently about yes, no and work life balance. And I thought this would be a really interesting one, as well as also addressing the mid year review process. So I thought we could go through both of those today, um, just talking them through and seeing what you all thought about it. Uh, before I do get started, I do want to remind everybody that if you go to the Technically Leadership website, uh, which you'll find, ah, that's where all of our show notes are, things like that. So it's at packetpushers.net/technically, ah, leadership. I think there's a hyphen in there. Um, you'll be able to go in and not only get the show notes, but also there's a place where you can follow up and ask questions. And those questions do come to me. So whenever I get a chance to get some of those questions coming in or I happen to be talking to somebody and they bring up a question, I do try to bring those back here to the podcast. So I would love to hear more of your questions and we could do more of these mailbags as time goes on. But let's talk about saying yes, saying no, and handling work life balance. One of the really common things that I hear from a lot of people exploring leadership in a technical situation, whether that's you are wanting to go down that staff engineer track and just trying to figure out how to get there. Or maybe you're a manager looking to maybe move more to a director or something like that, or you're a new manager. Um, is the question about how do we decide whether to say yes or no? And also if you say no, how do you do that without tanking your career or, you know, missing out on opportunity? And if you say yes, how do you say yes to things without burning yourself out from doing all of these different things? One of the things that often happens when there's a lot of opportunity out There, like someone approaches you with an idea, it's is that we get that fear of missing out that FOMO around. If I'm not doing this, who else is going to do this? Who else is going to say yes? And early in my career, uh, ages ago, uh, before I even was in tech, one of the things that I did is I told myself, I'm going to say yes to everything that comes my way this year, every opportunity. And I thought that this was an interesting way to kind of propel my me out of my comfort zone. And it did. It propelled me out of my comfort zone quite a bit. I ended up saying yes to a lot of different things, and it stretched me. But I also realized that at some point there needed to be a defensive no. I needed to say no to something. Otherwise I was going to fill my plate with too many things and not be able to do anything. Well, when you say yes to something that maybe is outside of your comfort zone, you need to evaluate one. Do you have enough energy? I usually talk about, do you have enough spoons? For those of you who have heard of spoon theory? Uh, you probably will hear about that a lot on this podcast because I talk about it a lot. Um, do I have the energy to be able to do this new thing well, knowing that I have a lot to learn? And so going out of your comfort zone like that really requires thinking through. Do I actually have the ability to try something new? Do I have that time? Um, do I have the, uh, wherewithal to, um, know that I'm probably going to be spending about 50% of my time just getting up to speed before I can even start to show some kind of impact. And I think that's a really important thing to keep in mind as you start thinking about, do I want to say yes to an opportunity? On the flip side, though, is learning to say no. And learning to say no is probably one of the hardest things you can do in any industry, much less tech. Just because a lot of times there's this concern that if I say no to my boss offering me this opportunity, am I going to be blocked out of getting a chance to do another opportunity like this in the future? What will, uh, if I say no now, are they ever going to give me a chance again? And unfortunately, there are people out there who, they make this assumption that if you said no, especially in startup land, by the way, this is really common in startup land, if you say no to an opportunity, people think that you don't have the guts to try it. You don't have the risk understanding to do this thing. And like, you're unable to take risk, you're unable to do this. That the other whatever. And Startup Land is a lot about risk. It's a lot about understanding that risk and taking a risk and deciding to do something that might be out of your comfort zone. And so unless you frame your no. Well, there will be people who assume that and there's always a reply that I guess I have that, you know, did you really want to work for that person anyway? If they can't understand a no. Maybe. Maybe they're not really a great person to listen to. Maybe they don't really understand risk. But again, it has to do with more about how do you explain risk and how do you explain the changes here? So let's take an example. And as, uh, I think through this example out loud, I, I'm trying very desperately not to reveal the background that someone gave me who asked me this question. So forgive me if my example is a little all over the place, mostly because again, I didn't really want to accidentally reveal the person who asked me the question. So learning to say no. Let's say that you've been running a team, whether you are the team lead, maybe, or the staff engineer doing the architecture on a feature of your product, and you've been doing it for maybe, let's say a couple years, you're just about at the point of this feature getting released, and your boss comes to you and says, hi, there's this new feature that we want to launch in, uh, just a couple release cycles here or, you know, within the next six months. We want to try to get it out before a series raise, let's say. And again, this is startup land. Um, we thought that this would be a great thing for you to go do. So, uh, would you take on taking the charge of this new feature? Well, clearly you've already taken charge of a feature before. This is not a question they're probably asking because they're thinking of it as, I need somebody who gets something done. I need somebody who does the thing, who provides the end result. We want. Clearly we're getting there. This is the perfect opportunity for us to kind of go drive to this new feature. But this new feature maybe is not something that's related to what you do. Let's say that it's a, uh, it's a mobile app and you're doing more of the operational side of trying to get some of the like SLA figured out. Again, super vague. I'm sorry. And, uh, probably not the best example, but you get the idea. It's outside of your typical job. Now, there's a couple things that you can look at here. First things first. It always might be possible that they are just kind of tossing the idea out because it came to them, like last night as they were trying to think through some things, and it wasn't a, you know, a serious question. Maybe they think that they're just having a conversation with you. So really evaluate that conversation and make sure that this is a serious request before you start really angsting over it. But the more the question I would say is you have to have an answer to start, right? And whether your answer is going to be yes or no. I usually try to make sure I give myself time to think, and it always starts with, hey, thanks for thinking about me for this opportunity, or, thanks for thinking of me. Thanks for acknowledging that, um, I must have done something right, that you're thinking of me for this opportunity. This is really great, because that underscores that you understand that this is an opportunity. And then the next thing I usually say is, let me think about this and get back to you, because I want to make sure that I'm doing the right thing for the company, or I want to make sure I'm doing the right thing for the company, considering that I have this other feature that is just about to launch. Uh, something where you define that. Hey, I appreciate this. I need a little bit of time. Is this urgent? Is this something that you need an answer for today? I've never really experienced somebody asking me, hey, can you take over this thing without being able to say, yeah, give me overnight. Let me think about it. Because this, again, gives you a bit of distance. It takes out that urgent, like, FOMO reaction that you might have. It takes out that possibility of feeling like you have to give them an answer right now. Even if maybe you're not so comfortable with the idea, it gives you a chance to think. And usually they're going to say, yeah, sure, absolutely, that makes sense. Or they might want to talk it out with you. Now, if they want to talk it out with you, they're probably really desperately trying to get you to convince you to do this. And it might be more of a question about, how do I. How do I ask the right questions? How do I do the right thing? And so you need to come at it from a point of curiosity, and it might be that you have to show them what the risks are, and you have to be thinking about that probably on your feet in this case, or if you get a chance to think about it ahead of time, maybe you need to think about, hey, um, you know, this feature is just about to launch and maybe we're not quite done with, with the things. And I've already told you that again, this is a. I've had long conversations with my boss and they are aware of everything going on. You can't kind of spring anything on them at the last minute for this kind of thing. But if, let's say the feature is going out and it's a great mvp, but there's three or four extra things that would make this really a, ah, wonderful feature to have. And, um, that's going to take another, let's say five or six sprints to get done, or maybe 10 sprints. That takes time. And you might say, like, I really need to think about whether me helping the team get this other work done and get these features out the door. That might be more important right now for the company because we really need this to land before our next series round. We need this to land and make a splash, let's say. Um, that might be one way of taking a look at it. Another might be evaluating whether there might be a better person to take this, let's say it is out of your wheelhouse and you know that there's a, another engineer that might be a better fit. You might say, you know, I'm really flattered that you thought of me. I'm really flattered that you think that I'd be really good fit for this. I also want to acknowledge that there's somebody else in the company who would know this space better than I do. And I'd love to see them succeed. I'd love to see this feature succeed and it might be better to have them driving this right now. Something along that line where you're just, you're making clear you're thinking about that long term, how does it fit, how does it do? And if the problem is that the person's not delivering well, that's obviously not up to you. It's not something that you're doing unless you're their direct manager. That's a different question. But you're not their direct manager in this case. So it's, it's helping them understand that there's a trade off. And if, if you think back a bunch of episodes ago, I was talking with Boyd about a lot of different things, but one of the things we talked about is communicating with executives and talking through, how do you how do you explain trade offs? How do you explain different things? And so, again, it's thinking through that. How do I explain the trade off of moving me from one project to another? Here's the concerns that I have, trade off wise, and are you willing to risk this feature failing over time to make this new feature succeed? And it's a question of, basically, you're helping them understand that there's a risk to saying yes here that you're identifying now. It also might be that you're realizing that you're now being used as a fixer. You're the person who goes and takes care of problems before they arise or after they arise. And everybody's starting to use you that way. And that maybe is not where you want your career to go. So maybe it's a conversation about your career. And hopefully you've been having that conversation. Hopefully you have been discussing that, you know, you want to stay as an engineer and you'd like to climb that technical career track ladder of becoming from staff to distinguished to fellow. That's the path you're interested in going and you are more interested in doing that kind of angle. And in that case, maybe you might be like on my very first episode, my friend Martin, you might be thinking along that line of you get parachuted in to fix things, but you're going to get pulled out over time. And so then maybe the question is, hey, I want to just balance some things. If you have me work on this new project, I'm not necessarily opposed. I'm just aware that I'm going to have to let go of some work here, here and here. Like, uh, this project will no longer be able to get part of my time. Can we talk about how we're going to balance that? That's a way of also saying no without exactly saying no because you're more worried about, I need to balance my time. I can't overwork myself to the point of burnout. Now, I will note, uh, there are people out there who do not believe in burnout. And if you happen to be listening to this podcast and are a manager and don't believe in burnout, I think you and I need to have a conversation and maybe that's a future episode. Um, burnout is very much a thing. Uh, and I will say that right now there's a lot of different things that go on there. But taking on too many things, saying yes too many times, will lead to the point where you just can't handle any more work. You are burnt out and your Work product will start to decline. And so this is something that you might not say it to your boss, but by identifying that there are certain pieces of your job that you may have to let go of for a while, identifies that, ah, you're one person. You only have so many working hours, and we need to consider whether this is the best use of your time. So when you're thinking about whether to say yes or no, like on your own, if you do get the time to say yes or no and think about it, you need to evaluate, is this a good use of my time? Is this somewhere I want to go? Is this a, uh, direction I want my career to head? Maybe you're still new in your career. Okay, you know, you're. You just became a staff engineer and you're trying to make that decision, or you're a senior engineer and you're trying to decide if you want to go to staff. Maybe this is a chance for you to explore that. And in those cases, I say, you know, um, as long as you're okay with it, say yes, it's okay to try something a little bit different, maybe a little bit past your comfort zone. But if for some reason you don't think it's a good idea, it might be worth saying no. Or at least having the conversation with your manager about why perhaps this might not be the best thing for the company, why this might not be the best thing for your career. And you need to think about, how do you explain that? But you're looking at it from the point of view of how do you make this their idea? And that's kind of how this gets down to is you start asking questions, you start being curious, you make them answer to you why they want to take this risk. And sometimes as they're thinking that through, they start to realize, oh, if I pull so and so off of this project, that project could fail, and that's needed for here. And, oh, okay, maybe I do need to talk to someone else. Maybe I do need to think about that. So that's just. It's one way of thinking through, how do you. How do you phrase a no without it becoming a liability, uh, for you? And, uh, it might sound odd going through that, but sometimes there are certain leaders, certain managers, I should say, who might not take you saying no to them very well. And I wouldn't necessarily say no flat out like, no, I don't want to do that. Like, as an immediate reaction, I would again, come to it with logic and an explanation. Because usually once they understand that it's not you having a knee jerk reaction and there's a reason for it. They're less likely to decide that you're not the right person or that you're going to be, um, too risky to ask these questions in the future. And oftentimes that that helps quite a bit. Uh, I can certainly talk more on saying yes, saying no. I can give you a lot of examples and history of my own where I've done these things and been successful and not so successful, uh, as I do different things. But I do want to get to the other question that someone asked me that I thought was a really important thing. This is that time of year for your midlife or uh, midlife. Boy, I can tell you that does feel like that sometimes, doesn't it? Your mid year evaluation that you have to submit. At most tech companies nowadays you have to submit a mid year evaluation. And thinking that through usually is it can be a little hard. It can be a little difficult. Especially since you're in the middle of a whole bunch of projects. You probably don't have a lot of vacation right now. It's not like the end of year where you're coming up to the end of the year. Projects are winding down because everyone is taking some time off for the end of the year for various reasons. This, you're kind of in the middle of everything and you're still trying to go through. Now some of these mid year evaluations are more like how am I doing this year? Some of them are talking about what are your strengths and weaknesses, what kind of feedback have you gotten? Things like that. Um, I'd say the first step to an evaluation like this, whether it's mid year or end of year, is keeping good notes for yourself throughout the year. I have a daily, ah, document that I keep that is kind of a, just a very short what went well? What didn't go well? Like what am I feeling? How, what's happened today? And I expect myself to fill it out, just a couple sentences every day that just talks through what, what's, what's been going on, what happened today that maybe it stood out to me. And usually this is. You might have heard the phrase cover your, um, cya. I don't want to say this because I can't remember if this would get bleeped out. Um, cover your tail, cover everything that's going on. These are the folders that you keep or maybe the tags that you use on email that say like, hey, these are the things that I got kudos on something Or I have something in writing that I think I really need to hold on to in case something doesn't go well. And so usually I have those CYA documents, whether it's a screen cap of a, um, slack message, let's say I keep those. If it's really important. I keep all of that together with this little short document that says like, hey, this is what happened today. This is the conversation. And then I also do a weekly report that goes through and talks about just kind of what's happened in my week. And this is actually something that I make for my manager more than anybody else. But I also make it for me, um, just because I find that it's a really helpful thing to have. Um, as I start to think through these mid year evaluations and end of year. And I actually keep it with my one on one notes. And it's just a short little document that says what's the status of all the projects that I'm working on? Very short, just very friendly message. And uh, it might be something like, let me see if I can find an example. I um, might say like here. The majority of my week was a lot of one on one discussions to figure out a situation that was going on. The personalities evolved and how I might fix those situations. Very short thing. This is something I'm probably already talking about with my manager in a one on one in person. But this is just a quick little status note that this is something that took up a lot of my week. Uh, I also met with an engineering manager to talk about low hanging fruit of some things that we could fix. I walked through a process that they're trying to work through at a foundation that we work with things like that. So this status block is really kind of a quick snapshot of my week. Help Needed is a section that I add that just talks about what help I might need from my manager. Because there's certain things that I need to escalate upward that are beyond where I can fix something. Depends on where I'm at. Notes is more of like the, hey, I tried this thing, we worked on this thing, et cetera, et cetera. Um, and then metrics, numbers and dates. Usually this is just my reporting on any really important dates that are coming up. Any, um, big numbers, big metrics, like uh, you know, hey, we're about to release this feature on this date. Um, marketing is going to be pushing this out, things like that. The reason I bring up these kind of reports that I do these daily and weekly reports is that it helps me Identify trends that I can start to then use as I'm doing my mid year evaluation and my end of year evaluation. So along with everything from my CYA folder and along with any other like, kudos I might have gotten through or feedback I might have gotten through, let's say workday or another system, I keep these because it helps me identify. Hey, I've been struggling with this aspect of my job. This little piece that I could really use to improve on or I notice everybody keeps coming to me about this piece that I could really help build things like that, that really helps with those strengths and weaknesses as well as thinking through the kinds of questions like, um, hey, I need to figure out how do I drive? Um, how do I get my manager to help me do better with this topic or I want to go this direction. This is the thing that I keep enjoying doing every week. So those kinds of questions might come up and if I have these, I usually can read through and at least get a decent understanding of what I want to put in my mid year evaluation about. Yeah, we're on track for these projects and I noticed that my team is gelling well after an initial period of discomfort or we handled a situation, an interpersonal conflict situation, and now we're doing a lot better. Um, and my strength might be making sure that everybody is on the same page. My weakness might be dealing with, um, uh, leading with influence, let's say, for getting everybody to do code reviews. One way. If there's, there's a lot of different ways you could write that mid year evaluation, but you want to really think about a couple things. One, um, remember that this isn't just for you and your manager. Uh, these things get scanned by hr. So don't put any, like major trigger words in here for anything. But do give yourself an honest evaluation to a point. If, for example, you're having a lot of problems with a specific person on your team, let's say, let's say you're having a lot of interpersonal problems, problems with someone. Don't bring that up here necessarily. Like, that's not a good idea. You can say that you're working on interpersonal relationships, but you don't want to keep it about you. Basically is what I'm saying, don't make it about someone else and don't make it so that you're getting HR flags on your evaluation. Um, but also, you know, as you're thinking through, how do I structure this? How do I explain this? Uh, like, how do I explain this piece? How do I structure this bit. Use things that you know, you can work on. Like if you, if you're talking about a strength and a weakness. But you know, here's where I want to be in five years or three years or one year. Think about the strengths and weaknesses part based on that information. Like, okay, I would like to make it to distinguished engineer. And so I need to work on my, like this is what you're thinking in your head. I need to really work on how do I get everyone on board with a technical change that I think is there. And I'm struggling with um, dealing with conflicting personalities on the team. Okay, so maybe you can go through and, and evaluate that and say, okay, how do I, how do I deal with um, I'm just going to pick two names, uh, Bob and Sally constantly at loggerheads over this and I'm just trying to get my work done. I mean, come on. So how would you do that? How would you write that down? And it might be the um, you know, working with interpersonal relationships, uh, working with different personalities on the team might be a phrasing on there bringing uh, the team along with possibilities on uh, changing direction might be a phrasing that you might use. Um, so there's a lot of different possibilities on how you could word that, uh, mid year evaluation or end of year. But uh, specifically this question was about your mid year evaluation and come to the meeting itself where you're going to be talking about this with your manager ready to talk about some of those things. And that might be the case where you're getting a chance to talk more informally about what's going on and you're trying to deal with Bob and Sally and you're just trying to figure out how do I best drive this. And if not, if for some reason that you think that that might get recorded for hr, bring it to a one on one later. Be ready to have that conversation later. Uh, but in general when you're writing these, you're thinking about, you want short good story that you can tell across your entire mid year evaluation. I don't know if this was all that helpful, but these are some of the things I think about as I'm going through mine. I also go through and sometimes I might ask a work friend to help me with some of this. I know I've done that in the past. Uh, just saying like, hey, I'm kind of stuck on this part. I can't figure out how to do this. Some people now are using ChatGPT and Gemini and usually if you're going to do something like that one, remember that most of the time those are not work safe, they are not confidential. Um, so you need to be extremely careful using those to reword anything that may be um, private in some way, shape or form. Whether that's officially confidential based on your work requirements, um, which a lot of these probably are by the way. Um, or they're private because they're yours. I wouldn't really trust a generic chat GPT or Gemini. But if like, let's say you're running a local AI and you're doing this, or uh, you have an approved AI through work and you're using the work based one, if you're going to ask it to reword it, have it really focus more on the professionalism of what you're saying and maybe uh, maybe pick a book like Crucial Conversations or something like that and say can we, can you help me reword this using this book or using this technique or using this kind of thing. But in general for these kinds of things, I wouldn't use an AI to reword it for you. I would go find a friend and work friend I should say, and just say, hey, I'm trying to figure out how to reword this. Um, because I want to really highlight this piece, my strength here, highlight this thing, uh, that I want to go do this bit of future, uh, that I'm hoping to lead to. So it might take a little bit of time to do it right. But I also recommend, uh, don't wait until the day that it's due to get them done. Uh, usually that's a bad idea because you don't get a chance to really think through what you're writing. Um, I'll usually poke at it over the course of a week and tweak it and mess with it. You know, just couple minutes here, a couple minutes there, uh, maybe make a note for myself. But I'll be flipping back through my weekly updates, I'll be flipping back through my daily notes just thinking is there anything I'm missing? Is there anything I want to highlight? Is there another piece of the story that I want to tell on this mid year evaluation? Anyway, uh, I think that's it for the mailbag though. Um, I'm more than happy to take more questions on this topic. If you want to dig in and have a long conversation on any of this, please feel free to leave me a note on the follow up form where you can find more information there. Go find me on bluesky. I will happily get into threads on there and have some conversations, and maybe we'll pick some of those up for a future episode. But I hope you enjoyed this mailbag. Uh, best of luck on your mid year evaluations. Cause I'm sure everybody's going through those right now, um, and handling those yes and no conversations. And I will talk with you in two weeks. Take care. Bye. Bye.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.