Agile Unplugged EP05 | Projects to Products | Mike Cottmeyer & Dennis Stevens

In this episode of the Agile Unplugged podcast with host LeadingAgile CEO, Mike Cottmeyer, our guest is Dennis Stevens, LeadingAgile’s Chief Methodologist.

The two share a candid discussion that connects the dots between the Agile Transformation market and broader organizational change management issues.

Transcript

– Hey everybody this is Mike Cottmeyer I am the CEO of LeadingAgile. We’re gonna do something a little bit experimental here. And so what we’re gonna do, is that we’ve been exploring some really interesting ideas, or observations about the Agile market, the Agile transformation market. How that ties into broader issues around organizational change and some of the things that you guys are probably hearing about from reading Gartner Research or consultancies that you’re working with. So we’re going to try to connect some dots with you over the next 30, 40 minutes or so. Dennis and I are basically trying to figure out a little bit about how to talk about where LeadingAgile has been, where we’re going, and some of the problems that we see in market. Nowadays some of the confusion that we see in market. So Dennis, I pass the ball to you here a little bit. So almost 11 years ago now, 10 and a half years ago, we formulating Agile together with this idea that Agile at least this was being talked about then, like wasn’t quite enough. So talk to me a little bit about your take on the formation LeadingAgile and kind of like what problem we have historically solved in market.

– You and I were introduced by-

– [Mike] David Anderson.

– David Anderson. Because we were both talking about the problem the same way but from different angles. What I had been doing was working with business architecture capability models to try to come up with organizational patterns and work breakdown patterns that matched so we could get worked on organizations.

– Yeah, and I was at the time, I was working at VersionOne I think when we got introduced. And so I was like really in like scrum Agile analyst. It’s like really before even safe was a thing. So we’ve been doing some scale Agile back in my CheckFree days, but like scaled Agile hadn’t even gone mainstream at that point.

– Yeah, and one of the things that you were talking about was VersionOne wouldn’t solve the problem ’cause the problem wasn’t the software, it was the organizations weren’t designed right.

– Yeah, so what we were kind of hunting at that time was, I was going into these organizations to try to help them install the VersionOne tool. And you’re consistently walking into these companies and realizing that they can’t even like form teams. They can’t get backlogs, coherent backlogs. They can’t get to a working test in an incremental software. And it’s like this whole story that I’ve been telling around the Agile transformation, it’s like teams, backlogs working to test the software, structure, governance symmetrics at scale. And so we kind of had this key insight about the relationship between business architecture and team design and enterprise agile. Talk about that a little bit.

– Yeah, and what we were doing at the time, what I was doing at the time was actually trying to solve like big enterprise project problems. So we’d go in and they’re trying to refactor part of the organization. The first thing I would try to do is go get teams aligned around the major capabilities we had to build and deliver, and then get the work really clearly articulated to them. So teams, backlogs, then with frequent delivery and integration, we were unlocking a lot of locked up value in organizations. So it’s really interesting to get to the whiteboard in my office and start talking about the thing it’s business architecture, Mike it’s all our capabilities, how we measure it-

– And I can’t stop talking about business capabilities ’cause nobody cares. But they did, but you know-

– So, it was really interesting to realize that we had a pattern that would solve the problem. And it was kind of like, how do you get people to understand that’s their problem and how do you actually go solve it? It became sort of a pattern that we’ve followed for a while now.

– Yeah, and so it’s part of our transformation strategy. So what we would basically do is kind of we look at the business architecture of the organization, and then use that as kind of an initial hypothesis on where we wanted to form teams and where we wanted to look for dependencies ultimately how we might govern the flow of work across multiple business capabilities or multiple value streams, and how we would measure it differently. All that kind of stuff. And so I think we’ve gotten pretty good over the last 10 years of being able to take what I’ll just kind of colloquially say is like a tangled up organization, a misaligned organization. And figure out how to in a really structured and disciplined way, untangle it so that the, I guess the product factory or the software factory can actually produce stuff.

– Yeah, and there’s some of the interesting things that we learned around organizational constraints and encapsulation and orchestration, is how to design the best possible organization within all the constraints that exist. So within dependencies of technology or within the organizational compliance rules with how they wanted to get product lined up.

– Yeah, so that’s a good point. So basically, because what’s interesting is when you go into some of these large organizations that we’ve had, I guess the, I don’t wanna say good fortune, is that quite good fortune, but we’ve had the pleasure I guess of working with over the last 10 years, is that initially you don’t get to walk into the CFO’s office. You don’t get to walk into the compliance office or the strategy office and say, you need to do your job differently or a talent management office. So you didn’t say you need to do your job differently. So what you just said, and I’m just kind of confirming is that what we’ve really been doing is solving the enterprise agile problem within the constraints of the broader organization.

– Yeah, and one of the things, that’s fair. And one of the things we talked a lot about is there’s so much value in dollars released in doing that. And so you don’t have money to go solve these other classes of problems as they come up.

– Yeah, for sure. So, we’ve done some fairly large transformations here. We’re in the midst of doing some fairly large transformation. So what makes a mega large transformation different than maybe a smaller transformation? And by that, I mean, what makes a 15,000 or 30,000 or 45,000 person organization different from say a couple hundred people?

– Yeah, so if you look at like what I was doing originally, we started doing it from, we’re solving these organizational problems within the constraints of the organization, at some point where you’re doing the whole enterprise. And even when they were doing it in relatively small companies, we start bumping into organizational constraints compliance, budgeting, strategy articulation, talent. We start to bump into those types of problems. And a small organization, we can move those because people just sort of rally around the new model. But when you’re doing it, the company decides, or some of the companies that were in, those are huge endeavors themselves to make those changes.

– Well, I might even say, so you say that you can do them and rally the people around them, but it’s also, you can do them on a reasonable enough timeframe…

– [Dennis] Yes.

– That people can see the benefit of the new system and delivery and then go, Oh, okay, cool. Help us figure out how to plug into it. So we can realize this more enterprise class.

– [Dennis] Yeah.

– So why is that different in a larger organization?

– ‘Cause it takes so long to move the whole organization to the new place. And there’s so much inertia and the processes around it at an enterprise scale. And it’s hard to begin to change those giant workforce planning processes at a company that has 20,000 or a hundred thousand employees. You can’t go change their workforce planning processes very easily. So what happens is, you get to a point where you’ve gone as far as you can go for the constraint has moved outside of what’s in our control. And we’re not doing projects, we’re not doing like a slice of the organization, a single problem anymore, that we can get exceptions to all those rules. So the whole thing gets bottleneck ’cause it went from solving a problem to being like an enterprise solution. So there’s big enterprise things that start to get in the way.

– So when you and I when we first kind of started down this path of inquiry together, one of the things that you’re working on with one of our large clients was an initiative, that I guess a lot of people are talking about this now. The idea of projects to products.

– [Dennis] Yep.

– ‘Cause we want to take a project-based funding model and we want to move it into a product-based funding model. And my initial reaction was well in our model, that’s just BaseCamp 4 Because at the point that you’ve gotten the system predictable and you’ve reduced batch size, and you’ve broken the dependencies, basically, the organizational units are operating autonomously. The idea was is then, you can now flip the governance model to be able to do basically team or organizational funding instead of project-based funding. And so the breaking of the dependencies between the organization, is really the key enabler of being able to entertain that next level of thinking. And so talk to me a little bit about the friction and why that the tension that you guys were feeling where it was true, but it was not true at the same time.

– Yeah, because you can change it for like a small subset of the organization or for funding like a whole team as a project and their current funding models. But to actually get all of my maintenance dollars and like these are a whole organizational things all my maintenance dollars, all my new project dollars, all my modernization dollars, all my operating and keep the lights on dollars into a single budget, to fund it across multiple organizations, breaks all kinds of processes outside of that delivery. And so there’s nothing that existed in the organization that made that possible without changing a whole bunch of stuff. We didn’t actually originally have agency to go address.

– Yeah, ’cause the way our consultancy had evolved, it was interesting. It’s almost gotten to the point where operationally day to day, we’re just almost like an expedition to BaseCamp factory. So we’d go in and look at the organization or subset of the organization, we’d break it down into expeditions we’d say, okay, what’s the destination that this one wants to go to? So we said, okay, this one’s going to BaseCamp 3, This one’s going to BaseCamp 4, this one is BaseCamp 2, this one’s BaseCamp 5. And we put together these journeys, these outcomes based plans to get them there. But I think the realization was, is there’s a certain class of problem in these large organizations that as you’re systematically moving expeditions to BaseCamps, so you can’t actually flip the funding model or some of the budgeting or HR things until enough of the organization has reached critical mass to be able to like fully exploit it. Talk to me

– So early on, when we started doing those, it started adding a little bit of burden either to the expeditions themselves or to the funding and budgeting group to try to keep track of two sort of modes. But at some point when enough of the organization has flipped over, the the old way of budgeting, the project-based budgeting, all those other things become untenable because the practice of bringing them together now fund stable teams becomes the burden. They shift from the orchestration of the old way versus the new way. Now the orchestration is greater to maintain the old way of budgeting, the old way of strategic planning.

– Yeah, so it seems like what’s emerging is that there’s this flow that gets teams and organizations into the right ecosystem to be able to be more Agile or to operate with more agility. But then there’s almost like a flow that like rides on top of it that as the organization starts to click into place, there’s some bigger things that need to be addressed.

– Yeah, the staff that’s in the office of the CIO or in the CFO’s office or in the CEO’s office around workforce planning. There’s big processes in organizations that are how we create the conditions for those expeditions to live with them that actually have nothing directly to do with the expeditions, except that’s where they get money and permission and agency and the ability to operate.

– The ability to actually operate.

– So it becomes not getting this Agile, it becomes creating those conditions.

– Yeah, so one of the things that I thought was interesting is we were kind of having our pre-talk associated with this, one of the things that I think that LeadingAgile did a really good job in market over the years is, is helping people understand that Agile isn’t just about adopting agile. It’s about solving business problems. It’s about helping your organization respond to see changes in market. The ability of the organization itself to pivot just not any particular requirements set to be able to pivot. And so I think what we did is, I think what we’re doing is we brought the people that were interested in solving the agile problem into this bigger worldview. And you and I were just exploring like what this bigger world view is. If you can, it’d be actually probably should have tried to do this with the whiteboard but we’ll maybe save that for the next rev. Talk to us a little bit about what you think the big, big picture of agile transformation.

– Yeah, I’m gonna try to do this with like a-

– Like a concentric circle drawing, yeah. So if you see Dennis waving his fingers, he’s drawing concentric circles on a white board.

– So in the center of the circle is the market and customer. And the conversation is, if your systems and structures aren’t aligned with your markets and customers, you’re going to struggle in market.

– Yeah, and like at a really simple level. If the team isn’t pointed at a product owner or an on-site customer, producing a working test at increment of software every sprint, well then that Agile team isn’t going to work.

– [Dennis] That’s right.

– If we have a work group, whether using safe or something like that, maybe 10, 15, 20 teams, the teams have to be pointed at their particular piece of the customer, but then the whole organization it has to be pointed at its customers well.

– [Dennis] That’s right. And then that expands out into the entire organization. So the secret, what it really means to have organizational agility is that every level, the systems and structures are pointed at their customers and markets. And they’re basically backlogs teams working and tested software.

– That’s right, same thing. What happens when you get really big in these organizations, is getting that team’s backlogs working and tested software there’s other controlling processes that are less connected. So we talk about things like product management, getting the system of delivery, awesomely delivering software as a factory that’s reliable and predictable and cost-effective is amazing. But if product management doesn’t how to use that system of delivery at break. So one of the things we ran into early four or five years ago, we started building a Product Practice. We started trying to address-

– Oh, I was going to go to the response. I was actually going to go one step before that. We actually had a customer recently. It was a prior year one, year two customers say, we got really, really good at building the wrong product.

– That’s right, that’s right.

– [Dennis] And it’s like you recognize that the product problem is a first class problem, but if you’re trying to understand your customers and your markets and all those things, but you don’t actually have a delivery organization that can produce anything-

– [Dennis] It doesn’t work.

– How do you get fast feedback? How do you iterate? How do you put things in front of them? ‘Cause most organizations aren’t built to do that. So we actually came to market as LeadingAgile with like, okay, let’s get the the software factory working, first of all. And then we recognized, well, we can’t leave the customers in a place where they’re building the wrong product with the state-of-the-art software factory. So we started building the Product Practice.

– And we have an amazing group around it. Now we sort of found out with the Product Practice, there were a couple of next obstacles. One of them was, just how do I keep stable teams funded when I’m getting sort of the bigger organizations, how do I build budgets? And so we would talk about how do I bring together all the monies that fund teams, so teams aren’t hunting money. And the organization, it turns out there’s kind of a class of problem before that which we had been talking about for a while, which is, until I know how to get my strategy articulated in a way-

– I was wondering if you were changing the model on me if you would just skip that one.

– [Dennis] Yeah, I skipped it.

– So if you would skip that one

– I skipped it ’cause as I was trying to put them in order, it became sort of like, this is the problem we were solving.

– Yeah, it’s kind of hard. It’s like a little bit of a chicken and the egg. So what you’re basically saying is that like, so you have this idea of there’s a, an organizational strategy that gets realized by this organization that is basically, where systems and structures are aligned with their customers and markets. But if the strategy isn’t informing what you’ve decided to do with those customers and markets, then it’s like you don’t really know where to head. You’re kind of rutterless as an organization.

– Yeah, yeah. And if you look at how most strategy sort of patterns work in organizations today, strategic decisions get delegated down than anything that’s not exactly how it gets bubbled all the way back up. So in order to kind of build these things and make it work fast, you have to be able to delegate decisions down. We talked about a trusted system if you remember, we talked about that sometimes. I feel I have a system that I delegate things into and that I actually only know when they’re off track or that I know they’re on track. Well, then I have to get status reports for everything, every day. But it also wasn’t this sort of general just trust the teams they’ll go do the right thing, ’cause they’re directly in touch with the customer. ‘Cause it may not be aligned with the strategy.

– So the idea is system and delivery, then make sure that you’re feeding it with the right stuff and then make sure you’re feeding it with the strategically aligned stuff, which is kind of like another way of saying the right stuff but it’s really connecting that dot very explicitly.

– Yeah, yeah. One is really understanding your customers and the problems you’re solving. One of them is deciding which customers and problems you want to go after. And they all inform each other but you kind of have to get good at that stack to really get the benefit. ‘Cause a great strategy with no ability to execute-

– Well, that rings true ’cause in some of the early engagements that I was more directly involved in, we’d get the software factory working really well get the product people really engaged in their feeding the backlogs. And then the team is building or the organization is building the software so effectively you would start the strategy queue right after it. So why does budgeting comes next?

– So budgeting comes next ’cause in order to get those teams stable and have the right structure in place to feed the backlogs keep the team stable, deliver frequently, you’ve gotta be able to fund that whole thing together. So budgeting is dependent on a strategy and a strategy– I’m gonna say strategy delegation model. We’re gonna come up with something different than that. But the ability to-

– It’s okay when you explain it you just don’t always have the opportunity to explain it.

– The ability to delegate strategy down into teams so I can then fund the team ’cause behavior follows the money in an organization. And if I can’t trust that what I’m going to delegate is how the world’s going to operate, then I’m gonna have the business people spending all of my product capacity on new things and running the product into the ground. Or I’m going to have IT, spending all the money on modernization which isn’t the next most important thing and not delivering the new slice. So I need some way to manage the behavior of the organization, pay attention to what the results we’re getting so I can fund it right. So the strategy thing comes before budgeting but I think originally I thought it was the other way around. But what we’ve learned is that you’ve got to do strategy first.

– Well, we reserve the right to change models anytime we feel. No, it’s interesting. It’s like to some degree, and this is something we’re exploring. Is that it’s like, you almost need to talk about it linearly, but in reality it’s often messier. Like we were talking about, so I think the next three are what, it’s like talent and technology uplift and then compliance-

– I’m gonna wrap talent and leadership around the whole circle.

– [Mike] Okay.

– So I’m going to-

– Hold this right, talent is on the outside, yeah.

– I’m going to put technology next. ‘Cause the thing that we have found is I can’t get the right funding to do the technology stuff, because if a team gets more efficient at building software, that money’s in a different budget than the budget that does the modernization or does the maintenance and does the support. So the way that we fund organizations leads to the result of people shortcut their projects in the stuff that’s going to take to support it, so technically, that starts to build up over time.

– [Mike] Got it.

– So I gotta drive the behavior through the dollars of bill something that’s supportable and maintainable over time.

– So you don’t want to start tackling the technology problems until you have really the strategy alignment and the budget problems.

– Again, it’s not that linear. We can start building muscle and skill around it but I can’t expect at different organizational behaviors till the money feeds it right, okay?

– Yeah, that makes perfect sense, yeah.

– So, now and I’ve got, and I’m all the way on the circle. Now I’ve got the Compliance One which I have is the sixth inner circle. And the Compliance One is about making sure that all of our compliance and regulatory things are under control. And I think we can’t abandon any of those. And I don’t really think that you can start to loosen up on those completely until you’ve completed the circle for some part of the organization. Like I have to be able to know that my InfoSec is in place. I have to be able to know that I’ve followed all of my compliance rules for building the software that passes all these different types of tests.

– So I’m gonna be a little provocative, but since our audience is largely comes at this from an Agile point of view, when we start talking about compliance and things like that, I mean, it feels very anti-agile. Like, I mean, why don’t we just again just tell those people to go away. This is an agile shop, we don’t need compliance.

– Because public companies and big companies and investors actually care about their risk management, care about not going to jail for InfoSec problems. And they care about meeting their legal and compliance rights so they can sell their product in Stan market. Those things are not intended, they’re implemented in ways that are obstacles to writing codes sometimes. But they’re intended to protect the interest of the company

– So what you’re saying is that compliance can be re-engineered, it can be transformed to actually support the goals of agility and not work against it?

– [Dennis] Absolutely.

– Okay, cool.

– Maybe it still slows down a little bit, but if you’re building something that allows your privacy information to get leaked into the market, and costs you a hundred million dollars to solve, that’s probably a bad thing.

– Congress calls you to Washington or something like that, yeah.

– So then that leads to the two outer circles and I’m not quite sure if it’s one circle or two circles. You’ve talked about it. But there’s a circle on the outside, which is now talent. So in every one of those areas, we’re not just teaching scrum masters and product owners, how to operate, we’re teaching everybody from a talent standpoint we’ve got to do the right workforce planning and put the right people in the right jobs and staff things correctly. I’ve got to make sure the teams that should be co located are co-located and teams that can be distributed are distributed. And all that becomes a factor towards that system of delivery working. But also becomes a factor in all those other areas working well. Career progression and teaming-

– They follow things we’re doing internally with our talent life cycle management?

– It’s the e-learn thing. And then outside of that, I’m putting leadership. And leadership is your job now it’s not some kumbaya servant leader sort of thing. It is, how do I build an organization where my systems and structures are aligned with my markets and customers all the time.

– Yeah, basically teaching leadership and management, how to operate this integrated end to end system.

– Yeah, instead of dealing with every escalation and every crisis and managing all the stuff, or casting strategy over the wall that can’t be executed, how do I build a system that works that way? So teaching leadership to run differently, that’s the model. So I’m going to pivot with you. So awesome. Thanks for explaining that. So here’s an interesting thing. So again, I’m gonna reiterate on where I just brought you. We’ve done a really solid job of bringing the Agile community I believe into recognizing that all of these, that there’s a larger set of concerns. A lot of times we get on the ground with clients and they’ve been reading the latest Gartner Research or they have other consultancies in and they’re talking about things like, we talked a little bit about P2P, projects to products. The PDO is a hot button word. Digital transformation is kind of a latest buzz word and things like that. So one of my frustrations internally is that sometimes it’s easy to like almost want to articulate a competitive response on like basically follow the market into those storylines. And one of the things that I’ve really deeply believed is that, is that it’s all really just the same thing a little bit. So talk to me a little bit about like maybe like how PDO is the same or different than an Agile transformation. How is it same or different from this big problem that we’ve been exploring for the last few minutes.

– Yeah, so if we look at at PDO, you can have perfect Agile teams, but if they’re not built around products, and you’re not connecting the customer and getting the right information into those teams, you’re not going to get any value. And so PDO, if you’re just going in and trying to say, okay let’s just form a bunch of teams and make them all product-oriented, but you don’t have the ability to build backlogs, you can’t govern the flow of work, you’re not delivering things frequently. If you’re not doing the core-

– Can’t get it aligned to strategy-

– Can’t get it aligned to strategy-

– Can’t get it right, yeah.

– And then it all falls apart. So what happens is, a lot of these items that come in are trying to address a symptom. It’s actually a gap, not even a symptom, it’s a gap. It’s-

– [Mike] It’s a legit gap.

– It’s a legit gap, but it’s only part of the gap and that the things connect together. So when you try to solve part of the problem, you don’t get the result that you want.

– Yeah, so it’s funny, right? So I obviously didn’t invent this story and clearly didn’t even make the connection to it. Initially, I think I got introduced to this 10 or 12 years ago in the early days of Agile. But this this parable out of India I think of blind men and the elephant. And so what I’ve come to believe is that this larger problem that you’ve been exploring about aligning systems and structures to markets and customers, and in everything that you need to do from your system and delivery all the way through the product and strategy and governance, all the different pieces we’ve talked about, talent, leadership. That is the holistic picture. Those are the things, that is the universe of things that have to be aligned. Finally an alignment problem.

– These are the things that must be true to get the results that you want from your organization.

– Right, so in that parable, like what you basically have is you have blind men that are trying to describe an elephant from their particular point of view. So they can’t see the whole elephant. So they described the trunk or the tusk or the leg. And you might imagine if you’re trying to describe an elephant from a very limited point of view, you end up with a very skewed perspective of what the nature of the work is. And so one of the things we’ve been talking a lot about internally is like how do you help a client understand that when they read a piece of research and it’s talking about PDO or digital transformation or DevOps, or I mean, it’s just tons of when we’re talking about enterprise architecture, strategies, outcomes basically, yeah, yeah, yeah. So how do you connect those concepts back to the bigger story?

– So the first one is, you have to kind of understand that the connective tissue between those different parts of the system. ‘Cause what’s happening is, somebody is getting paid in one of those slices to make that slice work better. And they don’t have the insight into the whole system. They don’t have a picture of the other .

– So they are one of the blind men, right?

– They’re one of the blind men.

– And they’re getting paid and are accountable for improving the performance of the leg. And because we don’t have a way to look at it in a big picture and identify the dependencies on how far you can move that leg before you have to move some other part of the elephant. I like this metaphor.

– [Mike] Yeah, I do too, that’s nice.

– You can only move that leg so far. You might be able to flap the ear pretty far and move the trunk pretty far.

– It’s only been vetted by like three or 4,000 years of-

– So there may be some more adaptable pieces and less adaptable pieces, but you’re only gonna, until you move the whole elephant, you’re not going to get what you’re looking for. And so there’s this contrast we have people held accountable for performance of a slice, seeing the problem from their point of view and doing their best they can to solve it. They go read something that looks like it will work and it may or may not work. But it will only work if the other conditions exist to move it-

– For sure.

– Together.

– Yeah, okay, fascinating. So what I think what you’re saying is that it’s incumbent upon leadership people that are leading change to recognize that if we don’t get all of these pieces working, then it’s really difficult to get the whole thing working. And so what’s neat about it is, like I talk a lot internally within our company about the language of gain versus the language of loss. And it’s like it’s not wrong, it’s just an incomplete view of the world.

– [Dennis] That’s right.

– And so I think the challenge is a C-level person or a change leader or something. We’ve got to see a lot of VPs and C-level people that are responsible for Agile transformations or PDO transformations or digital transformations to recognize that there’s this much larger problem that has to be addressed. And if it’s not addressed in its entirety, ultimately leading back to this idea of systems and structures aligned with customers and markets. The ability to pivot. What do you do that?

– But there’s, what we’ve learned is you can do this incrementally and iteratively across organizations. You can take a capability or slices it’s the next most important one to move to that curve. But you have to look at the whole ecosystem around that slice. You can move the system of delivery pretty far up that curve.

– So are you saying that if somebody was starting a digital transformation or a PDO transformation or a P2P transformation, that maybe that’s a valid place to start, even though it’s dealing with the subset, but just recognize that as soon as you do that, the constraints are going to move to someplace else in the organization. And you’re going to start hitting walls that maybe you didn’t anticipate.

– Yep, and so when you do, you have to be paying attention. You can’t quit beating the horse. I’ve broken that metaphor. Yeah, you have to then pay attention to where the constraint is moving towards. That you have your head up ’cause it’s going to happen. And then the other thing that happens is if you get it working even as slice, and you don’t address those other parts of the organization, then before too long, the ecosystem will beat that part of the system back to where it was originally.

– So you go with the best of intentions but if you don’t do that holistically, it will actually erode the progress over time.

– Right.

– Fascinating. Okay, cool, I’m gonna wrap us. It was awesome.

– [Dennis] That was good, right?

– [Mike] Yeah, great talk.