AA133 - Do Infrastructure Teams Need Product Management?

Welcome back to our Agile since I am a product manager, I want to have a podcast specifically on this article, it's from 2018. It's, it's, it's quite old, but also it's not that old, 2018. It's titled, do infrastructure teams need product management? I'll link the article, but while we're talking about it, I'm going to read through the article. It says many infrastructure development teams, Ooh, bless you. Many infrastructure development teams don't have a product manager or have a fractional product owner slash analysts working primarily on detailed technical requirements that forces an architect , or senior developer to manage a range of responsibilities they are not interested in and perhaps not qualified to handle. Sorting conflicting business priorities internally, quote, selling the value of architecture and specific improvements, tying technical decisions to quantitative business metrics, lobbying for increased staffing versus other teams, motivating developers with real world examples of how their work matters and users. Said another way great development teams. Want to work on great technical problems, but these never arrived gift wrapped, or fully defined, or conflict free, with clearly articulated business value. So, two observations, observation number one seasoned motivated development teams are the scarcest commodity in the universe. Let's keep them focused on what they do best and product managers and development teams solve different problems. We should not force developers to be product managers or vice versa. Initial take , Om, go! Oh, my goodness. Oh, hey. So first of all, this is so so so bipolar, right? First of all, seasoned, motivated development teams, not the scarcest commodity in the universe. Let them keep focused on what they do best. Okay. All right. So you know, those people that are like, overseeing teams that are almost circling the drain, PMO, you know who you are. Okay, you might agree, but product managers and dev teams solve different problems. Think about that for a second. Product managers and development teams solve different problems. It's like saying, people that are putting up the scaffolding on your home, Putting in one breeze block over another and putting some, you know, filling in between are solving a different problem than Your builder or your architect or your whatever plumber You're moving into a home. You want all of all of it to work together when you move in you don't want just The building infrastructure to be solid and then when you flip the light switch on there's there's no light because you know, see electricians Yeah, they're not part of it. I see that here. We should not force developers to be product managers or vice versa My biggest issue is when they say great development teams want to work on great technical problems. That is a loaded statement. I think, not only do I not agree with it, I would reframe that. Great development teams need to work on solving great problems. Business problems because technical problems. Okay, you can solve them, right? You can, you can do all of the technical work and you might get paid for a little while, but that's not sustainable. It's the business. What's what need are you solving? I don't know if I I think I disagree. Let's, let's, let's talk to, let's talk to the first statement. Cause I, I, we use, you zip through the first statement, see seasoned motivated, which, which is not honestly, it's not very much of a statement that I'm going to try to defend here, but let me try to jump in front of this moving train. Seasoned motivated development teams are the scarcest commodity in the universe. Let's keep the focus on what they do best. The, the. The subtext of that one, where I can get on board not agreeing is let's keep these developers hands on keyboard. Like the, the way that I see this actualized in the universe, in my career, I don't agree with that. Meaning, why do I need to talk to customers? Why do I need to have all my developers in the demo? Why don't I just have my lead developer do it? Or why don't I have my QA people do it? Because it's not that important. Yeah. Like that, that sentiment out of this. Is the wrong sentiment. Now, what I, what I think the author here and we'll, we can get through the rest of the article to confirm this, but what I think the author here is trying to say is. Development teams that are tuned into business problems, and development teams that work well together, meaning they've been around a while and they understand and how to consider the customer first, as opposed to whatever other things. That is a, that is a rare occurrence in the wild. I think that's where he's going with this. I agree, but why do you think that is? I know where you're going, right? It's that customer centricity. We can come up with the best widget ever on the planet. Is it really? Did by anybody? Why? What cause is that? See, that is an interesting question. Why is it so scarce? I mean, many factors? Well, number one number one first of all, consider every team that is not an agile team, meaning they're, they're put together around a strong personality and they stay together and they stay working as long as that strong personality stays there. Kind of sheltering them from the worst of the organization and that kind of stuff. And then when that person goes away. Then the team starts degrading as demands of the business. Culture. Number one would never let a season motivated development team form in the first place. So number one, your culture has to be right. Number two, the right people have to meet because you could have the right culture and the wrong people leading your development teams, and they'll still sabotage this. And then.. You're coming, you might have the right culture, you might have the right people, but you do projects, so you're constantly disbanding teams. You're constantly reforming teams, or maybe, maybe you're all in on this whole fluid team concept that I just can't understand because I have a little tiny brain and I just can't my brain can't get it of you're constantly shuffling people between teams, so nobody ever gets it. Working with different people so you never get that cohesion. There could be a million reasons for this first one of why you never... At your organization, get a single season motivated development team. I had this discussion today. What is that? What is what is the culture? Culture for me is a byproduct of four things. You know, our culture is a byproduct of the people., the organization is nothing if it's not for the people. The processes that those peoples have put in place, those people or people above or Before them, there's these processes that you have to follow the policies, right? So that's the third one and then and then the other one is for me for Organizational culture is really talking about the one thing that I find it very very difficult to quantify Which is the the other P which is the politics every organization has politics Yeah, if you think your organization doesn't have politics, you're kidding yourself is or you're just too naive maybe this is your first job but you'll learn, right? You just dust yourself off and, and, and you'll learn. So those are the four factors that I think form an org culture. Now, now that you know what those factors are, right? Think about what you can influence. Can you influence all of them? So you can influence culture and instantality. If you can, let us know because I'd love to learn about that. I found that... Most people cannot influence much more than just the process side. Especially, it doesn't really matter actually. I was going to say, especially if you're from the, the process side of the equation. You know, the scrum masters of the world, right? Or agile coach, whatever. Even if you're product, you're really not influencing the other three things, right? You're only talking about the process. We can deliver this product in the context of this time frame, in the context of who the customer, the target audience is, right? And then, what does it mean for us to meet that versus not meet that? You can talk about that, right? That's about it. That's the extent of it. So, large companies that are out there, their org culture has not remained static, right? I'm going to repeat that for those of you in the back of the room. The culture of an org is not a static thing. It morphs over time. You come in at a certain point in that fabric and you go, Yeah, I understand it. But, it changes. So by the time you've had long enough. to make a difference. Guess what? You're not making a difference on what you thought you were making a difference on. It's changed. Yeah. Right? A couple of examples, just because I'm kind of on this rant. Who would have thunk it 20 years ago that you would have things like self driving cars, Teslas, or Uber, or Grubhub. People would actually bring food to you when you can just demand it, right? It didn't, it didn't exist. You actually still had to go out and you could put orders in, sure. Yeah, it was a nap. It was a phone call, but you have to go get it. Yeah. Now they deliver it to your home. Oh, guess what? If it's not there within a certain time frame, they comp it. It's free. Domino's does that. 30 minutes or it's free. So, all of that to say, the landscape is changing. The old culture goes along with that. And if you're not keeping pace with that, I pity the fool, as the what was it 18, 18, Mr. T. 18, Mr. T, that's right. He, he, he wouldn't fly, but he pitied the fool. What about this oh, he flew. He, he, under protest. He just had to stab him in the neck, that's right. Did what about the product managers and development teams solve different problems?, let's argue on that one. Like, the, the, where he's probably coming from, again, I can't see the underlying tweets because you know. Because Apparently X is not going to give it to me. We don't have time for these zingers like we know we're trying to move. I think what the implication here is product managers solve the what and why development teams solve the how he's drawing a delineation between product management, not product owner, product management and development teams. I think that's where he's going with this statement. He is clearly right. But I actually vehemently disagree with this because at the end of the day, talk to your customer and say, we're solving the what with this and the how with this ain't gonna fly. They want a solution for what their need is, right? So get it together, right? They don't care the what the how and you know, they tell you what their need is. I understand what you're saying, but I, I, I put that back on product management. If you have a product manager. Who thinks in terms of solutions, for example, they don't think in terms of problems and they bring the development team constantly. I need you to build this solution or this solution. Maybe it's not fair to pin it on the product manager. I kind of think it is, but maybe it's not fair to pin it on the product manager. Maybe it's your sales people who are demanding the solution and the product manager is just being a pass through to the development team. I certainly seen that many times, but also. There is fault with the product manager in that instance because it they are the gatekeeper to the business Back to the development team in that I understand what you're saying Yeah, but I like I'm I'm I'm casting I'm casting fault on multiple people in this I'm writing tickets left and right in this equation Yeah, Jira is falling out. So I know it definitely I'm writing parking tickets. I'm telling cars right now. I Agree, I agree. First of all that You know, your assertion about the product managers. So, so the thing about this is the product managers are doing what they think is right. But how do they know what's right? Bring the customer in, bring them in, bring them into the discussions and say, what are we trying to solve for you, right? I'm a product person. I can, I can talk about the attributes, the features, blah, blah, blah of a product, right? And the delivery timeframe, whatever you want to talk about. Here are the development teams. They can talk about the how, but chances are you only care about the how. Like, I'm, I'm, I understand where you're going. But the way I interpret it is exactly. I could read the very next. I could read. The funny thing is I could read the very next paragraph and his very next paragraph might completely undermine what I'm about to say. But what, what I think he's saying is product managers, the developers, if you walk over to the developer and you say. I listened to the the, the Lenny's podcast recently and he had a, he had somebody on who said, I asked three people on the development team what they were doing this sprint and one of them told me, I'm putting bricks into this wall and the other one told me I'm building a wall and the last one told me I'm, I'm, I'm, I'm building a Church or cathedral or something like that. And you ask the product manager and you say, what is your team doing this sprint? And the product manager says, we're building this giant cathedral. So like, obviously. Everyone has a different picture of the vision like that. the end vision that the whole team is driving to and you need to drive towards that vision. That's your job. Your job is leading the team towards that vision. The team's job is to take it one brick at a time to build a cathedral and solve the problems as they're putting the bricks down. Oh crap. How do I put a brick where a window is supposed to be? Where do I even get windows from? Who do I buy windows from? Like the development team's job it's to build a cathedral, but it's to do it brick by brick. The job they're doing is much more granular than the product manager in this, in this aspect. Now, if you're gonna, if you're gonna crowbar product manager, product owner apart, then there might be a little more quibbling in here. A bit more bones of contention. First of all, I agree with what you're saying. However, look at that first one, right? Product managers, developers to solve different problems. Developers, think about their skill sets. They're wired to solve the technical issues, right? Sure. They're wired to look at something as a problem statement. And come up with what they believe is a solution statement. That's how they're wired. How do I know? I used to be a developer, right? So I have put up Hello World in more languages than most people have. Here's what I tell you. Did I know why I'm putting on Hello World? No. Because that's what you do, right? So that's an, that, I know it's trivial, but it's an example. As a developer, you're focused on the technical solution. To meet a need that is a technical need as a product person, you have to have the purview of why that technical need exists in the bigger picture, right? And the bigger picture isn't just about your provider org. It's about the consuming org, your customers, right? Why do they need what they need? But then also on the side almost like a margin, you know on a notebook if you know what the customer needs Why are they coming to you? They have sources they have alternatives, right? Why are they coming to you? He said so he says motivated development teams are the scarcest commodity in the universe. Well, like between that and and saying Motivated development teams are a completely renewable resource or where are you in that scale? I'll tell you exactly where he's coming from that. I believe he's coming from and then i'll tell you where i'm coming from He's saying motivated development teams are the scarcest Resources meaning it's very hard to find technical people that understand the why behind what they're doing. Oh, okay I'm with you. That's what he's saying. I'm with you on that There are a lot of technical people that know how to do things, right? They can give you 10 different ways to do something but why yeah So that's great, but that's where that first point stops for me, where it leaves off is like, what are we trying to solve? Right. And that's where product comes in. You can do all of these things. You're come up with the best toasters ever. Right. But is there a need for that? Because your toaster takes eight minutes to toast a slice of bread, man. I do love toast. I do. Toast is great. You know, so. Maybe there is no market for something that takes 18 minutes to slice, you know, a slice of toast that they can make out of a, I don't know, whatever. You can put avocado on it and it makes avocado toast. Now, you could say, oh, there's added value there. So anyway, that's really what I think he's arguing about. All right. But product and dev teams are not... Two different sides of two different coins. All right, let's move on to the next part of his article. He says, imagine that we're I don't know if this is going to be relevant, but I'm going to read it for the purposes of the podcast. And if I cut it out, then I cut it out. Imagine that we're at a medium slash large e commerce company with 90 plus developers and mission critical backend infrastructure. There's a lot of hyphens in that sentence. We formed a dedicated infrastructure development team to look. Buyer profiles, such as name, address, PII, order history, payment information, marketing preferences, and buyer analytics, such as transaction logging. I almost said lodging, transact, transaction, transaction, lodging. I don't know why that's so funny. Engagement stats, demographics, lifetime value, campaign response rates, etc. The team's overall goal is to streamline and centerize buyer information, especially for scalability and consistent reporting and privacy management. Our direct customers, I don't know why that's in quotes, are other product development groups responsible for shopping carts, order statuses, is statuses. Status? Order status? Shouldn't that be statuses? It should be. Anyway, recommendation engines marketing campaigns, and legal compliance. Inevitably, most of the following will arise. Now, I'm not going to read every single one of these. No, please. But he's saying, so we're an infrastructure team taking care of the back end of all this, all this. Which I would argue that some of this is not really back end work. However, I understand what he's saying. We're a back end platform team. We're just building the framework that the other teams hook into. Right. And he says some of the conflicts will be Oh, some, I'm sorry, some, some of the following will arise and those are conflicts among internal consuming groups about priorities, where the infrastructure boundaries are, like who makes rest services, you could all say environment, stuff like that, right? What are common end users slash need, want, need slash want executive interrupts, what executives think are important alignment on broader strategy, context and economic analysis. Supporting multi team initiatives. Let me start back from the top of the list of what he says are problems conflicts among internal consuming groups, so if you're if you're providing a platform to a Community of developers. Obviously that community of developers will look at what they're doing from your platform and demand different things and all say they're priority one. So there's some stakeholder management in here. I want to really move quickly over this one because this is the basics. Like someone's got to do stakeholder management. If you don't have a, the point of his article is if you don't have a product manager, now you're development lead, development team, whatever. He's going to have to sort of invent a system. So it comes, come up with some kind of, democratized process, ask who they work for. they're going to have a proxy for a product manager and their normal processes processes to do prioritization. That's what his first bullet points about. No doubt. And so He's talking about internal customers here, right? That's what I see here. Internal customers, okay, fine. You're gonna have, and he says that in his first bullet point. Conflicts among internal consuming groups, right? At the end of the day, who's paying for your product, your outcomes? Who's paying for that? Is it internal people that are just doing like, you know, cross charges and all that stuff? Okay. Or is it the actual end customer? If it's the end customer, it doesn't matter how many people it touches before it gets to them, right? So, decide that first. You know, and then move from there. So yeah, that first bullet for me is pretty straightforward. Conflict among internal consuming groups. You could have 5, you could have 50. But who's paying for it? Yeah, let's move to the second one. So his second one is where is the boundary of the infrastructure? So what do you own and what everyone else owns? Like I was in I was in a program one time where everybody contributed API endpoints and boy, it was chaos. It was chaos because API endpoints themselves don't talk to other API endpoints. You have to have services that do that or programs that do that. But if you want to do something that another API endpoint does already, but you just want to extend it a little bit. Like are you allowed to do that on somebody else's code, or should you just go to that team and ask for something on their road map? Like, you know, I mean, there's all kinds of the borders are very murky in a, in a shared, basically a shared back, one, one, one backlog. One product, multiple teams. That basically, if you can solve multiple teams in one backlog, you can solve this problem of not knowing where the boundaries are. I think the bottom line, I agree, right? What you're just saying. The bottom line of all this is, communicate with the other team and say, here's what we're doing. So to the point about where's the infrastructure boundary, we're delivering this. What are you doing? Oh, I see there's a gap here. Either you address it, we address it, or we jointly address it. You know, the other thing, I agree with everything you're saying. But, I will tell you, not having clear metrics makes this... A lot murkier when you when you don't and not not clear metrics. And also, the other thing I've dealt with on teams on development teams I've been part of is certain members of the team have access to all the logs, metrics, performance monitoring, stuff like that. And certain members do not. So it's very difficult to understand where the delineation where the edge of the system is when you can't see in all the logs. I don't know why anyone would try to hide. The, the infrastructure from you, other than the fact of like, maybe they're playing some games with, yeah, right. They're trying to hide some stuff on purpose. Right. So there's two, two parts of the play in the game space, right? One is pride. This is what we did. It's our, sure, sure, sure. Get out of here. Right. And then the other part is, oh. So, okay, if we reveal, sorry, if we reveal what we're doing, right, then it's going to reveal our vulnerabilities and we don't want to do that, right? So that's the, that's the been there. Shame game. Yeah. Been there, done that. It's like, Oh, I will be ashamed if we just, so all of this, nothing's going to improve in that. Nothing is going to improve. This is where the us and them ism kicks in, right? So be, be aware of that. So his, his next category in here is what, what our common end users need slash want versus how each application team interprets their users needs. So an example he gives is the shopping cart team wants fewer number of required fields for payment to lead to faster checkout, while the recommendation team wants multiple payment options. Per purchase this is kind of a, I see this as a weakness in the product side of the organization. He even, he even says, he even says at the end of this, he, politics as architecture points out. Yeah, that's really doesn't, architecture is the tail wagging the politics at the end of the day. I also don't think of this as a platform. I don't think this is flat. Like I think a platform like platform team, like the title of the article here that we're talking about. Is, do infrastructure teams need product management? I don't think of, oh, I need more items in my cart, or I need my cart to handle this, or I need a fast checkout button. I don't think that this is infa the infrastructure of the website, I think slivers, slivers of value. Right? I think that this is like, there should be a team developing this kind of stuff. I agree. Absolutely. Yeah. So may like, maybe this is not a great example, but the, the point the, I think the point of this item is, If what I think would be a good one, like an NFR that could be a good example of this is when I hit the checkout button after everything's been purchased, I don't want the spinner to spin for five seconds right now we've timed it in production and we know it spins for five seconds. I want that button to be nearly instant. I want the button. I don't want there to be any spin time. Maybe a half a second is appropriate a spin time and that's it. And now go to my platform team saying your platform processing is too slow. You need to drop everything you're doing and make this the highest priority in your platform of making the processing faster. And then you might take that as an infrastructure team and say, well, well, we integrate with these other vendors and we're processing your payment. We're doing all this in one step. And yes, we could split it up, but then we have to push things. All onto everybody else's roadmap to help us refactor. And it's a huge to refactor. I've, I did this in the world of mobile apps. It's huge to try to get that number down from three seconds to one second. It seems trivial, massive, but it ends up being massive. No. So from 20 to three seconds is easier than three to one second, right? Yeah. Right, right. Yeah, I can agree with that. Yeah. So one of the things that I know he ends with, you know, the smells is almost like a politics as architecture. One of the things that I think we have to really kind of bear in mind here is but I, I agree with he said he, he, where he says it smells like politics. over architecture. I do agree with that. But what's the difference between some VP saying this process takes too long and you, you doing a poll and the majority of your users coming back and saying this process takes too long. Like sometimes, sometimes, especially with A to B tests, like a, a B tests. Sometimes I think like I don't necessarily need to run a test. If my product intuition is already telling me there's a problem and I can investigate metrics to see that the majority of users between the time they click that button and between the time that the transaction says successful in the database. There is, is a three to five second gap. So, I can use those metrics just to say, generally, users have to wait three to five seconds. And, is three to five seconds too much for a general user? Now I've got a good question I can go investigate, and I can survey, and I can do some tests. That is true. However, if we have other things that we're trying to do that, that are based on processing time. For this example, it's, is it politics? Maybe it is. Maybe it's completely legitimate to say, Brian, it's just politics. So many executives, so many different departments, so many different teams are saying They perceive a problem. So you must fix a problem because of the perception. Listen, that might be true that it is politics that led us to this fix. That doesn't mean, I'm about to say something I don't believe in my technical heart of hearts, but I certainly believe in my product management, heart of hearts, the perception becoming reality and forcing you to fix it. That is a real problem. At that point, once your perception sets into reality, politics aside, it doesn't matter if it's policies or not. Now you have to fix it. A hundred percent. Right. So maybe more so customers vote with, yeah, it could be more, it could be thousands of customers vote with their dollars., engage a subset of your customers, you know how to pick the ones that you want as a pilot group, right? And then get them, not only just at the end of it saying, well, here's what we delivered and go test this stuff out. Yeah. Get them in ahead of time and say we're planning this Right. Here's what we're planning to achieve. These are the slas slrs, whatever that we're planning to meet. Yeah, are they good enough for you? Guess what? If they're not, they'll tell you. You could survey your customers. You could add, you could do something in app. You could do something in app. In the scenario I just described, which was a place that I actually worked, you could tell the time between the, the, in the mobile app, the submission of the, the submission of the thing and the processing of the thing, of the transaction. You could tell the difference. So you could pull in SQL every single transaction. So you can see outliers. You could throw out, if you saw like one transaction took. Three minutes. You can be like, Oh, something really wrong. What happened there? Connections stopped and they reestablished. Exactly. Maybe they went out of wifi and came back in. Let me throw that out. Let me throw that out. So you can throw out outliers so that you can do some stuff in the metrics. However you should be able to get real data on this before you let politics politics aside. You might have to respond to politics. This might take away from the from this discussion. Before we move in because again, we've dwelled in this too long. Yep. Politics will become a real thing And force you, and force your hand in prioritization. That is 100 percent true. No problem with that. You really shouldn't be too aggravated with that. That just means you couldn't get ahead of it fast enough. Right. And expect that it's gonna happen. Don't be surprised when it happens. Because it's a given. But that does not, that is not an excuse to not also walk through the normal process of having your metrics on the issue. Get your metrics. If you, if you don't have in app metrics, ask your developers, prioritize it, get the metrics, let them help you. It'd be better if you can pull them yourself, obviously, then you don't have to impact the development team. But that that's, I feel you can get ahead of this one. If you've got some metrics on your side, all right. Executive interrupts. Quite honestly, Executive Interrupts kind of goes along with the previous one that we kind of talked about. But also, but also, Executive Interrupts is also the the sales coming to you. Be like, hey, we, this customer is going to renew if we just add this one new feature. Or this customer will sign the contract if we add this. That's this too. He says, what if we use machine learning to suggest payment methods based on ship to address? Right. I mean, that's a, it's very meta, like I would, I'd be amazed if an executive actually came to me and said, well, but you know, here's the reality of what an executive come to you with this executive interrupt. Well, every other competitor has AI in their solutions. How come we aren't doing anything with AI? Or the other side of it, which I like to call ego stroking. They will come to your tech lead and say, Hey, awesome job the last 15 sprints or whatever it is, right? To your point, our competitors are doing this. I know you guys can do better. I know you have it in you. You guys are so smart, right? You can do this in two sprints. I know you can, right? Make it happen. And then they walk away. That's true. Yeah. Right. I have seen this personally, believe it or not way too often, right? That this is when good tech leads come to you and say, What just happened here? A whole world got changed, right? Bad tech leads on your end go, yes, sir. Would you be wanting to shine your shoes? Well, they can't, I mean, honestly, they, they, they can't help themselves because that's, they feel that's the way that they got there. So they're not going to, you know, they're not going to go against the company, but , I remember at a company I was at one time pointing out. The dips and spikes in velocity. And I had been with the company for long enough to track the major things that happened. I was a product manager at the company. I was not a scrum master. It was a product manager at the company. And. Each sprint, I wrote down what the sprint goal was whether the company or whether the team did or did not accomplish the sprint goal. And also I wrote down major things that were happening in the company during the sprint. So I wrote down like, oh, you know, this customer complained a lot or this executive was demanding this feature or whatever. It was almost like things that we were doing, things that were taking a lot of refinement time. While the sprint was also going on, it was like notes of what was happening in the environment during the sprint. And I remember showing it to the CEO one time when we did a program retrospective. Because the company wasn't that big. We did a program retrospective with the senior leadership team. And reps from the development teams. So it was like a, you know, leadership plus development retrospective. And one of the things I pointed out in the retrospective was I said this is these, I have notes of where you guys have pushed the team in the last quarter. And it was funny because when they pushed the team, the velocity went up and the velocity going up, like there was no, what the team was doing was working extra hours and working nights and weekends, that kind of stuff. Cause we had also had access to the system where the team logged their hours. Yeah. Okay. So we had full transparency in that team, which is actually good because I could show them the velocity went up, not because the team was over inflating, but because the team was working 60 hours instead of 42 or whatever. Yeah, right. And I showed them this is where you. Push the team and this is where they delivered and this is the next sprint and because there was, there was dips and spikes in the velocity. Always, right? Dips and spikes. And what would happen is the, the, the dips would immediately follow the spikes. And I told the executives, I said you understand following this data we're like correlation is not causation. Is that the thing? Correlation is not causation? Yeah, yeah, yeah. I was like, except in this case. It completely is. I was like, this is where you push the team and they worked extra and this next sprint after that when the deadline was over is where they all were burnt out and had to pull it back to return to their baseline and these next two sprints after that was the baseline where if you actually want to know how long it's going to take, that's what you should do. So I was like, you should either start understanding how baselines work. Yeah. And start planning to the baseline, so when you know something big is coming up, bring it up two, three sprints ahead of time, so the team can start baking it into the work and deliver it, rather than stressing the team out and then having to suffer for a sprint and a half after that, while your velocity dips because you just burned your whole team, this executive interrupt thing is exactly that same category is, Learn your team, work with your product people, ask them for, I mean, I almost want to say ask them for these stats so that you know when you're affecting or not, but just have a conversation. Hey, am I putting too much on the team? Have a one on one. Am I putting too much on the team? Am I pushing too hard? Let me know. Okay, the trade off is me saying have a one on one and ask them is they may not, they may be like the development. Oh yeah, we got this. We're working on Sunday as well. No problem, guy. Everything's great. That might be the trade off. They're not open to say how they really feel. Yeah, I agree. So, first of all, they're not open, especially if they're outsourced to different parts of the world. Because, you know, they're not, it's not in their culture to argue against having to work overtime. And I'm not talking about a few hours. I'm talking about substantial, significant overtime hours, right? So once so it's a double edged sword here. Here's what, here's why I say that when you have a team in Manila or India or wherever, and you ask them, you say, listen, leadership is really looking for this by the, by this date. And it'd be great if you could achieve that. Most of these team members don't work for your org. They work for some consulting org and the culture there is they do what the client says. And if they say, Oh, you need to work extra 20 hours, do it. If it turns out to be 25, do it, but build 20 anyway. Yeah. Right. So they do it right. I've seen this many, many times in my career and. These teams to their credit, they, they do it, they burn the candle at both ends because they're not the ones that say, you know, cause we worked last night and I, yeah, I won't be at the daily standard, move the hours around. So they burn the candle at both ends. So here's what happens long term or medium term is you meet to those demands that management's asking for, but long term what happens is it. It behooves this kind of expectation that management says, Well, you know, you just have to ask them. They'll just do it, right? So just ask them again. And then we ask them again. And we ask them again. What are they going to do? Just ask them. That's terrible, because I actually got to the point where I, you know, I connected with some of these people on a one on one basis, and I understand their motivation. That was a few years ago, where they had, it was long enough ago, let's just say that They wanted to stay with their their employer, you know, that had prestigious, you know, contracts or whatever, of course, fast forwarded today. That's not the case here. If you do that today, they're just going to say, no, I value my life more and they'll be gone because they can get a job like that today. That wasn't the case. I want to say eight years ago, even so people who are doing this. Please be aware. It's you're rolling a dice here, right? If it lands in your favor, you can talk to your management and say look what I got these people to do I squeezed them hard and we made it right. Can I have my bonus now? Right, but if it goes the other way It can be very, very bad because, you know, it's, you're gonna start off again with a new team. Yeah, right. So that is something that's reasonably new now, so be aware of that. I would also be careful of listening for that disdain when it comes to, you know, oh, these offshore developers are totally bilking me of all. Like, you can hear that disdain pretty quickly to understand that. And if you hear it, You should raise a flag to say, I think there's a problem here. Like it doesn't sound like we're treating these employees with empathy and we're treating them like they, we want them to integrate as part of our culture. It sounds like we're treating them adversarially. Is that a real word? I don't really know. But, but, but his next, Oh, got to ring out them resources. I mean, his, his next got to ring out them, them washcloths. His next point leads straight into what we were talking about, which is alignment with a broader strategy. Yeah. First of all, this implies that you have a strategy.. . Oh, what a concept. Oh, yeah, yeah. See our multiple, many, many, many of our previous podcasts on this one. But you have a strategy. Your product, people know what that strategy is, and you are tied into it. Obviously, he's saying here, he's saying here in the article is like, do you need. A product manager on an infrastructure only team. Well, if your team connects to strategy, then I think of saying like, well, we can have our tech lead, our tech lead should understand strategy. Maybe they could sit in. Occasionally on a product meeting and talk about where their team and products could tie into the strategies that Right that I feel like we've we've hit the first we've hit the first real black and white Item that he's he should like honestly if I wrote this article, I would lead with this one to say me too How is your team and the products that they provide their platform team, right? So they provide the platform that everyone else builds on how is your team and the platform they provide? tie into the broader business strategies and, and in his article, global business strategies, business strategies that my entire business is engaged in. I mean, that's a, first of all, first of all, and I will tell you again, as a product manager in this conversation, this is a full time job answering just what he is, his little two sentence, three sentence, three sentence. Yeah, yeah, yeah, this is a full time job. Somebody who just goes around to all the development teams and says, what are you about to do? What are you about to do? What are you about to do? We need to adjust our roadmap to make sure that we have bandwidth. We have the runway for you to take off because you keep building these bigger and bigger and bigger planes. So I have to keep building a bigger and bigger, bigger runway. With more and more and more parking spots. That's basically what you're doing on a platform team. So how do you even know that you're doing that? You're running around these other teams and you're gathering information and you're making concessions and you're trying to line their priorities up while you line your team's priorities up. And quite honestly I could end the podcast just talking about this one. Like, if nobody is sold by now that you need a product manager on your development team and it's not a part time job to play the role.. Sure, you're going to do this part time? If you can do this part time, Congratulations. You should have a podcast. Actually, come on this podcast. You should come on this podcast and help us. Because we don't know how to do this part time. So this is one of the things where people just say, you know, Oh, I'm going to spin a coin and it doesn't matter where it lands. I'm just going to call it one side. The product, product is usually more customer focused than development is. But at the same time, product cannot deliver to the business, the customers, unless development delivers too. It's so difficult. The Romans had a concept here, right? The Romans were very, very successful. Alexander the Great, he was so successful at basically steamrolling so many countries. How do you think he did that? He did that with two things. One is, he told his army where they're going, why they're going there, right? And the second thing he told his generals is what's next? Once we get there... We're gonna win and once we win that we're gonna go to the other place. We're gonna win. That was his thing So the generals were always aware of not only why they're there, right? But where are they going next? Guys, this is the product roadmap. Yeah, right So without that what they would have said is we're going into this place where there's 8, 000 of us We're going through ravines and whatnot and there's 30, 000 of the enemy What do you think the general will tell their soldiers? There's 8, 000 of us. There's 30, 000 of them. Not even a fair game. Right. So that didn't happen because, because the leader here, the product, right? He said, we're going to get this. And here's how we're going to get this. Our strategy is different, right? We're going to do XYZ. There were many strategies that he deployed. And you know, major generals now are now learning, or they have been learning from. This is goes back centuries, but they learn about things like the pincher movement, people learn about the tactics my whole diatribe here is to say your Individual development team members not just need to know what they need to do. If you stop in there, you're failing.. They need to know why they need to know the what, the why. And then they will figure out that. Well, it's not just the individual team members. Like one of his points here is supporting multi team initiatives. He says a big efforts require collaboration and shared priorities across several teams. The product managers on the teams do a lot of horse trading, which is a great term by the way, horse trading, and joint business justification to get things done. Complex decision making basically. And if that is done, Without the representation of the infrastructure team, there's a lot of assumptions that happen. And you and I both know , it's very difficult to do accurate estimation on assumptions. You kind of need to know, you know, and if you're leaving this, if you're leaving this team I guess piece, piece of the equation, I don't, I don't know, but like if you're leaving this whole section out and just assuming, like I don't know, that's like building your house on a mountain of sand. That's, that's, that's, it doesn't make me feel good. It would make me feel better if someone had a handle On, I mean, you're already going into it with the, with the, the military analogy of, of, which we also talked about before of what is the goal? Well, the goal is to build a cathedral. Right. That's the vision. We're going to end up building a cathedral. Well. I mean, how are we going to do that? I mean, I got this, I only got a couple of bricks that I see in front of me. Don't pay attention to all the bricks. Pay attention to where we're going and make your goals tied into, you know, building a giant cathedral. Yes. And Hey, no, well, one of the things that, yes, I agree. The bigger picture is often lacking, unfortunately, in large, complex, especially in matrix orgs, who people are in it for themselves, right? This is where you say, well, if I do this, I'll get my bonus or priority, whatever it is, or both. If you're doing that, great. However, your organization is not succeeding as an org. So you're sitting there going. Yeah, that person that I used to deal with as a product owner is now the product manager or the lead product manager or whatever. They're just going up and up and up but our customers are leaving us in droves. Right? How do you reconcile that? And if you're not reconciling that, think about it. Right? Because you're paid. You're paid because your customers are paying you and if they're not paying you not paid. I think the biggest difficulty here is having having that economic view Yes, and this is like gonna sound Terrible. Because those people that are following safe are going to, Oh, you're taking the economic, you know, I just gave this advice very recently to a team that was not ready to hear it. So it wasn't good advice because the team wasn't right here, but I heard it, but I told, I told, I gave them the old Mike Miller. I said, teams that do not have economic information, just like teams that don't have information about the platform roadmap or whatever. Like they cannot make. economic decisions. Teams that do not have economic information cannot make economic decisions. Say that one more time. Listen carefully. I'm going to say, I'm going to say economic this time because I'm American. Yeah. If all your decisions are made from non economic viewpoints. I mean, , how many decisions can you make until you make the wrong decision based on economic information and conditions? Like I said, Milton would be proud. I'm going to assume it's going to be very quickly that you're going to make a bad decision. Absolutely. You know, and, and your bad decision is going to get called out By the people who directly make decisions and can shut you down with a snap of a finger. Like, as opposed to all this, quote, horse trading that we were talking about before. No, the economic people in your company are going to be able to stop what you're doing. Absolutely. Listen, it comes faster than a tsunami, right? This is why we always say on this podcast, keep that resume up to date. Oh, is that what we say? I thought we always say on the podcast, boop, boop, boop, boop, boop, boop, boop. No, he wraps the article with something that you disagree with earlier, but I'm going to read the whole thing in context so he says, Development teams and their product managers solve adjacent but different problems. If a work stream is important enough to merit its own development team, then it's important enough to assign a product manager. Together we solve for what needs doing and how to gracefully get it done. It's hard to argue against the language here. In, in practice, what I've seen is Yeah, people are playing like they're not really treating, you know, those people that are in the infrastructure side of things with the same relevance. Same, I don't want to use the P word, prioritization, but the same importance, right? I understand what you're saying, yeah, I understand. They're saying, well, look, the teams have developed it it's done, right? We've tested it, it's good. So just put it out there. But the poor people that are putting it out there are faced with a dichotomy. And the dichotomy is this. They, first of all, you have to recognize there's only a few of them. Yeah, because these people have specialist skill sets. I'm specifically talking about the deployment, the dev ops guys here. And so there's fewer number. And if you're a large, large ish company organization, that's probably a separate entity somewhere. So you have to back still borrow their time, right? So you say to them, I want this thing to go into. Production by the state and they go. Yeah, thank you. But we have 15 things ahead of you. So you have to wait. And the product manager says to you. Why can't you get it done again? I'm going back to the podcast, which is your scrum master. And the product person says what we're done, right? You say we're done. Yeah, we're done. Why can't we get into production? Because We're backed up on DevOps. I can't tell you how many times I've seen that. So DevOps people say, yeah, listen, don't blame us. Give us more people. You can't get more people because these are specialist skill sets. So you go around full circle and you say, okay, what happens here? You have 15 things that need to go to production. Who is the loudest screaming voice here? Yeah. But wouldn't, Wouldn't the fact that you have a bunch of specialist skill sets on a team. Wouldn't it be even more important for you to have a product manager so that those specialists don't get tied up in Doing this other role part time, the takeaway his of his article is it's sort of a weak take it's sort of a weak call to action like the the call to action I would put in here is the people that work on the platform team that that that and the funding that goes into the platform team is And the funding that goes into features that rely on the platform team doing like hitting all the marks is so expensive that if you're going to skimp on one team, it should not be this platform team. This platform team should have a scrum master product manager potentially help for the some people have product operations to help product managers. I don't know if you saw that that their toolbox should be the most complicated full toolbox out of every development team as opposed to what, what you normally see, which is these teams usually are kind of devoid of all these additional skill sets again, probably because they're so expensive. I couldn't agree more. However, the reality of the situation is this. I'll go back to what I said earlier, right? You don't have enough people with those DevOps skill sets, but all of these are anti patterns. Here's what I mean by this. Why are you relying on an external team to deploy the fruits of your labor into production? Right? So you go to a bakery. Just bring it right down to what people can relate to. Because I like to do that. I like donuts. I like donuts too. So you go to a bakery, right? And, and you go, ah, I want this. They go, it's freshly baked. That's why I come here. I like the freshly baked stuff. Anyway, it's baked. It's just sitting on that tray over there. We'll be with you in about 40 minutes. Maybe 50. You know, when something can be picked up off of that stack of trays and be put into a bag and we'll give it to you. And you're like, okay. You wait and you wait. By the time you get it, it ain't... No longer warm. So the whole point of you going to the bakery to get something freshly baked and warm is already compromised, right? And this is exactly what happens with organizations that have this structure of DevOps teams. So, what is the real solution? The real solution is Perhaps not that palatable for most people, but it is still the real solution, which is empower somebody on your team to put things into production. Why not? After all, you empower them to create the thing to begin with, right? So empower them to say when it's ready. Sure, put the guardrails in place, right? UAT passed, UAT this and that, customer accepted. Whatever it is, it doesn't matter. Go through all of that. But then, before you chuck it over the wall at this team that there's not enough people in and all of that stuff and you wait. Your team says we got the skill sets to do this Now as a team with your product people you get together and say there are five things that we've done in this sprint Do we put all five in production? Do we put two which two do we put one? That's where you need to be because when you put that into production Guess what? You've done it in two weeks. You've done it in a sprint Instead of waiting for some external party DevOps team to do this. What I've seen in in my experience is the DevOps team is always under resourced on. They don't have enough people and they're being hit by multiple angles, right? So senior stakeholders are gone. Hey, we have this customer screaming. Put that stuff in and they go. Well, that's. Only partially ready, but we got these other 15 things that are ready, you know, not, don't care about that. And then another partner comes in, sponsor, and they go, yeah, okay, whatever, right? But I'm working with Ford or GM or whatever. And if you put this feature in, we stand again, XYZ. So I don't blame the DevOps team as such, I'm just saying, bring them into the fold. Don't make them a separate, like a distant cousin. That is where the problems start. Well, this is a, it's been a podcast. Yeah, it has. And this is how you get things done gracefully. I mean that like, I think like my takeaway from this podcast is it's, it's even more like we had a few points, especially that one where we talked about earlier. Especially the one we talked about with aligning up with the strategies. Like it's very difficult to do that when you don't have a product manager. I don't, I guess it's not impossible, but I mean, much like continually evolving your team and making sure that, you know, somebody is accountable for continuous improvement. I don't think it gets done without assigning it to a person. And I just don't, I, when I went into this article I sort of agreed with it. Coming out of the other end of the article, I sort of even more agree with it now where like, it's like, just put this, get a product person you probably have somebody on your team already who has the chops to be able to do product manager, just promote them, change their role, you know, even if they're still doing code 25 percent of the time and they do product 75 percent of the time that that's better than nothing. Right? They're not playing the role like they're playing around like they're playing with some Legos or whatever like they're not playing that you're making strategy to their full time job. You're transitioning into that role. Everyone knows they used to be a developer. That's fine. But the point, the point of the article here is your problem should have a product manager, even on infrastructure teams. It's probably useful, it's probably helpful, you probably should do it. So if you learn nothing else from this podcast, just, just, just, just throw some money at a product manager and have him, have him solve this stuff for you. You're not looking for some perfection state, right? That's right. You're looking for something that works for you, and then just evolve that going forward. That's right. That, that's really the bottom line. Start small and work your way up from there. Absolutely. And let us know what you think of this this topic. And what are the topics you'd like us to talk about. And like and subscribe in the button below. Oh. Or whatever, smash that button. But don't smash it because it's your laptop. Or desktop. Yes, yes. And if you do don't, don't send us the bill. Don't send us the bill. We can't, yeah, we, there's no money. No. That backlog is very steep. It's true.