AA176 - Arguing on Moving Away from Durable Teams toward Shared Services

welcome to the Arguing Agile Podcast, where Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando argue about product management, leadership, and business agility, so you don't have to. first of all, welcome back to arguing agile. If you're a product manager, if you're in the agile community, you're on development teams, really, if you work in software development at all, at some point you will run across this conflict of, we need a person to do this specific role on our team. And then management will say, we should have somebody like that. In fact, why don't we make them available to all the teams? And I'll quote, control the quote resources. well, wait a minute. Marty Cagan and Inspired and all these books say and then we just went through the whole thing about Transform talking about like you really need durable teams What about all that and they will say well calm down. Like slow down kid. Yeah, don't be a troublemaker. Oh, yeah Yeah, get back in your corner Well, the adults will take it from here and they'll then they'll push you Away from the Marty Cagan durable teams and pushing more towards like a shared services. One minute you have a durable team, and then the next minute you gotta pass the front end work to the front end team and the front end team can't start until the backend team stop, and then you gotta get your sign off from the DBA that your store procedures are all optimized and everything, and you've got to throw it over the fence to the QA department. And now suddenly we're all. Yeah, this is exactly where the handoff circus will ensue. Right? But this also applies to other domains, right? This applies to UX, DevOps testers, even you get testers seconded to your team from some shared services, team of testers. So this concept of shared services is certainly not new. And in this podcast today, we're going to delve deeper into the pros and cons of it, you'll recognize some of the behaviors that we will characterize in this podcast. So this podcast is specifically about when you're lobbying for durable teams, cross functional have all the skills that the team needs to do the job on the team, but share between the team members and you're lobbying for that, and the business is saying, yeah, yeah. We kind of know better how to do things. You know, forget that Marty Cagan guy, what has he ever done? Like this podcast will arm you to understand the typical pushback that we have heard in these categories. And hopefully you'll be able to gauge the depth of the quicksand here. You notice how people that push back and say, we know better how to do this right. Take that with a ton of salt, not a grain, a ton of salt. If they've never done it and you're listening to their way of doing it, you already know that things aren't necessarily going to work out. But we'll see by the end of this podcast where you end up. these arguments are very real and I may or may not have. Been on the receiving end of every single one of them Different parts you had your bet but I can tell you I have I've got the scars to prove it too on my back all right, let's get into this then. Point number one, You'll never lobby for having these durable teams and this is all the skill Distributed to the teams and whatnot because That's not what you have in the traditional work structure. That's right. We're starting a number one point. Number one with like, that's not how I learned it. That's not what I learned in MBA class. That's not what any of my other giant organizations did. So we may as well, we may as well open with our ACE of spades here, organizational structure dictates the way you work, right. Those of you in the back, believe me. That is exactly what happens. You're not at liberty to try and shuffle that up because you've got a whole drove of people that are going to say this is the way we should work because that's what we learned, like you said, in business school, this is how we grew up working and it must be right. Not that it worked right before but still, right? So take that for what it is. Org structure is not something you're going to be able to change overnight. Right? You'll have a better chance of fighting City Hall, but I'm silos, the pyramid or org chart you know the hierarchical org chart, whatever you want to say, we'll call it like, Oh boy. it's too early in the podcast. Om for surprise. It's Taylorism. I feel we need a banner and we need. Sound whenever it surprises Taylor ism happens on the podcast, but surprise. I, yeah, I agree with that. I wonder what music Taylor would like. we should definitely do that little flying banner. Unfortunately that is real though. if you work for a company that's bigger than 50 people, you're already suffering the tyranny of the org structure. And there are very few. Orgs that are 50 plus that have optimized the structure for success. I was going to say responded to, yeah, even, even responded to respond to that. It's just because people come from backgrounds that aren't like. You know, holacracy or anywhere near that. Not I'm not saying holacracy is a perfect. They're much better than what we already know. Right? So unfortunately, if you're in that kind of an environment, you are going to experience teams that are even if they don't call them shared services. It's basically you have to reach across the aisle and borrow people for your teams. Right? And when you lobby for that, you may or may not get the best person. You may not, you may or may not get the same person again. So you may have somebody for a sprint or two, and then they go away, and then whoever's available gets, they get seconded to you. I'm not sleighting the skill sets. These people have, what I'm saying is changing so frequently, right? It's just going back to the old context, switching thing, changing so frequently is not good for your teams because they're going to have to explain to the new person, everything they explained to the other person that left just a sprint ago So sometimes you get lucky and then, and you get told. Yeah, we're we're allocating Bob or Mary to your team and they're going to be with your team until the project ends. That never actually happens. Most projects run over and Bob and Mary have other things to do, so they get pulled out. Well, that's the interesting about Bob and Mary having other things to do is that it smacks of the traditional silos and it smacks of quote resource quote utilization. The two words that Go together so well, like two four letter words is that, I mean, that's what's going on here is that they're trying to say like, well, how many QA team members should I have per developer and per active project? And it can one QA person share across two projects at once. And what's the breaking point. And they're trying to stretch this. As much as possible. and then when somebody quits, all hell breaks loose.'cause they already know, they've already run the numbers and they know they can't stretch across three. But then you have to, until they can backfill a person then everything just falls apart. QA is a good example. I think UX is also a good example because a UX person on your team knows the full context of the customer journey and the experience. And when you have that person switched out for another very capable UX person, You lose the continuity and the team as a whole suffers and the customer suffers in the end, really. So does the organization, because if the customer is suffering, you can bet that the organization is suffering. It used to be that people used to say resource utilization a lot in the old days, right, of evil waterfall management. But lately they've been saying, They pivoted slightly. They say resource optimization. Oh, is that the new hotness? That's the new hot take. That's the new hot take. Resource optimization, spread thinly. Like it says on my you know, ointment. Spread thinly. Thanks for bringing that term to the podcast. I hate it. So let's strip away resource, calling people resources for a second. And just call this what it is. Utilization, like trying to squeeze like a sponge trying to squeeze every bit of possible work out of a person, just like the old consulting, you can take as many vacation hours as you want. As long as you work 40 hours at the end of each week and charges to the client. That's exactly right. Well, like that, that's, this one is utilization. I need to have my people as close to whatever the company, usually finance picks this number we want everyone to be 95 percent utilized. I don't know where they get that from, but 95 percent utilized and you know, go, go managers, make it happen. We're going to hold your feet to the fire or whatever. Although I don't, I can, When I was a manager, I don't ever remember getting pinged for this positive or negative utilization. Most of the time, because I think like the spreadsheets that they get those numbers from a timesheets that they give those numbers from people's in or whatever, who's going to check who goes around and checks everyone's timesheet. the Taylor time manager person. I can't remember what they were called. The time clerk. I think that's what they were. Anyway, the utilization. So I guess if I'm going to be a product manager on the podcast, I represent product management, I'm going to be a product manager. I'm going to push back on this one of like, well, Brian, how do we know that people are not taking advantage of us? And how do we know that they're working the correct amount of hours or whatever. And my response will be, and has been I could care less, I don't care. If you want to make yourself feel good, you can make people put hours against projects or GL codes or whatever. That's just going to be a feel good thing for you in reality. If somebody puts their work three hours on a team and then two hours on another team for a fact, that's a full day already because they had that context switching cost in there, their effectivity goes way down. Yeah, and this has been proven already. that's that is the fact of it. but again, to this manager who thinks that on paper they need to do this consolidation and see that 95 percent of the hours were spent on like I'll give you an example. And we're all developers and we both knock out our hours and I put 40 hours charge to the client done and then you put like 30 hours and then 10 hours of like something else filling out paperwork because you had to go through some mandatory trainings or whatever now the company is going to be looking at you negatively. Or like, because the client's not going to pay for that. Whereas like, what happens if you don't, what happens if you don't pull 40 hours because you had other things you were doing? What what is, why does it matter? It really shouldn't matter, but I've lived in that world where I have to bill a net 40 and then not include in that 40 the hour it took me to do my expenses because I've been on the road a while, or do an internal status report for my company, not my client, because I can't be billing the client for something that my company wants. So it's like, yeah, I mean, you're going to rob Peter to pay Paul at the end of the day. I worked at a company once that had two buildings. The buildings were very close to each other. But with driving and parking and all that kind of stuff, we would take probably half an hour to go from one place to another. they very easily could have said the finance people could have said we know it's a regular part of business to go from site to site during the work day. And we're not trying to say that you do that on your own time, but when you charge your time sheet, we would like that on a separate line item. So we can see how much time we're spending on this. So that we can justify it. Okay. Again, making sure people are working X percentage rather than just like that specific example, I could actually see they're trying to use it for something. They're trying to decide whether they should keep these two sites somehow. That is not , what I'm talking about. usually in this is they have utilization targets. They say, we want our people to. Coding X percent of time. Call centers have metrics like this big time. Basically we want people like sitting in their seat doing their work. For X, they'll, whatever, they'll list the thing. You know, a work center I was at one time was 85 percent was the developer's utilization number. actually doing code and meetings, including the scrum meetings, believe it or not, were counted outside of that that wasn't counted as development. They're like, Oh, that's meeting time. That's not development time. But my pushback, my very long winded pushback to this as a product manager is you're swapping people from task to task in order to seek that, that, that holy number, whatever that number you're trying to hit. is a waste of time and is not generating any value. For sure, I mean it's a paper exercise really, right? At that point. Yes. You know, those people in, in their ivory towers I wanted to say are looking for target measures. We've got our people at 85 percent utilized, right? Or 87 percent utilized. We're doing better than we did last quarter because it was only 85. It's like, That's just such a game, right? It's just internal for the first one thing. Yeah. Does your customer really care that people are 85%? it is a game. It is a game. Yeah, that's, that's why like, this is a waste. It's a game. So we're, we're, we're quote resource utilization, trying to make sure everyone's doing whatever work on these timesheets that they self report on anyway. It's all done in the name of. Cost efficiency. They say, if we have these people that are centralized and you only ask for their services, when you need them, assuming the most ideal scenario, they're immediately available and you ask for them and they can immediately jump on your stuff because delay will beat up the showing cost of delay. we'll really beat up this, the people that are lobbying for this resource utilization when you're a product and you can show financial dollar impact of saying like, every time I asked for a QA person, every time my developers go through the process of getting all this code done, talking to customers, figuring out what they want, now I've got to ask for a QA time and now I've got to wait or UI UX DevOps for deployments is a great one. You know, every time we hit submit we are waiting an average of two days to get our build out there. Our team should be able to click that button it's all done under the banner that somehow it may be more cost efficient to centralize all these resources. when in actuality, I've never seen anyone does this, takes people off of a team and puts them in the ivory tower. I've never seen them have to lobby back to the teams. Why they should continue that practice. I've only ever seen them trying to take people away from the team to fund their ivory tower positions. Yeah. What I have seen is when teams have complained we're waiting to two days on average for DevOps, for example, right. Just to use that as an example. So the reaction from those people that are resource managers has been to take somebody off a project that they're already on and put them on yours regardless of are they the right fit, etc. Now the other project's suffering too, by the way, right? So it's the squeaky voice syndrome and they keep doing that just so that you whittle down that two day to a day and they say, look, we've got a 50 percent improvement. You know, it used to be two days. It's only one and we're striving to zero. And unfortunately the teams I really know it not any better off. They just get a warm body with a pulse. They'll say, but Ohm, what, what if you, what if we dedicate this person to your team and you can't use them 100 percent of the time? what then? You'll have them sitting around and we'll, we'll pay them a full time job, even though they're only working 30 hours a day. 28, 30 hours a week. Cause you can't utilize them full time. Thirty. I'd be very happy with, listen, if you do the math, I mean, it makes sense for them to work on that team only at that utilization rate It makes sense to me because the switching costs alone will take up the rest of the time to 40 easily. Oh, but switching costs are not on their budget. That's right. They're not a GL item either. They're not tracking that stuff. Right. Good grief, right? Also, like I thought I'd point out now we're talking about the cost efficiency. I guess I'm going to keep using, going back to the banner example of QA on the podcast, because again, that's, that's where a lot of these I've interacted with in my career. Boy, if I had a nickel for every time I've heard some, some real ridiculous reasoning, some real breakdance reasoning to try to avoid hiring people if we stagger team a and team B sprints to where when team B is kicking off a new sprint, team a is ending, we can have the same QA person on both teams because QA people just sit around the beginning of the sprint, right? They don't have anything to test while development works. these are more teams cost efficiency that say QA sits around until developers got something to chuck over the wall at them few days into the sprint yeah, you are really not doing that agile at all. Just the mental back flips to get to this cost efficiency. It's, this cost efficiency category thinking , that you know best. Other than the people that are in the code, the people talking to customers, the people generating and finding their way to value, but you know, better and let you handle it somebody who doesn't talk to customers. Who doesn't, maybe doesn't know the business domain wow. Like the arrogance in this category is I almost can't even say here anymore. It might be time to move on in that case so we talked about resource utilization, and we talked about cost efficiency It's just resource utilization using different terms. It actually, I think it's research utilization using a more Powerful weapon which is the finances because you you will get your way, you know If you control the finances in this It's also looking at just one side of it though, isn't it? Really? So we'll, we'll explore that maybe in another podcast. the other one where I've seen people lose for is just standardization. we got to move all the QA people over here. that way we make sure we're All the QA practices are or we got to have all the backend engineers on one team because we gotta make sure that all of our, API engineers or whatever your backend is, right. We gotta make sure that, there's some kind of standardization with all of our APIs and all of our API development, Java development, C Plus development dot net development, right? We gotta make sure all of our dot net developers we're going to hold each other accountable. We'll all be on one team and you can ask them to make changes to the back end or whatever. Yeah, yeah, I think you're right. So I just want to be careful with this one. Explore a little bit. There's nothing wrong with having API standards. That's not what we're talking about here, right? We're talking about getting all those API developers in a single team as a shared services team. Using that model is what we're talking about here. So if they weren't in that model, if they were in any other model, they could still develop their APIs according to a corporate standard, let's say, because the standard is their guide, right? That's okay. You could have developers on different teams still using the same standard, right? we're talking about really, it's again, how organizationally structured. These centralized teams are and yeah, I mean, the argument is we need to standardize. I've seen that even in non development areas. PMO is a perfect example. Standardize all project management practices, right? And the PMO will give you A folder to say, welcome aboard, right? This is your new project. Everything you need to know about the project and how to deliver it is in this folder. every project's unique says PMI. And it's probably true, So how are you going to encapsulate the rules of any given project into a standard folder, but that's what they do. standardization also allows them to do something else, which give them a level of control. Kind of right. Centralization is another word, I think. when you say control, I heard enforcement when you said centralization, I heard governance. These are all dressy words to mean the same thing. Governance. It means someone taking control of yours, your things. I heard an interesting take on governance. I think it was in a book I've been reading reinventing organizations. I think that's the book reinventing organizations. By Arthur Y, Yeung and Dave Ulrich. I didn't like it. but one of the things that they do talk about in the book was governance and they say. governance should be, oh, I'm going to screw up how they worded it very well in the book. It was governance should be having your governance body decide who can make what decisions and then empowering those people to make those decisions. So basically it's handing out decision making responsibilities. or empowerment, I guess to different people. I was like, wow, that's an interesting way to view governance which I've never seen anyone do that, but it's an interesting way to view governance. And maybe someone should do that. I like the idea. Decentralizing decision making to the lowest level possible. That's basically what the book had outlined. I mean, governance to me always has been you go to the Emerald City and you sit in front of the wizard and he tells you no, and then you leave and you go sulk. Like that, that's been governed. It's a governance panel you have to go in front of to get permission. Yeah, they slap your hand or do whatever, ask you to do a million things. where you were going with, the centralization, I thought of some cases when you were talking that I wanted to bring up here. Cause they're great. Cause I actually do see them get their way by centralizing these groups and pulling them off of teams. DevOps. I see a lot of, they pull the DevOps engineers off and they centralize them in one DevOps group security specialists. I see them doing that with security specialists and compliance is another one. Compliance is a great one. the cloud infrastructure people, like they used to be networking people, but yeah, they pull those people off. And then, architects, sometimes architects 50, 50, sometimes I see architects all sit in the ivory tower and they're protected from having to do actual work. And then the other people that I've seen get scooped into this is believe it or not, business analysts, I've seen business analysts where that, like they take them from off all from, from the teams or from the product people and they put them in the central group. And then if you need a business analyst, you have to request that. The project manager has to request a business analyst and then they get the business from the business analyst organization assigned to their project for the entirety of the quote requirements phase and then the business analyst goes back to the pool to some other project or whatever. Yeah, I've seen that fairly often in the CMMI waterfall model where you get the business analyst come in the first thing they do is document the as is, and then they document the to be, I guess, right? And then they leave the requirements PRDs for developer teams to execute on. So yeah, definitely have seen that. the thinking there those people can work with their tight group of business analysts. To work through standards and as they go from project to project, they bring those learnings back to the team. And they say, okay, my project had these things. Here's my PRD, here's my learnings, or whatever. Here's the things I had to change and the structure, maybe we should standardize that. And they'll standardize the template that all projects have to go through now. that's how they see standardization, benefiting the BA organization, which benefits all the projects. And now. Again, like put my product management hat back on. I would pay real money to have a BA that could work with me to do BA things. I think the BA skillset is completely underrated. I would love to have a BA just setting up interviews, talking to people all the time, bringing me a constant steady stream. Of user interviews and then kind of documenting and being a neutral observer, that'd be fantastic. My company would never pay for that. And then very few companies I've ever been at would ever pay for something like that. the one or two organizations I've been at that have been lucky enough to have BAs, they've been controlled in this sort of over there kind of model that I described. Sadly, that's true. And unfortunately, what that begets is the behavior where they say, well, if that's how BAs work, that's how maybe product owners should work or product managers. So we get these org structures now where there's a pool of product people to be dished out to various teams. And I think it's extremely dangerous. I mean, I think it's dangerous enough at the BA level too, because there's no substitute for a person having continuity speaking with a customer throughout the course of the project. If you're going to pull that person out and put somebody else in, who's maybe equally as, qualified, if not more, it doesn't help because you've lost the continuity of thought you've lost the, the what's really important to the customer. You've lost all of that. We haven't even brought up the Tuckman stages where you just set your team back. you took the BA who could answer all those customer questions and you just set your development team back again. Like, why would you do that? Oh, well now we have to get a different BA. If the project's continuing, the customer renewed the contract or something like that. Now they want more development work. Now, are we going to get the same BA? Maybe, maybe not. Now you get a different BA. Theoretically, maybe they're writing to the same template, but they're not the same person. I understand you're saying, look, if there's standardization, it shouldn't matter which BA you get, but in the real world, we know yes, it does Oh, most definitely if it's, if it's Java, what does it matter? What developer you get to code in? If it's whatever language level of abstraction, you take it to everything's the zero and a one at the end of the day. No, listen, I've seen the worst. Impact of this on a large project where the BA role was swapped out multiple times Different people come in so after the project was almost over That BA who stayed with the team, the implementation team or teams until go live, they were pulled out, at a time when the customer was all the more willing to tell you what else they want, right? And this is a waterfall project type of waterfall naming like a Agile name only type of project. But we did receive enhancements that the customer said they wanted. somebody needs to do the due diligence and capture those. Somebody needs to then have meetings with architects to make sure they're even feasible, doable, etcetera. Are they feasible? Are they profitable? Didn't have that B. A. In there. So different B. A. Came in and decided no, unless they've got money, we're not doing any of this, right? And the customer got extremely ticked off to the point where they called the C. E. O. And said, Why is this person? I know they're still with your company. Why did, why was that person removed from my team? The CEO did what CEOs do. Oh crap. I didn't know that. Sorry. I'll fix that right now. The old person comes back and then it took some time to smooth the relations over. It worked out okay in that scenario. Doesn't always. So I just want to highlight through that example the fact that this has repercussions beyond what your team can see. And imagine what happens if that's a PO or a product manager. It's a no brainer. It should be a no brainer. I could, I could totally see it. Again, I told stories on the podcast before about specific people that when you call support, you got this engineer as your final explanation. And it was the same person for your customer. They were assigned to only a select group of customers. I've seen entire development teams roll off of a project. you'd have the main development time span then you have the hyper care period and then there's no support if you didn't extend the contract when the main development team rolled off. And then the hypercare team was, which may not be include anyone from the original team. It may be some new, it's usually offshored, right? And offshored, like you're not going to get good service with those people. And you know, they got this terrible, terrible, terrible, I call that white glove for the warranty period and then kick in the pants. So I want to, we've already started talking about specialized experience with DevOps, with QA. We took a few data science is another one we haven't talked about yet. So I'm going to introduce that one with specialized experience. The idea that if I sit with just my group and I'm just loaned out to other teams and other projects, that I'll actually have more benefit to advance my career. What would you say if I told you, I think that if I keep all my QA team over here and you just tap me when you need something, I'll just assign somebody or whatever. Like then all my QA people can concentrate on career development and their skill development and stuff like that. Whereas if they were on your team, I couldn't be guaranteed that they could be doing that stuff, or maybe since you would overload them with work, they wouldn't have any time. maybe you listen to our podcast on Cognitive Switching, on Cognitive Load, and then you would say, Well, Brian the experts are saying, like if my people are loaded down with work, they're not gonna learn, so I need to make sure if I'm in control of their time, of my, resources, my utilization of my resources, Then I can make sure that I'm giving them time to learn, time to take those mandatory courses that I decide they need to work on as opposed to them being on a team long enough to understand that domain and really build up their experience and knowledge there. Right. And hopefully they work with a savvy team members scrum masters product people that say, yeah, we're going to build in learning. that's the alternative, which I would much rather pursue than this idea of a governance body that dictates how many hours of training you have to go through every quarter, because that's how they will budget it and when they do that, they say we've now enabled all these skills. No, you haven't. All you've done is for someone to sit through a class for a few hours. So what I would say to that is that you a person Isn't really gaining skills, they're getting book knowledge at best. how do you apply that in real life? How do you learn from experience if you're not on a team? I'll tell you how you don't apply it. I think it's the same thing as data science. QA, at least QA that they have to be in line with the rest of the work that everyone's doing like directly servicing the customer, like data science. Oh, I've got to have specialized expertise sit on their own team because what they do is so unique and they don't need to learn customer service skill and they don't need to learn how to work with development. And then Lord forbid, they actually sit with a tester. And watch what the testers doing and get question and learn some testing skill, learn some cross functional skills that will help them in the rest of their, like I also think about like, Oh, sorry, I don't have any data scientists to give to you there. There are 100 percent utilize on other projects and, and I will, and I will look at you with a straight face and say, what other projects show me the value of those other projects. Oh, well, it's that's it doesn't work that way. It doesn't work that way. Someone screamed louder than you Brian So I had to give that person to them. Show me the value of that person screaming louder than me Yeah, exactly. Unfortunately, this is reality and I think The more, see how do I want to say this a lot of times the skills that are really impacting teams in this structured way where we have a shared services model are skills that aren't very prevalent, like DevOps, DevOps skills are highly specialized people, right? Architects, UX, you can't just tell a developer, hey, you go figure that out yourself. I mean, In theory, everyone's self organizing, self managing, but still, you have to have some level. It's the verticals here. you can learn for sure. You can pinch hit for someone if they're not around, but you're not the core expert there. You don't get that just by sitting in. Like a box basically saying, well, this is a group of the cadre of UX people or testers or whatever, you don't get that. Stick with DevOps because it's such a good one. is such a good one because DevOps to me. Let me, let me, let me sit down and break out all my pet peeves on the podcast. Just open my box of pet peeves that I don't talk about before DevOps was a thing. Let's talk about the old times. Ah, there you go with this. Let's talk about, the old times. Before the empire. The dark times. I remember managing a server room, like racks of servers in a room and doing hardware maintenance and network maintenance and stuff like that. I remember temperature sensors. I remember a whole different world that just doesn't exist now because someone said, Hey buddy, Why don't you move that to the cloud and pay me some cloud monies? And then the company's like wait a minute, I can pay you and then you'll guarantee me an uptime of nine point X, X, X, And then I can fire all my network administrators and I can fire all my system administrators and I can fire all my support because that side of the house used to have A whole staff of people that came with it. I can fire all those people and I'll just, all my infrastructure will be in the cloud. We'll have infrastructure as a service and we'll have cloud as a service and we'll have, you know do your laundry as a service or whatever. We'll have everything as a service. Customer service as a service. Customer service as a service. Send your, send your customer service people to me. I'm laughing because these problems of oh, I can just have somebody else do this stuff Like that just exacerbates every tiny problem that you could have. Well, I think a lot of this is really kind of like When the cloud became a thing cloud providers went out and sold it pretty heavily. They did saying, you don't need a DBA at 140, 000 a year. We'll take care of all that. You don't need a support person. You don't need a hardware person. You don't need a networking person. You don't need etc, etc. And in return for all of that, we're only charging you 30 percent of what you're paying, right? So I mean look I don't blame companies for falling for that because they were hoodwinked I don't even believe them either because of what we were talking about before whoever owns the finances wins And there's like I wish we could give people Some better pushback or some better understanding see like we did a couple podcasts and one with Newton on finance that might open your eyes to understand and to talk with these folks and try to empathize with them and understand why they think the way they think To slowly start breaking down that barrier to say The way you guys have done things forever in the past may not be the best way Maybe there's another way Let's sit down and talk about it. That's the only way you're going to break through. But listen because you've gotten rid of all this skill and hope that somebody else will do it for you. And then let's say, for example, all your systems start blue screening and you don't know how to conduct business now because you don't have any simple network engineering orchestration at scale skill in your organization anymore because you've gone with this idea of like, I'll just let somebody else do it and we'll just trust that it's getting done rather than say, these business critical systems are done by this specific team and they are taking full ownership of everything they're doing. Yeah. And again, I go back to that. to how they were sold this by the providers of these network security, et cetera, et cetera. But at the same time, the whole thing is all around transferring risk, right? You own the risk of your infrastructure. If you own it in house, if somebody else owns it, they own the risk. Yes. You pay for it, but they own the risk, right? So that's really what this is. And then when these BSOD start happening and you go, why is that impacting my flight tomorrow? Do they own the risk though? At that point, like they own the risk. But, all that pain is transferred to your customers. That's right. Even though that on the balance sheet, I understand you made a decision on the balance sheet to say this other company owns a risk, but I mean yeah, no, Om, there's going to be lawsuits and contractual obligations and this and that. That damage is done now that damage is done in multiple ways. So you're right. It's the, customers that are impacted. Therefore it's you feeling the pain, right? it's not just the incident though, right? It's also reputation damage. Now your customers have lost trust with you. Build that up quickly. If you can, I thought you were going to say now your customers know that you're clowns. Yeah, that's right. Now they know you're clowns. Yeah. I mean does it, I, so. Again, two big problems with this, this like, Oh, trust me that because I'm keeping all the specialists, I'm making sure they're having better career opportunities and I'm making sure they're more informed as the industry expertise. Like, first of all, this falls apart when you introduce the value tests that the product management that Marty Cagan books and stuff like that. Right. So this falls apart for, for that is like, you're not. Producing a value in these silos. So right out, you're, you're done right there. So you don't, there's no arguing point to that. That's a great one to use. the other thing is why are you not doing community practices across all the teams? With all these specializations. There's a way to set this up where you don't need to take control of anything. You're just facilitating people's learnings. And, you can't force people to learn. So you can facilitate. Attempted sharing of knowledge and learnings and you might get 20 percent 30 percent like I've done this in the past where I've been or I open up like product management community knowledge and this is a scrum master community, a community, a community practice, community practice, community interest, whatever you want to call it. 100 percent of the people in that role across the organization do not show up. Like you, you will get a small percentage and be lucky to get engaged people with that small percentage. That has definitely been my experience. You'll be lucky if a few people show up and that's because they're not incented. And you're saying you're going to force them and they're going to get more from being forced to do it because they're now controlled under a group or whatever. I feel when you do it as a community of interest or a community of practice and people come to it, at least then they've taken the first step to say, I am here because I want to learn. Yeah, they're showing initiative right there. Right. I agree. I think I would take that people self selecting. I would take that over you know, Hey I'm sending everybody to this class or everyone's got to go to You know, pick two lectures or whatever. They're just chucking a box at that point, aren't they? Because they're saying, well, I'd rather just go, then you're making me go do this instead. So I'll just go do that. I'll watch these videos at double time speed or whatever. The point is, you can do that anyway. You don't need control. But if you don't have control and you're the manager across this matrix thing, right? How are you gonna establish your authority and put your stamp on it? You know, ensure your longev ensure you're gonna be around a while. Longevity. Longevity? Oh la la! Longevity.. So I feel we've stayed Then we should have the, the idea that, Oh, I, because I control the people, they have better career opportunities. I mean, I like also there's a, there's also a little arrogance in that statement that it says like, Oh, I, I know it's a lot of, there's a lot of arrogance in that to say, I can prove to my superiors that I am actually managing and improving this area of the business. Right. Look how many people I've trained hours of training. Yeah. Yeah. There's another category in here that I, I, when I first saw this as a topic when we first thought about this as a topic was one of the things that we identified very quickly. And it's probably spent way too long talking about is agile misunderstandings. I was going to say purposeful misinterpretations. That's, that's how I was pitching it. I went to an agile conference once and they were talking about fluid teams and I'm like, Oh boy, this sounds terrible. And everyone assured me they're like, no, no, no, no. This is a legitimate thing. Fluid teams is the thing. I was like, I don't know, man. I understand the actual concept of fluid teams was actually for, but someone taking one line out of context from something that they heard in agile and then lifting it and being like, see, agile says we can do fluid teams. Agile says we can throw out the back hashtag. No backlogs. We just go from the hottest fire to the next hottest fires and the next hottest fire. And. Everything is chaos and eat pizza at 7 a. m., you know. Yeah, look, I agree with all of that. I mean, if there's one industry where people take a single line out of context, this is it. You know oh, let's do twice the work in half the time. And to hell with the quality. I mean, that last bit is hidden, but it's still there, right? I mean, to heck with the quality. That's what I meant. Ooh la la. Ooh la la, exactly. So, I mean, people do this all the time, right? And they do it the other way, I find. Like people say. I need to have everybody do everything on my team because we're supposed to be self directed, self managing, self organizing. If you really like that, why do you need a scrum master? You don't need a scrum master. The teams just do whatever they want. I mean, not in a rebellious way, but they can just be self organized. You also don't need a product person because every team member talks to the customer every day. Except I haven't seen that unicorn team in action anywhere. So you just have to get there. Over course of time, and it's in the pursuit of that, that I think the secret sauce lies, right? So people do take these things out of context. It's like the first thing we saw when agile kind of really gained momentum was there's no place in agile for project managers, delivery managers. The reality is they're still there, right? So you gotta deal with them. They will come in and disrupt you otherwise. So either embrace that role and say, how do we make sure? They get what they want. We get what we want. Right. Or you can just keep fighting. I remember very early saying you very easily could keep your project manager. There's no reason to fire all your project managers or whatever, try to crowbar them in a scrum master or product position and do any funky stuff like that. Because the typical agile team a huge missing link in their chain is connecting them to funding and, and, and the rest of the business, basically like the, the, the agile, the way it's trained, it like lives on an island. That's one of the critiques of, of it right now. And I, and where it loses online to the, the product management communities and stuff like that. It's not, it's not linked to value basically. But yeah, I mean, the project manager could very easily link you back to the, if your business runs on if you're like in the government space, you run a project contracts and or maybe you're scaled and you have tons and tons of teams and you really need something, some kind of scaled overhead. Yeah. I mean, if that weren't the case, you wouldn't have rules like Program managers or delivery managers, right? Like, isn't the team responsible and accountable for delivery, right? So why do you need a delivery? Even Marty Cagan says delivery manager, project manager. I mean there's so much vitriol about that kind of stuff in the agile community. I just don't talk about it anymore. I just don't bring it up but there are definitely people who have that professional experience that you're. You're wasting like you're going to a gold mine and you're wasting all your opportunity. Coming out with sand. Yeah. Yeah. Absolutely. Coming out with rocks. Thinking you gotta do it all yourself. But it's the panning experience that we're going for. Ain't fun. No. Digging trenches ain't fun. If I keep a pool of people specialists outside of any team, then we can be more flexible if any one project crops up unexpectedly or one project scales up unexpectedly, I can throw more people at it and I can take people from. The pool of the shared service and throw them there because if they were on any other teams, then we'd have to do this big tap dance and something. We'd have to do something it'd be a big thing. That almost assumes you have people sitting around, right, that you can just pick off you know, off the bench. It never happens. So they say, well, we need somebody, but you know, Joe over here, he's a senior executive and he's yelling and this guy over here is a director and I've got somebody on his team, but you know, I got to make Joe happy. So I'm gonna pull Mary off of that team and put her over here and I mean, come on You still have the tap dance going on, right? You just have this perceived illusion of helping someone As, as that person who's in charge of these people up, I'll push back on what you're saying, because in my experience, the way this functionally works is there are dates when those people are rolling off of their project and then they'll say, okay, we can give you a resource quote resource. At this date. And that day will be weeks in the future. So basically you can't get anything done until weeks in the future. If you want that cross functional skill. So what you do on the team usually is you just figure it out. If you're not going to get cause your deadlines are, you'll blow all your deadlines out of the water. If you have to, you actually have to wait. So either you will do your executive screaming and get a person, right? Somehow, whatever person. Well, they have to hire a person, right? Or you'll just figure it out. Now you've got the skill in your team, which you wanted to have your skill in your team anyway. Well, that's the positive outcome in the long run. I think, I mean, you're going to have some roadblocks on the way. let me give you another experience. Which is a product management, product marketing, UI, UX, like plenty of people. And then the development team, plenty of people on team that enjoy talking to customers, know that the real value is talking directly to the customers Was on the team one time where we wanted to meet with prospects, we wanted to bring leads in the company, the product management, product marketer, UI UX, and the dev team, like the dev team, usually on the leads side. pretty silent, to be honest. It was mainly the UI the marketer and UI UX person. And I would when we would commit to things, I would commit things on behalf of the company. You know, I would say like, we could do that or we can't do that. Or I would kind of be the arbiter to be honest. And the development team would chime in whenever something. You know, it was because some of those calls people would bring their technical person. We're talking to prospects. We're talking to people we could make a sale to. And boy, you want to talk about getting into fights with sales? Like they did not like that. Cause you're providing a reality check on their you know, did not like that. Yeah. The fantasy view of when she's a competitor, we were perceived as a competitor. they have the normal sales meetings where we talk about the pipeline and they talk about the prospects and whatnot. So they, they perceived it very negatively and we should have been way more coupled with sale. I will be honest, the salespeople, we should have been coupled with the salespeople and bringing them to every single one of our sessions and looping them in. But because they were shared services and we were not basically, they were too slow. their calendar was too hard to get onto and they were not responsive enough. When we would email a customer and say, Hey, can you meet with us? We would throw out some dates and they were all like Today at 4 p. m. Tomorrow. Tomorrow morning at 8 a. m They were like immediately and and the team was down because we were one team, you know We could clear our account we can we could stop any we can we could take any of our team events move them around Sure, if you're in meetings with yourselves anyway, yeah, so just too slow too slow too unresponsive and I mean we won in that case because We were We were bringing in new work and the CEO, it was small company CEO. They're like, who cares? Bring it in. Yeah, bring in the new work, but, we were burning some relationships to do that. You know what I mean? We were churning and burning to do that. You bring up a good point about these coordination issues, right? We internally in this way of working when you're matrixed and you have skill sets that are focused elsewhere. this can apply to anything let's just say you have a customer meeting and customers talking about potentially what they're. Product journey looks like you know, maybe not immediate, but going forward. And you don't have UX people available for that meeting because they've rolled off your team and now you have this meeting for the next phase. This can happen throughout. I think it's a real challenge to try and do that as opposed to having the skills on the team or have that person on the team, you're not reaching for that then, right? They're already in the team. Project flexibility and scaling. Now, if you're going to say scaling down, I understand like returning resources to the pool, I get that. But if you're talking about scaling up well, if your project becomes wildly successful and brings in more money or whatever, then it's easier to add people To decide what skill they need more of and just hire on that project from that project's margins. I understand you saying, well, I need to hire, and let's say I need to hire a data scientist because everyone's using AI ML now. And it's like, we want to include that in our products and we don't have any AI ML. People on the team right now. We have no data scientists on the team. So we want to hire one, add them to the team for the first time. Then I understand now I'm approaching a shared services. For help in hiring. I don't know what a good AI ML engineer or data scientist looks like. Right. So now I do need to pay for some coaching or for someone to be included in the process until we hire somebody. And maybe to help this person or whatever, to bring them up to speed or whatever, But that's a little bit different than, paying for coaching and assistance in hiring. It is different. I don't know how often you've seen that actually happen at work, the concept is definitely valid, and I think if people try it, they'll find that it is quite effective, When you're hiring skill sets that are scarce to begin with. I mean, A. I. M. L. Is a great example. There's not a whole lot of great, very good data scientists out there. you can't just pick them up off the shelf. Good ones. Not, not self titled AIML people that have been doing AIML since 2001. not a lot of, it's like the agilists that say I've been doing agile for 30 years or product managers that have product manager on their resume from 2004. Yeah, exactly. it's good that if companies could consider this as a adjunct model, you don't have to throw out everything and just adopt this, but try this also and see how it works. I'd be very interested in seeing studies like that, or even anecdotes. Right. So you're listening and you have come across this. Please let us know. the other one that I wanted to bring up, I want to talk about this one because I remember this one from early in my career of so early in my career, I joined the QA department and the QA department and the development department were kept separate. They had their own manager and the managers were peers in the organization. And they were set up intentionally like that because the idea was that if QA people were kept separate and assigned to shared services to the development teams, they could be seen as objective to the development work because development was incented on speed to delivery and getting things out the door fast and QA was incented on QA. Escape defects and a whole bunch of the quality as quality, the actual quality of the software bugs coming back in from the field that bugs being reported from different segments So the idea was if we kept this pool of people outside of the reporting structure they could be empowered to be objective as a key part of their job. Yeah. I've heard and seen that argument play out. But the question I'd have is this, why wouldn't those QA people. Be just as objective. They're part of the team instead. I mean, so that's half of my question. The other half of my question is, what's wrong with your teams that you can't just point out something that's wrong? And shouldn't the whole development team be concerned with quality? not just those people with the Q in their titles no, everyone's responsible and accountable for the highest quality product we put out there. I think everyone was concerned with not being shot because that was a shoot the messenger. Of course, that culture will be, get those kinds of structures, right. And vice versa. Those structures will give you those behaviors. I mean, although I could apply this again, DevOps, I could apply this If DevOps sends something through the pipeline and one of the alarms goes off or one of the automated tests fails or something like that through the pipeline, then the DevOps team will kick it back to the individual team that contributed that release. And you know, the DevOps team will. Be the quote gatekeeper boy. I haven't heard that one in years They'll be the gatekeeper to basically approve and reject Yeah, and that seems like an overhead to me, you know at the best of times, right? It is an overhead because I remember doing that job as a qa I would advance the release pipeline and if something failed there were my tests. So if one of my tests failed, I would just like, what am I going to do? Override my own test? No, of course I'm not. I'm going to stop the release. I'm going to stop the pipeline. I'm going to let the failure happen, roll everything back because all that stuff happens automatically, and then analyze why the failure happened, go manually test it, see if I can recreate it, figure out the automation that failed. That's the shortest path to resolution, right? So instead of having somebody as an interim saying, Hey, it's failed. Must be one of your something, your code, go figure it out. Now I have five developers, right? So now you're trying to figure out like which contribution broke it. Assuming that you don't have a system set up where every time you merge, there's a trigger test that happens, right? Including full regression. That way you know, what broke it was the last merge, but. I was surprised at how many teams don't even have that, right? Branching and main trunk, all those concepts are sometimes even being followed. But yeah, DevOps seems to me like at the end of the day, all you're really doing is just executing scripts to deploy things into various environments and pipelines. Why can't the team members do that? What you just threw out. Probably we'll get the majority of the pushback because the majority of places that, that, that. That the orchestration of the pipeline like that scene is somebody completely somebody else's job and people will dig in to be like, Oh, we've got to have separation of duties. You've got to have separation responsibilities because you can't have the one team just saying, Oh, we got to have this out, got to have this out. Because again, the development team is incented on speed when you, join these skill sets to the development team, there's a perception that. The development team's culture is going to trump everyone else's culture. So that, that, that I'm incented on speed delivery. I just want to get stuff out as fast as possible. I don't know the customer's experience, the quality of software, whether it meets the goal that we're shooting for or whatever, like all, all of that is secondary to, can we get stuff out as fast as possible? And I would even say there are people online that are talking about speed is a number one issue. They'll say the ability to release fast. Is the number one issue because they say, well, even if you break something, you got to be able to iterate and release fast because then you can release a fix fast and you're, Oh, you didn't release something of value. You can do it fast. So like speed is the most important thing. People are online lobbying for that right now. I'd love to figure out from a customer perspective, would they rather see something fast, even if it's a dubious quality, or would they rather see something a little slower, but it's a good quality that they can consume right away? I don't know the answer, but I'd love to know. I 100 percent agree with you. I would think that those people expressing that number one, probably come from a development background, number two, they're probably not asking that question to the customer. Yeah, I don't doubt that. I think they should be asking that though. They're just responding to internal pressure. On which we'll always be pressing development to get things done faster. Yeah. Unfortunately, that's the reality. The final thing on this podcast, I started with the org chart because I think that's a great place to start because that's the number one. that's like this is not worthy of me thinking critically, right. I'm just going to repeat just, just parrot whatever, like critical thinking, by the way, should be a whole different podcast. Like that's, that's going to be the Toyota way lean podcast. That's a good thing. You get like getting people to questioning people in a way. That gets them to think critically and as opposed to saying like, well, that's what the org chart says. That's the way we've always done business. Once you have that skill to be able to ask questions, to dig, and then you don't need anybody can have that skill. You don't need to be a supervisor. Imagine anybody could have the skills to, to just say like, Hey, you don't seem to be thinking critically about this. Why don't you shift into critical thinking mode? think about this take a big step back and think about it. There was a set of questions to get you there. But it's a great topic for a future podcast for sure. It's a really good one. It's a super interesting one, but also I need to read the book again. I might have to get that book to mark it up because it's, that'll be a dense podcast. People talk about that in the agile community a lot. But there's not lot of walkthroughs of here's how it could be done with examples. And I feel I would need the book on hand to walk through that. So the final category here that I dipped into and then we may or may not be returning from the tangent is this shared services idea. we're not going to fund durable teams. We're not going to fund fully cross functional teams. We're going to make you I was going to say big, we're gonna make you beg for a shared services and we're gonna, we're gonna make you write your Congressman and hope that the funding comes in for your shared service. Before all your deadlines pass and the business opportunity passes, et cetera, et cetera. it's all a bit short term thinking, isn't it? It's very much so, and I think you nailed it. It is begging, really. It's like, I'm gonna go stand on this street corner or intersection with a bowl and hopefully, resource I need now, resource, will fall into my bowl. it's terrible. I know that there are projects out there that are suffering because you don't have the right person available at the right time for the right business opportunity. And it passes or it wanes at least if it doesn't completely you know, wither away. So, yeah, I mean, this is causing real losses of real dollar terms and yet it's not something that we pay much attention to. Why is that? Oh, he's done it that way, Brian. Oh, I thought, I thought, I thought you were going to say like correct. First of all we also would have accepted let me break out my laundry list. We also would have accepted, we don't know how to financially value the cost of missed business opportunities. We don't even look at that. Unfortunately, listen, well, what I have learned is if you don't look at a metric, it doesn't exist. That should be a law. Brian's law. Don't look at the metric and it can't cause you any problem. If you can't see it, it doesn't matter. we just went through several categories of objections or reasons people will use to lobby for share services. We want to do a companion podcast, a follow on podcast to this. I don't know if it'll be next. I don't know exactly when we're going to do it, but the idea is it'd be really cool to put together a podcast that's in the same format of all the Arguing points. That will be used against you, but in the opposite direction, things that you can use to say, Hey, before we talk more about shared services, let's talk about how we move more fully to fully durable teams. Yeah. I think that's going to be the, the value added podcast on top of this one. So it may happen really quickly or it may not. Definitely look for that. Through the magic of editing, all things are possible. That's what I'm saying. Well, listen if you've worked in an environment where you have shared services at work, let us know what your experience has been like, what you really didn't like about that and what you might want to do. Change if you had Harry Potter's wand. I was going to say and any other arguing point that's been used to lobby for shared services that we didn't cover. I'm very interested in hearing. All right. Well, thank you again. And don't forget to like, and subscribe.