AA97 - The What & the How: Two Sides of Software Development

Whoa. What do you know? We're talking today about the how and the what, what does that mean? How and the what? Okay, I'll explain what that means. In a normal organization, the product people bring the what to the teams, and the teams bring the how to the product people to the product, people to the product. They bring it to the product. So the teams decide how they're gonna implement what product wants, product comes to the teams and brings them what the business needs worked on next. And should also know at the same time why they're bringing that as well. So, the product people bring the what, but they're also informed as to the why to the larger business organization around 'em. And then the team tells 'em, okay, based on what you brought, this is how we're gonna implement it. So there's two wheels in the company. I'm trying not to do this on camera. So what I wanted to talk about today was the what and the how. It's not really what versus how. It's just the what and the how together. and it's interesting you said the product also brings the why mm-hmm., because without that, the teams are limited in their spectrum of imagination. You know, the, there's ways to come up with solutions if you knew why you had to do something so it's important to do that. I wonder if most organizations bring the why as well or they just, the what? That's why I figured we'd talk, we start talking about this cuz different people listening to this will be in different size organizations. Yeah. So I figure we'll step through this conversation. We'll try to move quickly through the, how this applies at different size companies. So if you've seen this at different size companies, it look, it's gonna look a little different. It's gonna look a little different if it's functioning properly. And also if it's dysfunctional, it's gonna look a little different. Right? Very different. So in my experience at a, at the smallest of companies, , small companies, let's say like 20 people startups. Startups, yeah. Startups. Yeah most of the what will come probably come from your ceo or if you're lucky enough to have a product person early with the startup, it'll come directly from them. It'll, basically, what I'm saying is it'll, it'll seem to all come from one person who, who either will be a product person, but if your company doesn't have a product person, it will likely be a founder of the company. Right. An entrepreneur perhaps. Right? Yeah. So, yes, I agree. This is what we're building. This is what my company is all about and maybe he can even, or he can even articulate the, the why um, but you're unlikely, I would say, at that scale to, to have product roles just yet. Well, you'll, I mean, you'll have product roles, but they, the people that are in positions may not, I mean, they'll be named literally whatever they want to be named. Yeah. Sales roles. Yeah they, you could, yeah. Well, if you understand what, what modern product is about, you'll be able to understand the, the founders that are playing the role of product in the organization, you because they will be the people who are subject matter experts of the business domain, where the problem you're trying to solve exists? That's what I'm trying to say. Yeah. You know, and, and you should be. And you know, basically they're, they're a, a, a, a bottomless, bottomless bid. They're, they're, they're an endless fountain of facts and expertise about the problem that those users, that you're building stuff for whatever, whatever you're servicing they're, they're uh, an, an endless source of, I'm trying not to say bottomless pit again. Cause , that's, it doesn't sound right at all. they can answer any question they're complete experts at, whatever the area is that you're operating in. Yeah, for sure. They'll have plenty of ideas, opinions maybe some facts. I, I think what I'm saying is the, when you have that as your source of facts in quotes mm-hmm. you really need to kind of validate them cuz they may have a colored opinion on what they're trying to solve and why. Yeah, yeah like there's a problem. Well, sometimes what happens is they have a solution in mind first. Mm-hmm., this is what my company's all about, therefore, I'm gonna come up with problems that can be solved with this solution. Right. So you need to vet those. You need to vet the problem statements, the pain points. So who are the paying customers, right? Yeah. Yeah. Now you're getting back into like the, the podcast I want to have with Tricia, where we're talking about being the first product owner at the company because the, the first product owner at the company you'll, you'll deal with this with the founder. You'll deal with, um they're the business expert and you likely are not. Okay? So you'll deal with there'll be a certain part of your time that is spent building credibility. I in that, hey hey, trust me, I can deal with the problem. You know what I mean? You've delegated to me some responsibility and now I've gotta prove that I can handle the responsibility where you can let go and you're not coming to all my refinements and you're not coming to all, you know what I mean? That kind of stuff. Like, hey, come to the demo occasionally, pop into a refinement where we need you to answer questions or we need your expertise. And then go and do whatever else you're doing in the business and go go run a good business. We got the product side of it until they trust you to do that. Um, there's a certain amount of, of, of work that goes into that. That's all that stuff is a whole separate podcast. It's all, it's a, it's a special skill set it's a lot of empathy a lot of like quick learning and, and, and experiments and stuff like that, that I'm sure will eventually talk about... Tricia... maybe. Please come back! so small company, right? You have the two sides that we talked about. The what, hopefully the why as well. Mm-hmm.. And then the how. So what are some of the issues there that we can dive into here? Right. Small company. Yeah. Clearly somebody's brought in the idea of what to build. Like this is what we need, right? Maybe even why we ne need this Now the team goes away and does that, and, and somehow magically it all works. Or are there issues where the teams aren't perhaps clear on the what necessarily? Day one, they come up with something. Let's just call it a a prototype or even a pre-totype. Mm-hmm. And they need to validate that. And the, the people, usually a person, as we just said, would. Look at that and say, yeah, not quite what I had in mind. Yep so all manner of different interactions could come out of that, right? Mm-hmm.. So we can probably yeah. Look under the hood a bit there. I'm kind of okay with getting pushback from your internal stakeholders and getting your product over the initial hurdle of the people in the company are happy with it. I, I'm kind of okay with that as a product manager to say that like, Hey, the internal stakeholders I I, I'm used to the internal stakeholders just being far more vicious than anybody externally. And, and like, but that's good. Like I don't, it is good. I don't, I don't mind healthy conflict as long as it leads to, cuz I'm not gonna take it seriously cause the, like the product is not my.. It's not my child, you know what I mean? It's a . It's, it's something that we are producing and we are going to keep working at it until it gets better. It's not something we did one time and that's it. And we don't have a chance to improve it. Yep. You know? Yeah. So we're gonna keep working at it. So I don't, I don't mind vicious feedback like that, or just people just telling me like, oh, I don't like this cuz whatever but, but also, um we have priorities and limited resources. All the stuff you do with a small company. Where I wanna go with this is at a small company let's, if they're 20 people or whatever, maybe you have two separate teams, three separate teams, whatever it is, at a small company like that you have the opportunity at the end of every sprint to quite literally get the entire company into your review, along with maybe a, a key stakeholder or two from external or whatever, right? Um, or people in the field that you're trying to solve a problem. People, customers, external customers that you're trying to solve a problem for. And and, and literally the whole company. I showed this in, in the podcast where Stormy and I were talking about going from being a product owner to a product manager. I showed a graphic that basically was the percent of time that product managers spend in their day. Talking about how much time you spend tactical, meaning with your development team, how much time you spend op operating, operating meaning lining, updates, dependencies, stuff like that between teams and how much time you spend at a strategic level. Those three things, The operating thing. I feel the advantage of a small company like this is you don't have to spend so much time operating. Cuz every time you do a sprint every time you do a sprint review, I was gonna say sprint demo, I'm trying to use the right word. Every time you do a sprint review, you, you literally have everybody possible in the sprint review and you can say, okay, this is what we're doing and , this is what we have. Let's get feedback. Let's all talk about it. Let's decide what's higher priority, what's not, whatever. And then you can watch me adjust the backlog. You can watch me record the items and you can watch me bring up the backlog and say, this is my plan going forward as next steps based off of what you said. And based off of what I know And this, and like, everyone is always informed about the absolute latest latest of the latest, basically. Yeah. Yeah. That's the advantage of this in a, in a small setting, right? Everyone's available, they're in arms length. That's a good thing, right? Yeah. Yeah. in that, I feel the, the what is very well covered, right? Because we're never going more than the normal cadence without syncing up with everybody. That, and that's the advantage. So if we're talking about like, hey, maybe our practices about how we're delivering things between teams are not the best. Like you, you have a session where you're doing a, a, a review and, and although we're not, we're, I'm specifically trying to not talk about scaling today, cuz I hate talking about scout feel like every time, every time anyone ever in any podcast to listen to talks about scaling I'm like, woo, I'm out. I'm out. I'm not learning anything in this very small organization with like two or three teams, right there in that sprint review. You can go team to team to team and basically see the sprint review for three different teams right. In one session. Okay. And, and literally it's the whole company. But then when when you're planning and when you're trying to say like, oh, well I need you to work on this, or, or you know, oh you're, you're the way that you work with this component is a little bit different than the way we work with this component or whatever. Like, you can kind of hash it out because it's three teams. There's no meetings three weeks out, there's no delays, there's no cost a delay in the waiting time and stuff like that. If, if you decide that you wanna change your process. That's what I'm trying to say. You know, there, there's very little delay in changing your process. The team members just talk to each other and it's, you do it. Yeah. That at that level, the organizational inertia is just not there. So it's, it's much easier to move., I agree with that. The process change of how teams work with each other, I consider under the how cycle. I just presented a new idea, which probably was hidden from the beginning of the podcast till now, which is I consider all of the business prioritization and the breaking down of work, like typical business analysis type work. I consider that under the banner of the what and under the banner of the, how I consider everything that development does on a day-to-day basis. Writing code, everything, testers do, stuff like that. Anybody on a Scrum team, right? But also I consider the process in which teams work with one another. I consider that part of the, how to be discussed in whatever, whatever group just talks about how yep. I fully concurrent with that. Absolutely. So it's pretty clear right at, at a company that's quite small, you don't have a lot of fluff, a noise, all that stuff that you have, people are available, you can get things done right. And decision making chains are much shorter. Yes. Which is great. Yes. Delay. Yeah. Delay is much shorter too. Yeah Is it time to sell Brian and Om's software firm? Uh, and cash out, uh get our golden parachute for staying for a year to make sure that not all of our employees quit like after a year . Because that, that's what happens when firms sell out. Like, I don't I don't know if I'm shocking anyone right now about like, your founders are under some kind of contractual obligation to stay for a certain amount of time. Depending on how savvy the negotiators were that bought your company, and then they're gonna cash out and go on to their next venture. But in the meanwhile, another company bought Brian, M's. Software development firm our, our 20 person company. And now our 20 person company is getting merged into a, i, I don't know, a hundred, hundred and 50. Well, ain't have to be that big. Let's say it's 150 person company. So let's say it's not a huge company, it's just a, it's another equal or just a little bit bigger company perhaps now what happens now you've got two companies, either if it's takeover, merger, it doesn't matter, the ways of working are going to change. Mm-hmm. Um, would you like them? Not typically. The acquirer-er will prevail. Sure. So it's their Yeah. Ways of working that would be kind of passed down to the teams. Do it this way now. Yeah., if you did have any middle layer at all, E even if it was a small company, a development manager is perhaps, perhaps an example. they may not be around anymore because you don't need two sets of development managers. Sure. So maybe the teams are rolled up under the acquirer's dev manager or mm-hmm., your director of development, whoever. Mm-hmm.. And, and they will have their own practices that they will basically get the teams to, to follow. And then what I just said about the development team and the how also applies on the other side Product side. the interesting thing here is, Development is development at the end of the day, but product is different because people's knowledge of a domain set is different. Mm-hmm.. So now you've been acquired by a company that may understand your domain to some degree or may not. Yeah. And now you've got some friction because if they keep your product folks around, you're gonna wanna see how that plays out. Right? Yeah. Yeah. How does that play out in practice? I feel it's fairly important at this point to point out like what, what you just highlighted it goes pretty much unsaid on every every podcast, every source I read if you are grouping inside the organization right. Your, your subgroup inside the organization, A lot of people are gonna be like, what does that mean? That means nothing to me. I don't understand a subgroup. If, if the teams that work on software that were from the merger, from your side of the organization and the teams from this other side of the organization, if the users that use that software are different from one side of the organization to the to another, now you've got a much bigger problem. Cuz now the., the what cycle needs to divide between user segments And you need to like, you need to draw a, a, a, a dotted group line between those user segments and keep those groups separate. Because now we're talking about context switching of like, let's say that we sell Brian and Om's uh, software company, , . I like the side of that. And, and uh, and, and you take the deal to stick around and deal with the pain for a year to make sure all the employees don't quit. And I'm like, whatever. There's no amount of money you can give. You're retired. No amount of money you can gimme to stick around suckers. You're on a cruise already. Yeah. And they're like, but Brian, we'll give you all this money to stick around for a year. I'm like, I'm not sticking around. Will you guys dismantle my product? And my teams like, not, not happening. And I take my money and I go off and I start like, Brian's logistics software. Company cuz that's where like a, a lot of my domain expertise is. And, I buy a company immediately. Like, oh, I'll buy a logistics software firm. And I find out that like my logistics software firm uh, services like truck drivers and dispatchers, well truck drivers and dispatchers, like the software that works for truck drivers and dispatchers, it's very similar cuz the dispatchers talk to truck drivers and the truck drivers talk to dispatchers. Makes total sense. However, yes. However, however, dispatchers care about one thing, and truck drivers care about something completely different. That's basically they both care about the same things. The only thing, the only difference is their problems that they. Are centric to themselves, they're concerned about themselves, the you know what I mean? The truck driver's concerned about like, what, what's my route? When, when do I have to stop? Uh, am I gonna be, you know what I mean? How's my equipment? Is it safe? That kind of stuff. Like depending if they drive themselves or if they drive trucks or whatever there's a lot of variables., am I gonna be penalized for speaking out about something if I point out a problem or whatever? the problem of a truck driver and the, the way the software flows for a truck driver is very different. So the team, when you go and deploy a software development team to say, Hey, write me great software for truck drivers, that team and their product people are gonna spend a lot of time concentrating on the what, what needs to happen, what are your problems? And then the team's gonna say, how can we solve those problems? And they're going to get to work solving those problems and those problems that they solve. Dispatchers, maybe some, there might be some overlap, but dispatchers are not gonna, they'll be like, I don't care. I don't care about that. Let the, let the truck driver figure that out. They can figure it out. They're smart people. They're figured out, solve my problem. I'll give you an example of a, of a complicated dispatcher problem. Like I, there was um, dispatch systems do this. They, they they go tag people. I don't know if this is, I might cut this whole thing out. It's just a, it's a fun story. It's a fun story for, for logistics when you're like, oh, like how hard is it to be a dispatcher? Right? Like, you're, you're, you're Uh, if you, if all the trucks have little electronic logging devices in the trucks that they'll be phoning home and telling you where the trucks are. So you can map all your trucks over the whatever, region, area, whatever you mean, roll up, roll down so if you wanna know Hey, hey, I've gotta go pick up, I've gotta go pick up a, a, a a, a truckload of something in some area. So Tampa, Florida, for example, I have a, I have a truckload of something sitting on the outskirts of Tampa. I need to know what truck drivers are within a 50 mile radius. You know what I mean? Or are going to be in a 50 mile radius within this window of time, you know what I mean? Before, before. Because a different cargo has different requirements. A lot of variables anyway. Yeah. A lot of variables with the right capacity. All that stuff. Yeah. With the right capacity to drive. Yes, with the right capacity to drive. So I, I need my software to, to understand all those variables. And then when I go, Hey, I've got this, I've got this load. I need to be picked up. Show me who I could offer this to. I need the software to go out, query all that information, and then, and then give me a list that I already know. It doesn't include anything that is out out of my criteria. So , the software for the dispatcher gets very complicated. Everything I just said, applies to the truck driver from the perspective of like, I am a driver. I'm in the area, you know that I'm going to have availability, should I hit all my commitments so I am a stakeholder to the software, but the main person's problem is, I don't know what drivers to offer this to. It solves a very specific problem. For a specific user. So what again, like that was a huge giant ridiculous around the world story. Where I was going with that is the dotted line is like, these people are the experts at what a dispatcher needs. These people are the experts at what the driver needs. And, you can scale your teams and stuff like that depending on like if I write a lot more driver software than I Right. Dispatcher software than I, maybe I need more people over here. But the point is I'm drawing little group dot dotted lines. And I'm not saying that this team over here can't work on software over here or whatever if you're a smaller company, most likely you will be servicing multiple personas. Yep. However, I started this example saying in, in, Brian Cash out money, I'm gonna go buy a logistics firm. Like I'm going to try. To have my team that writes things for one persona only ever write things for that persona. So they become absolute experts. They're the best at solving problems for that specific user. Yeah. What you said makes perfect sense. You wanna make sure that you are trying to get that expertise in the right pod team, whatever you wanna call it. Yeah so that the, the depth, the richness of their product is super I mean, it's as good as it can be. And they, because they understand the problem statement, what, what they're trying to solve for um, they understand all wise. They understand all the why's. Exactly so in small companies, you may have people that are doing double duty, et cetera. Mm-hmm., and that might even be okay. That might even be okay because you know, what you've got is backups, et cetera, but when the company gets bigger or gets acquired, however, it gets bigger. Mm-hmm. things get different because now you've got different forces pulling at these people, right? Yeah. So you have you have internal forces, which is the, the pos that are for product A versus product B. Yeah uh, they're saying here, here's my product, here's my product. Yeah. And teams have to now figure out how they're gonna service both. Yeah. If you don't specialize one versus the other, how do you do that? Right? Yeah. It's difficult. Yeah. I, I see where you're going, but, if you don't specialize the what category, how do you know you're not cannibalizing one product over another or one feature over another with your different teams? How how do you know you're not cannibalizing? Especially I think of like, , I think of visionary led companies, cuz visionary led companies can blow up too. You know, I, I think of all the companies that I've ever seen that start expanding like unchecked expansion. Mm-hmm. Or I think of every sales led company I've ever been at or interacted with, where their salespeople are going out and finding new audiences and selling things and everything's selling like, like wildfire. but the users of the software are so different that every time the sales makes a sale of the product, they leverage some feature that doesn't exist yet to be like, oh, if we just add this one thing you'll sign, okay, well why don't you sign now in the next X number of days, 50 days, 30 days, 10 days, whatever it is, we'll implement the thing that you need and now the development team is under the gun to implement whatever the feature is in, in whatever the. Contractually obligated deadline is basically the salesperson wrote a blank check. Oh wrote a blank check and the development team's gotta cash it like that. You know, that, that's an effect of the the what is very murky because you have, you're servicing different personas to hook onto, I guess I'm talking about personas. No, that, that's, that's absolutely right. I've seen that. I've seen that where parts of the sales organization is servicing, let's say the government sector versus Yeah, yeah. You know, the private sector. Yeah. Things like that. So yeah, it can get very murky. Yeah. And like, I'm like, I'm not trying to beat up sales and like, I, that's, that's not where I'm going with what's going well. No, we need, we need sales. Where I was going with this tirade was. At, at when the company starts expanding and you have different products entering the mix, the what is getting less focused. That's where, that's where I was going, less focused. So whether you have multiple teams working on one product or multiple teams working on multiple products, or the worst case, which is one team working on multiple products, that's the worst out of this regardless of what it is, like you, now, you're losing focus. So when you're losing focus, I, I think the only thing you can reach out to like a, like a, like a drowning person, the only thing you can reach out to is like, what, what is our why? Why are we doing this? Who are we servicing in the small organization? The founders are playing that.. I can tell you why I just said, come into my office. I'll tell you all about the, the deep, deep, deep problems that this segment of the market has, or this user has, or this persona has basically right now that my company's expanding and is servicing maybe different segments of the, of the same market or maybe branching out into different markets. Who does that role now? Like, do we have to bring in product now? I think there's very little choice at that stage, right? Because what's happened here is you've got, you've got different products, I'm assuming there's different products. Mm-hmm., uh from both companies. Even though if it's a huge overlap, there's still different products, right? And they need to be understood right by people. They need to be owned by people. And if you don't have product here, what's gonna happen is may. Yeah. Well, I think if you don't have product by this point in the company, you'll be, your culture will be doing projects. You'll try to handle it. You'll try to handle them as a one-off. Like we, we can throw this out there and then toss it over the fence and then ride off into the sunset and, you know what I mean? Get rid of the entire team and never look back. And then it basically the customer will get something and they'll be like, mm, this isn't exactly what I wanted. I don't know about this. You know, maybe if it did this and this would be a better product. Like, I, I think at that point you'll get people that pay for your stuff and then like, use it for a while and then never renew or, or, or never use your product in the first place. They, they get it, they try to mess with it and they discard it. You know? That's how you lose customers. So let's, so now it's a mid-size company, let's say. Yeah we have, let's assume we have product. Yeah. Because the other alternative is much shorter. Talk about, oh, we have to, at this point, if we have multiple products, we have to have product people. At this point, there's gonna be at least two products in the lower case, right? Yeah. Because you have company A, company B likely there's gonna be multiple products. Right? So you have product, they come in. Now, what are some of the issues that you see here? It's now a single company, but the mindsets of the company staff are still divided. Okay. Okay. I'm going. I, I see where you're going. So, so the most obvious problem now that we have right now is, even if, even if, let, let's say one company had product people and one company did not. Yeah. Cause they had founders. Right? Right. One, one company had it. The 20 person company, Brian and Om's, software development firm had founders and we knew everything. So you mean Well, you knew everything. And I just . I just waved, took the money and ran. Yeah. I just waved my hands and took my money and ran, cashed out I, I had the patent. That's what, that's what, that's my contribution. I did the paperwork and and the other, the other company, the acquiring company now they have product people. So there's a transition period, you know what I mean? You're working with their product people and you're still kind of serving to anchor the business until your contract is up at the end of the year and then you've cashed out or whatever. You've gotten your golden parachute or whatever. And I was like, I don't know why I'm harping on this so much , because it's hilarious. What I think you will have problems with is company A over here that was run with the founders involved and company B over here that like, kind of like graduated to having, like handing off the product people. What I expect is the product people will come in and be like, okay like we'll set up some product stuff, we'll do some personas. We'll start learning our users, like the, the product people will know what needs to be done.. Okay. Assuming they're not just marketing people that are called product people, right. Assuming, assuming, but we'll, we're, we're gonna go out on a limb and say they have real product people for a second what I do expect to happen is all these people over here that would just get together in a company meeting and be like, this is what we did, and Oh, this process isn't working and whatever. I expect the two companies to have big problems sorting out how things get delivered. Like maybe one, one organization is completely on board with test driven development and the other, other organization basically like their product. People just like clicked through the site when it went live and said, this is good enough one company went and installed stuff at pajama parties in the middle of the night on servers and the other companies completely containerized that they don't do that. There was some discussion about like, wait a minute, wait a minute. You can't touch our server. Right? Whoa. What do you mean we can't touch the servers? Like, how are we gonna deploy any software? We can't touch the servers?., that discussion now has to happen and it's gotta happen with a fairly high priority . So that the, the, the, what I think of is a definition of done right? But we're gonna, I'm trying not to use terms that might scare people or whatever. I'm trying, I'm just trying to say the w the ways of working. The process of how the software gets developed needs to be discussed and agreed on between the two teams so that a definition of done can be established, amended whatever between the teams and then the other team that never did any of that kind of stuff can kind of come up the speed and learn what they need to do. So cuz you're merging two, two different teams that do things differently. Absolutely. I agree fully. That's where I was going with the mindset question, because you're gonna human beings, right? You're gonna get that the quicker that's addressed the better. Usually the acquirer company is going to basically put down the rules and say, this is how we do things around here. At the smaller company we had regular cycles of just adjusting a little bit to get back on. Now when we're going through and we have wildly different teams coming together, so when the two teams come together, they need to spend more time upfront trying to figure out how they can consolidate their ways of working, to, to bring the two worlds together to, to coexist and work together, right? Just like a backlog, refinement for a team that is brand new. So if I'm leadership and I say, Hey om thank, thanks for , staying on at Brian and M's. Software development company. It's now just Om's development company Om and Om plus corporate overlord development company. Like, thanks for staying on , I need you to , get these teams working together. Okay. Well, in order to do that if I were to go to to you and say, Hey, you're gonna develop a brand new product from the ground up, you'll say, well, I, I need some time to, to seed a backlog. I have to build a backlog from the ground up. Like what's my first epic? What's my second epic? What's my what are my initial, what are my goals? What is my product vision? Like? You'll have to sit down with your team, bring stakeholders in and talk about it all together. Yeah. It's gonna take time. Absolutely. It's like reset for me, right. Coming from that small company in this example. Yeah. It's a reset. It sure is. Yeah. So I'm gonna start with the basics, right? Why are we in business, right? I mean, we'll just start there and, and go from there. Which is gonna be painful for the company that's been around and just been doing things that, their way, so to speak. Mm-hmm.. Now, if they don't have good practices, this is where the friction's gonna happen. The small company that got acquired, it's gonna say, we had all that figured out. You are saying don't do that. You're deploying in the middle of the night, all that stuff. What's gonna happen is there will be some friction, maybe more than some, you're gonna lose some good people. Yeah. That's what's gonna happen here. And we talked about this being an issue on the, the how side, the how circle, but it's also an issue in the what circle, because ways of working are different between the two companies. Yeah. You know, people are working from different perspectives from a larger company versus small companies, small company. Maybe they, they. Their niche product that hits certain personas. They've got those personas well defined, et cetera. the larger company, on the other hand, may or may not be in that same spot, right? Mm-hmm.. So again, you're gonna have those issues there, probably less so than in the how circle, but yes. You'll, you're still gonna find them there. let's say for example, that whatever exists of Brian and Om's software development company in, in, its in its current acquired form. I'm random, random corporate executive, whatever, a CTO's, cfo, whatever, you know what I mean, in the company and I say okay, like enough of this, like we need to integrate these companies I'm gonna go out and I'm gonna hire like a enterprise agile coach to make sure that like we're, we're meshing and, we're integrating together over time. if you were to come into a company like that where we're, we're integrating two companies together what would your game plan kind of be? Would you go to say like, Hey like, let's establish the definition of done. Let's do some basic working together stuff. Because I, I would assume you would do something like, make sure that your product, your product function is operat. Well, you know what I mean? Communicating that kind of stuff, but also development team to development team, you know what I mean, in between development teams is also cooperating and talking to each other and working together and stuff like that, you know? Yeah. You're absolutely correct. So the first thing you said, you know? Yes. Well, the first thing, first thing I would do is nothing. I would probably just observe. Yeah. Observe, yeah. Figure out what's going on. Sure. And then come up with a game plan, certainly will be based on some base level education, right? Mm-hmm.. And the point thing there is not to single out the acquirer company and train that group of people only because you're assuming based on your observation. So you're assuming that the company that was acquired had everything perfect which I haven't seen yet. Yeah. So everybody together do base level sets of delivery of Agile education. We'll split it that way. Establish some good sound principles and practices, get the tooling set up where it makes sense. And then the, the next order of business pretty soon actually for me is going to be to integrate the teams in a literal sense. So this us and them thing, it's what I have to break up. Right? Right. Yeah. So I may take a developer from the acquirer company and put them in another team. Mm-hmm. from the other side. Mm-hmm. and vice versa. Mm-hmm. We talked about the how still, but even on the product side, do the same sort of thing. Let them understand their ways of working. Yeah. Let them commonly agree or disagree on why are they in. Who are the customers? What are the products? How can the customers be served best? Yeah. What are our delivery channels? I mean, the whole plethora of questions so that will be the game plan initially, but you'd still have to put out some markers out there to say, how do you know if it's working well? Right, right, right once you get into that integration phase, you'll be able to gauge as an edge coach, you can gauge how well it's going after a very short period of time. Mm-hmm., like literally maybe a month. Mm-hmm. And you make minor adjustments to the process. Now it's not the time to really make big adjustments because the whole thing can come tumbling down because people haven't really established that trust with one another yet. So, minor adjustments and minor improvements. Building up the, the product side, and the how, the development side. All right. I mean, the third side that is almost always not discussed is the leadership side. Cuz now you've got leadership from both sides too. Well, that's right. I, I feel at the point where I like the, the CFO or CEO or whatever, I, I feel at the point where I bring you in as an enterprise agile coach, like I'm bringing, I'm also bringing you in to tell me like what, what am, like if I'm the cfo, for example, just, just, just to pick a random C-level executive. Yeah. I, I could pick operations or the ceo, I really could pick anyone I'm picking on the cfo. Cuz the easy, easiest to say like why am I paying for all these development teams? Mm-hmm. like, what, why? Like, Hey, I acquired this other company and I got all their backend systems and I go their source code and whatever. Why don't I just fire their entire team and my developers can maintain their product backlog. I don't understand why I have two like I, I, so I'm bringing on an agile, agile coach to basically tell me like, cuz I don't know anything about developing software. So not only am I bringing on an agile coach to help me understand what I'm paying for, Again, the, the people at the top of the company that pay the bills and stuff like that, like they, they, I can't expect them to be experts in what works in software development. So they're gonna bring somebody in to help them, even if it's only whatever, three months, six months, whatever it is. Yep. That, that's kind of why I'm going down this road of hey, maybe the people at the top are looking for help. Or I say people at some, maybe the people upstream are looking for help on how to better communicate and, maybe the people dealing with the what and the people dealing with the, how maybe they are loaded to their max with all of the activities in the, in the, in the company. And I, I'm gonna bring on somebody to kind of be a a, they're out of the day-to-day work. They have the ability to be with me at a leadership level to give me a, a clear opinion, an unbiased opinion, with clarity, because they're not stuck in the day-to-day work. That's what I'm trying to say. Yeah, no, I think they used the word there, unbiased. I mean, somebody coming in isn't really vested in one side or the other, or any side really. They're just coming in looking at it and kind of almost holding up the mirror and say, this is how you guys look. Right, right, right. Now let, let's just acknowledge that the status quo and then how we go forward from here is that's when I would partner with the, the leaders, like the directors of development, et cetera. Right, right. This skills matrix and say there's some justification. Get the hard data and say, you really cannot support that product. You cannot fire all these people. Yeah. Maybe, maybe we can do some reorg, but it would be foolish to say you can just cut this loss. Right, and take 'em off the spreadsheet that that's not how it should go. Maybe, I don't know. Yeah. But that's the sort of thing that you would do is go in there reason, armed with evidence that, this is your proposal and this is why, and the, and the numbers back you up. I want to ask you what the ideal situation looks like, at least as close to, to it as we can get. What I think the ideal situation looks like is all of the product managers with, I don't know, maybe a rep from each team or whatever, all the product managers basically are meeting on a regular basis, regular cadence. I'm just picking numbers outta the air. It could be whatever it is for your organization, but for, for Brian & Om's development company we've chosen the proper cadence is once per iteration. All the product managers are gonna get together, talk about what's upcoming, talk about the, the initiatives that the business wants to get into. We're gonna have reps on that call from all around the business, and we're gonna have the decision makers from the business on the call to say, yes, this is what I want to commit money to. Or or maybe, no, I don't want to commit money to that. Or maybe, maybe like, Yes, I do want to commit money, only a little tiny bit or you need to prove that there is a, a, a market there before I commit money to it. I've seen that a million, million times. Yeah that happens on a regular cadence and it's, it's constantly going forward. That gives leadership confidence that the product people are moving forward with the top business priorities. While that's going on, there is meetings happening on a regular cadence as well with everybody from each of the development teams to say, these are the things we're working on. This is how it might interact with the other teams. This is how it might not interact with the other teams. Also, in addition to that, they're saying, what can we be doing process-wise to improve the lives of all the teams, together. Product might sit as like a stakeholder in that conversation, but product normally that, that, that meeting is probably like, so in the weeds. That product is just like multitasking and listening and whatever, you know what I mean? And in case they're called on, they're, that's the only reason they're on that call the, so assuming we're at a point now in our company where we have those two processes working and both are healthy a producing healthy results. That's what I was gonna say. Yeah. I, I fully concur that in that scenario where product is meeting on a regular cadence probably depends on a lot of stuff, right? The nature of the product to what degree, various products, it could be several dependencies, et cetera, et cetera. Yeah. Yeah but let's assume that the process is working pretty well. When the the how side that circle when they're meeting for process improvement, then yes. Products at the table, more of an eye on the RACI. More informed maybe, maybe c maybe consulted if there's something that we want to change about the intake process or whatever it might be. So in that scenario, yes, but mostly it's the eyes that there, this there is informed. I also wanna say you asked about the ideal situation. So if I had the magic wand, the ideal situation would be that vice versa would be true. So when product is engaged in conversations about product, you would have somebody may maybe multiple people from the how cycle attend those meetings to primarily to understand, but also to interject when things are getting to a point where technologically feasibility becomes fuzzy, right? Yeah. They, so for example, they say, well, can we do this, this, and this? And we, we can do that on five different mobile platforms or however many there, there might be, right? Yeah uh, development can, can say, You really cannot do that right now. Uhhuh, maybe next year or whatever, whatever might be the case. Yeah. So hearing those pivots early on and getting to pivot early on is key. Mm-hmm., instead of going down the road in terms of product ideation and then coming back saying, this is what we want. And that's when the development folks will go away, the architects maybe mm-hmm. go, come back and say, no, it can't be done with these three platforms. Yeah. That's, that's shortening the chain. Yeah. And that's very, very easy to do. Cause , you're having the same meeting, you're just having it now instead of then mm-hmm. Months later. So that would be something that I would, in an ideal situation, would love to see that. Yeah. I wanna dig into the, the multi-product environment that, that you were talking about right there. If there are multiple products, each product having its own roadmap, like now there is like, there's the what meeting, you know what I mean? Of like, here's what's going on in the business and now that, that what meeting spans multiple roadmaps for different products. I feel there's a higher level meeting now that is, is basically. A high level business intake, like the, like the, the true leaders of the business saying, Hey, we need to, I'll give you just here's a random example outta the air. I'm gonna go with this example. It's not a great example. Hey, we're in a recession, and our customers are all not doing great financially. So this is not a great year to raise prices by 10%. So we're gonna lock in prices with a 2% raise. So we don't have a lot of money to give employees. So what we need to do in order to have a little bit of extra bandwidth this year, Is we need to reduce the cost of maintaining all of our systems by 10%. So now I, I, as leadership, go to product and say, Hey you need to bring to your teams, we need to reduce the cost of all over the systems across the board, 10%. The business objective I'm looking for is my final number for what it costs to run all of the systems, teams, employees. Everything is 10% less than what it was last year, so go figure out how to implement that. Now, whether that's a reduction in the amount of servers, whether whatever it is, I don't know what it is, but, there's now a higher level like leadership coming down, and now all of my individual products that have their own roadmaps are figuring out how to take this, oh, this is the number one priority. Now they're figuring out how to take this and bring it back to their backlogs. And engage your teams to say, what can we save money on? What can we reduce? Can we do some cleanup on the database? Can we reduce the number of servers? Can we reduce our spend on Azure or whatever, whatever you're spending money on? I don't know. I'm, I don't, no, that's a fair point. So when it comes down from up on high like that as a business initiative, you're almost looking at senior leadership, deciding where they're putting their money or cutting their costs, right? Sure and that, that does transcend all of the different lines of product. so everybody that has a product that the product folks will take that objective and then go to their teams and figure out,, but there's value in them talking to one another about that objective as well. Right? Sure. For example, just taking that, that, that example you cited you wanna cut the cost by 10%, you're gonna engage with your ops folks, et cetera. Mm-hmm., that's fine. Maybe you come up with some creativity there maybe you can say we've been very good to our customers when it comes to support, right? we've always had people available to answer the phones twenty four seven. Now, what we're gonna do is to say that, that answering the phone, they only get that between say, nine to five, right? Outside of that, there's a premium to be paid if they want the answer so try and try and raise a little bit of money that way. Sure. Another example is maintenance contracts that the customers are on. Mm-hmm., get them to sign up for multi-year contracts, even if it means a sliding discount. Mm-hmm., so you get the cash upfront. Mm-hmm. There's all these things. The reason I, I mentioned those two things is. When you think about cutting costs, everybody goes straight to how do we cut costs? Fire everyone. Yeah. Fire everybody. Shut down servers spin 'em down when you're not using 'em. That kind of stuff especially on the call. Raise the rates. Yeah, exactly but there are other ways. So I think the product folks talking to one another germinates these ideas. Yeah. And I think that form is very, very important. Brian and Om's software development firm, we sold out we cashed out, O m stayed there for a year or whatever and now like the, what, what was a 20 person company is now like a hundred person company. Yeah. And then at some point a private equity firm comes in, is like, Hey, you know what? Like we need to be in this market space. We're gonna go buy eight companies that are all about a hundred people and merge them all together. And now there's ultra chaos. Like, it might not be this way, it might it like you might naturally grow from a hundred percent company into a 500% company. I see that all the time. where, hey, we were in this market segment and now we're gonna expand to this other market segment. And now there's all kinds of unchecked growth throughout the business. You know, we, we, we move our product into another line of business. Maybe our product was marketed specifically to restaurants, but then we discovered that like every hotel in the world also has a restaurant inside of it. So now we sell to restaurants and hotels. So now we're a restaurant, hotel company, but also we don't know anything about hotels, so we have to hire a bunch of people quickly to be able to service that market segment. So now we're expanding rapidly. So it's, it's, it's completely conceivable. and I'm not this is not over like a 30 day period. This is like a two, three year period. Yeah. Like we go from a hundred people to 500 people., whether we are bought by someone and merged with someone else, or whether we grow organically, it doesn't really matter. We went from. being able to manage all these relationships and now, now we are big, and that's, that's assuming that we don't get bought by Google or another company like that where they're just like, Hey, we like your product sign on the dotted line. And also we don't need you anymore. Right. Or, or, we like your customers. We don't care about your product. We're just gonna run that dry. Yeah all right. So yeah, I mean, if, so, if I've hung around from when we sold our little mom and pop thing, I don't know why you would. I don't know why I would, but what happens now? So in terms of the two sides of the. house, so to speak the two circles that we spoke about, yes, if you've grown organically, you may have less of an issue because you had the luxury of growing from within, hopefully. But yeah, hopefully but if you got, if you got bought by a bigger company, you're gonna have the same problem. Only now there are more products, there are more product people. Yeah likewise on the other side, more developers, more teams. So the whole thing exacerbates as the problem statement, right? Yeah. Yeah. The flip side is the people that bought you have probably bought others and they're trying to assimilate everybody together. Like that just happens with the same ease as it does with them putting numbers on the spreadsheet together. No so, Coming in to that sort of an environment, you have your work cut out. Yeah. And at this point, this is where you quickly have to form alliances. Mm-hmm., you have to figure out who's gonna help you get to where you need to get to. First of all, there is no equilibrium when you go there. Oh boy. Right. So you've gotta reach to a a point where it, the ground is still shaking, but it's shaking the least. Oh boy. Did, did we just transition from a podcast about having a functioning what and how cycles in your company to a podcast about how to build influence in the area in which you are responsible inside of your large ecosystem that touches other ecosystems? Cause for product managers in organizations where you are not directly responsible for products. You only have influence in other backlogs, basically. Mm-hmm. We just jumped into the podcast of, Hey, look, welcome to the company. And also like you are not in control of anything and nobody reports to you. So I hope that you understand how to exert influence over different segments of the company to get what you need done to make your product successful. Everything that worked before now that we're 500 people, a thousand people, 1200 people, 10,000 people, whatever. Um, doesn't really matter. At some point when we broke Dunbar's number, we were like, we were driving on the road before stopping at stoplights or whatever. And then when we broke Dunbar's number, we were just like, we were like a, a a a Doc in back to the future. We were like roads. We don't need roads, and well, we're just flying around everywhere. You know, cause like now nothing there are no rules and nothing matters. Like the only thing that matters is do people care about your message organizationally? And will they stop to listen across whatever business units or product lines or whatever? Yeah. I mean, we can, we can continue down this path or save that for a separate, dedicated podcast. I don't want to, yeah, I don't want to continue because I don't like No, this is a separate podcast. Yeah. Functioning in an organization of a hundred thousand people, the largest organizations. Uh, how much of your job, what percentage of your job is just connecting with people and just maintaining relationships so that one day you might need those relationships to say when we test things we have unit tests on all of our code and we have automation and t d d in all of our code. And your product that we intersect with, that we whatever hand off to or integrate with or whatever, doesn't have any of those tests that's gonna be a problem at some point. It, it sure is. I mean, when you jump into a company that big, let's just say 1,000 thousand, doesn't matter. The biggest companies are three times that big. Sure. But there, there you are not gonna have binoculars to see past just your little sphere of influence um, and anything that's happening beyond that is simply made aware to you by looking at the company bulletin. Mm-hmm. like, this is what we've done over there. Mm-hmm., that's it. You don't know what's going on really over there so it becomes all the more critical at that point to say, we're gonna take. Two or three things that we're gonna improve on and you're gonna sell that just to your own team first? If you're a product person, you're gonna sell the idea to your product manager and your development folks, right? Mm-hmm. that. That's it. Just, just our little microcosm and see if we can make success happen based on that assumption. You're testing, it's like an experiment almost. Yeah. You're testing that out. If it doesn't work, well stop as early as you can and pivot. If it works well, you can now, whoever's asking about it, or you can tell a few more people about it. And you build out that way. Mm-hmm. It takes time, first of all, clearly. Yeah it also is fraught with a lot of risk because no matter how well your, your experiment is going, someone's gonna come back and find a way to spit on that that just happens when you have 10,000 people. Yeah. That's where you need alliances even more, and I'm not gonna go back to that, but you do need people to say what we're doing Makes sense. Yeah. It's not one person, just some wacky person saying, let's do things this way. It's gonna be multiple wacky people saying the same thing, more or less the same thing. So that has some gravita to it. So when we were in a slightly smaller company, we built a a, a community of product managers and we built a community of dev team representatives. Now that we're in a, a much, much, much larger company and a much larger ecosystem, you know what I mean? We got bought by Google, congratulations. We we're we, we can all buy mansions now we still have to set that up to be successful. So it sounds like what you're saying is you want to reach out to the people that kind of align with your way of thinking or your way of working, or your product or whatever. The people that kind of naturally align, you wanna reach out to them first and start rebuilding that circle. Mm-hmm., no matter how small or big or whatever that circle is I, I'm wondering if, if like the what and how we talked about before were like functioning cycles that drive the business forward. Now I'm wondering if it's, if it's functional cycles that drive the business forward inside of smaller business units. Inside a larger organization, but also if it's like, if there's like a community of practice slash interest element of it as well on top of all that. You know what I mean? So when you say community of interest or practice, these are mainly around adoption of practices, right? Yeah and you can definitely do that and they can transcend all these, I'll say, political beliefs that persist in an organization within groups. Yeah because it is what it is, right? So you can have external people come in and, and you know, wax lyrical about good practices. You can do all those sorts of things that doesn't make those people adopt them. Yeah. They simply attend their optional most of the time anyway. Yeah. If they attend, they'll attend and say, that was interesting, and then they walk away. It doesn't make them say, Hey, this is something we need to do, that unfortunately is grassroots. It has to grow in from, from like, from one little sphere and it's gonna be small initially, but once you have success, you can now really expound on that, tell people about it, evangelize it and touch the next layer that is on the periphery of your domain. Forget about all those other people that are doing things that way a different way. That's fine. They're gonna continue that way. But yeah, soon, very soon people will realize that what's happening here is of value. Yeah and that's when you can start to grow that. The downside to this, this idea, there is one downside and it's significant and that is, it depends what your role is in the organization. If you are a product person or if you're a development person or if, or even Azure coach really, I mean, just in one little area, one of. You have your work cut out. Yeah. Because other agile coaches, I speak for them, they're gonna find 20 reasons to think or, and tell you why your way is not the best. Oh boy. It, it just happens that way. So if you have influence with people that can drive decisions and that takes trust and all of that, then you have a better chance. That's it. And a podcast. That was such a great exit that I don't have anything to add after that. Cool. We talked about what happens in small, tiny, small companies. We talked about medium sized businesses. We pretty, we pretty much talked about like positives and dysfunctions in medium sized businesses. We didn't really harp too much in this episode on uh what happens when you get someone's like, just like, just do what I say, you know what I mean? That kind of stuff., I feel we harp on that. Let's, let's save that for a different podcast. Well, we harp on that so much on our regular podcast. I, I feel like people that listen to this, they, they understand our viewpoint on that. So I, I like that we're like, Hey, this is how you know that things are clicking. Right? Well things are working well that you see these things going on and then it got real murky when we moved into large companies cuz uh, cuz things are murky. Yeah, exactly. That is exactly right. So things are murky when you get to a large company, right. Lots of, lots of forces at play. Well, yeah, you, I mean, the, the thing for me there is like, yeah, you can't separate the political from all of the operational and strategic and all, all the things you're gonna be dealing with like that. There is, there is a political element. You have to be spending a good amount of your time making sure that you are bringing people into your uh sphere of influence, basically. Yeah. There's not really anyone out there talking about, I don't think that should be a big thing in the scrum master uh, trainings and whatnot. I was like, expanding your sphere of influence and I just don't see it. Yeah. It's lacking. Yeah. Hopefully one day they'll incorporate that. Cause that's not the kind of stuff that you learn in college. They don't teach you that. Well, they definitely don't teach you that. Like they, they teach you about Gantt charts. Oh yeah. Polynomial equations and Gantt charts. That's right. Neither of them I have any use for. That's right. All right, well if you're into polynomial equations and Gantt charts like and subscribe