AA210 - The Need for (Engineering) Speed!

Om, I wanna paint a picture for you. You're working in a company. Someone comes up to you and says, the engineering team, they're working too slow. We need them to go faster. if I had a buck for every time I've heard that, . It tempted to just say, well just whip 'em harder. Oh, no. Yeah. So faster. for what purpose? what are you trying to get out of this? I'd start there and say, why is this a pain point for me? More, for less. More is better. More is better. Supersize everything. I saw what you did. You immediately looked, you were like, you pulled back the covers. but why? what else is under there? you were sitting at a table and lifting up the tablecloth, what's under here? Why don't we have any leg room? We Just need more. Period. when we can't find cheaper people in the world, we will enslave AI and make them do it. Can you imagine that though? Just asking more faster. so definitely this is something everybody has come across, today in our podcast, we're gonna tackle different aspects of this, this ask basically I would start with one thing, and that is, is there a legitimate business? Reason why you want them to go faster? What are you hoping to get out of this? Are you hoping to deliver to the marketplace more of whatever the team's building, what are you trying to get? And then we can take, a path that hopefully gets you some of that, right? short circuiting this conversation usually is something like, we need engineering to go faster. We need to hire five more developers. Yeah, that doesn't work so well either, We know that. So some of this is, figuring out the why and then asking the question, the engineering activities that are taking place, are they, are aligned with what the business is expecting? Out of them. Well, let's start with that one. And this is outta order for us, but that's okay. So is your engineering effort aligned to business outcomes? I guess the first thing is can you show me on paper what your engineering efforts can, can you list out what you're working on? Because like, you'll hear a lot of people in the product management space be like, we don't need your systems and your scrum masters and your processes we're all just cool. Well that's true, but I thought you were gonna go a different place. Can you show me what your expected business outcomes are? And ask four different people in the org. Let's see how many answers you get. People should be aligned to what it is that. the organizations in business do. if you're not aligned you can have,, all kinds of different tangents based on who's asking and what their interpretation is of what the outcomes should be. Do you have a vision that your goals are aligned to. Do you have OKRs? You can keep saying to the engineering group, go faster, faster. And they will. it's the first thing that's gonna happen there is your quality will tank. So we did argue manager 180 5, what companies do instead of strategy to cover. What we're talking about now. Right. Which was the working title of this podcast, by the way, was The Goal Mirage. I still think the podcast should have been called the Goal Mirage So, let's look at some of the chapters like growth is second Growth Five Ys of why we need to Grow. Good strategy, bad strategy, looking at the book, there's a lot in this podcast. And I think the relevant one might be the blame game in software development because everybody else, other than engineering are saying You're too slow. So they're blaming engineering at this point. So we have that as a chapter in that same podcast. there's another one that I wanna find. It was argument Agile 1 0 3 challenges to building product roadmaps. challenges to building a product roadmap. why a single product roadmap? Well, if you're having trouble with one, you're gonna have trouble with many. That's true. But in this one, we had the pyramid where we gave you some tactical advice with the pyramid that your mission and vision are at the base levels of the pyramid. They're what everything else relies on, right? That's why they're at the base level. And then , your strategies in the middle, the goals that come from the strategy, how you're going to advance the strategy, come above that, , what are your goals? do you even have a strategy down on paper? And I feel at that point, like most companies are, they're out. They're out. Yeah. Like, you're not even, even get, you're not even gonna get to the roadmap portion at the top that's actually prioritizing and stuff because , the middle layer, the strategy is already missing. Yeah. And most companies by this stage, we'll just gravitate to, add more bodies. Right, and they don't get there adding more bodies. obviously you wanna have a strategy. I mean I personally think that we're pointing it product management and or , if your company's like small, you don't have a product management function. This is the leaders of the business Yeah. That you're pointing towards But if you're engineering and don't have strong product management in, I mean, you can always. Say like, there's no OKRs, that this work ties back to no value. No value document or strategy document or anything. This work ties back to, and then you'll get told like, why are you questioning me, Brian? Get outta my office. Just get back to work hands on keyboards. Sadly, That's true. But if you don't have that though, right? If you don't have something that the engineering team can align to, how do you know that? How do they know that what they're doing is contributing directly to those objectives as opposed to doing something else? Building something that's cool, but it's not really contributing towards your objectives and furthering them. They have to know that. They have to see those, they have to understand those. And they have to be visible. So, , at all times you could say whatever you are working on should be furthering us, towards our goals and objectives. If you don't have them start there, , even if you don't have strong product management that stuff can be written into tickets sure. I mean, all should be linked. Everyone's got an a LM tool. Yeah. Right? They all, they're all terrible, but they all have hierarchical linking where, the stories roll up into the epic, which rolls up into whatever, and the higher you go up in that chain, the business reasoning should be there. The business objective, the outcome, right. Whatever you wanna call it should be there somewhere., in an organization that doesn't have product management, it could be. Some level of risk onto yourself To ask why are we doing this? When it's not clear who it's for or What impact it'll have, but also, , this is what makes seniors of developers and stuff like that, you're always asking what's the value of this thing? How does it connect to the business? Yeah. You're looking for those opportunities. Absolutely agree with that. I think the alignment is critical.. Now that we're all aligned we can go into the real categories, not that any one category is more, we think all categories are equal. That's what we're saying here. We are an equal. Categorizer. That's right. That's a word. The first thing, you know, the first thing I thought of when we were thinking about this episode of like, oh, engineering's too slow, or We need to go faster with the engineers the first thing I thought of is like faster as related to what, right. The first thing I would want to look at is, is this just a observation based on nothing by some person that like really doesn't have a window into the roadmap. Right? Just, just an observer is , man, traffic looks really heavy today. Like from the side of the road. Not driving. Or is this someone with actual evidence? Basically , is the cadence of your engineering output predictable or not? maybe somebody's just reacting to a point in time datum, right? They're just looking at it. We need to go faster, we need to do more. But they need to look at a trend, first of all, to your point. and if your teams are doing things properly, not by the book, by the way. Every team's unique. So if they're doing things properly, they would have more or less a sustainable pace. All things being equal. And if you look at that average and say, okay,, this is how we've been pulling so far. You need to go faster than this. Let's understand why. And there are things you can do. If there's legit business reasons to go faster. there are things you can do. Maybe you can split the workup differently, spin up another team, right? Not necessarily adding bodies to an existing team, right? There are other things you can do, reprioritize. Faster might mean there's something driving that. Like you have to get something ready by point in time. There's a regulatory deadline or a conference that this feature has to be, you know, shown at, right? Whatever those things are, you can pivot and adjust so that you can satisfy that need. But that said, what you're not doing is permanently guaranteeing that faster clip. Right. that would be the business person's pushback why I don't see that hockey stick,, sprint over sprint. Why are we not increasing our velocity like that? I was trying not to make that call out.'cause it's like I immediately know I'm in the wrong, and that's not, defensible but let's pretend you got , one of these Stanford MBAs you're working for, and they actually understand, throughput and cycle time. They're gonna say, oh, , I've noticed that quarter over quarter our cycle time is not really getting any better,, it's getting marginally worse, but not a lot, but just like we seem to be slowing a little bit, we definitely seem to have plateaued with regard to improving our cycle time and our throughput in the last two quarters. they're asking you questions that factually are true. And they're doing it in a way to justify I need developers to be putting out more features faster, but I don't wanna spend more money to spend up more teams. Yeah. Yeah. I mean, they've probably at that point, if they're looking at a wide enough timeframe, reached a plateau where the team has reached its natural, , cadence, right? This is what they can do. This team has been together. Let's assume for a while, and you are, where you are. You can't just keep asking for more and more , they can ask, but I was like, slow down Silicon Valley.. You can ask. But, , you can only stretch the elastic band so far. at some point it's going to give, right. People are gonna get tired of this and you lose good people. They'll leave. or they'll just break down. there are a few shops here in town known for being grind houses no matter how fast or good the thing is. More, more, yeah, exactly. Well, there are some dysfunctions in the organization as a whole, perhaps, You could look at where this is emanating from. Maybe people are promising dates without, any basis behind it. So they're saying, we need to get this done and we need to go faster because my date's approaching and you're not delivering to what I need. The right thing to do there is not necessarily just simply say, how can we meet that date short term? Maybe you do that once, but I would look to change that behavior.. Why are you promising dates like that? where's the scope on all this? we can make any date you want, but the scope has to flex. All right. So for the purpose of scoring in these categories. in the four category, we're gonna use a worker revolt. And in the against category, we're gonna use a dystopian crackdown. I gotta tell you, I'm a big favor of dystopian crackdowns. The benefit of this category is you are asking the right question when you're saying Hey, I understand you wanna go faster. But can we agree to say, are we working at a stable and sustainable pace? And the answer might be, yes. Point over here for the worker revolt. The answer might be yes, but I don't care because the business is declining, we're on track to run outta money, the business has problems. Basically. Yeah. And I'm not absolving to say engineering has no part in helping the business resolve its business problems. But I have seen businesses run by poor management where it doesn't matter how fast you're gonna go, , the question here, the real flippant question that's not gonna win you any friends, is how fast do we need to go to make you happy? And I guarantee you, there's no answer to that question. There's no answer. Faster is the only answer. Right, right. Unfortunately. Right. on the dystopian crackdown side, I'm gonna award a one therapy session. Alright, so let's move on to the next category. a sub note on this category. It's an addendum to this category of reducing cycle time, lead time variability. Yeah. But we're talking about , the lean manufacturing essentials of batch size and flow. We'll probably get into this a little bit when we talk about product management and their role in all this. product management has a lot of influence on the batch size going into it. if you're always handing your developers Hey, I need this new report engine built and I need 15 banana reports , where Yeah, you could be 15 different dimensions of how we count bananas. And that's all one story. engineering can't just take that and say yes sir, right away. Coming right up., the example I gave was a little flippant 'cause it's loaded just to show you but your point's valid., when it comes to your system your company and your software features, you'll get this type of thing all the time. The team is not sure how to break things down to be predictable. The team doesn't understand Making things similar sizes when it comes to refinement. Maybe the team doesn't understand that. I actually, more than one team I've been with, they don't understand the difference between a refinement session and a sprint planning. Like using Scrum, they're like, well, these sessions look the same to me. Yeah, well a lot of the same people are in both, right? Yeah. So they didn't understand, you know 'cause to them it all seems the same. I think the concept of flow is critical here on this underlying discussion. I mean, the larger the bat size, the slower the flow, if I can put it that way. Right. So if the team understands that and the team isn't just the dev team here, 'cause they may understand it, but maybe other people don't in the company. Sales product folks, et cetera. If everybody understands that, then I think there'll be a concerted effort to say. Let's establish a decent flow by reducing the bat size and deliver in incremental fashion, right? Rather than deliver a feature at a time. And these features could be quite large with multiple things in it. I'm always coaching teams and product, to say, when you have a description of something and if there's a conjugation in there, that's a prime candidate for splitting right there, right. Split the feature. Yeah. I mean, it, it does help having some method to, to show the business the value of being able to release things. In small batches. There was another podcast where I told a story where a developer was questioning like, if all these things need to be done, like these, six stories need to be done. Before the user has agreed to change their behavior and start using this process rather than their current process or some other vendor tool and flip over to use our tool. why would we release at all in increments? Why not just hold them all until they're all ready and then go to the user and say, Hey, it's time for you to flip over. Right. and, in following that line of thinking, you are prone to basically saying to the user, we'll let you know when something's ready for you to see.. And it'll be weeks, months. And we find ourselves in that spot that we've known for years now, decades. in Waterfall voila. Here you go, customer. And they go, that's not what we wanted. Right, in the old days we would jump up and down and say Change order. But nobody's happy at that point. The customer's not happy. You are not happy, your salespeople aren't happy. But also the customer doesn't consider themselves part of the team at that point, you know? Yeah. Well, yeah.'cause they've been distanced. Right? Right. They've not been engaged. The funny thing about that story is that it was a real developer that had that viewpoint it wasn't some MBA, business manager or something like that. This was a developer on one of the teams Who's like, I don't understand why we wouldn't just hold it all until we're done. And get all the requirements up front and then do all that., there's value in showing the customer along the way through the journey and bringing them into the development process. it's their software that we're writing. it was very difficult because it's just the way that people had been trained in the workplaces that they worked at, but for sure, one that I really, really want to talk about, is product management. I want to talk about the trade-offs that you make with technical debt slash technical complexity. When you're a new team and you're working greenfield, like there's no, no software exists. You're building things from scratch. Mm-hmm. You can go fast, fast, fast, create all the things in the world. What do you want, Mr. Customer? What do you want, Mrs. Customer? We'll create that. same day. we're sending it out for testing same day. Oh, you guys are great. You're so fast, so much faster than all my other software vendors. But the more code you generate now maybe you have some design trade offs where you decided to like, well, we're not gonna fix that right away. Or we know we need to refactor this 'cause it's a little too big, but we don't have time to break it apart. Or there's real time users using the system 24 7 and we can't afford x hours of downtime that it would take to improve the back end of the system or create real time database replication. there are some structural things that would take a lot of time and you didn't build them in, some of it is the long term costs of short term shortcuts. Some of it is that technical that, but other parts of it are. the more complex the system gets, the slower you will be to make changes to that system, Absolutely agree with that, I think savvy teams that are keeping separation in their backlog, for example, things like tech debt refactoring, performance improvements, right? Those are the teams that have a, a holistic view of what's going on and can moderate what they're gonna pick up in a sprint if you're sprinting, So that is something I haven't seen too often because what happens often is they are overridden by typically product folks and say, work on my product. You can make it better later and later never happens. whenever I give advice on this people think I'm kidding. And then they're like, there's no way that would work. Denial, anger, depression, and then they go to sadness., I never talk to 'em again. I don't think they ever make it to acceptance because repaying technical debt. Or stepping out decisions that you made that need to be re-looked at in future refinements. Right. that kind of thing. What I will tell people is if it's a refinement thing, then cool. Just put it on the refinement schedule. We'll just talk about it.' sure. unless there's something special going on. then I'll schedule an out of order refinement. A special refinement.. So I don't mind people throwing things into the backlog. we talk about 'em when we need to Right. But also, I've been on teams where they don't write this kind of stuff into the backlog. the tech lead and engineers figure out, based on this number, You wanna keep 20% of your velocity for backend engineering, refactoring, chasing things down, experimenting with new things, the number could flex to 25 to 30 or maybe it's 20 to 30. I don't remember what the book number is. It's in that bullock. It's somewhere around there. My other advice which again, people don't like, is just, just don't just take it outta your product management, like feature velocity. If you're in this feature mode where you always prioritize features a hundred percent of the time over anything tactical, just don't make it negotiable. Just have that number and the engineering team decides what gets refactored or whatever. It's reserve capacity. a savvy tech lead is your friend here, They'll figure it out. when you're looking at this and you have multiple things, the team has to prioritize what to pick up in their refactoring realm, The best way I suggest people to do this is. Figure out who cares and, and why. Right? Right. We're gonna make things faster. Well, why it's running fine. Who needs it? There's a value in making it faster. Who is the value delivered to? And based on that, so a lot of a LM tools allow you to assign business value of some kind. Right. You know, to each of the work items in your backlog. This business value for refactoring work is no different. If the customer doesn't care that you're making something faster by 10%, don't do it. if you look at it that way, it helps in prioritizing what you should be picking up. the other side of the equation is obviously don't fill your sprints to the brim. Things happen, but allow capacity in there. if developers finish things in the sprint. But don't have capacity to pick up something off the top of the stack in the backlog to finish it in the sprint. They can pick up a small refactoring story, PBI, whatever it is. Yeah. I'm on the fence with this one. Make it valuable to x, y, Z user. I do think that is the better strategy. You should document the work you're doing, refactoring changing the technical architecture basically any work that needs to be done. Regardless of feature development, backend development, refactoring, whatever. On one hand you should make it visible and connect it to value, business value for that particular user. They should have a rep that lobbies for them wherever feature prioritization is lobbied for. wherever those things are done. On the other hand if it's just something that you've reserved that capacity and it just gets done, there is also a value of people just stepping up and just getting stuff done. And that's just the normal cost of doing business. Every job in a company, there are people doing things that just need to get done anyway. Yeah. So this is no different People might hear this and be like, oh, how dare you? engineers are gonna do stuff without me telling 'em they had permission or whatever. How dare they? I don't think that's the right thinking either. there's a little bit of both where some sprints you gotta dial left some sprints, you gotta dial it, right? So I don't really want to prescribe one over the other, but I do like the, I do like what we have in the four category more than what we like, well, more than what we have in the against category, make sure that it's understandable and you've communicated clearly the value of the thing. The problem with that is a lot of product managers, especially the influencer type of product managers that are telling you, like, just talk to people and be cool man. It requires deep technical understanding to really lobby for these things in some forms Yeah. business might be grilling you and your tech lead might not be there at all, I've been in conversations like this where the tech lead or whoever like VP engineering, CTO, will start defending the point to say listen, we've had x number of crashes. I got people up in the middle of the night. This can't be the way, you know, this is not gonna scale. We can't add more. Customers can't reuse it. Every sale you make puts us at risk. Is this really the way you wanna do it? We gotta pause and we gotta do this. You know, we've been saying this for months, Yeah. Or I can try to arm myself with all those arguing points, But if I don't understand technology and I don't have a great systems view across products Somebody like a tech lead who's across a couple product lines or teams can pretty easily argue for that. So, on one hand, I like the against on the other hand the, the problem with the for is that that product manager really has to be dialed in with technology the business and the systems. A lot of stuff. To be able to lobby for this when they're with those audiences, you can't be guaranteed that the tech lead's gonna get in front of those audiences all the time. Yeah, absolutely. that's a good point. I think it's up to the team though, as a whole to figure out how. they relay the messaging, It becomes a habit after a while. initially, yes, you're gonna have to sell it, but it becomes a habit. That capacity is just there for that work. Now if something emergent comes up, sure enough, you can drop that and pick up, something else. But then don't let that be the bad habit going forward either. Right, right. Well, we have a lot of bad habits. I don't like it depends answers, but since both of these were, it depends I'll award a 0.1, depend on each side. Yeah. 1, 1, 1 dependency per side. That's better than depend. Okay. No one depends per side. All right. let me get to the architect of this crime product management. Aha. Where are you? Product management. why are you not at your desk? We've all returned to office, right? Seven days a week. That's right. Seven, seven days a week. Product management. So when I hear engineering should be moving faster., there's two things I suspect right away number one, engineering has no predictability. I think they're all over the place. I'm expecting to see zero story points or zero. What kind of points am I gonna say? Brownie points, zero touchdowns. Zero runs in this inning. 10 runs the next inning. One run the next one. Like all over the place. Yeah. I expect to see their throughput, right? I expect to see it all over the place. that will be like, Hey, engineering needs to step up, ask some real questions about why things are like this and start recommending some fixes or making some fixes depending on where the problems are, right? I need engineering as a full-time partner in helping us be a, little introspection to say, where are the real problems? Let's actually talk about it. And then on the other side of the mirror is myself looking at myself back in the face of product management of like, are you sure that product management is not just saying like, build mirror reporting engine that has these 15 different reports from all these 87 different databases and have it done in one sprint? That's one story. I could do that. You know what else is a one story, A single story solve world hunger. That's right. Yeah. So one story. Yeah. I, I think there's so much under this, is your product organization working with the team or against the team? are they not a real product organization? Are they project managers who found more product management jobs than project management jobs on paper applied and got this one, now they're just throwing a bunch of stuff at the tech lead and say, do this not showing up for any refinements, you know, a laundry list of work, a mile deep. Nothing's prioritized, you know, or I mean, it could be prioritized, but like, here's 10 priority ones. That's between engineering has no velocity, like very undisciplined type of thing. And product management is not really doing product management between one of those two things. I, I would say like there's a lot of nuance in the podcast but 90% of my experience is one of these two things is fundamentally broken. I'd concur with that. I think that's true. That's where majority of the functions are. It's like saying, look, you know, the, the product side of the house is. Often customer facing. Whereas engineering is inward in the company. They don't talk to customers, a lot of organizations. But they should however, this is the reality. They don't, so products saying, look, do as, as we say, because this is, you know, this is what the customer needs. How do you know the customer needs that? Trust me, they need this. no, I don't trust you. Can I talk to them? Engineering should be able to do that. But if they don't do that, they don't really have an idea of what the real needs are and be able to sort out the wheat from the shaft, the needs from the wishes, the wants, the desires, all of that is great, but you are getting paid for the needs right now, so just satisfy that. Yeah. Correspondingly go to the backlog and sort it out that way, front ending the conversations when. Product or sales? Typically it's sales. It says customer needs X. Right? There's all these ability questions that need to be asked that don't get asked. They need it to work. what scale, how many users? What does it scale up to? What about availability? Does it have to be, 99.99% the engineering folks need to know that so they can build the right solution. Yeah. Right. But these convos often don't happen or they happen late in the game, so you're always backpedaling. Right. Sorry, I still haven't gotten over. The product manager who actually is a project manager retired. Oh, yeah. I still haven't gotten over that because that's how you get like if you want something to hold up to the light to look at, it's like if you wanna hold this glass of water up to the light to look at all the floating stuff inside of it. The, the thing that you wanna look for floating in there is like, did, did someone figure out the business viability? Like, can we actually sell this and will people buy it and give us money for it? that one thing should shut down 90% of the rest of the, maybe not even, not, maybe, maybe that's your Pareto principle. Maybe that's your 80 20 rule of, hold it up to the light, see if anyone even thought about the business viability. if they haven't, you probably have major problems in product management. Ultimately, yeah. your prioritization is based off of whatever the executive or whoever, you know, highest paid person in the room type of. Yeah. I wish I had a better outlook on this one being a product manager, there's a lot of people out there even the Marty Cagan four Categories, just write those down. For every epic that you start, it's a starting point. Absolutely. and make it an integral part of your discovery, your work items. it's not a bolt-on later, it's part and parcel of it. It's organic. If you do that, you'll be well served. I forgot what topic we were talking about. For this category, I mean, for devs too slow. I can't think of anything I would put on development from this one. In this category is usually, it's a, a function of product management is either broken or disingenuous. in that case, I'll give it one Maltese Falcon . Maltese Falcon great movie. It is like the ending of, I guess, one Maltese Falcon because it's fake and everyone died for no reason., that should be a negative Maltese Falcon. This is gonna be product management is a Maltese Falcon. That's gonna be the title of the podcast, development is too Slow. The Maltese Falcon of software questions or something like that. I like it. That's a good one. Let's stay on the Maltese Falcon analogy and talk about when you're doing faux product management. Because along with faux product management becomes this, like, this project management in disguise, sort of like MBA, like company thinking of, I've gotta have resource utilization. Gotta have everyone working at a hundred percent. So nobody's taking advantage of me. I gotta have engineers, on multiple projects and, switching between things. And I need real pain before I go out and hire any new people. Yeah. that kind of thing. So a lot of this emanates from picking a random date on the calendar for delivery. Go live as it's known, the diamond on the Gantt chart, and then you're back fitting. So you say, well, I have X number of people, if they work eight hour days, it'll take this much. Oh wait, that's beyond my diamond.. So I'm gonna ask them to work faster, harder, whatever. And bring that in so it matches with my fictitious date. and in there you're looking at your pool of engineers and say, are they busy? Are they actually working eight hour days? Are they utilized? And when you put 'em on two, it's four hours here, four hours here, or six here, two here. But reality is it's not like that. But that's where it emanates from, I think measuring their busyness. Hours per day on a project. I was gonna say. I wasn't thinking like value optimization versus resource optimization. When we started talking about this category, I wasn't thinking in terms of optimizing for flow, which we kind of talked about earlier. it's sort of like a drop in replacement for this utilization nonsense. What this category really represents is the people running the business don't understand a different way of doing metrics. they're sort of like perverting the metrics that they have. I think about OKRs for example. It's like, well the team's gotta have a key result to be judged by, and then every key result's gotta have a date next to it.'cause that's what the framework tells me. You gotta have a date next to it. So now I'm just gonna pick a date outta the air. And we want aggressive dates home because we wanna make sure we're pushing the team. Because that's what I see my job as management being to push the team, And if they don't, you know, if I, I say you need to complete 120% more widgets than you did last year, whatever, I guess it would be 20% more widgets last year, not 120. That would kill the team. Yeah. We'll just get new, younger whipper snappers in here for half the cost., if I want 20% more widgets by this time last year from the same team with no extra money or anything. And by the way, no extra bonuses. Isn't the game here, just playing games with metrics, isn't that really what's happening? it's less about because you can pick anything here. flow is just one thing. I said earlier we need 10% more flow month over month, every month forever. Hockey stick growth for flow, which is ridiculous, right? unless you're gonna throw unlimited money into your assembly line. saying we need unlimited whip or unlimited whatever. Like it's, it's just some kinda like metric that's been picked outta the air. And then used as a weapon. It doesn't matter what that metric is, unfortunately. All too common. Absolutely right., weaponizing is a good word, right? Yeah. So they do that, but then the teams figured that out. So they're gaming the metrics, right. So nobody's winning here. There's an illusion of progress here. And nobody's winning. Least of all the customer. They're not winning. So how about we pivot this whole thing and say it's less about keeping people busy, and it's more about taking customers from being satisfied to being delighted, How about we focus on that, you know, deliver not necessarily faster, but of higher grade, higher quality. How about that? Well, I really can't argue against, like, I would, the way I would argue against this is just, just don't do this at all. Refuse to even play in this game. Like, take your ball and go home and play a sport that you can actually win at. I wouldn't even play with this being measured by, you know, x, y, Z number of hours, this kind of nonsense. I would just go work for a business that's gonna put that other business outta business by just winning. Yeah, I agree with that. I mean, gamification of metrics is not serving anyone, for sure. this is also another good indicator that your product management people dunno anything about product management because I, 'cause I've seen OKRs, I've seen this come down from product managers. Oh, for sure. Yeah. Or from, you know, leadership that's supposed to understand product management, you know, so rather than saying Hey, we're, Brian m software development company, and customer A has a big problem with, onboarding because they get accounts and they can't figure out, it's too complex to onboard. Yeah. well Brian and Om's software development company, Brian and Om's team on Brian, software development company, you're gonna stay on this onboarding problem until you've reduced pain, until we, onboard these users in a certain amount of time or whatever, we stay on it until that business outcome's achieved until we get X amount of people onboarding and staying on the app because the onboarding process is, made a lot easier. Yeah, I agree with that. if you have good sound objectives, I'll say in, in kind of like a general terms, it could be OKRs, whatever it might be and you focus the team. On those and making sure they understand and enact on those, that's a lot better than simply saying, we need everybody to be fully utilized. Yeah, because you'll get that from the get go by having the team inflate what it's gonna take. Right? Yeah. So you're already losing right there. Okay. Well I'm gonna award one real point in the four category and one illusory point they look like real points. but actually when I calculate at the end, they're not even calculated in because they're not real points. They look like real points, but when you look at 'em, they kind of just melt away. just like utilization. Yes. Alright. Well I hope we learned something from that category. Cross-functional dependencies. You wanna talk about cross-functional dependencies? I think it is, right? teams are. Not going fast because they're waiting neck deep in muddy waters. all you can say here, is product and anyone else management, leadership should have an appreciation for the environment that the teams are operating in. their goal should be to free the teams up from these obstacles. So the teams can walk, run instead of having to wade through mud., this category is kind of about silos. and org structures again. Yeah. And that's how, we're getting near the end of the podcast when we start talking about organizational structure being terrible for being the culprit, But if I'm gonna try to push back against this one, like I started real early in the podcast saying there are two things out of this, which is like, engineering is not, engineering is not , what'd I say? Product management is broken. Or like engineering is all over the place. Those are like 90%. Or I guess 80%.'cause Pato principle I would shuffle this cross-functionality thing under engineering's all over the place. You probably would detect this under engineering being like, oh, zero points to this sprint. And then 10 points an sprint, and then 30 points an sprint, and then back to two points to sprint after that. Like when you look underneath the tablecloth, you'll be like, oh look, a whole bunch of cross team, cross-function dependencies. I'm waiting on my DBA to roll out the new table. I'm waiting on my DevOps team to roll this thing outta production, and I'm waiting on my senior whatever engineer who isn't even on a team. He just goes to meetings all day. but for some reason he does all the code reviews, you can find all these bottlenecks, right? and you know, I think good companies will simply identify these and then say, okay, let's not be wetted to those structures of teams that we have now, let's create teams that are more pliable, more fickle teams It is basically a collection of individuals that are needed to get this stuff done. and that might be just maybe for a few sprints, and then you shuffle people again, You can do things like that. You can also keep the team together to service what they built, so they can operationalize it and support it instead of having those handoffs that we often see, So there's things here, but I think those are tangential. By this stage, the damage is already done, right? So you have to figure out how you can improve that on a systemic level going forward. Well for this category, I will award three pieces of red string against and zero pieces of red string for because we'll see how that tangles out later. we'll see how that plays out. I don't know. Okay. Lemme see what else we got 'cause I think we're almost done. Let's try to wrap up with feedback loops. I dunno if I'll really have a great against in this category because the two things that I said start is like you have engineering's kind of all over the place and product management is basically non-existent or basically like faux product management. that's how you like the feedback loops. I don't think you get that in either of these. when engineering has a bunch of dysfunctions or product management has a bunch of dysfunctions. You're likely to not use feedback loops at all. You're likely to be more engaged in silos , and pointing fingers. The feedback loops we often think about here would be internal engineering and product, But I broaden that out a bit more. Feedback loops with customers too. You're probably not gonna have those too often because engineering is focused on what they can get done. Park is focused on asking more and more and more from engineering, so where's the space for customers in here? Are they coming to your sprint reviews? Are they even coming to your sprint planning? people go, what customers? Yes. You're building for them. So bring them into sprint planning and say, here's what we're planning next. At the very least, they're aware of what you're doing and potentially they could even shuffle some priority on you. It's their priority that you're operating on anyway. You're less likely to have those kinds of feedback loops to begin with. when you're in this scenario where engineering is just being whipped to deliver more and more. With functioning product be stuck in this type of in, in this kind of like the, the turf wars and the kind of like being stuck internally in discussions and the politics that goes on when the majority of your feedback loops are internal.' cause the customer can cut through all that Sure. If you let 'em in. Yeah. Right. You have to let 'em in. Right. And that's the organization as a whole being vulnerable. Right. Customer comes in, they can see the good, the bad, and the ugly. There's nothing wrong with that. But people aren't comfortable with that. Yeah. They wanna keep their. stuff hidden, the dirty laundry, so to speak. That is true. So because of that, I'll give 10 iterative loops for using feedback loops in learning that involve customers and in the against category, I'll give 10 go-to loops. Anywhere they might be completely broken or processes just wait forever, you know? Maybe somebody will come along and develop them eventually. There you go. Maybe one day they'll break out of that infinite loop. That's right. the only product management and Agile podcast that talks about go-to loops on the internet, the people see using them. I don't think so. No. I could be wrong. Write me a comment. So on the statement of we just need engineering to go faster., the claim at face value versus, there are other things that need to be inspected here. Let's, let's look, plus one worker revolt point for inspecting further and one go to therapy. Point against. I'm gonna make it a negative point. Just because of the time involved I gave one dependency for either side. I'm gonna count that as a real thing. And then I gave a multi falcon in the against category which is not real so that doesn't count. Right. And so interestingly zero points for in that category. I don't know what we did in that one. And then a plus one elusory points. The sad thing about I lose three points is you can look at them, they look like they're there, but on the tally sheet they're not. I gave 10 iterative loops and 10 go-to loops. I think we'll all agree those even out. They do. The problem is when you add zero red string to the 10 iterative loops, you still make it through 10 iterative loops. But when you add three pieces of red string to 10 go-to loops, you just get a whole bunch of string and a whole bunch of loops fly in in the air. Now you're really, now you're really lost. Maybe you'll turn to a helicopter and fly off. So the points seem to imply that you need to inspect a lot deeper when you hear this question of engineering's not going faster. We've gave you some tips in this podcast to kind of help you get started. A little bit if you're on the product management side, the development side from the business. I don't know if we've helped any project managers that are product managers in disguise or vice versa. But if there are any, let us know what you thought of it. And as always, don't forget to like and subscribe.