Arguing Agile

AA225 - The Team That Got You Here: Navigating Growth and Team Evolution

• Brian Orlando • Season 1 • Episode 225

Share episode

Your founding team delivered your first million-dollar quarter - but can they scale you to $10 million and beyond? 

Join Enterprise Business Agility Consultant Om Patel and Product Manager Brian Orlando as we talk through the challenging transition from startup scrappiness to operational excellence. Along the way, we ask about loyalty vs. performance, innovation vs. optimization, and how to manage team evolution without destroying trust and culture.

Watch or listen if you're interested in:
• Why early-stage generalists struggle with structured processes
• The emotional cost of replacing founding team members
• Innovation vs. optimization team dynamics
• Career development and succession planning
• Communication strategies for organizational change
• The role of coaches in team transitions

#StartupGrowth #TeamEvolution #ProductManagement
REFERENCES
AA221 - Steve Jobs' Radical Decision-Making: Why Consensus Beats Disagree & Commit
AA217 - Extreme Ownership: Military Leadership Lessons for Professionals

LINKS
YouTube https://www.youtube.com/@arguingagile
Spotify: https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3
Apple: https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596
Website: http://arguingagile.com

INTRO MUSIC
Toronto Is My Beat
By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)
CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Your startup's scrappy founding team just delivered your first million dollar quarter, congratulations. Now, the same team of heroes that got you across that finish line might be the exact same reason that you fail at scaling. So today on the podcast we're gonna talk about that loyalty to that initial team that got you some success versus the skills that it takes to succeed when you have an operational product to maintain when you got customers, when you got a code base that's getting complex. We're gonna kind of argue both sides of this one, like the team that got you here versus the team that can get you ahead. Which side are you arguing? I'm arguing on the side of the horse you rode in on I think for this podcast I'm gonna be on the side of, there are different skill sets and never the two shall meet. And I don't know if one is better than the other, you can't do both. You have to choose one path or the other. If you try to do both, you're gonna fail at both and then bleep you and the horse you rode in on. There you go. That should be the name of the podcast, bleep you and the horse you rode in on. Be careful with when you get the treasure, because they'll be pirates. That's, yeah, that's right. the, different phases of organizational. Maturity, I guess is kind of one yeah. They require different skill sets. That's my claim. They require different skills. So early stage teams will excel at ambiguity and rapid iteration, all the stuff that we talk about in Agile community, right? Let's say talking to customers on a regular basis. And then when you grow the company, maybe you sell your little Lizards and Wizards gaming company to private equity and they're like, we love this Lizards and Wizards game, but it would be better if you had my Little Pony and like, what the heck? What are you talking about? Why would we do that? Okay, we'll just do it'cause we're all fun people. But like it's, that's not a lizard or a wizard. Why would we include, so you make some compromises and suddenly you turn around and you're like. What am I doing with my life? Yeah. So I like, I, that's probably not the best example, it's a example because we never did get to sail away into the sunset on our yachts after selling that company. But there's hope. That's right. That's right. And if you're Mark Rosewater just think about your life. That's what I'm saying right now. This is gonna be a hard podcast for me 'cause I have been on both sides. I have been the team that is tapped, that comes in after the thing is designed and is like very good at finding the bugs and vetting them out. And also I've been the guy who develops a thing out of an idea, out of someone's brain and takes it to market and launches it to success. So I've been on both sides of this. But I would say only because I have been on both sides of this, am I in tune with one over the other? If I had only ever been on one side of this, like if I've only been on like, well, I only work in startups and they're the purest form of this, where we have an idea and we talk to a customer and we produce something that's actually useful, that solves a real problem. Only if I had only ever done that kind of work, would I be able to challenge and say, well, the other guys that you bring in to maintain your bank software that you know it's gotta be reliable and whatnot., Those people. Can't do the other job 'cause they don't like talking to customers and the organization kind of doesn't like them talking to customers and the organization says, look kid, just sit down in the seat and make sure that every transaction goes through a hundred percent of the time. That's your job is to basically perfect this widget on the assembly line. When we punch it out, it comes out exactly the way. Like your job is not to like, to innovate. listen, I've been on both sides with the same company for over 15 years where it was just a germination of an idea. In the early days before we had intelligent terminals. they came up with this concept. Nobody else had thought of it solving a real problem because it was taking essentially the compute power of a mini computer. The size of a refrigerator. Right. And putting that inside a dumb CR team machine. We blew smarts on EPROMs and plugged them in. So early, and that was the innovation and that company kept those people around in the form of rewarding their loyalty. So they became very good at that. And then the innovation curve tapered off and we had to innovate continuously going forward because five, seven years down the road, we have now competition and the competitors are doing smarter things and we are not. I saw the company essentially just stagnate away until one of those competitors, the biggest in the market, decided to swallow us for the expertise, by the way. So it's interesting, this topic is very interesting. I'm gonna argue the other side, even though I don't necessarily believe in it. It's gonna be a confusing podcast.'cause normally we would just pick sides. But with this one there's too many good arguing points on either side. The first arguing point here I've been through four mergers and acquisitions and every single one of those mergers and acquisitions you have early staged generalists. I use that term. Not, not in the pejorative. Because these people they took their jobs. They were told in the interview, you're gonna wear a lot of hats where a scrappy startup get used to it. And they said, that sounds great. And they learned to love it. And now that you've grown, you're saying, no, you've gotta be a specialist. Now you've gotta stay in your lane, bro. You've gotta stay in your silo. That we built after the business became a certain size and now these people are problems now. Their roles become compartmentalized. Right. So I played a role where as the demonstrator of. Brand new cutting edge software and it would break all the time. But you would go out to trade shows or customer sites and do demos? After that, once they signed the contract, we would go in and do a quick workshop for the purpose of creating a, proof of concept, where it didn't have to produce at the end, but it looked like it could for them before they signed the rest of the contract, so to speak. Then I went back in there as an implementer, so we took the software and tailored it to the customer's use on site. So no two systems look alike, even though they share the same skeleton. Completely tailor it using scripting. As soon as they were live, it took nine months or so roughly. Who supported them? The person who knows their system best me. So I did the full gamut of all those roles. And it became exciting after a while because the variety excites me, right? Sure. Yeah. And then as we grew, especially once we were acquired, it was, well basically you're the project manager now, somebody else demos and then they leave. So that level of continuity with the cus the customer and that trust they put in you is gone. Right. So I lived through that. What are we saying here? The teams should evolve and change Is the four here, right? The four here is that the team that basically built the function should stay together and evolve and change as the function matures and the market around it matures, right? Some of the fours here are represented in my against type. Viewpoints, which is like , the people that you have that got you here who are used to chaotic environments, rapid iteration because of ambiguity and this could be an accusation level directly at a founder to say, these are not the people. They're not good process people. Actually that would be the way it would come across, right? It would come across as an accusation like that. Yes. what I really mean is like, these are not the people that are good with strong, structured, stable processes that they just stick to. They get super uncomfortable when stuck in a box and they just start like melting down, their bad behaviors manifest because they feel stagnant, they feel frustrated for sure. Right. I mean, they thrive in fickle environments. So yeah, I definitely agree with that. The other strongest point here is the rapid prototyping phase of developing your application. That generates a lot of technical debt. It might not be technical debt in terms of like, well we got this large code base of like a bunch of APIs and some of 'em aren't useful anymore and there's a lot of like garbage code in there. We need to go and fix it and we, maybe we got security flaws or whatever. Like, maybe not even that. It's just like the way you design your database structure. You can onboard a thousand users, but if you ever wanna onboard like a hundred thousand users, your database structure is completely insufficient. I was at a company one time where , the onboarding activity required some scripting into the database. Right. Like they didn't have a frontend form to onboard users. It was just like, go to the developers, fill out a form and then the developer inserts into the table until you grow to a certain point, but at a certain point where you're onboarding a certain amount of customers. You basically had to take one developer offline forever. Not 24 7, but basically like your entire sprint, you would lose one full developer.'cause every sprint you would say, oh, the on-call developer does all of the onboarding and scripting and watching the servers to make sure they don't fall over and stuff like that. Yeah. So every two weeks, , one developer would just have a terrible experience until they rotated all the way around the whole development team and they got back to that person and it was not pleasant to be on call.. So those decisions that are made in the early days when you're just rapidly prototyping and getting feedback, they can come back to bite you, right?. Mm-hmm. At some point you grow out of those limitations, right? And now you have a decision to make. So you could institutionalize other processes on top of that, like having an on-call developer, all he is doing is you or she just putting in scripts to onboard new users. Right. Things like that.. But the opposite side of it is, well, we're not gonna onboard that many users until we have a proper onboarding process that's structured, documented fully. Right. We're not gonna put any money into having a proper because again, you're in that phase between like you're separating from the initial founder kind of built in a vacuum and now you're bringing in processor, there's some kind of success. And now you have to scale the founder, remember what I said? this person isn't good at process, doesn't want to get stuck in this side of it. They're kind of frustrated by it. You swap that person out and you get a professional manager. We'll get this person. They're really good at communicating. They're gonna run our business. They were super successful on this other program. I've told stories on the podcast in the past about the program that I was on where they got another manager or director from some other business he was super successful. Everyone loved this guy. He's got a great reputation. We're gonna get him. He's awesome. He's gonna run our business. And he just couldn't cut it. He optimized this for a process. Like, he was like, oh, invite me to all your standups, invite me to all your refinements and everything. I was like, yeah, but you're not the product person. You're not the scrum master. You don't, you're not gonna be developing on the team. So like, why do you wanna be on the team's daily standups? He's like, no, no. I need to be fully integrated in the whole program at every level up and down and whatnot. That's what he wanted. He wanted to be a professional manager to have his eyes on everything at every level. And that dude killed innovation. I mean, he just destroyed innovation.'cause he wanted to have a say in everything. I know the type that come in and embed a process so deep that you're basically just simply Taking on the cost of delay and all that stuff. When you're being used to innovating so well, that's a real experience I had with a big swing from one side completely to the other side. So I was with that team when they were out, just trying to find work, going out into the business, kind of paddling oh, we can do this for you, we can do that for you. They got , some, some, some people that were Their ideal customers, they found their evangelists. they found their people that helped them with their product. And that one team in the business evangelize , what our development team did for them mm-hmm. Throughout the business. And then everyone came knocking like, when can you get to our stuff? You know? And it really only took one market breakthrough. But yeah, that guy came in and that was it. Yeah. That guy. That's what I gotta say. is there a call to action here, like the, you, so your team skills in the phase that you're in and, and also like, I feel we didn't talk about succession planning what happens with this product and this work when we decide to scale it or decide to hand it off or whatever. Like, I know handoffs a dirty word, but I never hear anybody in the space talk about. Do we hire on a team to take this work and then hand that over and then our innovation team, or our founding team moves over to cooler problems or do another new edge of market kind of stuff.'cause it seemed to like dream something up from an idea you're gonna strap them down and hold them in place. I mean, I feel like there should be a organizational conversation about like, do you guys want to keep doing that? Because some people might like, oh, I love this product. This is great. This is what I wanna do. This is my calling. I wanna stay here. And then they stay and then some other people leave'cause they, they, maybe it's not as important to them. They just wanna do cool stuff maybe you split and I dunno, maybe you split the fellowship. I'm just saying like, maybe you're Gandalf. I think the concept or the idea of transition planning is what you're talking about there, right? That needs to be discussed. And so if you are a company that is going through that phase. You've innovated something and you're now getting to that maturity phase, and what do you do? Do you onboard all new people? I don't think it's a step function. You don't just onboard new people that are good at maintaining it, et cetera. Customer support and so forth. And just handoff or transition is I think the new word for it now. But you don't do that. Right. I think what you do is you bring new people in and have some of the team that built it work with them so there's some knowledge transfer and gradually taper away and, the people that built it become more senior over time. Absolutely. I mean, it's like you transition plan sounds exactly right. But also sounds like a promotion path to me, is that the people stay on that program. You get new employees in to take over the thing and move it to the future it becomes a conversation with people about what they want for the future. Yeah. And then the people that wanna stay sort of transition to this like, mentorship role where they're shepherding along the product line and stuff like that. The innovation people get to move over and do some other cool stuff. The people that wanna stay, become respected kind of senior folks on there. In practice it's a little different from what I've seen. You bring new people in, you throw the product at them and say, good luck. You give 'em some kt it's not like that, but Right. But people that were there that built it, yeah. They essentially keep working on new things. And they're, they're like, their department, if you like, is now called the Skunk Works. Yeah. Right. So they get funded for new things. But they're not responsible or accountable to make sure that the product sticks. Like you, you come up with new things and then if you have weak product folks you might actually go to market with some of this stuff. I think we were talking yesterday about when is an MVP not ready? You might get into that kind of situation. Because there's a void. People that are in the Skunk works aren't really thinking about some of the like scalability that Sure. All of those things that make the product stick in the market. Mm-hmm. But yet these new people that come in, they have to sustain it. Yeah. And they have to make sure you don't have customer erosion. Sure. All of that stuff. Same practice. I've seen that happen more than not. Yeah. Well, I mean, we could stay here. All night. Yeah. Like this, this, this category is super interesting, but, there's an organizational design conversation happening as well as a product conversation. And they're both together. I'm worried about most organizations, 'cause most organizations cannot have that adult conversation in the way that I just described as like you're having a product conversation and also an org design conversation. Just have it. I think we are at the nexus of those two and smaller companies that aren't in it for the long run. I mean the entrepreneur simply is looking to get it to a certain point and flip it. Yeah. So there's a lot of that. But those that want to keep going, they don't think about both of those aspects. Right, right, right. Especially the org design aspect. So they're basically just saying, throw more bodies at it. Right. And that's not the answer. So I'm glad you went there because I want to talk about emotional damage. so there is an emotional challenge here about moving people aside who built the company there is no such thing as employee loyalty anymore. Like, if we put that aside for a second, like the, the, The vapid cruelty of being rigged for performance. Over loyalty of the people that got you to a certain level of success, is what I want to say in that vein. Like you're pushing aside people that got you to a certain level of success. Yeah. And like there's a performance at all costs, which I hear in my product management brain. Money at all costs.'cause that's what I'm really hearing.'cause again, like the team that got you there, like these slow and steady wins, the race team that got you there. Like, well, just like why do you, why is like three to 5% gain year over year? Why is that not good enough for you? Greed in a word. Greed. Yeah. But I mean I already know there is valid pushback against like, well if you shuffle the early folks out and you bring in people that really do know how to scale . you can make the scaling phase frictionless enough where you can really leap ahead. So there is a shell game going on of like, well, the founding team can stay in place, but I'm gonna bring in the scaling team and kinda help them help each other leapfrog over all the competition and really take over the whole market. That's a real thing that can happen. Yes. I do have to say, however, this whole, loyalty, it's usually brought into development teams as a loyalty versus we want more money. So, we like that you guys came up with this solution, which helped us corner the market in X, Y, Z, but now you're out on the street. We got these other, supermodels, to get us to the next level. Again, very prevalent out there right now. That's exactly what's happening right now, which is why you're seeing so many people being pushed out. The tough, and again, this is another podcast, is not this podcast, but , the tough part is the market very quickly turned around from being very accepting of junior PMs and people with that three year under. Market and then that, that took a nosedive. Yeah. In the last year and a half. So like negative 24% year over year hiring people in the early stages of their career. And most people want like eight to 10 year pm like experienced PMs. Most people are, they're all fighting over the experienced folks. I'll tell you, like flat out, I don't like it because like you should not sacrifice one side of like giving back to the community and helping train new people. You should never be at a point where you're like, oh, I only want superstars that are performing these eight to 10 year. My whole staff is like older folks who have eight to 10 years experience. I don't hire new people. Like you should never be in that position. This is like take any sports. Right? Right. Any analogy basically applies I think sports analogy here. You don't want to hire new people and train them up, but you know, you wanna keep your superstars right and they're gonna keep winning or the Super Bowl for you every year. Well, good luck with that. That just doesn't happen on a sustainable basis, yeah. We only wanna hire superstar athletes. We don't wanna hire anybody straight outta school. We don't wanna draft anybody we only wanna get the best of the best. I worry for the future actually. If we stop training people, where's the next generation coming from? Who's training them? What does that mean for us as a nation competitiveness, all of that. There's a lot there. But I think this loyalty versus performance thing is. Rife right now. You see so many people at the open work banner. What would you say if I'm a soulless corporate minion and I'm gonna say, well Ohm, you're just making sentimental decisions 'cause like. The company that got the, the, the people that got you here can't get you to the next level. So just like wash all those people out. Why are you being sentimental about This? Is, this is business home. It's business. Oh boy. So it's business. Yes. But they've proven themselves already. Right. Mr. Pe They've already proven themselves. So guess what? They can thrive Yeah. In these environments. And you're not thinking ahead, you're thinking now you're just saying, well, in order to make the books, now we're gonna lay off a whole bunch of people that were there from day one. Right. Great. You'll make the books. What happens next quarter, next year to year after? So I will tell you the problem with the case that you're making right now. Okay. And I'm telling you this problem because , I am very interested in the correct way to push back on typical corporate folks with this.'cause I don't have a good way to push. I will just tell you right now. Yeah. My normal way to push back is like, why do you hate success? Why are, why are you terrible people no, sorry. What I will say is high performing cultures are built on trust. Trust is built over a long period of time working together and learning how to get to success together. And the minute that you break that team apart, even one person, you're setting me back to zero. And now I'm trying to perform for you, but also I have to rebuild that trust that you broke. I'm trying to get to Mordor and one does not simply walk into Mordor. I'm trying to rebuild a fellowship. Right. I got no wizard. My little hobbits are trying to run across the ground together, I can't have you mucking around in my fellowship. At what point, like how can I make this case of loyalty means something? I think you look at results and say, these people have delivered. Right? And in order for us to go further from here, especially if you're in that scaling dilemma that we talked about earlier, right? Yeah. You can take those same people and you can develop them rather than displace them. Because they're smart, right? So let's enable them, and we'll figure this out. But to throw the baby out with the bath water, that's short term thinking. I wanna point out two things right now. This is like, number one, developing people is hard. It takes a level of expertise and skill. And most corporate executives and the people that I was just describing they won't even, they don't even sign up. They're like, I'm not doing that. That sounds hard. I'd rather throw the dice and get somebody else that maybe just like is a seven right off the bat. Yeah. And just keep grinding through people, which is great when you have a bottomless pit of talent to pull from. But in a limited talent pool or a limited pool of reputation. You can only bend your reputation as a company so far until you just don't get the best candidates. There are companies here in Tampa Yeah. That have to pay top dollar for people to fight over the positions 'cause they're just like, they're not great employers. The other point that I wanna make is the message that you send about loyalty by your actions over time that says something. You're right on both fronts there. Right? So the message that you send, if I take that one first, right? That's going to either retain good talent 'cause they see that loyalty is rewarded or at least valued. Yeah. Right? And the other side, you've already made that argument. If you need people and you don't have a culture of rewarding loyalty or valuing loyalty, you're not gonna attract top talent, right? You're just not. Right. You're right about the other side, the first point you made, which is, yeah, these people aren't gonna develop people, they don't develop talent from within. Right. But there's a gap there. It takes time to onboard people. You're losing domain knowledge, and if they don't recognize that yeah. Keep that resume updated folks. Well, I just wanna point out before we move off of this category, like the takeaway here is create explicit career development conversations out of the paths that you see for your teams. So if you're transitioning a team to stability or maturity of the product line, we did a whole podcast about the maturity lines of your business. Yeah. I can't remember what it was. I'm not gonna search for it now, but maybe I'll link it in the references for the, because I'm, I'm getting better about doing references for every podcast. it's not role elimination. You move people where their best. So if people are more like do cool stuff, kind of move fast, break things, not move fast and break the law again, that's, that's what every time someone says, move fast and break things. I hear move fast and break the law now. But if, if you got people that are really good at that, like keep them in that job. Whatever, but they're like, you have to have a one-on-one conversation with people and understand what they're excited by where they want to be, and then keep them over there. Like have a one-on-one conversation, but the career development conversation comes along with the where to move that team or split the team or do whatever to keep your people engaged, keep your products exciting and on the edge of the market. And I mean, there's a lot here. Again, we get, every topic today, we can say on it's huge topics. The whole podcast. But I'm gonna keep us moving. It's not about career or it's not about elimination, it's about evolution. it should be. going back to the previous podcast we did about Steve Jobs talking about if there's people that just don't believe anymore, which is another podcast that goes back to our extreme ownership mm-hmm. Podcast that we did with Ed, where like one of the tenants of extreme ownership is you have to believe in the thing when people don't believe anymore that like, then it's time for an honest career coaching conversation to be like, listen, like no hard feelings, but like, if you don't believe in our products and our direction anymore and you don't want to do what we're doing. Why are you still here? Right? You got great talent, you got great ability, and you should be working for a different purpose. Why are you still here? I can't even imagine being at a place where I didn't feel free to talk about. I don't believe in what we're doing. Like I don't think this is right. You know, I don't think that like having this software that incentivizes people to gamble away their houses and the places their kids live 'cause they're addicted to gambling, and that's, we just hijack that like gene in the human mind. Yeah, I don't think that's right. I don't think we should be in that business. Period. I think a lot of people are muzzled when it comes to expressing their voices and opinions in a lot of companies, sadly. Then it comes down to us as individuals, right? If you feel comfortable working in such an environment. Are you gonna be happy there? But that's a call only you can make sure, right? Sure. Let's talk about innovation versus operations. The teams and team members that are optimized for innovation often struggle against the same kind of mindset that is optimized for operational excellence, keeping things moving, not having errors, kind of knocking down bugs. Right. And then one of which, if you tried to take the team that is good at innovation. And try to force them to be good at optimization, you're gonna kill that innovative spirit and vice versa. If you try to, if you assemble a team that is good at operations and then you, they'll struggle to innovate and then you force them to be like, oh no, I don't understand why you're not innovating. Like, you're not gonna get that outta that team'cause you hired and you optimized for this thing. Is it fair to try to ask one of these types of teams to do the others' jobs when your organization grows and they're still in the same spot? So just to repeat back a little bit of what we were saying earlier, while your organization is small, you probably have a team that does everything. Yeah. But as you're growing, these are different characteristics, and these characteristics often are born out of characteristics that people bring with them. It might be better to ask each team member what do they want to do? And you could even consider something like moving people back and forth. So do a tour of duty, go from one team to another so that they can experience it and learn and come back to their team. They can do that. There's nothing wrong with that. But don't force every team member to rotate like that. Only those that really want to. Yeah. I'm worried about moving people especially the more junior folks, because depending on the speed at which you move them from team to team. It could be considered context switching. I also think about a team where you built a product and now we're asking you to maintain the product, but also still kind of explore the market where you're in this middle zone where we haven't decided we want to split your team yet. So now you're doing a lot of context switching. You're doing a lot of interviewing, trying new things, but also you have to optimize. And , now we're in a budgetary kind of argument of like. How much of my team's time goes into , stabilizing versus the Yeah, that, that phase that , you mentioned. That's the tricky phase right in the middle of it. Right. I call it the boring phase. The boring phase, the twilight. So , what you can do is this is why I say don't take a team member inside. Part of your time is spent here, part here partly. That doesn't work. We know that , this latest fad of calling people fractal, insert expertise here. Now if you're talking about part-time, that's different then call it part-time. But I think what would be better is to say to a team member, are you interested in understanding the operational aspects of the game? If you are, how about you spend a week, two weeks, a month, whatever, right? Whatever it is. And it doesn't have to be the same duration for every team member. Let them pick. How about that? So as a team member, I could say, well, let me go over there for a couple of weeks. If I like it. I might stay longer. If I don't, I might come back sooner. You've gotta give them the latitude to do that. Yeah. And I think things will fall into place if you give people the rope to work with. Have you ever been with a team who's like, great at like. Customer interviews and like really vetting out what the real value is with the customer when they're with the customer. Let me think about what, what they would be like. They're real bad at estimation. They're like, oh, it's gonna take like two days and three weeks later., What are you guys doing? It's three weeks. You said it was take two days. That was two and a half weeks ago. When they deliver it is absolutely like solid gold, like liquid gold. And the sales seems so excited and everyone's buzzing about it, but , they're just terrible. And you just have to like get over your you know what, maybe it's just me expecting them. I think you can support these teams. Don't have the people that aren't the best at doing estimation do the estimation. Those doing the work should be doing the but I mean, that's an example. I get it . so I think in the case of. Moving team members. Why a lot of organizations get this wrong is they wanna compartmentalize roles. Right. You are in this department, so that's where you go every day. This is part of optimization where you're going this is part of the opposite, like the innovation people they will get hives with even just what you're talking about. Like, they wanna come into the building and sit at a different chair every day. they wanna work from Starbucks around the corner. Yeah, that's fine. A failure of organizational leadership to recognize that. And then to yield to it and say, yeah, this is fine. But again, this innovation versus optimization trap, this goes up and down throughout the business. You need leadership that is used to ambiguity and is, and, and like, wants more frequent check-ins and is like they want to be closest to the work. To support these kind of teams because if you bring one of these professional managers in that just wants a quarterly check-in type of check in box, they're not gonna be good with this. Yeah, yeah. Where you're going with this, they're not gonna be good with that. They're gonna be very uncomfortable with that. And then you're gonna have some super uncomfortable conversations . With them. Definitely agree.. Yeah. I mean you will know if you are misaligned. If every time you talk to someone who's like your boss's boss and above, it's a very uncomfortable conversation. This is this setup right here, this innovation versus optimization. This setup is like not optimally dialed in. And the funny thing is, the way to get this dialed in is you need to have a lot of uncomfortable conversations at the level of the decision makers. Go back to our last podcast that we just did with about Steve Jobs and like who makes what decisions. It's probably not clear who makes what decisions. At all, right? Like, not only is not written down, nobody even knows, you know these problems just snowball and get worse and worse. the optimization versus innovation, like what we, when we were planning this podcast, we said the reality of this category, 'cause I didn't like this category so much. So the reality of this category is ideally you should be taking your optimization people and your innovation people and you should be kind of mixing them every year or so six months, a year, a good period of time. And ideally what you wanna be doing with that mechanism is you want to be teaching the optimization people that they always need to be looking out for business opportunities. Innovation opportunities and the innovation folks, you need to be teaching them about building maintainable systems in the long run. And you want that to be a cross-functional skill. So, oh, I'm a developer. Okay, that's a cross-functional skill. And most people will look at that and say, okay, that's, you're a developer, a quote developer. But I, as a product manager will look at that and say, no, no, no, no. You're a, you're a optimization developer, you're an innovation developer. If you're a developer, can I pick you up and have you join my team? Where every other week, the broad priorities are changing completely, 180 degrees, completely different from what we were doing the week before. And you love it. There are some people that love that kind of work. And then there are some people that are like, I don't understand what our goal is. I'm completely lost. I don't like this. And there's always friction. And those are different people, I would say that is a different development. Not development meaning like develop a writing code. I mean like person on the development team, personal, personal development. And honestly in, in the business business, that is a different business skill. I think where you're heading is the onus is on the organization to encourage and make, to encourage people to essentially learn. Hybrid skills so they can thrive, right? You can thrive in one area or the other, but you should really be able to initially, perhaps just survive in the other area, right? But that requires commitment on the part of the organization, which most organizations they never recognize when they have outgrown their current organizational structure. And also they don't have any kind of checks and balances or mechanisms to say, Hey, we're at a plateau, right? Where do we go from here? When I was at that phase of my career where I thought I wanted to be an Agile coach, I was like, no, this is terrible. I don't ever wanna do this. This was the biggest problem is like, I could see so clearly , oh, you guys are at an organizational plateau. And it's obvious to me, you haven't just taken a step back from the edge of the precipice and said, how should we get across? What should we do? Because most people are just like, their brains in the organizations are moving so fast, they come up to the edge and they're just like, oh, I gotta jump, I gotta jump. I can't think of anything else. You know, they just can't, they can't slow their brain down and say, let me step back from the problem again. This is all stuff we talked about on the extreme Ownership podcast. With Ed, you have to step back from the problem. Take a moment when you're too close, you can't see the forest for the trees. That's right. I mean, over the years we've built up certain organizational designs or structures. They may have worked in the past, . In the sixties, seventies, eighties. They haven't evolved. We're still working essentially in the same sort of structures. Right. And that's a huge problem. But I feel, if I'm gonna argue in the vein of this one, the warning signs are there, the worker level people can see the warning signs well ahead of time. Oh, for sure. For sure. But if you're in a culture where nobody listens to you, you're not gonna say anything or if you say something and then you find yourself typing out resumes again because that's what happened to you. So we talked about warning signs are usually visible and at this stage most organizations go into this reactive mode of, they only make org changes and org design changes when they're in reactive mode. And I think this is the worst 'cause now they're just chasing what's happening. This is the worst org design when I usually come into organizations is like they're leadership and whatnot. They're only reactive. They only react to things. They're not proactive at anything. They don't ever look at the current org structure and the way like, Hmm. Does this lend itself to the organizational decision making and efficiency? No, they don't do any of that. You're right. They don't do any of that, and they usually react to some kind of stimuli. Right? Right. Usually it's an external stimuli, like the customer says, Hey, you guys are delivering way too slowly, or You're not, we're not hearing anything from anyone, or whatever it might be. Your sales might be saying, well we're not getting things out to the market fast enough, or whatever it could be. A lot of their scaling problems or problems with speed are actually process problems or communication problems or both? Ultimately, those three things will sink or swim. A company is swim, sink, or float. Definitely. So there's varying degrees of those symptoms that they could be experiencing too, right? I mean, the funny part is like especially in the private equity bias, right?'cause they're the worst. They're the worst because like, they're the ones where like, people that have come up and built this successful organization, the human relationship starts breaking down between those people because of the stresses being put on them by the system and the original teams. What's really going on is the original teams and team members, just need more support and better tools and a better structure that could easily be built for them. If it was just one person's job to be like, how can I help everyone do a better job at what they're doing? And that one person would just analyze everyone's ways of working and help. I feel very gifted to be able to have that phase in my career where I could just focus on doing that as a job, you know? That's why I don't think the agile coaches will ever be outta work.'cause like that, that is what you do is you look at the system and you say, how is the system breaking down and failing everyone and, and then you suggest. You know, the problem is that it's a suggestion. Also, the problem is that these roles don't fit neatly into the traditional roles. Sure. this is a problem too.'cause the organizations, they don't see any need to create an environment for someone who can sit there and just like you said, look and make tweaks to the, the, your design. Right? Yeah. But the but, the wonderful part of that is all of the people that made it possible for this organization to scale. None of their roles fit neatly either. That's right. And like all the people that came along, it was like, oh, you, you're a developer, but also you're a system administrator on the weekend. And also you're a customer support rep when people call in, 'cause there is nobody else and you're DevOps. So you deploy everything and you manage a cloud infrastructure. Like none of those, like you wore 15 hats and smaller companies though, all of those different activities, if you will, or roles will basically roll up under it or something like that. Right. Whereas, whereas an agile coach doesn't neatly fit into any of those traditional type of org designs. I understand. But like, let's, let's, let's fix this. Let's say we have quarterlies anyway, for all quarterly strategy review, quarterly business review, quarterly revenue review, quarterly, everything. Let's have a quarterly, communication systems or design review. Are the systems that we've put in place still working for us? And if not, let's identify those and talk about'em as an initiative. You could do that, right? Who would do that within the company? Like it has to be somebody's. Main focus is it HR right now? Who's gonna do that? It's not hr. I know their job's completely different. Typically if you want one, it's not a one-off in that you're gonna keep doing it. But if you want something that's out of the norm, it would be a person that you simply slap a label on him or her and say, you are manager of special projects. So do this. When we're saying like, well the agile coaches have no role anymore, we can replace 'em with the chat bot or whatever. Like, okay, cool. But also if it's people, processes, and policies, well the executives obviously are gonna handle the policies. The HR is organizationally in charge of the people. So what does that leave you with these processes? Okay, well, who's gonna direct the processes? Oh, well the executives will just tell you the best way to do it. Right. Well, I mean, aren't they dealing with the policies? Like, don't, shouldn't there be some kind of separation? Also I have to question the expertise of any one group to manage multiple things. So if you're gonna tell me that you're an expert at one thing, I might believe you. But if you're gonna sit here and tell me, Brian, don't worry, I got this. I'm an expert at 15 things, now I'm gonna start to question your expertise. Yeah, okay. Yeah, definitely, definitely. That's true. But you know, that's not happening elsewhere, right? Like in the industry where people are frequently examining and tweaking their processes, listen, get help, there's four P's, you've hit three. Okay? The fourth one is politics. And politics is a corporate cancer that is really killing organizational you know, abilities everywhere. I can't help you with that one. No. But what I can help you with is you have at least a three Ps. Offload the last one. Yeah. To someone sorry. I was gonna say, who's someone who cares? No. To, to someone, to someone with some level of expertise. So now this, I will freely admit this requires you to have a little bit of humility and say, I am not an expert in every field, all at the same time. And that is tough for some executives, but you get help. That's what I'm saying. It doesn't require a bunch of money. There's plenty of consultants out there that can give you an outside opinion, right? Whether you take their opinion or not. That's up to you. Do it at your own peril. But get help, ask for an outside opinion. Worst case scenario is they, they back up everything you're saying. They validate. You're doing a great, you're doing a great job. Om change. Nothing. Right. You're on track. Yeah. Validation's always a good thing from my, from an independent person. That's right. And if, and if you want somebody to tell you that you're doing a great job and to not look any deeper and to just pay you a bunch of money, I'm available. Give me a call. But you gave me an idea. I'm gonna create a chat bot. For org examining org structures and giving you advice. Speaking of chatbots, how you communicate, the need for team changes. Determines whether you get buy-in or create organizational trauma that damages performance. Communication and change management. Here we go. We're talking about change management. Om, I'm excited. This is my most, I always save the juiciest categories for last because we're already like, we're already crunched for the time box at the end of the podcast. Like transparent communication about team evolution. First of all, people hate the concept of team evolution. We have to change the way that teams interoperate and operate within themselves. Intra in and inter and interoperate. Yes. So honest conversations about role changes. You create a bunch of surprises and resentment right off the bat. Listen, people covered stability. Absolutely. So doing this is seen as. You're upsetting the apple cart. Absolutely. We don't need to do that. We're gonna maintain the status quo. That's sad. I think there are very few organizations that foster this environment where people can say, we need to do this, let's do this together. And there's no blame attached anywhere. That could be happening out in the open. It's a transparent, clear communication about business needs and then allowing people to self-select into that pool. And now the executives have an easier time to discuss.'cause now we know people's preferences. The hardest time you're gonna have though the executive team is to trust the teams to do the right thing. That's gonna be the hardest time.' 'Cause you're not used to doing that. Right. So if you let go of this control mentality and trust the teams to organize however they want, just tell them the why. Show them the why, they will perhaps come to you with a better. Question or set of better questions on even the whats, let alone the house. But you've gotta do that, right? If you don't do that well, you're bordering on another podcast I wanna have about implicit versus explicit motivation. Like, if is is the way that you manage running around giving ultimatums all day, do do this by the state or else do this by that day or else? Because if it is I'm gonna, I'm gonna go out on a limb and say like, you're not gonna get the best out of people, people are gonna rise to challenges when giving opportunities to self-select into things. They're going to volunteer for things that they feel strongly about. Yep. And if you're saying, look, oh, well, Brian I've never seen anyone self-select like I I don't know. If you were to tell me that. I would be looking back at you sassily, I don't know if that's a word to say, do you think that's a problem with your people or do you think that's a problem with you look in the mirror? Exactly. Yeah, I agree with you. You said explicit and implicit, right. And extrinsic. That's what I meant. Sorry. Yeah, yeah. No, it's fine. So I think that's, it's Todd and Human today. The valid thing here is if you think there are problems out there, look at yourself and say, what did I not do?. That led to this problem. Again, this goes back to that previous podcast with Ed. Extreme ownership. I mean, a lot of this is, very nuanced team development. It's very nuanced organizational design. It's a lot of stuff that if you have a Scrum master slash agile coach, someone with that skillset. Because we're asking a lot of organizational design out of that person, and we're asking a lot of helping us to design our organization around the people and the teams and the communication circles that naturally happen when you have someone that's good at that and then we're actually taking their advice and using it to modify the structure of the organization. And this is where like a lot of people just get under my skin when they start talking about like, well, I dunno what a scrum master does. I was like, well then you probably have only ever been on bad teams where you don't get any say in how the team is put together, who's put on a team when people are removed. And I feel sorry to be honest. I feel bad that you've only ever been abused your whole career. And some people will say, you know we just heard this very recently. You are hiring cheap Scrum masters from offshore teams. Sure. Okay. But that's a decision you made. Ultimately you get what you pay for, right? Sure, sure. I mean, I don't understand why this is like scandalous. If you wanna buy the cheapest tool for the job and then you're upset and shocked when that tool breaks the first time you use it, I work on engines a fair amount of time, and I don't buy cheap tools because I would like to be able to do the same operation many times and have a reliable tool. I can't be stopping in the middle of my operation when a tool breaks or bends and having to go out and run out and get another tool. We used to think that way in corporate America some time ago. Now we're thinking, yeah, I just buy the cheapest tool you can find right.'cause we can just get another one. Sad but true. Working with people to identify skills, working with the organization to identify like lanes of communication and adjusting that this is a very advanced topic but probably again, many of the subjects that we explored here could be their own podcast. Oh, for sure. In their own right. Like this is a very tough one. the skills for the individual team members. There's a lot to talk about in this one. The concept that transparent communication about team evolution, is organizationally under the scrum master and agile coach. If you don't wanna go with those job titles, scrum master, agile coach, and you wanna say like director of organizational design or something like that, cool. But also what you're gonna be contending against is the people who are like scrum master could just be a chatbot. It should be a chatbot. I completely agree with you. But also a chatbot with underhood AI agents. That are connected to your finance systems and your email and your Slack channels and your calendars and all that kind of stuff, to see where people are involved, to be able to read and identify who is overloaded and to read and identify when people are stretched too thin. And then to immediately like act on it.'Cause like a chat bot is cool, but an AI agent who is basically what you're saying is I need an AI agent, scrum master, who is capable and empowered to do all the things that a scrum master should do, but also without the organizational blockers that most organizations put on Scrum masters that force them into this impotent state. So if I'm gonna hand over my business operations. To a quote, real scrum master. I think you're gonna get blown away by what the agent does.'cause it's gonna start fir I don't know if it'll start firing people, but it will call out a lot of stuff. But it will, it will start making design changes. Yeah, it will for sure. And you better be ready for that. Yeah. Yeah. We might take that one offline and make it a whole podcast of itself. Ooh, I like that. It is like, so the main premise of this podcast came from the germination of an idea. That the team that got you to a million dollars may not be the team that can get you to $10 million. And pretending otherwise, and not dealing with that, that real world consequence. That's not productive thinking. And I feel like in this podcast, we covered a lot of ground, and each one of the segments that we covered could have been its own podcast, but I wanted to put all this out there so that people can absorb it, think about it, react to it, write us comments about it, and maybe future podcasts come out of this one. Yeah, I like that idea. All right, folks. Don't forget like, and subscribe and let's hear from you!