Understanding the Agile/Agility Ecosystem

Help me think through how this episode applies to my situation. Start by asking what I am trying to change. Separate the episode's claims from your suggestions, and say when the notes do not support a claim. Use the transcript to find passages, then check the audio before quoting. Transcript: https://yuvalyeret.com/podcast/episodes/understanding-the-agileagility-ecosystem/transcript.md ## Published episode notes Yuval is a guest on this episode of the Private Equity Funcast focused on Agility in Private Equity: Beyond Agile TheaterSome topics Jim and Yuval cover – - The importance of principle-driven agility over rigid adherence to frameworks. - Leveraging agility in various industries, organizational functions, and broader business operations - “Agile Theater,” where companies follow agile rules without understanding the process. - OKRs (Objectives and Key Results) as strategic guides rather than rigid metrics. - The unique position of private equity firms and consultants in driving agile transformations through pragmatic, principle-based solutions. 00:00 Introduction to Agile in Private Equity 00:45 Exploring the Synergies Between Agile and Private Equity 01:50 Welcome to the Scaling With Agility Podcast 02:07 Guest Introduction: Yuval Yeret 02:45 Yuval's Background in Product Development 04:13 The Evolution of Agile Practices 05:51 Challenges and Misconceptions in Agile Implementation 12:12 The Importance of Customer Feedback in Agile 14:42 Agile and Risk Management 16:48 Adapting to Market Changes and Disruptions 26:40 Implementing Agile in Founder-Owned Businesses 29:22 Building Effective Cross-Functional Teams 32:06 The Pitfalls of Over-Organized Cross-Functional Teams 33:34 The Waste in Work Processes 34:17 The Misuse of Agile and Strategic Goals 35:05 The Jeff Bezos Meeting Philosophy 35:46 Principles of Agile and Empiricism 36:58 The Agile Theater and Real-World Applications 38:12 Case Study: Biotech Firm's Scrum Implementation 40:50 Challenges in Product Management and Agile Processes 51:30 The BMW vs. Bulldozer Metaphor 54:39 Scaling Agile and Cross-Functional Collaboration 57:18 The Role of Private Equity in Agile Implementation 01:01:30 Concluding Thoughts and Contact InformationDive deeper For more PE Fun - Check out the Private Equity FuncastLearn more about ParkerGale Follow Jim Milbery To hear more, visit yuvalyeret.substack.com ## Transcript This transcript was edited from automatic speech recognition for readability. Speaker turns may be wrong or absent, and it may contain recognition errors. Check the audio before quoting or attributing a passage. Episode: https://yuvalyeret.com/scaling-ai-podcast/understanding-the-agileagility-ecosystem/ ## The friction around leadership Why should private equity operators care about agile at all? Why should they pay close attention to whether the companies that they're buying and operating following an agile theater, where they're just abusing agile rules without understanding the process, or actually leveraging agility? What is the importance of principle driven agility over Regidud Hill? adherence to frameworks. What's the unique position that private equity firms and consultants can take in driving a transformation towards real agility? I've been an avid listener of the private equity fund customer while I find the private growth equity space fascinating. There are lots of potential synergies with agility and with my practice specifically. There are interesting conversations and exciting opportunities. On the private equity fund cast, Parker Gayle partners, Jim Devon and Paul and their guests shared their culturally-oriented perspectives in approach, which is a refreshing take on the private growth equity world. Due to the name, I had lots of fun discussing the agility ecosystem, especially in the context of middle market private equity, Portcos, with Jim Ilberi, a partner and a firm. I was pleasantly surprised with how much Jim knows about agile and agility, and we even had some laughs about Agile Theatre. We dove right into what we're seeing in the trenches comparing notes, ideas riffing off each other. I hope you enjoyed this episode, at least as much as I did recording it, and consider subscribing to both the private equity fancast as well as to scaling with agility. Speaking of that, welcome to the Scaling with the Agility podcast, the place for leaders who are trying to pursue a nuanced approach to agility instead of the edge of theater. Five, four, three, two, one, Thunderbirds are go. Welcome you, Val Yeritz. For today, how are you? Good to see you. Good to see you again. Yeah, yeah. Surprisingly. My response to you is somebody says you look good. It's like, hey, you got to get to lens crafters. Quality eyeglasses in about an hour. You know, you clearly earlier, how's it going? So, so today we're talking about agility in the private equity space, which is going to be a religious war over agile, not but it's a good way to introduce it. So you've got a great background. So just talk a little bit about your background, how you got into the space and kind of your focus on project management and we're going to dive into the details of this. Yeah, so a bit about me. I've been in the product development space, started in the Israeli Air Force back in the 90s, mainframes, TCPIP installation on mainframes, routing, networking stuff. Hold on, I didn't know you were a ZLS guy. Interesting. You're a ZLS guy. All right, ISPF, you know. Yes, exactly. I installed TCP AP on the Israel Air Force mainframe. Oh, nice. Yeah, that was that was back when you got to remember that, you know, the IBM like SNA, they didn't like TCP, you know, the deck, I mean, deck at deck that TCP AP on a non Unix operating system was like a big deal back in this day. Yes, it was. I was in charge of the VPS virtual printer system. Oh, Oh man, this is good. I was pretty good at assembly. You know, my original Israeli Army computer school, so they sent me to the systems team. And from then on my career for like 13 or so years was in the, let's call it lower in the OSI stack, lower working, networking, Linux, kernel stuff, but eventually made my way to leading teams in those environments, engineering and product development leadership. Back in 2000, around 2005, six started to feel the pain of some problems in how we were working at the time and started to look at different ways to do things, got the agile bug. We started to use it in my engineering group in two places. And since 2009, I've been helping others do this. A lot of the companies that I worked with were companies that were in spaces like that, deep technology, networking storage but over time it became more and more diverse cybersecurity companies, you know, other devices, healthcare, banking, financial picks, so all over the place including all the way to recently companies like Gillette and biotech farm companies in the Boston area, trying to help them figure out How to do this agile thing, how to become more agile, how to figure out agility, how to navigate this weird space with so much dogma around it. Well, that's the key. The key is the words around it. Well, even Martin Fowler, you know, kind of one of the original signatories, you know, he claimed that when vendors got involved, they kind of ruined everything when it came to agile, you know, you. Yeah, because we buy software companies, I can't install all of them, I'll get crucified. But it's true that, I mean, the interesting part is if you read the original manifesto, a lot of the rules were arbitrary, on purpose. They just had to pick something and then people sort of treated them as a real religious endeavor. And I remember the original, you know, cut back, you know, a lot of Kent's writing. So he was kind of the angry young man of of Agile, if you will. And I think, you know, Penn's original argument, I think was a good one, which was, hey, you know, software developers, we have to be flexible about change, that customer requirements change, we can't be on some roadmap. On the other side, management, you can't tell me how long it should take to build this and what it should cost to build it, because you don't know anything about engineering. This became the sort of, I think to me, that was the stress between the two is, software developers getting more flexible about, hey, looks like the customer needs change, we have to change direction, but at the same time, it's like, guys who aren't writing code telling me how long would you take me to write code became a problem. Is that a fair? I mean, that was kind of the original. I still worked on sitting on a panel in an agile conference like 10 years back, if not more. And there's this question from the audience of, you know, leadership is asking us to predict, to give a roadmap to say, when is this thing that we're working on going to be done and having one of the agile pundits, you know, speaking of dogma, saying you can say when it's going to be done, we're living in a vooka world, right? Well, it will be uncertainty. We simply don't know. And you know, my role in that conversation in the world in general is trying to meet people where they are, trying to both the engineers that are right in the fact that we cannot predict everything, but also meet leadership and management and the business and product people that sometimes do need to make some plans. How do we make those plans? How can we predict what is reasonable to predict and what is unreasonable to predict and what levers, what degrees of freedom can we have in order to be able to predict if something is really important for us to predict it. But my conversation around agility rather than the dogmatic, you can predict it. Well, I mean, I had a boss years and years ago, who was a big fan of Disney, you know, I'm not at that Disney or big fan of Disney's. I personally the wrong generation to be a Disney fan. I want to start having younger kids, different story. You know, but I still remember the presentation a long time ago, this is pre agile. So call it early to mid, maybe even late 80s. And his premise was we should all be like Disney. When the movie hits, the toys ready for the store, the rides are ready at the theme park, the marketing's built around it. It was the whole product release. It wasn't just, hey, we get the movie. Now what should we do about the toys now? And his area goes, hey, we're not there in software, but we should think about that as a goal, right? And I think that's part of what was a good part about Agile's. You know, we see this all the time, it's not just getting the product done. Do we have the documentation? Do we have the market materials, how do we sell it? You know, what's the value proposition of customers? And a lot of that is, you know, it's kind of lost in the shuffle. We don't think of the whole product solution. And that's part of we've gotten the little, you know, most of the teams I see today, I don't put public companies, whether they're completely honest with themselves or not, they're all doing some version of agile. Now the fanatics will tell you that, oh, if it's not perfect agile, it's not agile, I'm pushing that. They tend to be if it's not agile. Let's call it Orthodox agile. It's not Orthodox agile. It's waterfall. I don't think that's true. What are these using waterfall these days? I care less about whether it's uppercase, a agile, or a case, a I think agile is a term and we'll probably talk about it later. There's a lot going on with that term agile that is unhealthy that has become toxic even I would say and there's a question what is going to replace it is it agility Is it product operating model? If you ask some of the big consulting firms in this space, there's going to be another name, but I think we can agree that I hope most of your portfolio companies are at least trying to close fast feedback loops and learn rather than make assumptions and build for years without validating these assumptions, which is essentially what we're trying to do with this. And I agree with you, by the way, that Part of what happened is that because of many reasons, Agile started in just development. And when people implemented Agile frameworks and Agile techniques just in development, they forgot about all of the other stuff, go to market stuff, product marketing, even operations, wasn't part of the initial picture. and then people had to add it through DevOps. It's not that the agile concepts themselves don't think about these things. Edge all was not framed, or there is a good conversation around whether Edge all was framed initially in an inclusive and encompassing enough way to include all of these other aspects, or was it too focused on solving developers problems. But it's pretty clear these days that when we are talking about successfully using it, it does have to include all of these other aspects. Yeah, I don't think it was. I think it was inclusive. I think people just read it the wrong way or didn't think they had the problem elsewhere. And using the agile approach outside of engineering is something that I think we're still in the early stages of marketing departments, tech support departments, you name it sales departments, that problem of not having quick feedback loops tends to be a problem. I think the highlight was in engineering and that's what people thought the problem was first, but it's been everywhere. I don't think we've done a great job of extending it beyond that. I still don't think even in engineering, even my best teams, we don't talk to customers enough. There's always still the fear of talking to customers and I know it's hard because nobody likes feedback they don't like but why should you assume it's not gonna be good feedback and maybe really good feedback in fact they may be able to lead you in a much better direction than you would do on your own. It's more vulnerable to say I'm not sure it's an hypothesis right? As investors do you acknowledge that your investment thesis is in many cases an hypothesis. It's always a hypothesis. What I remember You plan according to the fact that it is an hypothesis. Do you run feedback loops in how you, you know, on a plan, one year plan for achieving this investment pieces. So that's interesting. If anything lights me up like a Christmas tree, it's the 90, 180, 12 month plan. All of our, anything beyond like the next 30 to 60 days is directional. It's not a plan, right? So we look at this as it depends. So what are we going to do first? I'm okay with having a line says, hey, we want to try to get here. We think in the next 18 to 24 months, but we may be way off, you know, way off, especially if you treat it like a moon landing off by two degrees, you know, we're out in space for the rest of our lives, right? It has to be it depends. We have to do a lot of course correction. And that's one of the key things about Agile is this idea of course correction because for us, that feedback loop you about is what a hypothesis, we believe a little bit in the Ray Dalio approach, which is find two really smart people who completely disagree on an issue and get in the middle of them and you'll learn a lot. I mean, at the end of the day, we have to make our own decision, but what do I do about XYZ? The best thing to do is find really smart people and let them tell you what they think. And we find that to be a much better way of, you know, I love having a great thing for me as a hypothesis that your return is a hundred times their money. Also a great one is that gets killed right away because it's a really dumb idea and I didn't spend six months, you know, banging my head against the wall thinking this was a great hypothesis. I mean, both of those are great outcomes, you know, to be fair, the whole fail fast. I hate that expression. It's like, failing is great. Failing is not great. Failing is lousy. But if you fail without wasting a ton of time, that's not failure. I mean, that's course corrections. Is that fair? I like to look at it as risk or de-risk. I'm working now with an organization whose whole purpose in the world is to help people manage risk, company in Chicago. And I find that people don't talk enough about the relationship between agile and risk at multiple levels. And the way I've recently started to look at this is to use the ideal model of the different types of risks, the variability, viability, feasibility. Each one of these is a potential risk that you might have when you're building products or when you're trying to come up with the new sales management approach. Let's say you're trying to implement force management in your sales and revenue organization. And there, there's this durability for the salespeople. Do they want to work this way? Do the sales leaders want to work this way? Do your customers want to have conversations that are the sort of conversations that force talks about? Is it feasible to do it? Probably not the biggest risk for that sort of question because Salesforce can do force management, whatever. And is it something we can do from a business perspective? ## What is really happening in the system one of these are risks that the whole purpose of agile is to reduce the risk that we're taking the wrong approach either because we are focusing on the wrong problem or that we're taking the wrong direction in solving that problem or that something else is going on. So, you know, for me, if we can learn on something as weakly as possible, and based on that, make a decision which we're to go, that's a success that's not a failure. But, you know, it's not a gene that a lot of our assumptions are leap of fivesumptions. Yeah, I mean, that's the interest. I guess the other part I'd love to hear your thought on this that one of the places where I see this go wrong, even in organizations that are looking at it the right way. Yeah, things happen in the market and You know when you you maybe you de-risk yourself and you've used the right approach But you can you know that risk profile can change sometimes almost overnight Without you expecting for me use a great example. I don't have a specific use case here, but AI and the chat GP guy to you like processes have disrupted a lot of software companies Again, I hate to disrupt because that begins another one else. I'm a change agent who disrupts There's been a quantum leap in what you're able to do around analyzing text. It's not a perfect solution, but any business that's got a heavy amount of text processing is going to have to rethink what they're doing in light of the improvements in these large language models. And so that's one of the things that we see when I look at risk. I don't know if you've encountered that in the wild, but I found cases where, hey, we've done everything right and de-risky. We've got good feedback loops, but we're three quarters of the way down the path of this product. And suddenly the market has something innovative has cut the legs out from it. And we've got to admit to the fact that we did everything right, but it doesn't matter. We're going to have to change direction. And I don't know if you find that happens a lot in real life. COVID was another example where companies, you know, I was working with a health care provider. We were talking about each of our own orthopedic challenges earlier on. I was working with an orthopedics network up in Maine, where we were applying agility to both their IT, but more interestingly, to their whole business operations, to how they were thinking about merging clinics, introducing new services at the clinics, moving to an electronic medical record system, changing where X-rays are being analyzed, and midway through a plan that they had for how to look at the next 90 days, let's say, COVID hit. Now, do you continue to execute to that plan? Or do you stop, rethink and double down on whatever makes sense at the moment and work really hard to figure out how do you do orthopedics over Zoom? That's exactly what they had to do. but it's reality by we are living in an environment that is volatile, that is uncertain. We just need to learn how to serve. Edgley is about learning how to serve or snowboard or ski, whatever nature throws at us. And just minimize the impact of those changes that will happen. minimize the bureaucracy, minimize the amount of long-term planning that is not easily changed. It doesn't mean we don't do long-term Planning doesn't mean we don't have a certain level of animal operating planning. It doesn't mean that when you go and talk to one of the companies that you invest in, you don't have a certain altitude directional plan for the year, but that plan could change. The model that I kind of like to use for that is what we call evidence-based management. Generally, there's a strategic goal. There's what we're trying to do here over the next few months. next couple of years, what's the business strategy, product strategy, that might change itself, that might move around based on what's going on, that might move around significantly. If AI is going to come and kill, if the meteor is going to kill all the dinosaurs, all of these things might change dramatically our strategy goal. But in the short term, what we do is we set intermediate goals. would probably look familiar to people that are practicing OKRs, BHAGs, you know, big rocks, whatever your flavor that's not anything new, the important piece is that even when you said these sort of goals, what you need is to iterate towards these goals. Identify what do we really know, what do we need to experiment on? And so that's interesting because you hit something interesting, which I'm finding is a problem, right? So OKR has become another, you know, religious thing that people love to hang their hat on. And part of the problem I find is that you end up the OKR drives your strategy because that's what people feel like they're being reviewed on. Even OKRs themselves need to follow this little map you're showing of, you know, having very specific OKRs in a 12-month period, make your team to doing something and you just don't need to do from a strategy standpoint. But if I'm the employee, I'm like, look, this is how I'm gonna be judged. So I'm gonna keep going down these OKRs. I don't know, you know, I don't know if you've run into that, but that becomes not. No, I don't. For me, that's an OKR theater. That's not how OKRs should be used. It should be used to set a direction. Not to set the steps. So like, this is the mission that is important for us to achieve. Now go figure out what's the best way achieve that mission, whether the intermediate goals to work towards in that mission and even within those intermediate goals, what is that going to look like? Yeah, and I think that's in a lot of people abuse OKRs, of course, literally to how they abuse agile. There's this whole dynamic that is happening in the market, which I'm spending a lot of time on in the last couple of years. We summarize that by this statement. I sit in an engineering meeting and they show me a chart that says, velocity's up, but we haven't actually shipped any software. You're missing the point. This is missing the point. You could call it the peak of Mount Stupid, right? We have tons of confidence in That's a great line. OKRs, whatever. Parker Gail gave us, measure what matters. I don't know if you do that with your companies, but I know a lot of other P firms and VC firms, when they make an investment, they show the founder, the team measure what matters. The OKR book, they asked them to read it and implement OKRs, so there would be some interface for managing the organization or So, you know, the CIO, VPN engineering, the product leader, they understand, okay, we have to be agile because that's the thing that you do, that created the situation where the mainstream is doing agile these days. It's not the early adopters anymore. And while there are great techniques to achieve agile at scale, the problem is that the amount of advice, the competence, if we want to go back to the Dining Kruger effect, that is available to all of these people, hasn't caught up. The same is happening with OKRs, the same is happening with anything that's succeeding beyond the organic ability to scale it, and that creates something that the late Jerry Weinberg called the law of the Raspberry Gem. There's not enough competence to spread around. So there's a lot of dogma, there's a lot of religion around how to do things, a lot of too high confidence in the, you know, in the skiing world, they call it the juries, right? The people that go on the slopes one day a year and they think they know what they're doing and it creates a lot of issues in our industry that actually create problems and are part of the reason that a lot of people when you go to a lot of product people these days, they don't want to do agile. They want to be more agile, but they don't want to use scrum, they don't want to use scaling frameworks because they've seen some of the pain that results from people not doing it well. And the same is happening with OKRs. People are already saying that OKRs are a pase because and that's not because OKRs cannot work. It's not because OKRs are not a good idea. It's because OKRs have been abused to just replace project management with OKRs and that's not the intent. The intent is to do OKRs with empiricism, with empowerment. So I will tell you that our focus is on, so I can only speak for what we know, right? And we buy founder-owned businesses, software businesses, and in just about every single case, the founder is retiring. So this is not a, you know, it's not some kid who invented technology as garage and there's 30 years old run this thing. I mean, most of our founders started their businesses in their 40s, came from the industry that they brought a solution for, and they're selling to somebody like us in their 60s, right? And there's a little bit of, you know, survivorship bias. And if they make it far enough that somebody like us will buy them, they've already been successful, you know, by virtue of the plenty of businesses have gone under. They've made money. And it's two things. So this is a big hot button for me, you know, because you hear a lot about private equities, value creation plan, which I think is just a crock of crapola, right? Like we're so smart that we can, you know, jump into somebody's business that they've been up to 20 years and more. They, we don't, right? I would say the The two things that happen in founder and businesses where a process like agile starts to unlock stuff in cooperation with their PPE partner. Founders, when they get successful, they start to get a little nervous about taking risk. These guys started, these gals started taking risk when they started their business 20 years ago. But now it's generating cash flow. Maybe they bought a boat. We always say, this is statistically significant portion of our founders who have bought a boat, right? They don't go in there every day anymore and they start to become, as my partner says, achieve warrior officer, right? That's one part of the problem when we come in. The second part of the problem is that, and for people who only listen to the audio podcast, you're gonna see my great hand gestures, but the founders don't mean to do this, but they teach their managers to go, everything goes up through the founder, right? So in our fictional business, the founder's named Fred, every manager knows they have to talk to Fred before they get a decision. They don't talk to Sue who's their peer necessarily, they talk to Fred and Fred will tell him what to do. When the founder goes away, That becomes one of the biggest problems is that, the top level managers, they're used to go and afraid to get a decision. And now the decision comes to them, there is no Fred, right? And that becomes the, they don't have these processes built in. They don't have a methodology to make decisions necessarily because they never had to, right? And that becomes one of our biggest issues. Yeah, I see a very similar pattern in scale ups. Where the organization reaches the point where there are a lot more people, but it's still very reliant on the founders, whether those are the Whiz Kids, 40-year-olds, 50-year-olds, Whatever, there's this sort of early culture of all of the decisions going through leadership. And there's a lack of an operating system that balances effectively, you know, how do we empower people while keeping them aligned? And people are working this spend-a-loom of they're trying to empower people. You listen for example to, you know, look at the very big example, Brian Chesky at Airbnb. He's been told by his people and experts, empower people, let people run with stuff. And, you know, became very frustrated with that, eventually, because there was a lack of alignment and lack of focus in the organization. The organization is all over the place. That's something we see as Well, it's very tempting to go all the way to the other extreme. Oh, let's hold everything back. What we are trying to do is build some sort of operating system that actually creates that scale through leading with context, providing alignment, creating teams that don't need to go through leadership as much, both because we push decision rights to the teams, but also, and that's an interesting. in-heart change for a lot of organizations because we start to create some cross-functional cross-cutting teams within engineering, across engineering and marketing or cross-marketing sales, customer success, depending on what is it that we're trying to. The power of that is that those people in those teams can now be players, run stuff rather than just feel like pawns that wait for their leaders to have a conversation in the team. I know you guys talk about five dysfunctions of teams with your companies and five dysfunctions is a great tool for a leadership team to work together in the organization. But if you still need to work together with your team, you can also work together with your team. to go to that leadership team in order to have collaborations between people in their functions, then it's still not as tuned as it could be. What we're trying to do is go beyond that to create those teams in their organization that work on some of the organization's toughest problems, whether they're in product development or more and more these days beyond, that use the same language that become highly effective teams that know how to work effectively together, that care about results across the board rather than their own function and are measured and are accountable for an OKR together, for a goal and a KPI together. This doesn't need to be done for everything in the organization and that's a slippery slope as well. Some people are saying everything needs to be this way. I don't think so. I think there's still room for working, you know, in a simple way inside a function. I don't think that, you know, sales teams need to use agile for their day to day, for example. Maybe, maybe not. But the way I see it, this operating system is an operating system that's rate for developing your company or changing things in your company, for working on your company, rather than beyond running your ongoing day to day. Yeah, I mean, we've seen, so yeah, my partner, Paul Stansick, is in love with Patrick Lencioni. So he quotes him nonstop. I have to deprogram him from that. But we definitely see that. One of the things that we've seen is It'd be interesting to see if you've seen it, you know, this approach. Sometimes when we build these cross functional teams, what we do is we make it too official and organized and then a lot of the ceremonies become a waste of time, right? So, you know, we've got some thing we've got to do, some release we've got to make or some giant trade show or some huge customer implementation. So you put together a team and then, hey, we're going to get together every week and we're going to spend about an hour going through whatever. And I drive people crazy by saying, look, guys, We don't need a weekly meeting. We get a small team together, a cross-functional team. At the end of that meeting, it's like, when do we need to get together again? Because it's like, we're going to get together next Monday. For what? We're going to get anything done by next Monday? We're going to have the feedback loop. And the ceremony starts to become, we're cross-functional because we have this meeting every week. And we're not getting anything done in the meeting because we're not giving people enough time to make progress. And it becomes the ceremony of being at the meeting and presenting at the meeting, of the meeting not actually getting worked on. And that becomes, that is a real frustrating thing for my teams because I have the, hey, we're gonna get together today and then at the end of it. All right, what do we think is two weeks right for this? Like you're doing this, I'm doing that. And they get nervous about what we don't have something scheduled. You don't need it. You can imagine that they see these concerns that people have in the trenches, as well as leadership, there's so much waste in the way we work. I see that way too often when people aren't strategic, when people have so many things that they're working on, that the people that need to do the work 50% or worse of their time, they're in meetings about the work rather than doing the work. For me, there's a good conversation on whether you need that work session or not. I'd rather it be a work session rather than a status meeting. But if all we can do is spend an hour a week on this thing that is strategic to us, that to me is the smell. ## The practical shift What are we doing here? Is this really one of our strategic goals? We can't have 30. That's another OKR theater problem. If we have 30 goals, none of them is strategic. My old boss once said, it was phenomenal successful, but he loved malapropism and one of his favorites was focus on everything. That's like, guys, we can't focus on everything. We do see that, right? There's too many strategic, but again, strategic is also overused as a word, right? That there's too much strategy, you know, which sounds good on paper, but it doesn't work. And we've just seen it doesn't work. People get lost in the details of it. They also get lost in the details of, I don't know if you see this as well, for me LinkedIn's a good place to see what goofy trends are popping up. For example, you cannot go a day on LinkedIn without getting a chat GPT cheat sheet. Like we need another one of these things, right? But one of the things that seek Kapapa from time to time and we're in another cycle of that is the Jeff Bezos meeting philosophy of what made it successful is you read the thing before you go to the meeting and it's one pizza, whatever. It's like, hey, great, Jeff, I'm glad that worked for you. That doesn't mean it works for every other organization. I look at this as building an agile way to work, maybe somewhat custom-free to organization based on the skills, characters, and the type of business. So picking somebody else's thing that worked for them, that's great from a research standpoint, and like, hey, let's see what somebody else did. Does that have any application for me? But it may not work in my organization, right? I don't know if you run into that yourself in real life. All the time, all the agile should be around first principles. It should be around, why are we doing these things? It should be around empiricism, It should be around a little balancing alignment and autonomy. It should be around continuous learning and adjusting. Even the ways we're working rather than sticking to dogma, that's what agile should be about. And that's hard, right? Working from principles, it's hard. It requires critical thinking. It requires you to think about what you're doing. People want those shortcuts And if we go back to what's going on in this industry, we're now in the late majority for this agility. And these people don't have the patience for thinking about how to do stuff. They want the playbooks. And even though in the playbooks, you include what are the principles, it's hard to get them to pay attention to that. That's part of the culprits, I think, or I'm seeing behind this agile theater, scrum theater, OPR theater, just copy pasting something, not understanding what's behind it. Yeah, and I think that problem in our industry. Yeah, and I think it comes down to, I mean, you mentioned empirical evidence, and that's another one of, you know, a lot of times fuzzy numbers, strict conclusions on fuzzy numbers is stupidity, in my opinion, right? That, you know, I think you need to use, you know, common sense around empirical evidence, in some cases to decide is this working for us? Or is this not, are we moving as quickly and as effectively as we could be here? Sometimes that's a little bit of a subjective measurement, right? You can have some empirical evidence, but it's a law of small numbers potentially. And so trying to say, oh, we're at 52%, therefore we're better. You know, what's the data back here? Is that really where we want to be getting to, right? And that becomes, I see that in two ways. We see the organizations that become overly focused on the ceremony, the Agile Theater, and the other half who are so offended by the process that they say, none of it will work for us. Like, I'm going to throw the baby out with a bathtub. I can't do anything because this is one little piece of it just doesn't work for us, right? And that neither one of those are good things. We see a ton of that, neither which I think is effective for how we work. I'm going to be talking about an example of a similar case that illustrates this scenario. I worked with a biotech firm here in the Boston area a couple of years ago. They'd essentially try to use Scrum, and they were trying to do it in a very interesting environment both for engineering, product development, R&D, as well as they were trying to think about how to apply it to other stuff, like running tests in the lab, trying to find, you know, cup seeds that are beneficial. That's what their business was around. But going into the situation, Scrum was perceived very mechanical micromanagement without real value. The Scrum Masters that they had were considered meeting organizers, task truckers. That's a very common situation when I meet organizations. We can describe it as that breathy, excited young person that's got an arm full of file folders and they bustle into a meeting, taking notes and asking people they just done this week. Did you get the what are you going to do next week? It's horrible, right? That's so not the intent. And what we did there was teach them the principles, teach them the critical thinking behind this, help them to shed away some of the mechanics. There's a lot less on mechanics in that organization right now, but there's much more agility. There's much more agility in how they manage the work, how they plan the work, how their leadership team is working, because we applied some of these ideas there, and there's much more agility together with much more alignment in how they're on their planning and strategic planning process. They were using OPRs. But now they're using OKRs in a significantly different way. There's much more of that balance of alignment and autonomy and how do we involve people in planning? How do we connect without prescribing the connection? And I can tell you that once we establish the principles, what principles were important, how it was important to organize teams that can really run with stuff. I don't have a lot of work to do for that organization. That's the beauty of it. They get it. The leaders in the organization, they become masters of agility and how to drive towards agility. It's a long journey to make that happen, but now it's their journey and not something that somebody came down from Mount Sinai and dropped the full methodology on their laps. Yeah, I think the other part of that that we see, I don't know if you see this as well. I'll make two points. One is, you mentioned this earlier, There's so many bad agile consultants out there that, you know, you can easily get down the wrong path. You get the wrong people that are sort of dogmatic. I would say the other side of it is that we tell people, there's this feeling as I'm doing another visual example that nobody can see that, you know, as you're doing agile, you're getting more and more effective. It's a line that goes up into the right consistently. And that's not the case. To me, agile is like anything else. You're going to have some flat steps where you just get a little tired. It's like people who start out and maintain an exercise program. They may just go gung ho for a while. I always say, don't go crazy gung ho. Don't go from doing nothing to saying you're going to work out eight hours a day because you won't. Go from nothing to 15 or 20 minutes a day. And then you'll plateau a little bit and then you get reinvigorated again. So the key for us is don't go backwards, but it's okay. Sometimes if you need to put it in neutral, take a breath because sometimes time helps give you some perspective on, hey, is this working for us? What's not working for us, right? It's the let's use agile to affect our agile process, not just use agile to affect our products. And that becomes a hard thing, I think, for people to do, right? Because they feel like if they lose that momentum, it's never going to get back again. And when in reality is, you just can't work at an unbelievable clip nonstop. It just can't do it. There's an interesting corollary between what you're describing and some of the debates, let's call it in the edge of religion words of the early 2010s, okay? There was this debate between scrum, which was considered very revolutionary, turn your boats, you're in the new world, call things very different names, you know, just capture new ground and you know, you should succeed. And there was this Kanban approach that was more evolutionary, that was more, let's meet the organization where it is, let's evolve, let's, you know, not just map how things are working, but also start to go on a diet, which limits the amount of things that you're working on, limits the amount of big rocks, the amount of small rocks that the team is working on if you're at the portfolio level. And that might take more time to make an impact. But in many cases, it's more sustainable as you're describing. It's a diet that people both understand better, they understand why are they making a certain change. They see the connection, the correlation between, oh, we're working on so many things. This is what we do in order to reduce the amount of things that we're working on. We are asking people to talk way too much across organizational boundaries. it makes sense to actually create some teams that will cut across. It's a more organic introduction of patterns that work. It requires more patience. And patience is hard to find in many organizations, especially as they're trying to transform, but it is a better fit in some cases. So if you look at the agile ecosystem, there are techniques that are based more and people that are that have a preference for this evolutionary more agile. If you wanna call it that method, that also by the way involves the players, involves people in the organization in building their own story of what agile looks like, which is my preference. I mean, when I go into an organization, a big part of it is giving people the tools to build their own operating system. And it's never the same. There are repeating patterns, but people build their own leg or build their own operating system out of it. And I find it more sustainable. I find that for at least the organizations that I'm working with, and maybe there's some, you know, a correlation match there, maybe the organizations that pull me in, organizations are looking for these sort of pragmatic, principle-oriented solutions. and I'm totally happy that those are the people that I work with. I find that these people, even if they pause along the way, they make some of their decisions using these new principles. And at some point they'll get back to the table and think about, okay, what's the next peak we want to pursue from the perspective of improving autonomy? autonomy. How do we create some more cross-functional collaboration, cross-functions? What's the next strategic thing that we want to tackle as an organization? What's the next important thing for us? What would be the right way to tackle it if we follow these principles? Yeah, so we run into a couple of problems in that. And I think in general in the market, it agile is well known enough that now people are trying to look for non dogmatic solutions, right? And the early go when they grab any consultant they could find and you got a lot of bad ones because they just, you know, they, they, they went to a class, they got a little bit of religion and the success was to just apply the religion to your business because if it didn't work, then you could say you're doing the religion wrong, right? So you take the blame off the consultant, it's like, well, you're not doing it perfectly. So that's why it's not working for you, which is, you know, it's a crock, right? So we see a couple of challenges. I don't know if you see this yourself. So one, because we are focused on founder owned software businesses, that in the early going from a development standpoint, almost always the founder had some customer that was more like a consulting customer that kind of built the product for a customer or two. And then over time, every net new customer, they would you know, grab, oh, they had a great idea. They'll only buy it if we do this and we'll add that in. So it becomes now, again, survivorship bias. Plenty of those businesses are going. The ones that we would buy, or any of our competitors would buy, have gotten to some, you know, they're 20 million of revenue and three million of VB does. So they've done something right, they've successful. But they still have that DNA, right? Of they go to see a prospect and the prospect says, I'd buy it, but I don't really love this. And then, you know, we come back. We have great guy in our portfolio. This is the funniest thing ever because his name with Mike Prophet, which both Prophet, F-I-T and Ph-E-T, he was a product manager, he had both of those, but Mike would always, he had a great approach, right? His approach was product roadmap should never be super defined. They're directional as opposed to commitments. And his argument was, hey, see all these wonderful things that we're talking about doing, Mr. Prospect, and the prospect would say, yeah, we love all those things. And his argument, and if you ask me to do this one custom thing for you that you claim is the only reason you need this thing or you can't buy the product. I can't do all those other wonderful things because if I say that to you, I got to say it to the guy down the street and the guy down the street and suddenly I'm spending most of my time doing custom. And most of the time, when presented that way, they would say, you know something you're right. And if we can get to that approach, a Kanban style works great because we're picking from a basket of stuff to get done as opposed to we've committed to this, rigorous product roadmap that prospects have committed to, You know, I mean, it is, by the way, just my wife says, the chorola here is my wife says, she married me from the demo, but the production release has been a very big disappointment. ## What leaders should pay attention to There were features shown in the demo that made it to production. She's not wrong. So I don't know if you see that, you know, and not to suffer businesses, but businesses in general, have you seen that, you know, those two problems that I'm working right now with, I see it more often than not, But just one example is an IT organization in a pharma company that I'm working with right now, they have that project mindset. They're just doing what stakeholders are asking from them. They want to move to a product mindset of, we have some sort of direction of, where do we wanna take this rather than do everything that we're being asked of? but whether it's a founder-led company that started with custom, and it still has client concentration, which is worrying from one perspective, but also conducive to the sort of product management struggle or lack of real product management, the team like Paulie, and whether they actually solve the client concentration, but the culture still stayed, that sort of product roadmap is used by the salespeople to go and sell stuff. And salespeople sell the... Ask customers what do we need in order to sell or are willing to have these conversations with customers. And the people in the organization, in the product organization, don't have the conviction and don't have the support by leadership to actually say, no, no, no. We have product strategy. We listen to our customers. We listen, we build a picture. We do pattern matching. We look at what the market needs, and we will figure out a roadmap that does not necessarily map one to one to what the stakeholders are asking for. This is what we call real product leadership. This is what we call real product ownership. It's very rare out in the trenches. It's much more common to have people that use agile processes just to manage a future factory. So definitely a challenge that regardless of the agile process that you use and the agile framework that you use, all of them are trying to point to in the direction of real product management, but the problem is not necessarily in the agile framework that you use, it's with does the organization have what it takes to understanding the willingness to change its culture to be a product live culture rather than a project or stakeholder-led culture. Which is hard, not trivial. It's hard, and we see it, I have to use a very simple stupid metaphor called the BMW and the bulldozer, right? If you need to move a bunch of dirt or snow, a bulldozer is your right choice. If you want to go faster the highway, the W's your great choice. That usually gets me to an argument with people who like Lamborghinis or as Mercedes, but just for the purposes of alliteration I use two beats, right? The challenge is that you get in a sales process and you do run into situations where they're looking at us and they're looking at a competitor, we're a W and they're a bulldozer. One of our certainly wrong spot. You got two guys in this process, we don't make any sense, right? If you're buying a bulldozer, you're probably talking to John Deere and Caterpillar, you're not talking to John Deere and sales, you see a big customer with a big budget, you just wanna make it, well, well, we could put a blade on the front of the BMW and it's technically possible, right? And you could, the discipline to walk away and say, guys, we're not the right fit for you, right? Long term is a much better solution than trying to stretch into a category that you weren't trying to stretch into on your own ahead of that prospect. You may have decided, hey, this is where the market is going, we're gonna move in that direction. No, we've got a prospect who's got us in the wrong spot and that's really hard to do, right? Cause the sales reps looking at some, especially if they're like, hey, this is a $2 million deal, I can get this this year, this is amazing. And tell that person, look, we can't compete because it's gonna make a mistake like that. That's really hard. And a lot of organizations, when faced with that, they just can't make the tough choice. And that's despite the fact that they've got a product mindset and they're trying to stay focused, sometimes that dangly carrot looks so interesting that there would be exceptions. The question is what are the exceptions and what's the ongoing thing? And by the way, if all of our salespeople are hitting a need for a bulldozer and what we have is a BMW, that might be a reason that we need to pivot to go back to the drawing whiteboard and say, OK, what are we doing here? Product should be connected and in tune to what sales are hearing. What sales are seeing, what the business is seeing out there in the trenches should definitely affect what we have on our own map and where do we go. But it should not be, we do this thing just for a specific client. It needs to be something strategic. Now we see that as a closed loop. So here's where we like the agile approach across functions. Is if we're getting drawn into a bunch of situations that you said, where, well, they look like they need to pull those or we're BMW. Sometimes it's like, hey, the market's moved and we've got to move with it. Sometimes it's the marketing function, detracting the wrong prospects. Yes, we're getting pulled into a bunch of bulldozer things because whatever it is we're saying from a marketing standpoint, it's convincing bulldozers shoppers that we're a fit, right? And that's the mistake that hurts us the most in the market, in my opinion, because it's like we're making a directional change that we don't need to make. It's because we're just talking to the wrong folks, right? And that's hard. That's where, and again, this is not an insult to marketing. It's not a knock on marketing. Product management be telling marketing stuff that's causing them to go in a particular direction. But it's a thing to what we talked about earlier, which is there's a set of things that happen in the life of a company at certain points, which are very hard to fit into a function. It's not marketing, it's not product, it's not sales, it's not customer success, it's not engineering, it's something that needs to cut across. And the typical way organizations are structured and operate, all of these situations go up all the way to the leadership team, because that's where these functions sit. And we can make it work better by working on the effectiveness and the performance of that leadership team, whether we use this model or another, but that's not scalable. If we, the larger and larger the organization, the more such situations we'll have, the more people will feel like funds where the real players are making the decisions we just execute, the less likely they're gonna actually gonna come up with creative solutions to problems. If we wanna tap into the potential of the people we have in the trenches, these ideas of feedback loops that involve all these people, people, what we refer to as rugby in the world of agile, we want to have this rugby game happen for these sort of challenges as well. The challenge of a mismatch between the BMW and the bulldozer that has marketing aspects, pricing aspects, sales, customer success, the product itself, Well, whatever, we want to bring all of the players to play rugby together, not just have a meeting once a week to discuss it, but put them in the room, give them an Apollo 14 situation where Houston, we have a problem. If you remember that scene where all of the relevant engineers were locked in the room, them pizza under the door, give them everything that they need in order to simulate, you know, the problem and try to come up with a solution. And they just work it out. Well, the best part about that is the Ed Harris line. You know, let's not make the prom worse by guessing, you know, this is a great Ed Harris line. It's perfect. It was Eugene Krantz. So here's what I'll tell you is the only, in my opinion, as an operating partner in private equity firm. Here's our value, right? Like, so you have all this value creation plan, which is all in my opinion, just crap Ola. Here's my value in terms of this conversation with our portfolio companies. We own them, okay? So I can say the stupidest thing I want and you can't fire me. And that's my job. My job is to go into product engineering sessions and it's like, look, I understand this hierarchy and these companies and I understand trust can be a problem and an employee doesn't wanna look foolish or take on a project that may hurt their reputation, right? I can do all of those things. And that's what we should be doing as private equity partners is my job is to suggest stupid. Yeah, I'm not saying I'm picking stupid things. I could, you know, hey, what if we do this? And then it's amazing. When I say something like that, they all gang up on me, like a wild pack of, you know, Wolverines, which is perfect. I don't care. You know what? We end up with a good solution because they know the answer and they know more about their business than I ever will. And that's where I see agile processes. You got to have somebody that can be the suggestion or craziness or, you know, I can't be hurt. So there's nothing to do in that organization that's going to hurt my reputation. I don't care how stupid I look. I don't care what to ask, but usually we end up with a better solution. But the problem I see is a lot of outside people, private equity people, consultants, they don't want to look stupid. They need to be the strokey beard. Here's where you're wrong kind of thing. And I think that's useless in most organizations first. So I guess the interesting question is how can you scale the value that that brings? How do you create an operating system? where you can unleash the ability of people inside to experiment with potentially stupid ideas, throw something at the wall, see if it works or not, which is exactly what we're talking about here, right? So I saw that as quickly as possible because there's no big risk, right? So I tell you from a totally scalable standpoint, I haven't solved that problem. Here's the only reason it works for us. We're a small private equity firm. Yeah, and most, I've got 10 maybe 12 companies in our portfolio. And if we're doing things right, you know, that my team isn't heavily involved in those companies after a couple of years, because they're running at their own pace, they're cranking it out, right? So they don't need me, you know, if we go sell a company most of the time, the people have been hired the last couple of years don't even know who I am. But they may have been... So there's something that you're doing probably in those early on interventions that is unlocking something. Yes, but it's always creating a culture in which people feel like they can bring up lip So, you know, I'm not sure if there's a lot of assumptions, loafers, and have conversations around them, or something in the organization learns how to try things and avoid that risk and worry that you talk about. Yeah, I would say it's still in our case it's a semi formal process. It's an informal process, right? It's not I couldn't take this out as a framework that people can use, right? I mean, I'll give you a funny story we own the company many, many years ago called Royal and Company and of course they had a lot of great that a big campus. They had a lot of conference rooms. one of the conference rooms in engineering, they had other kind of pithy patterns, you know, a lot of times conference rooms have Star Trek names or whatever. They named one of the conference rooms after me and they only used it for stupid ideas and conflict. It was like, this is one we got to take to the millberry and they would go into the millberry conference room. And, you know, they meant it as a compliment and I took it as a compliment, right? And then it became this kind of free space. We were like, all right, we just don't know what we're going to do. So let's go yell at each other and draw stupid ideas on the grease board. We'll come up with something, right? which is pretty funny. So I would say I haven't cracked that diamond to know how we can make it truly scalable. I've got a relatively small team, we've got a relatively small number of portfolio companies, and we've got a focus fund. We only buy software companies, so the only thing that makes it work for us is I've got a little bit of a smallish world where I can jump between it. It is certainly not a process, it's certainly not something I could turn into a world-class solution. So have we solved the world's problems here today? You've all I feel like we have. All of these. Okay, so if they want to get in touch with you, how do they get in touch with you to bring your magic to their non-angel or to their edge all theater. I spend a lot of my time these days fixing a jilly. I'll tell you that fixing a jilly in writing about my thoughts around that. If people want to find me, I write about it in my blog at uvaliora.com slash blog, which surprisingly enough is my site. There aren't that many valuettes in the world, so if you type valuettes into Google, you'll probably find everything about me. If you look for me on LinkedIn, there's only one as far as I know, out there in the world, and that's me. I'm happy to connect and talk about anything related to bringing pragmatic, principle thinking to the world of agility, whether it is inside product and more and more increasingly those weird outside product business agility scenarios that we talked about. Fantastic. Well, thanks for being a guest today. I really enjoyed the conversation. Happy Friday. Happy Friday. ## Source boundary These are the published show notes from the podcast feed. They are a starting point for discussion, not a verbatim record of the conversation. The transcript is machine-generated and may contain errors or unlabeled speakers. Check the audio before quoting anyone.