MICROMANAGER! Is This Developer Being Managed Out?!!11one

Transcript is auto-generated and may contain errors.

Hey folks, I am just leaving the office. We're going to go to the comments for the topic today and it's going to be I think it says I think therefore I am okay. It's a it's it's a good topic. Oh man. Okay. Hi Nick. I'm a software engineer at a big tech company and recently got a new manager. She joined in 2025. She is much more micromanagy than my previous manager, which I've been trying to navigate as frustrating as it might be, which it's very frustrating. Um, my real problem is that she has unrealistic expectations on the amount of output I produce. For context, I have 6 years of experience and I've been at the company for 3 years. Consider themselves a strong IC and annual reviews corroborate that. It's good. I've tried walking her through each step I've taken, which thankfully I keep a daily log, gather requirements, root cause analysis, documentation, writing, drive alignment, etc., but she remains insistent that I should be done a week earlier.

Am I getting managed out? Do you have any advice on how to move forward, it's been discouraging, feeling like my work, which I feel has been thorough, is not appreciated. So, thanks very much for for writing that in. I appreciate the thought, the detail. Um, we'll see what I can do here. So, we got an over an hour to drive home. Give me a break, man. Okay, cool. Um, good start. So, friendly reminder, if you want questions answered, leave them below in the comments. If you're new to the channel, that's what I try to do on this channel. Otherwise, I go to Reddit. Um, the alternative is that you can send a message over to Devleer on social media. That is also my main YouTube channel where I primarily have like C programming videos, but there's also a podcast and there's a live stream every Monday at 700 p.m.

Pacific. And the live stream is based on topics generally from this channel, which is pretty cool. Um, and it's really great to see people from code commute heading over to the dev leader. Nah, can't even speak. Dev leader live stream. It's harder to say than you might think. Um, and yeah, like people that engage in the comments and stuff, you know, jump into the chat. So, it's really cool. Anyway, um, so this is a a tricky situation. Um, shout out to Devin cuz he knows exactly what I'm going to say. Devin, you know this is coming. It's all about level set expectations. Um, that is one of the two things I basically repeat in every single video. Um, so it's it's a good at least that this person's having conversations with their manager about it. Okay?

So, I want to highlight that that it's not, hey, you know, one year went by before having a conversation with my manager about performance stuff and I had a surprise and this is all bad and what the hell do we do now? So, silver lining, at least conversations are happening. Okay. Um, don't get me wrong, this does sound frustrating. So, this person is claiming that they have, you know, do I got to yawn. It's coming. needed that. Okay. Um, this person's claiming that they're documenting um, you know, what's going on, how they're spending their time, which I think personally, if you're in a situation where you even think that this is happening. I think it's good that you do this kind of keep a written record of how you're spending your time and stuff. Uh, I think that's I think that's good practice. Um, if you can make time in general to like kind of like summarize your day and stuff, I think that can be helpful.

Um, but you know, in particular, if you're in some type of, you know, performance improvement situation or getting feedback that's that's like this like, hey, you know, we have different expectations, then getting things documented, I think, can help. The reason I say that is because you want to be situating yourself where when you're having conversations about this stuff that you're going in with like like evidence if you need it, right? So, for example, if a manager is like, "Hey, like we talked about this and you haven't, you know, you haven't delivered any features in two weeks. I'm just making something up." And you can be like, "Hey, actually that's not true. like based on you know the daily or weekly sort of you know tally that you're taking of your notes for your progress you could say like you know on this date like this

is when I ended up landing this on this other date whatever like just having evidence so the nice thing about it is that it takes things away from being like ambiguous um takes things away from being I don't know like like feelings to just like objective data. Okay. So, as much as possible, we want to make sure that we can be objective about these things. And that goes for the manager as well, right? It's not like, oh, I don't I don't really like this person on my team or I don't know, they're taller than me or they're shorter than me, so I'm going to treat them differently. I'm just saying that cuz I'm really short. Um, you know, it like being objective about what's being discussed is important. So, having evidence is important. Same thing goes for managers. the other way, right? If you're a manager and you're having to work with someone through performance improvement, um documentation is really valuable.

Uh I am historically not great at this and like primarily because I I like to lean in a little bit more to like benefit of the doubt for people, but ultimately like when I have to take action, I need to make sure that I'm having documentation in place. Absolutely. Like required. Um, so I think that's good that this person's doing this. Um, the to answer very briefly like am I getting managed out? It's impossible for me to answer that. I I cannot tell. Um, now it sounds like there's misaligned expectations. So I would get Sorry, someone was coming up a little too quick behind me and I don't like that. Um Oh, come on, buddy. Get in here. Come on. People put their signal on to move and then just don't even after I've slowed down. um in those conversations.

So, it sounds like it's kind of hard for me to tell from the way it's written, but it sounds like there's conversations about like here's what I've done and then they're still going, "Yeah, but I, you know, you should have done that a week ago." So like what I am struggling with a little bit from the scenario is understanding like okay so going forward like let's level set on what the expectations are right like if if it's always retroactive then it's really difficult to like to set the expectation going forward that might be happening but I feel like the way that I the comments written in the comments public. You can go check it out, but uh I I feel like I'm kind of missing that. And I'm not saying like it's any fault of the person who wrote it. It's, you know, a scenario and I'm just trying to kind of navigate it.

So if that's not happening, right, if it's always like more retroactive, then um the problem ends up being that so you're getting told in a conversation, hey, like not meeting expectations in this case from a an output perspective. You go, okay, like but here's here's everything I did. And they're like, yeah, but that's not meeting expectations. if you stop there, right? Maybe they discuss other things or whatever, but then the next week you just repeat the same thing like yeah, like it's very easy then to go for either side to try and argue I've done enough or have not because you didn't come to an agreement about what the next milestone is. So what I like and again I'm kind of going down this path right now because I I don't know exactly how things are set up there. I would want to make sure that if someone's having that discussion and they're like based on the throughput that I'm seeing.

I don't think that's sufficient for what expectations are. Couple things. One is I would personally want to sit down with that person and let's go through their notes. How are you spending time? Right? And you know, I the way that I at least like to lead is that I don't want to just assume that someone's like screwing off and doing nothing. Man, this person does not understand merging. They're just blocking a whole lane of traffic. Come on. Just embarrassing, man. I can't believe what I'm seeing. So, just for context, because I don't have my 360 camera going, I'm sitting in a lane. There's about another kilometer. I don't know what that is in miles, less than a mile. About a kilometer of like back to back before um bumper to bumper before the exit. There's a lane of traffic you can see beside me that's flowing.

Um, this person stopped blocking that entire lane of traffic to try and merge into this, but there's like another kilometer of runway that they can merge in at any point. Just like chaos. Anyway, um, what I would want to do in this situation for this individual is go cool. If I I'm trying to take the perspective of the manager. Let's assume that I I don't believe that I have an sorry I have an employee that I don't believe is you know uh that has throughput that I would expect at their level. Okay. Um I've absolutely had situations like this. Uh then you might say okay well what's what is the right amount of productivity? How are you even measuring that? Let me just say I've had situations where the amount of things that are actually committed and shipped is like almost zero in months. So I don't need like a a scientific measure to be able to say like something's not quite right here.

But um what I would want to do is go through with this person. Okay, like you're taking notes on how you're spending your time. Awesome. Let's go through it and try to understand how we can optimize this for you. My approach is not to say give me your notes. Look, you're being an idiot here, here, and here. You're wasting time. I want to sit there and understand, okay, you're saying that you're just making this up in a day, right? So, working roughly eight hours in a day. you have written down for what you're doing is you know uh an hour coding and then like uh an hour going through code review comments and then an hour uh deb or making the changes and then another hour like I don't know working on a doc for something and then like four hours I don't know like

the rest of the day like I don't know like looking for documentation I'm just making this up right I might say, "Hey, look, seems like you're spending a disproportionate amount of time trying to find resources, right? And maybe there's a pattern we see across the days and just kind of randomly making up one day." So, I'd want to go through that with them and say like, "Based on how I see you're spending your time, it seems like there's a challenge here." And that doesn't mean that this person is dumb or they're bad or whatever. It's just like how you're spending your time is disproportionately something I don't think is a good use of your time. Now, if you're unable to find resources, it might mean we don't have the right setup for the resources, right? I'm not saying like this person, it's this person's fault. They're bad.

They're wrong. It's just like that's not a good use of your time. I got to switch lanes here. Cool. Um, just a nightmare. A nightmare of traffic. Okay. So, so like then we identify that. Okay. like you seem to be looking for resources a lot and you're unable to find them and like that's why you don't have a lot of time that's actually spent coding or doing like more productive work. Cool. Like let's dig into that. What sorts of things are you looking for? Right? Or there's like a really common one is like I can't get my environment up and running. Right? And then we dig into it and it's like did you talk to anyone about this? Well no. And it's like, well, dude, like you spent three days trying to like get your IDE working and you didn't reach out to anyone for help.

Like that's that's not a good use of your time. And it's okay that you're having problems, right? Like I'm not saying that you're, you know, illquipped just because you had problems with your IDE. I'm saying we need to talk about when you ask for help like if you're uh researching something, you're trying to debug and uncover something like spending extra time on that could be valuable, but getting your IDE set up like everyone on the team already had to do that. It's probably a solved problem that you don't have to go relearn. So that's one, right? the the documentation thing is like cool like maybe we're missing documentation. Maybe you didn't even know we had documentation for it or you're looking in the wrong spot. Like okay, like let's talk about that or you found it and the documentation totally sucks ass. Great. Okay, like now we know we can identify that and then we can see once it's improved is this person able to start recovering from it.

But one of the big challenges or maybe I should say a common theme is like when we have this kind of stuff going on, if you have people that are very like self-sufficient, even though they encounter the same types of problems like this, because they're self-sufficient, they end up navigating them, right? They talk to people on the team, they get things resolved, they move ahead. It becomes very glaring when you have people that aren't self-sufficient. And I'm not blaming individuals for this. I think there's a lot of different sort of approaches that people take. Some people can be very effective, but like they need like a really guided path. Um, I think sometimes the remote nature of work can really mess with people on this, right? where they're like they might have felt like they're pretty self-sufficient, but that's just because their idea of resourcefulness is just turning to someone next to them and now that they're remote, they're like, "Ah man, it sucks like I don't want to reach out to anyone.

I don't want to disturb them." So, this can just like I'm not I'm just trying to say I'm not blaming individuals for this necessarily. I just think it's a common pattern. Um, and the other part to that common pattern is like if you are self-sufficient, then becomes less of an issue. So, I would like to sit down with the person and go through how they're spending that time to see if we can come up with more action around that. The other part though is like um it's kind of clarifying expectations, right? So to give you an example, someone's got code that's been sitting in review and a week goes by and I'm like, okay, like did a week go by and there was like active conversation on this stuff and like back and forth and it's actually progressing like maybe not great. We spent a whole week in code review, but like we came up with like there's a good solution that came out of this.

We maybe something was unexpected. Now we're like, "Oh, hell yeah. We're on the right track. uh or there was some other like build system breakage that was blocking you but it's resolved but it's very explainable right week not great two weeks I'm like okay what's going on with no movement right or barely any it's like what's going on like like that you're basically in a position where you're feeling mostly code complete but unable to actually get it across the finish line or get it to start rolling out. So, what's up? I got to move over lanes here. Come on, people. Let me in. And then it the problem gets worse and worse cuz I've seen stuff for 3 weeks, a month with little to no change. The problem with this kind of stuff though is like when it's discussed like, "Hey, are you blocked? Are you stuck on anything?" No.

No. Like everything's good. It's like everything's not actually good. If you have like a code review or a pull request that you're trying to progress sitting for multiple weeks, like there's there's something wrong. And again, if you are not self-sufficient, you're not a selfarter, you might just be sitting there waiting expecting something to change and it's not because it's already been weeks. So, like you need to be proactive like, "Hey, like I'm trying to get my work done. Could someone please have a look at this?" Right? Maybe you ping the team when the the review went up and I don't know, people were in meetings or whatever. The chat got it got buried in the chat. I don't know. It could be a million things like, "Okay, you lost a whole day on it." I would be like, "Oh man." Like, that's a whole day gone.

like in the morning I'm like, "Hey, someone start looking at this, please." But that's not that's not the attitude a lot of people have. So, I would be trying to clarify with this person, hey, if you're saying things are going to take this long based on like us reviewing some things together, it seems like you have I'm just making up a particular example, right? Like it seems like you have code reviews sitting open for a long time. My expectation with changes of like this scope is that you should like whatever your coding time is going to be it's going to change from feature to feature and stuff, but we're seeing that you're having stuff like uh sitting open in a poll request with no activity for weeks or minimal activity. Like maybe you got feedback right away. And I've seen this a lot. you get feedback right away and then and then there's no updates and so what it's not done.

You got to do something. So, hey, like my expectation is that once that stuff's up in like as a as a poll request and being reviewed, you should be able to close that well within a week. And that's my expectation. If you're like, "Well, Nick, the change is too big. I can't." Guess what? Maybe break down the change into smaller pieces. If you don't know how to do that, totally cool. Let's talk about it. Right? I want it to be the exception that your review is longer than a week. I'm using a week a little bit arbitrary here, but I still feel like that's a gut check. like longer than a week. If something doesn't feel right, there's got to be like a, you know, a good reason for it. Like, hey, I really needed this subject matter expert to review it. Um, they missed the one day, they were sick the next day, and then they were on vacation, so I had to wait till the weekend to finish.

And there we go. Right? That's the exceptional case. If it was urgent, then I would say, "Hey, we need other subject matter experts to go review this." But I think you get the idea. So level set the expectation with the individual around some of the process time. So hey, if your stuff is sitting in a pull request for over like a week or you're approaching a week, that should be alarm bells for you. And that's one expectation. If I meet with this person the next week and the same poll request is still open with no movement or there's a new poll request that's been sitting for a week like you are not you're not meeting the expectation I have now again I want to understand from you like my goal is not to on you for this right it's like I believe that when I'm having a conversation with someone and they're Oh, yep.

Makes sense. I get it. Like, I believe them. They understand. So, if it happens again, I'm not like, "Oh, you must be stupid." It's, "Hey, like what's up? Like, you seem to understand. We aligned on this." This is where documentation's really good, right? But being able to um being able to I lost my train of thought cuz there was a message on my phone. Um I was talking about code reviews stuff taking too long. Oh, so week over week, right? Um, I want to talk to them and understand like something must be going on still if you seem to understand it but you're unable to do that. So like how do I help you like where are you getting blocked so that you are unable to you know work on this commitment that we agreed to right so my approach is generally that I want

to like provide a framework of guidance not like every individual feature is like you must do X or like no um but like here's my framework here's my guidelines and like those are my expectations for So for this person, like if you're not having those types of conversations after receiving like, "Hey, I think this should have been done a week ago." Okay, hear you on that. Maybe we can go through the stuff you've documented, see how you're spending your time. Cool. Hey, here's the next thing I'm working on. Let's come up with some expectations for that based on everything we just looked at. Are there some process improvements I should make? Do you think I'm spending too much time uh updating documentation? Is that maybe a gap in the team cuz no one else is doing that? Um a really a really common one and this is a an example I want to share because it's not ownership spans a couple different people here.

Um let's take some of my uh principal engineers. Okay. At principal level there's an expectation that individuals are um like the impact they're having is quite significant, right? It's not just small feature work and lots of it. It's actually more significant feature work architecture spanning different teams in terms of what their uh their improvements and feature sets are. And if like that's not happening, again, it's not like a, oh, you're bad, you should feel bad kind of conversation. It's like, hey, well, you know, what's up with that? Like, why do you find that you're unable to do that? Is it cuz we don't have the things or they're not like you're distracted by other stuff? And I found it to be a common theme. This person's going to try to That's not very smart. Don't shake your head at me, lady. And tried to tried to pass.

I don't even want to explain it. Anyway, started tailgating me and then shaking her head at me like, "Sorry, you're actually the dumb one here." Um with some of my principal engineers, the challenge has been that when there's such a sort of like volume of uh you know help needed to maintain the service, the challenge ends up being that because they're experts, they're like I keep getting pulled in to help with things. And it's like okay, so here's this interesting situation. Their time is very valuable. Everyone's time is valuable in terms of the impact that they're able to have at principal level. This applies for senior engineers as well. Just using principle to kind of go the furthest end of the spectrum for like direct reports. I have their time is better spent on larger scope, larger impact work. because they're subject matter experts. When they're pulled in to go do firefighting, that time is taken away from that style of work.

But then it's a it's a resourcing problem, right? It's like, okay, so you don't want me to put out the fire. So you don't want the fire to get put out. And it's like, no, I want the fire to get put out, but at some point someone else has got to put out the fire. Well, no one else can put out the fire, Nick. Right. there's there isn't someone else on the team that has the knowledge and the experience in the space. So, if you want the fire to get put out, I have to jump in to do it. So this is a it's a really good like balancing act to try and have a conversation about because it's responsibility on the individual and for me if I can't help make adjustments in our team to be able to free up the principal software engineer

the senior software engineer because they are a subject matter expert if I can't help free up their time they will never get sufficient time to do the impactful work that is expected of them and they're just trying to do the right thing. It's a tricky balance. So that means that I have to start looking at things and going, "Okay, next time we got to put out a fire. How bad is that fire?" Because if it's not about to melt down the whole world, like, okay, someone less experienced is going to go on that and you know, they're going to try to drive it and it might be a little longer. The fire might spread a little bit worse, but we're going to learn, right? Or I might pull in two people to put their heads together and it's going to slow us down a little bit.

And yeah, it might not get solved as quick as the one expert could do it, but now I'm gonna have two people that learn. So, we have to like slow down to speed up over time. Just one example. I wanted to share this though because that's an interesting conversation to have when level setting expectations on this kind of stuff cuz it's like, hey, if my expectation is at your level, you're doing this style of work and we're meeting to talk about it and you're like, hey, I'm not doing that kind of work. It's not that you don't want to or you're not capable, but guess what? my time spent doing this other Cool. Okay. Like, let's talk about that. So then I need that person to understand this is, you know, the expectation. They explain their time and I go, "Okay, cool. When you have these types of things come up, you can feel free to pull me in.

If you're like, I don't know how to balance it. It seems like a fire. Let's talk about it, right? I can discuss with you. How urgent is this actually?" If you're like, "World's on fire." I'm like, "Okay, I hear you. We got to do something right now or yesterday." Cool. But if the world's not on fire, then at least we talked about it. Let me go find someone else to help and free you up. So, I think it's really important that when you're having these conversations about expectations, you need to be talking about going forward. like let's let's learn from what happened. Let's understand it. But like now going forward, here is the expectation. Now, are you on the same page? Because I don't want to leave the conversation or I don't want it to like be done. We can always follow up with more or whatever, but I don't want to just like walk away from it if we're not both in agreement.

I want the person to understand and then I want to make sure they feel good about the actions that can be taken because they like this person and their the comment is kind of like I think I understand what my manager is saying but I don't think it's realistic. So to me that conversation's not done. So if I were the manager and I was I don't know I was saying hey I think like you know work at the scale you're doing shouldn't be taking this long because you're spending more and what and maybe that's where I leave it right I'm like your change that's not like a one month kind of change to land the code I just don't think it is and I think that should probably be something in the order of like half that time or less if that was the expectation I was setting and the person was like well I disagree.

Like I'm not like this is me. I'm not like mad at the person. I'm not going to be like, "Well, you're not allowed to disagree or have an opinion." Like why do you disagree? Why do you think that work should be so much time, right? And then we talk about it and then they might say, "It takes me like takes me two weeks to get someone to look at my code." Okay? Like that's where we need to talk about that. I'll give you another brief example. Um, I had uh a more junior engineer. I had him estimate something. We were having a conversation uh about some work that had to get done and said, "Hey, like you're going to be tackling this. It's kind of in a space he's familiar in.

So, like what are your like you know, not going to hold you to the exact dates, but like roughly what are your ETAs for this?" And um there were a couple changes and he basically scoped them out over the course of like two months. And I'm not if he ever listens to this, we've had a conversation about it. I'm not um I'm not picking on him for doing what he did by any means because what he did was he he wrote his he was like it's going to take this long. It was like whoa. Like break break that down for me. Like why? Like what does that look like? And then he walked through it and it was like I think one of the line items was like it was going to take like I think there was two things going on. One was like it's going to take like a month to test and it was like it should absolutely not take a month to test that.

That's four whole weeks to test it. So like tell me and again it's not like oh you must be stupid. It's tell me why. like walk me through that thought process because 4 weeks is a long time to do anything. So tell me why the next part was that some of this work can absolutely be done in parallel and it was structured to be completely sequential. So we talked about these things and it was good. It was like oh you know back and forth like okay like um this is how I was thinking about testing it. here's why, but we're talking about this other thing instead. Okay, that makes sense. I can easily cut back on that time. So, if you're not going through some of these details and like explaining the thought process and going back and forth on it, you're not like digging into where the time sync is and understanding.

And it does take both sides to go through it. Now I'm It says I got 20 minutes left on the drive, which is nuts because it's not 20 minutes to get home from here. So that's scary. Um, but I want to start talking about a bit of a different angle here. So a lot of when I talk about things, it's like from my perspective as an engineering manager, and that's what you've been getting basically this whole time. Now, let's let's assume this manager isn't the greatest manager in the entire universe, which is obviously me, right? Just kidding. Um, but let's assume that this manager is like, you know what? I'm done with this person. Like, these are these conversations are just whatever. Like, words are wind at this point. Like, we're just getting through this and this person's out of here. Like, I'm working on getting them out.

Um, what do we do? I would say that if you've been trying to move these conversations forward to be a little bit better in terms of clarity on the expectations, they're not going anywhere. Um, or or they are and you're getting more clear expectations and you fundamentally disagree with them, I would say it's time to like start looking. I personally think it's worth investing time into understanding what those expectations and stuff are. But if you are actively trying to say, "Hey, I need clarity on this. I want to understand better." and you're not getting that. Like that's also like you can't get the clear expectations. Like maybe you got a manager or or maybe they've already just kind of given up on on doing whatever, which is hard because I don't know, like this person said, they've had good performance reviews and stuff. There's no reason to think that.

But we don't know what the manager's thinking, right? I don't have them sitting in the car with me. I've never talked to them. don't know who they are. So, don't know. But I do think that if you're trying to get clarity and it's not happening or you fundamentally disagree once things are made very clear to give you an example, if um I'm trying to I can't even think in my role for something like this, but I wanted to give like an AI example or if I was like, "Hey, maybe let's do 101 ones." Okay. Uh, if I was like, "Hey, I have um like 12 direct reports. And if I were to do one-on- ones every week for half an hour, 12 * half an hour is 6 hours. It's going to take me 6 hours of my week at least because muffer around that to do 101 ones." If someone was like, "Oh, well, no, it shouldn't take you that long.

Just uh just do AI notes for them, right? just like get them to use AI notes and summarize what they did and then you can use AI to to kind of summarize your thoughts back and then you can probably cut that down into like an hour. I would fundamentally disagree with that, right? Probably a stupid example, but I think you get the idea. If someone was telling me how to do my job in a way that I fundamentally disagreed with, the pay better be so good that I'm like, "Okay, well, you're paying me and I'll just do this." But, uh, I don't, you know, that won't last long. So, I would say if you fundamentally disagree, time to start looking. Um, I don't see another way. And now to start looking doesn't have to be like necessarily the end of the world. Like depending on the company, maybe it's a team change.

I have done team changes before. I've been very happy with team changes. Not very happy sitting in traffic in the last little stretch here. This is nuts, boy. But yeah, it's it's hard to know slashimpossible for me to know if they're trying to manage this person out. Um, it's tricky too because we only get not that I doubt this person and what they're writing, but like we only get one side of the story. This is how how things always are when people write in um, and I want to give them the benefit of the doubt. But it would be interesting, right, if we had the manager's perspective. Maybe we uncover something different. But because we can't and we don't know, we either assume a bunch of stuff. I don't think it's either. I think you just have to assume a bunch of stuff or you kind of just acknowledge like we don't know.

So, I don't know. I don't want to assume too much. The assumptions just give me different paths to kind of walk down. But I certainly hope this person's not being managed out like that at least. Um, if they are, I would, like I said, keep up on the documentation side of things. Um, and also, I guess if you're documenting things, if you're trying to um get clarity like, okay, the way I was framing it was like, okay, you talked about what happened. What about going forward? Like document that because if you document this week and you say okay the plan for next time we meet is like this is the expectation. Okay. If you keep notes on everything you're doing that's that's relevant, right? You're keeping notes and then you go into the next meeting and you're like okay did the things and they're like well no like here's something else.

It's like, okay, but we agreed I improved on that one thing. Cool. What's the next thing? Right? You keep going through this process. If it's if you're not documenting it in terms of the things that you're addressing, then like how do you tell the story? If you're able to say at the end like, hey, it was always a moving target. And like it's kind it kind of makes it a shitty story for someone who's trying to manage you out. If it's like, "Okay, Johnny. Um, you know, the thing I'm most concerned or the thing I'm concerned about for you is this and we need to see this improve." And you're like, "Okay." And then you go improve it and they're like, "Johnny, it's great that you did this, but like this sucks." And you're like, "Okay." And then you go do it and they're like,

"Well, Johnny, no, next thing." And you're like, "Well, wait, why don't you just tell me the things to go work on?" Because if you're always going from one conversation to the next, making an improvement in an area and then being blindsided by something else, it's like if it's a regression in something else, okay, like you're regressing. But if it's just something completely different, it's like, man, just tell me. Tell me so I can go address things holistically. Um, but I I think it makes for a pretty bad case if someone's just all over the map with random things every time to try and improve. There needs to be some consistency to that. So, your your documentation is your best friend there. Um, but yeah, in the situation we're being managed out, like I said, I would lean into trying to get clarity first. Um, if you fundamentally disagree, then that's the way it is.

And your best friend is documentation. So, um, I hope that helps with the question. I realize it's a long- winded way to just talk about a bunch of but there you have it. Thanks for tuning in. I'm going to turn this off because I still got more traffic to sit in, and I will see you next time. Take care.