AA152 - Weaponizing Efficiency

Efficiency is a big one in the software development space. A lot of people try to be as quote, efficient as possible. And there's a lot of tropey arguments about effectiveness that we're not going to delve into on this podcast. we want to keep it strictly a rant cast that we haven't had in a while. I love a rant cast. Talk about efficiency. Times that you've seen efficiency weaponized in software development teams. So efficiency is usually a a time dimension based attribute, right? Do things quicker, faster, more in a given amount of time, etc. So this will be relevant for you if you've ever had those things thrust upon you. So let's, let's get into this. A lot of what we're about to discuss, I think, come at you, come at you, come at me, bro. I think a lot of these things that we're about to discuss are implemented under the banner of streamlining. We're just streamlining. We need all the teams Om to be on the same cadence across the entire program, and we need all the teams to write their stories the same way. And we need all the teams to do like demands basically from outside the teams. Yeah, I've come across two other terms that basically say the same thing, right? One is optimizing. Oh, yeah, right, right. And then the other one, which really, really irks me is Standardizing. We gotta make sure all the teams write their stories the same way. All the teams do this, do that, do that. All the teams have the same amount of water intake per day. It's like, come on. Yeah. Right? So yeah, absolutely. We've all seen this, I'm sure. Yeah. So I, I guess now's the time of the podcast to introduce that deals with , team and business agility and ideal of product management. And I will tell you right now, the, if you want to kill creativity in your company, this standardization. That's the way to do it on both sides, both sides. Yes, absolutely. Yeah, people forget that people are live, organic human beings. We're not robots and efficiency really is a way to make sure that we're leveling the, the measures right across all team members. If, even if it's one team, right, if it's multiple teams, we're saying every team is the same, every cog is the same size. In our machine, so they have the same number of revolutions per minute. And if we just keep cranking harder, we'll just get more output. In product, I look at it this way. I have a road map. Okay? The road map says I'm going to drive from Tampa, Florida to Chicago. Okay? Chi Chicago. Chicago! Right? Okay. Deep dish pizza place. I'm, I'm I'm leaving it up to the driver of the cars, multiple cars, to get me, to get all the cars to Chicago. The goal is, I want all the cars to get to Chicago. That's my goal. So I, the product manager, have given you a road map. And I'm going to tell you exactly what roads you have to drive on and at what speed you have to drive. That's how you want to have a great trip and you want to stop and get pizza in certain cities or go party in certain cities or go, you know what I mean, stop in Nashville for a couple of days or whatever. I'm not micromanaging you on these details, but if every single one of my car has got to take the exact same trip and stop at the exact same stops and down to the detail to the hour to the speed. that can't be fun for anybody in those cars, or any of those drivers. It's also unrealistic, because people are people, so some people are gonna get relaxed in their driving, and some people will be anxious, and yeah, so it just doesn't work. It really doesn't work. And also, when all those drivers get to their destination, what will they have discovered along the way? That will benefit me, right? The, the original person who's paying for the trip, sponsoring the trip and whatnot. They will have discovered that this way of working is really not for them. So they quit. And not so quietly either. Absolutely being micromanaged, but, I'm telling you the goal. I'm telling you where I want you to be. Right? I could even tell you by certain dates. Hey, I want you to be in Memphis on this date. Right? Like, doing milestones. Going back to our other podcast where we said, Look, deadlines in Agile. Completely. Okay. Completely. Okay., there are still things that you're leaving up to the team, the how you're leaving up to the team. And when you're talking about standardization, usually in my experience, the weaponization that happens is you're using the banner of standardization To cover for air cover for micromanagement. Yes and right. Yeah, absolutely agree. But also you're now comparing teams. If it's one team, you're comparing team members. You're comparing basically when you're talking about this. So you're saying, well, team A does it this way and team B does it the same way because we've standardized and team A is faster than team B. Why is that? Team B, buckle up. Right? Come on. Right? We'll forget the fact that we are individual, organic human beings and we work in different ways. Right? Yeah. So, yeah. Weaponizing the, the, the, the efficiency. Angle, which is the title of this podcast, is a real phenomenon, and I'm pretty sure everybody has experienced this, whether they realize it or not. Let's go straight to the heart of the podcast. So, on these teams, where efficiency has been weaponized, you have less trust. Like I had a manager one time who with a straight face, with a straight face told me that fear should be a, a, a, a tool in management that you exercise. Like basically the employee should fear the manager at least a certain amount because you have to wield that tool to, to get things done or to, to bring people in line or whatever. And they were very serious about it. They, it wasn't a joke. You know, I bring it up here as a joke. But, it wasn't a joke to them. And, and, I I didn't even really engage. Cause I was like, well, this is, I'm, I'm basically fundamentally, like reverse of your opinion. So, I, I really don't see us seeing a middle ground on this one. Wait, it clearly tells me that, that they have an inability. to motivate the teams and they're using the stick more than the carrot, right? Right, right. But that's what they needed. They needed when they needed a deadline rolled out and they needed the team not to argue against it or whatever. They needed to wield this this positional authority. You know, To get what they needed done, and they needed to wheel out that fear, that tactic, they needed to employ that tactic. And that is just, without a focus on efficiency, I don't know if that would have been effective. I don't know if that tactic would have really worked I think the team would have driven that particular manager just absolutely bananas. If they had said Oh, why do you, why do we need to buy this deadline? What happens when we don't hit it by that deadline? And like, just try to engage like normal dialogue, like normal adults would engage in at a business. Like, oh, no, why, why that deadline? Do you think maybe we can talk to the customer about the deadline that you've set? And what makes you think that that is the, the, the, the feature that we need to deliver by that deadline? Can we kind of talk to the customer to try to figure out maybe we can decompose this a little bit? Like That, that, that particular individual would have, they would have gone nuclear. They would have imploded. Yeah, they are. No, I agree. I, I think that's a real conversation though, right? We can make the deadline bucked. Right, yeah. Right? Yeah. Can we flex on the scope a little? Or, we can make the deadline But they're not going to like what they see because the quality will be subpar, right? So those are real conversations to have. But if a person has that in their mindset that they've either they or someone has delivered to the customer an expectation of a certain deliverable, a certain date, and they're going to just simply just do the task mastering, right? Do this, do this, do this, do this. This is not going to work because it will demotivate your team members. They may work really hard to pull out that deadline. And let's just say, if they're lucky, the quality is good, everything's good. Yes, the customer loved it. Unfortunately, that begets the same behavior. The next time, the customer is going to basically, not the customer, sorry, the manager is going to demand that because they are a micromanager at this stage. They're going to demand that. Do this again. And out comes the whip. And now what happens? Suddenly, you're going to find some team members say, Yeah, I forgot, but I gotta take a day off here. Right? People are going to start doing that. And, because they're human. If you don't treat human beings as human beings, you're not going to get the result you're looking for, long term. Or even medium term, honestly. Well, let's talk about what's required to implement these efficiency gains because in every time I've seen this lobbied for and put into action, what is required is measuring the, the time it takes to do things, the effort it takes to do things in the pursuit of a utilization metric being applied to the teams. So and, and, I would add, and, and, not yes, and. Oh, double and, double and, double and. I like it. And what ends up happening is, estimation in hours. Estimation in hours, tracking the original estimate that you gave. At estimate time and then tracking your time with the item that you're implementing to track how much time goes into implement. So, so like an estimate, but then an actual along with it and I would also point out in this, in this environment, peer programming is not a thing. It is not a thing. No, because they could be doing twice as much work at the same time. So, so you're, so you're measuring utilization of a developer, by the way, knowing that. Development is a discipline where some people are five times faster than other people. That's just the way it is. Mm hmm. You know, it's, it's just like sports. Some people are just naturally faster than others. That's just the way it is. But now your metrics don't reward people that are cracking out runs when they're at bat. Your metrics only reward people for hitting home runs. That's right. Yeah, that's a good analogy actually Absolutely. So so, you know what happens in that scenario is The teams figure out what's going on They know what's going on, right? It's painful for them, but they figure it out. Sure. And they will gamify this whole thing. They will gamify it by estimating things in hours that are artificially inflated. Sure. Right? So they'll just say, well, I know this is going to take me two hours, but I'm going to say four just in case. And if I get it done in two, that's fine, because I committed for four anyway, so I'm good. That's what's going to happen. So the optics look In the optical world, they look aberrant. They, they will, they will try to do that. But again, the teams that I've been on that do this kind of, kind of stuff they will have their director of development or development manager or whatever will come into the room when they're doing estimates and basically start undercutting, whatever you say. Oh, it'll take four hours to get that done. Four hours? Really? It should only take one? Oh, it'll only take me, blah, blah, blah. I'm not even really bending the truth that far to say I've seen that happen a lot. I agree. Ditto, right? Same. When, when in that situation, when somebody says it should only take an hour, I say, well that's great to hear. Maybe we'll just assign this to you. That's right. Right? You can knock it out in an hour if you think you know that's what's going to take you. That's when they kind of go yeah right? So, this kind of overt pressure on the team. It's like keep blowing into a balloon until it bursts, right? It's not a good thing because short term, yes. I'd far take the approach to get the team together and say, Look, this commitment has been made to the customer for this deadline, for this date, right? What do you think we can do by that date? And be fully prepared if the team says we absolutely cannot. Be fully prepared to say to the team, Well, when can we make it? Right? At the earliest. No compromise on quality. That's never an option. Right? And then go back to the stakeholders or whoever made the promise to the customer or the customer for that matter. Right? And say, look, this is when we can deliver. If you want quality, this is when we can do it. We know we told you this. Somebody told you this. That just cannot happen. Be brave enough to say that. Because you're saving yourself so much aggravation. Doing it that way, then Delivering something, subpar quality, it's going to blow up in their face. You lose credibility. I mean, all of that is worth so much more than just simply missing an artificial, derived deadline from someone's mind, basically, right? Somebody made a promise. Why? We don't know. But work on the process too, because they don't do that again. I mean, like you just hit a really key point. If somebody made a promise somewhere the bullet point I had written down for this one is where do the ideas come from? When, when you're, when you're fueling this efficiency focused organization oftentimes I will hear people say like, Oh, we got to make sure we have quote enough work for all the developers. In the feature factory. Basically, your product people become the the feeders of work to your developers and they say, Oh, no, we need to have more backlog refinements because we're going to run out of work, right? Because again, they're not peering, they're not doing exploratory tests, they're not training, they're not doing a million other things. So where do the ideas come from? Usually they're dictated down to the team, like do this, don't talk to customers, when I used to be in consulting. I would tell, I would often at the beginning of the contract, because a customer in consulting, usually I was at, at director or C level positions, right, or one of the other, and they would ask me Brian, how, how do we know that your consulting is going to be moving the needle, basically, and I would tell them well, how many of you, the features that you implement from your teams, not from a leadership person or a customer or whatever. They like your team's come up with a cool idea, who are they vetting their ideas with and how are they building? Like how, what's the percentage of ideas that come from outside your team? Versus inside of your teams to build things. And usually they will tell me like my, my teams don't like other than like, Oh, we got to upgrade this database or we got to refactor this thing or whatever. Enablement, not like we could add this new feature and we think really be enthused about this new feature. Yeah. And I will tell the, I will tell the executives, you will know we're making progress. When I start reporting the percentage of features that we implemented that were direct suggestions from your team members through our normal refinement process. And I'll have that percentage, I'll put it on a dashboard and whatever tool you're using, , it could be Microsoft, could be Jira, could be any tool that you're using. I'll put that percentage on the dashboard so it's visible. And when you see that number be a non zero number, You know we're moving in the right direction because your team members are the closest to the problems. Again, assuming you're talking to customers, right? So, where did the ideas come from? If they're all coming from outside of the team, and the team's just taking tickets and serving up orders that's an issue, we probably should do something about that. but when thee team starts suggesting things, that indicates we're moving now in a direction towards delivering value. As opposed to just doing whatever people tell us. Yeah, I agree with that. I think they need to also line up with the what, what, what you have as a roadmap. That's one point. The other point is that that dashboard widget should be really a trend line, right? Not a data point. So if you look at that and say, look over the last three sprints, four sprints, pick a number. This is going up or. Not, right? But, but it's non zero. That, that's a talking point right there. But I have worked with teams where or worked with clients, I should say, where they don't like their team members talking to customers. They just say, well, these are developers. You know, they're not very savvy in terms of how they talk to customers. Or not polished enough. Not polished enough, yeah. So we'll just keep them away from the conversation. Essentially, I boil it down to this, keep them in the basement, feed them pizza on their door once in a while, and have them crank out code. If you are in that situation, you're off to a non starter right there. Because you, again, this is not this is not a robotic kind of a situation where people are just taking input and churning out code. We're not too far away from the AI doing that for you, right? I think we might already be there. Well, I mean, the reality of what you just pointed out is that is the way that the development team is viewed by some of these pieces of the organization. We talked about this in the very previous podcast, if your organization on paper by the financials shows that the sales department has signed these contracts and therefore brought X revenue into the, into the company, right? Sales department plus 3 million development department. Each developer costs 200, 000. We've got 10 developers. So minus 2 million. No revenue in. If that's your financials, cost accounting. If that's your, if that's your financials, you're always going to see all those developers as just a cost sink. They never make your company any money, which is patently untrue. I bring that up to say, most likely, if you view your development team that way, Then you're going to say, I don't want those people talking to customers because every minute they're talking to customers is a dollar on my financials that's expiring that I'm not going to get back because they're not producing code that can be capitalized. They're spending their time talking to people and I have to immediately write that off as OpEx and it's money I'm losing. I have sales people and I have product people and I have whatever to talk to customers. I don't want the developers doing that. That statement. Big problem. Absolutely. Development team is seen as contributing to the liability column on your balance sheet. Big problem. Big problem meaning your financials are all messed up. You're looking at it incorrectly, the people that are solving your business problems, you have all the financials wrong. Yep. Yep. And if you're in this situation, those of you that are watching or listening, the only advice we can give you is keep that resume updated. That's like, I have more advice. Go ahead. Go ahead. I have more advice. My, my advice is watch our podcast with Newton about the financials of software development to, to, to educate yourself because quite honestly, it's not that difficult to understand. It really isn't rocket science. It's, it's numbers on the spreadsheet. Your time talking to customers directly impacts the value of the software because you can better understand the problems. So you have time for this in the scrum model, whatever you're using, whatever model you're using. There is time for talking to customers. It's, it's baked into the process. It really shouldn't be earth shattering, to make this adjustment. I agree. I absolutely agree. If your organization values that, if not still keep that resume update. All right, let's, let's move on to the next topic that we have. We talked about talking to customers in the time, basically time away from hands on keyboard zone. Oh, we got to have hands on keyboards. Anytime you hear that phrase, hands on keyboards. It makes the hair on my bald spot whoo, it'd go crazy, mine too, by the way. It figure. So the same thing about, Oh, we can't have you talking to customers that, that, and like that's time away from hands on keyboard. I think about well, well, what about, what about exploratory tasks or learning new technologies or training time for training? Well, like usually in organizations. That have this outlook if you're in an organization with this outlook of like, oh, don't don't have developers talk to customers That's a waste of their time. Oh, I can't like they won't have hands on keyboards be less time coding Yeah then probably your learning and development is probably done on nights and weekends on your own time on your own time Absolutely. Yeah, because that's all you know, that's all perceived as Waste or detracting from your utilization, right? What do you mean? We have to give them two hours every week to update their skillset. What do you mean? We have to give them every Christmas off. They had that last year. I hope it doesn't turn to a trend. Again, I go back to my previous suggestion. Anyway, that's right. Rubbin is racing. I think that's that's what we want to say on this one. The, the, the idea like all of this, the, the banner of all of this, like if we're going to put our arms around the whole topic, the banner is we're trying to drive costs down. So the idea is anytime away from the keyboard writing software. Well, Is time wasted anytime that you're whatever, exploring a new technology because maybe we could take advantage of when we need an opinion on the new technology is time wasted. So anytime the organization looks at something and and perceives it. As time wasted, I'm assuming they're trying to dissuade you from engaging in that activity. Yeah. And typically this is, this is usually driven down from the bean counters, right? They're, they're looking at two columns. They're looking at the liability column. Here's how much the resource cost is. I hate that term. And you know, there's really nothing they can put in the other column to balance it out with. So yes, I agree with you that they're looking at that and saying, maximize utilization, keep squeezing people till we get every drop of whatever it is we're looking for, right out of them. But there's opportunity costs here that you alluded to, right? So like lately, it's been AI. So if your team aren't, if your teams aren't looking at How AI impacts your environment. You're going to miss out, right? And when are they going to do that? If you're looking for maximum utilization, it'll be far better to say we'll give you a certain amount of time that doesn't count towards your utilization or contributions that you can go ahead and explore these things because they will help the organization, right? See the opportunities, identify them, leverage them, right? Collectively, not just the dev teams, but the whole org. If you're not in a company that values those sorts of things, then I'm afraid you really do need to keep that resume updated because that company is Circling the drain. Well, look, I mean, let's, let's stay here for a second on driving costs down that, like the, the, the company has decided, like the way that we drive costs down as we keep hands on keyboards and keep writing software, the best software possible for dis dispatching cabs around the city while the whole cab industry dies.'cause Uber has killed it, right? that's the equivalent here is like, you, your, your eye is not on the value of the broader solution. Your eye is on being efficient in the solution that you have while the market dwindles., but also. But also I'm going back to the old Mike Miller adage, like teams without financial metrics. Cannot make financial decisions, right? So if you take Financial information away from the team. Oh, you don't have a budget now. You don't get to see any financials You don't get to see the P& L. You don't get to see how much you your product is making with certain customers and You don't get to see when customers leave the solution and stop paying or whatever I mean, you you're no longer exposed to that you lose a dimension of data And now you can't, like the decisions that you make, I mean, I hope they're good but now that you don't have financial data, like how good are your decisions? This is like a team being in a cave in pitch darkness and they don't have a compass or a flashlight. So just go somewhere. Right, you run into brick walls or stone walls or whatever. Yeah, I, I, exactly. You're, you're so spot on with that. Because a lot of these organizations say that's not the team's business. Right? Right? So let's just let them crank out code. Or they're scared to share financials with the team. Yeah, that's true too. For reasons. Like I've never been given, I'll be honest, like I've never been given a good reason why financial information is not shared with the team. Other than We're scared we don't want to. But there's a lot of that, but there's also this thing about, well, the product of the team is contributing X dollars to the company. Sure. If they find out that, they might all ask for raises. There's a lot of fear based around all of that, right? I've seen that too, in organizations where they say, well, if you tell them what they're worth. Right? Because what they're bringing into the company, they might all ask for raises. We can't have that. It's like, okay, why not incent them instead? Yeah. Yeah. I mean, I mean, like if an employee suddenly learns like that, like their value is not. 10 times their salary to the company. It's 50 times their salary to the company. I, I don't see a reason why not, why not to have a conversation. Like you're, you're just having a conversation. I mean, the conversation might end with company only values you at this rate and that it is what it is. you're not going to have that blunt of a conversation with the company, but the takeaway, the outcome of the conversation might in fact be. The market rate for this job is only X dollars. So you're, I mean, people have this conversation. All the time when they think that they should get a promotion or when they make a decision to leave a company because they know the only way to get plus 50 percent or 20 percent or 30 percent of the salary is to move. Absolutely, yeah. So I really don't see a problem with having the conversation of there shouldn't be a roadblock is what I'm saying. I agree, although it's not in the psyche of the people that are guardians of this data. Yeah, that's the problem. I mean, I guess it goes back to the the category that we're discussing now is drive cost down it You're one of the costs Is the cost of labor and certainly you want to try to keep the cost of labor as equal this year whatever this year plus inflation to next year, right? You're like, if inflation is like, I don't know, 8 percent for example then next year you would expect your labor costs to go up by 8 percent and you would try to budget for that. Unfortunately, this, this kind of thinking also precipitates down to the teams themselves and people controlling how much time they spend doing things that they should be doing like sprint events. You know, why are you spending an hour and a half in a retrospective every two weeks? Surely that should only take 15 minutes. Sure, yeah. Right? Go crank out code in the rest of the time. Yeah, I mean, how effective is that? In the medium term, never mind long term. Well, I'm glad you brought that up because Ed is going to be happy with this section of the podcast where I talk about Gino Wickman's book, Traction, where in the EOS, the entrepreneurial operating system, I can't say entrepreneurial, so I'm going to say it three more times, that He, he has a section where he talks about working in the business versus working on the business. Working in the business is all these metrics that we're talking about. Sure. Hands on keyboards, gotta punch out. Number of keystrokes. Yeah, number of keystrokes. Oh, the lines of code. Yeah. Written per developer. Yeah. Versus. on the business, which is Hey, we really should be peering and we're having some terrible problems in quality. Maybe if we just peer or, or our, our PRs, because they have to be approved by the architect plus whatever other person takes six days is on average peers reviewing to get it, to get a PR done, right? Yeah. Like ridiculous. How about instead of that? We just peer on everything and then checking in immediately goes in the pipeline. Yep. How about that? Like working on the business is different than your normal day to day in the business. Sure. Because working in the business, you become myopic at that point. Like you can only kind of see directly what's in front of you when you're working in the business. But when you stop and take a step back and look at. What you're doing from far away from a little further, even, even if it's a little further away you gain a whole different perspective. Absolutely. Couldn't agree more. The last bit here that we want to talk about is when dealing with efficiency, if we're going to focus the lens and get more efficient all around as a company, that's what we're talking about. And we're not just blaming the development department. Okay. A lot of the improvements to efficiency are not in your development department. They are outside of software development. They are outside of the development team, the individual development team. They are at the layer of the organization that comes up with the objectives, at the layer of the organization that makes decisions based on the key results that are occurring, and decisions to to pivot. Decisions to go with a certain decision or not. Like that cost of delay in decision making, having to run things up the chain, come back down the chain, that kind of stuff, right? That kind of stuff, coordinating with the customers, trying to land things in different roadmaps at the same time for execution, right? Those things, in my experience. They outweigh by a long distance. A long distance outweigh? That makes no sense. An order of magnitude. An order of magnitude outweigh what any individual team can contribute. A bad strategy pushed forward well beyond the time when the evidence proves the strategy isn't working anymore and we should not pursue that strategy. Far outweighs anything, any individual team can do to be more efficient. So the efficiency should be taken up out of the team level and applied a higher level to start. That's where I think most efficiency pushes in organizations would help if they got out of the team level and started, how we pick ideas, some ideas over others. Let's make this process a bit more efficient. Again, I'm going to do this yes and thing with you and say, what if you started at the very top instead of just looking at the dev teams and then up a level or two at the very top. People aren't making themselves available often, right? So there's delay, cost of delay comes into the picture there. But what you outlined with all of these things gets magnified in large. Companies, large orgs, where you have the PMO, for example, right? The PMO comes in and says, Brian, you need to do these three decks by Friday. That's something you have to do, but it's not contributing to anything, right? So, you could talk about that and say, Well, what value is that giving you? What problem is that solving for you? We need to see. What do you need to see? We need to see how much the team's delivered that week. Okay? Why do you need to see that? Short conversation usually the PMO is so entrenched, but come back with solutions like, well, we have this dashboard. I'll give you a link to it. It's real time data. So I'm not going to produce an, a polished PowerPoint deck that you may or may not look at anytime soon. How about that? Yeah, I think there's ways you can kind of influence the process from bottom up. It's not going to happen top down because those guys that are at the top and the middle layers, Did not get there by working in an agile way, right? Just historically. Again, I'm not blaming them. They are where they are. It's a function of time. So as they were evolving through their careers, it was not necessarily working in an agile way. It was definitely the old way of working, right? The command and control. And that's fine. But for them to impose that on your teams today, right? And expect different results. That's where we have an issue. So if you're in the situation where you're being asked to do things that are not directly contributing to either making money or saving money, right? Basically, that's what it boils down to. You have internal projects you might be working on that save money, fine. Your customers are internal in that case. If you're not either doing one of those two things, right, then you should question the time you spend on that activity. It's going to help you in the equation of utilization. My utilization is still 80%, but in the 80 percent that I'm spending today I'm delivering this amount of value as opposed to the 80 percent I was delivering last month before I pushed back on these things. Yeah, but I was only delivering that amount of value, right? And so it's the illusion of progress at the end of the day and you need to question that. Is it really progress? Yeah, again, like the, as the product manager on the podcast, like I could care less about efficiency, when challenged on it, which I have been before challenge on it, when challenged on it, I kick it over to say that's something for the engineering management to talk with the engineers about what is best in their discipline. Cause it was like, who am I in product management to tell the engineers what is the most efficient way to do software engineering? All of the metrics I am measuring. To know if the product product, meaning the aggregate efforts of the product management product design the UI UX people, the software engineers, everybody that the metrics I'm looking at are what you just said that the, the dollars, the bottom line dollars are the dollars increasing because if I bring everything back to that number, Effectiveness utilization, like none of those numbers matter. Like utilization, for example, you can make a very loose interpretation about utilization to the bottom line of like, Oh, where where my developers are 90 percent hands on keyboard writing code, but that has nothing to do. With the fact that we got renewal from other customers or brought on more customers look, in that example, I'm just going to extend the the example. Your developers are only 90 percent utilized. Mm hmm. But you're getting renewals from customers. That might be some of that 10 percent that they're actually talking to them. You never know. It, it very well could be they're, the customers are only renewing because of that 10 percent of time that developers are taking to outreach to customers and talk to them and they say, Oh. Developers from Brian and Om Software Development Company regularly reach out to me, even though they're automated emails, they go back to real people when we reply, on a regular basis, to say, are you happy with the solution? And I get to talk straight to the developer, development team that maintains my solution, and they're, they're on top of it, and, every time I log in, I see new features in the platform, and, and I really believe that this is the right thing to do. Product can carry me to the future. Making people feel like we are part of their company. None of these metrics contribute to that. The, I argue that a whole, there's a whole other category. We can have another podcast on effectiveness. Versus efficiency where we just talk about things that make your customer feel like they're getting value out of your solution, and they could care less that your customers spend 7. 5 hours a day coding versus. You know, 6. 5 hours. Yeah, I think that's a valid podcast that we could do in the future. Staying on point, one of the things I would say, just, I'm going to press a little further on this and say, The focus on utilization actually detracts from that. Because there is a time involved on your team. And it magnifies if you're at scale, by the way. Obviously, right? So that time element of doing things for the purpose of maximizing utilization is actually detracting away from that experience you just talked about. That is a huge opportunity cost. I think you're right. Just like the people who think about hands on keyboards, I think about every second we're talking about maximizing for efficiency. And I am the worst for this because I will quickly say, this is a waste of my time. We don't need to spend the engineer's time doing this. I've got other things I need to do. So, I like, I will quickly intercede in conversations about like, Ooh, I was like, I don't know Do we need to spend an hour on retrospectives? Maybe we can get that done in 15 minutes. You know, this is not where I want to spend my time. Like come on. I agree. But also as we, as we wrap this conversation, like I feel for a lot of people out there that are, they're not in a position where they can pull this Elmo card and say, this is not where we want to place our bets. Yeah, absolutely. I think you've summed it up nicely. Was that the last topic? I think that might have been the last topic. We done. All right. So here we go. Efficiency. Now you've heard it all. Let us know what you think in the comments below. That's right. If you want to be efficient, go ahead and put a comment in. ArguingAgile.Com, ArguingAgile.Com, we got a form for comments. You can put a little microphone in there and record a little angry We listen to every tweet, I promise. That's right, we listen to everyone, especially the ones that we don't. Yeah, so, let us know and like and subscribe!