Agile Unplugged: EP01 | Mike Cottmeyer and Brian Sondergaard

Welcome to an all-new podcast hosted by LeadingAgile’s CEO, Mike Cottmeyer. Agile Unplugged is your chance to explore LeadingAgile’s freshest ideas, mental models, frameworks, and solutions with the people that are actually doing the work of leading large-scale Agile Transformation, out in the field.

In the inaugural episode, Mike sits down with our CIO, Brian Sondergaard and reminisces about the world before LeadingAgile. At one time, Mike was working for Brian and together they paved the way for Agile at a company called CheckFree. Then, shortly after LeadingAgile became a reality, Brian was a client of ours.

Put two and two together, and you might imagine that Brian has a unique perspective on the Agile community given that he was an early adopter and thought leader in the world of Agile—and at one point a client looking for solutions.

Now that he’s on the consultant side of things, he brings his unique perspective to each of his engagements and is able to empathize with his clients in a way that only he can.

So get ready to settle in and listen to this all-new podcast.

You can also watch each and every episode on YouTube, IGTV, and Facebook.

Transcript

– Brian, thanks for being here with us.

– Thanks, Mike.

– Yeah. So, are you familiar with the hypothesis of what we’re trying to attempt here for the next hour or so?

– You know, at a certain level, but I’d love to hear you explain it more in detail.

– Yeah, well, so, the idea was is what we wanted to do is we wanted to go deeper into the backgrounds of some of the executives on our team, some of our really senior consultants and things like that, and start a conversation because, you know, I’ve been out in the market for a long time talking about things like the four quadrants and the three things, and the 10 circles, and such, right, all the stuff that’s up on the website that I talk about all the time. So, what I thought would be kind of cool is to get some of you guys and to go like, really deep into what it is what we’re actually doing on client sites and talk a little bit around it. Super casual, super informal, and just a conversation, and we’ll just kind of see where it goes.

– Sounds good.

– So, what’s cool about having you be my first guest is that you and I have a lot of history together. We do.

– So, you wanna tell our listeners a little bit about how we met?

– Sure, sure.

– I’m giving you a really open palette here, so be careful please.

– Yeah, you know, it was such a fascinating time. What was that, probably 2004, or ’05 or something in that kind of range, I think?

– I’m counting at like 13, 14 years ago.

– [Brian] Yeah, something like that.

– Yeah, yeah.

– And, so, you and I were both at CheckFree in those days.

– [Mike] You were Director of Development.

– I was the Director of Development. I was running a team in the e-bill space.

– And I was a project manager.

– And you were a project manager in a different part of the organization.

– [Mike] Yeah, yeah.

– But I was building a new team, because we were setting up a new organization. We were actually, we were moving a team from out of the country down into Norcross and had to build up a whole new team from scratch.

– Was that the first thing that I did with you, was the Waterloo?

– Yeah, yeah, I think so, I think so. That’s what I remember, anyways.

– Okay. You know what I think actually the first, first thing was, is we were working on eBill Five project together, but I didn’t work for you at the time. Your team was involved in that. I remember, so let me see if this rings a bell, right? So, I had never, I’d like heard of Agile, but like, I had no experience with Agile. And so we were doing RUP and the traditional PMBOK stuff and all that kind of a thing, and I sent you an email, and I said, “Okay, so you guys are doing Agile. “Tell me what Agile’s about.” And I think you sent me some Mary Poppendieck stuff, or you sent me the Agile Manifesto, or something like that.

– What I sent you, I remember, and I probably still have this someplace, it was the “World of Agile According to Brian.”

– That was it, yeah, that was absolutely the title of it. But I think you totally ripped it off from Poppendieck.

– Well what I did was, sure. Poppendieck was an influence for me, no doubt, and several others in those days. I had consumed everything from those that I looked up to and built my view of what was the right way to develop product over some number of years and had assembled that into my message. And that’s what I gave you. But sure, it was heavily influenced by Mary Poppendieck. I think those two things happened in the opposite order, but they might not have.

– [Mike] Okay, cool.

– Might not have. The thing that I took away from that experience in those days was, you and I had gotten to know each other a little bit, just casually at that point. I kind of knew what I wanted to be able to achieve. I knew something about how you looked at the world and knew it was completely compatible with the principles that I held to be true. And so, I knew when we were building out this team, and it can be either one of those programs.

– [Mike] Yeah, sure.

– Building out that team, assembling the talent that was gonna be necessary to go and achieve, you know, a really big objective in a really short period of time, that was one of those that most people would look at and say, “It just can’t happen, “or it’s gonna run into trouble.” But we knew it had to happen, and I had the latitude to assemble the team that could make it happen. I remember thinking, “Okay, I’ve gotta go get Mike.”

– [Mike] Very cool.

– “And have him share the pain.”

– Yeah, consider the pain shared at this point, yeah. So, what I thought was really, really interesting about that time is that we were, like, really, if you think about it, Agile at scale hadn’t been invented. Leffingwell hadn’t done his initial work on scaled Agile. The Larman and Vodde stuff hadn’t been released. Nothing about scaled Agile. But we were doing Agile at scale from like, the very, very early days.

– That’s right, right from the very beginning. I mean, I don’t remember the size of that team exactly. It eventually became probably, you know, 200 people or 300 people, something like that. And in those days, so if this was 2004, 2005, something in that kind of range, in those days, then, you know, for the most part, Agile was still maybe one team of six, or eight, or 10.

– [Mike] Yeah, yeah.

– Maybe two teams of six or eight or 10. That was the level of kind of coordination and orchestration that was required, and were setting out to do, you know, several hundred people on an enterprise-scale initiative that needed to go fast, needed to go right, needed to move into this financial services space where there’s not much tolerance for mistake. You know, you’re gonna move people’s money around, you gotta move it right.

– [Mike] Can’t be off by a penny.

– You can’t be off by a penny. And so, we were definitely in a position where we were having to put together constructs that allowed us to connect, legitimately connect, from, “here’s the strategic imperative” to, “here’s the hundreds of people “that are gonna be involved; how do we marry those up? “How do we make it happen?”

– Yeah, what I thought was really interesting about that time is that we had mainframe teams that were doing pretty hardcore waterfall with biannual releases and things like that, all the way to some of your teams that were doing like, straight technical XP kinds of practices.

– [Brian] That’s right.

– Trying to figure out how to marry all that stuff together. It was fascinating.

– It was. You know, in that same period of time, not on that same program, but in that same period of time, we also had teams interfacing directly with really large banks.

– [Mike] Yeah.

– You know, largest banks in the country, which were also, you know, to your point about our mainframe teams being kind of traditional, waterfall-driven teams, well, the banks as an entity, that’s the only thing they understood, and looked at anything contrary to that to just be an inappropriate way to build software. But we had worked out in those days really clear ways to interface between, you know, these kind of high-speed adaptive teams that were constantly sort of seeking, learning, responding, and these giant banks that were not that. We worked out pretty simple ways to create interfaces between them so that both could move in their lanes and in the way that they needed to, and in keeping with their compliance and regulatory requirements and all that kind of thing. But we can match them up to deliver on big objectives.

– Yeah, I remember one time I think I drove up to Charlotte to meet with some executives at MBNA and to teach them about how we were managing software projects.

– [Mike] Yeah, that’s right.

– And I was supposed to have other people go with me, and then all you guys ditched me or something. I’m sitting there as this relatively young project manager, teaching all these folks at the bank about Agile, right, and risk management and things. So, what were some of the key takeaways from that time? What helped us be successful?

– You know, one of the pictures that comes to my mind, you’ll remember it well. I’m almost embarrassed to say this now, but it was the Portfolio Tree, right?

– [Mike] Oh, yeah, of course.

– Remember that? You know, we came up with a way of decomposing what are the critical factors of the portfolio, how do each of those decompose and normalize into what today we would call programs, or maybe today we would call product teams. How do they decompose into things that we’re gonna feed particular back logs across the enterprise, which might be different people working in a little bit different ways, and then how did that cascade ultimately to teams that might be Scrum teams or might be XP teams, what have you, and be able to show to ourselves, you know, driving these results, but importantly, to senior executives that were completely unfamiliar with all of this way of working, how it was under control, how we had a reliable plan, how we were demonstrating progress against that plan.

– So, I think one of the interesting takeaways during that time is that you’ll, again, I wish we almost had like a whiteboard. We drew, like, I’m gonna use today’s words. We weren’t using those words 15 years ago. But we had the portfolio at the top, the program in the middle. We had the team level stuff, and the way we talked about it was that the portfolio established constraints for the program, the program established constraints for the teams, so the teams had autonomy to decide, unless they violated the constraint the level above. The program had autonomy to decide, unless they violated the portfolio stuff. And what we were trying to do at the time was there was a really heavy change in management culture, and we were trying to figure out how to get the teams to be able to inspect and adapt in the small and really put some guidance around it, so not every single thing that the teams were going to change had to go all the way up at the top as a change management initiative.

– Yeah, that’s right. And what was fascinating about, and really sort of formed, solidified some of my way of thinking about these things, in some cases, those constraints, as we would identify them, they would be identified as explicit contracts between systems.

– [Mike] Yeah.

– So, it took what we had understood about architecture and enterprise architecture and good design principles, and applied it to good program management disciplines that folks like you also brought to the table. So we put these principles together and swirled them around and came up with, “Okay, well, wait a minute, “if we’re thinking about how to orchestrate “across these teams and set up those constraints, “and we’re thinking about good architecture “and design principles and the delegation of responsibility “into these different teams that own “these different components, how do we get explicit “about what’s the contract across which they’re sharing,” and then we can turn them lose to do what they needed to do.

– Well, so what’s fascinating is that, again, this is so long ago to put yourself in this mindset, but it’s like, the prevailing wisdom at the time was that you would create a complete cross-functional team with all the skills necessary to be able to do everything. Well, we were dealing with systems that had, like, front ends, and .NET, and Java, middleware systems, reporting systems, COBOL mainframe systems, and some of those systems were like risk engines and things that required a tremendous amount of domain expertise, and you just weren’t gonna let anybody touch that stuff.

– Yeah, that’s right, encapsulating that domain expertise, and then, just add one more layer. I know I already said it, but maybe one of the providers within that whole set of programs is one of the banks who’s contributing maybe UI components or maybe back end components that all have to fit into this set of capabilities that are gonna add up to the whole. So, yeah, “All right, bank, hand over two of your people, “and COBOL team up in Ohio, hand over two of your people, “and reporting team, and data analytics,” for what there was data analytics in those days, “hand over two of your people, and we’re gonna “swizzle together this cross-functional team.” That just wasn’t remotely practical at this kind of product, at this kind of scale.

– Well, I think it remains to this day not practical.

– [Brian] Yeah.

– That’s where we’ve kind of landed in today’s language, was to organize around business capabilities, encapsulate teams and services and things like that, but we just didn’t have the language as crisp at the time.

– [Brian] Right.

– One of the things that you had, I think it was an example you used back in the day that really helped crystallize it for me is that, we would make service calls out to, I think it was Equifax, at the time, to do credit authorizations. So if you were gonna start up a bank account, you had to get a credit authorization. And so, they were putting capabilities into their product at their own pace, and we were putting capabilities into our product at a pace, but there was a point in time where what we were developing and what they were developing had to come together. We didn’t have control over their people. They didn’t have control over our people, and that was like one of the first examples where I went, “Okay, if we were gonna have two totally autonomous teams “creating services that were interdependent with each other, “how would you orchestrate and make sure “that those two things came together at the same time?” And whenever it was within a company, you could always make the case, “Well, why don’t we just share people? “Why don’t we do this?” But when it was two different companies that had to come together to provide a common service, that was an interesting use case.

– Yeah, that’s right. So we applied that, you know, design principle, system design and program design principle, which was aligned one-to-one in those external interfaces, but as you’ll remember, we did apply that to our internal interfaces as well.

– [Mike] Yeah.

– It comes to mind, I think even in those days.

– [Mike] Yeah, you were just ahead of me at that time. You understood it better than I did. Yeah, maybe for a week.

– [Mike] Yeah.

– In those days, we would think about the principles like Conway’s Law and the importance of respecting the communication boundaries in an enterprise.

– In case somebody’s not familiar, Conway’s Law, give us a brief recap of it.

– Yep. So in a nutshell, probably won’t use exactly the right language, but in a nutshell, then the way that components of a system interface with one another will naturally follow the way that teams are organized and interface with one another within the organization. So, while the prevailing wisdom was, “Let’s put together all of the cross-functional people “and build these feature teams “that work across all of the layers,” in a lot of cases, I’m certainly not saying in every case, but in a lot of cases, especially in these big systems at scale, you’re working opposite to this principle that you wanna respect in the design of the system, and convoluting the communication patterns between those people are gonna cause the architectural patterns to blend, and you’ll no longer have boundaries that are respected between components, and then those components won’t be able to adapt on their own over time, respecting their own objectives. They’ll experience chaos and entropy that leads to poor performance much faster if those boundaries aren’t respected. So if you want the boundaries to be respected, then the organizational boundaries have to be respected as well.

– Yeah, but the challenge with that is that when you have, like, ’cause one of our classic problems, this is a problem that we’ve been trying to solve conceptually forever, and we have solutions, but it’s a non-trivial problem. We were building the systems of systems, right? So you had, I think back in the day, we had the platform, right, and that was a set of services that were consumed by multiple other products, and then you have those products that are coming along and injecting requirements down into the services, right? So what we would end up with is we’d end up with services that were effectively a constraint in the value stream. You had multiple products that were trying to inject features into those core services, and they would become the bottleneck with the system that would prevent all of these different things. And we’d like to avoid that, but you remember that giant spreadsheet that I pulled together that did all of the resource leveling across teams and stuff?

– [Brian] Yeah, yeah, yeah, yeah, yeah, yeah.

– I still wish I had it. Do you have a copy of that? I’d love to see a copy of that at some point.

– [Brian] I doubt it.

– I spent months working on that clandestinely while I was trying to do the rest of my job, ’cause there’s no way I was gonna do resource leveling some other way. But anyway, the long story short, what we were trying to do is trying to figure out which teams were the constraint in the system, and then basically respect the capacity of the constraint and subordinate the rest of the system to flow across the rest of the system to the constraint. And that’s where a lot of organizations that we work with I think really struggle, is that they have a constrained team or a constrained capability within the system, and they just continue to build around it without actually ever elevating that constraint or investing more resources in the throughput of that constraint.

– Right, so the overall ability to serve the market is, you know, it experiences friction. Because we don’t elevate that constraint, we don’t resource that constraint in the appropriate way, we don’t feed the product teams at the rate that they need to be fed and new capabilities coming from that platform. And so, one of the things, of course, we learned to do in those days, the platform itself had to start understanding better what the market was going to need, right? It wasn’t only fed linearly from product down, because the platform was itself going to serve multiple products, so really, you needed to look at it just like a single product serves multiple customers. In most cases, if you start getting in a position where you start thinking about your product in an “n=1” mode instead of an “n=many” mode, then that product starts to suffer. It doesn’t move at the rate necessary to move the market in the way that you need to move the market to gain the market share in business performance.

– So let me see if I can restate what you just said in a minute. So it’s like the platform service was like a product unto itself whose customers were not only the external market, but also the products that were going to consume it internally.

– [Brian] Yeah, exactly.

– Yeah, so it had to go out into more. Rather than just being an order-taker and saying “Okay, I’ll build whatever services you want, “whenever you want them,” it had to go out and look at its customer base and prioritize its backlog to bring the highest value features to market as fast as we could, right?

– Yeah, that’s right. So we needed, and of course, this is a balance. It’s not an obvious black-and-white thing, but we needed for the product, I mean the platform, excuse me, to start acting a bit more like a product.

– [Mike] Yeah.

– Recognizing that it’s serving many customers. Its customers were the products.

– [Mike] Yeah.

– Platform was serving the products; the products were its customers. It needed to act more like a product, get a little bit ahead of those customers, feed them what they were going to need to be able to solve the market problems that our ecosystem as a whole was being asked to serve. But of course, that was moving into some weird multi-dimensional prioritization of requirements across the enterprise.

– That’s complicated, right?

– Yeah, it was complicated. Yeah, it was hard for people to get their head around, but that’s what was necessary.

– Well, that’s kind of why we ended up having to go with kind of the portfolio layer, ’cause the portfolio had to be the arbiter of the business’s priorities, because all the programs were, in effect, competing with each other for resources.

– [Brian] Yeah, yep.

– Yeah, fascinating. Okay, so one thing I wanna just give a nod to, it’s like somebody who’s heavily influenced our thinking on this was David Anderson’s stuff around the pre-Kanban stuff.

– [Brian] Yeah, that’s right.

– The Agile management stuff, right? And so, I like to throw that out, because, you know, we talk about the Agile thinkers a lot, and I would consider David one of those guys. But it’s like, he was the guy that introduced me to Theory of Constraints, right? So then read all the Goldratt stuff and that kind of thing. But that was huge in really understanding how to run a portfolio.

– Yeah, no doubt about it. In fact, I was caught a little bit when you said, this isn’t exactly what you said, but how it came to my head was, “We wherever heavily influenced by these Agile guys, “but then also people like David Anderson.”

– [Mike] Yeah.

– And it’s like for me, it’s all in the same system, right?

– [Mike] For sure, yeah.

– I’ve always imagined that as different pieces of science that are leading us to understand how to stitch together the way of working. From the top strategy to the last line of code, how do we bring the right science into the system and design it?

– Probably the reason I made the slight distinction is ’cause I don’t think Mary’s writing much anymore. I don’t hear much from David. He might be out there. I just don’t see as much of their work as I do the guys that are doing Scrum and LeSS and SAFe and things like that.

– [Brian] Yeah, yeah, that’s right.

– Yeah. Okay, so let’s fast forward a little bit. So, CheckFree gets acquired by Fiserv. I moved along. I went and go work for VersionOne for a couple years, had a time with Pillar out of Columbus. Started LeadingAgile in 2010. So after I left, tell me a little bit about how your career took off?

– So, let’s see, when did you leave? You just said that.

– I would say 2009-ish, early 2009 maybe.

– [Brian] 2009, 2010?

– Yeah.

– Yeah, so it was probably just right after that.

– [Mike] Oh, no, it was probably ’08. It was probably ’08, ’cause I did almost two years at VersionOne and then about 10 months at Pillar. And then, so LeadingAgile will have its 10-year anniversary August first, 2020, yeah. So 2007, maybe, wow.

– Yeah, so I continued to run development. We did a couple of more programs like the ones we were talking about a minute ago for another year or year and a half, and then moved over to a different part of the organization, global payments, as CTO, and immediately took the same.

– Did you just skip over vice president? You just went from director to CTO?

– [Brian] Yeah.

– Or did you actually get an intermediate promotion there at some point in time?

– Yep, yep.

– Yeah, ’cause I remember during that time, I wanted you. I had always planned to try to chase you down and get you to come work with us, and we couldn’t keep up with you. It’s like, you kept getting promoted, and your salary kept getting bigger and all this stuff. So yeah, you were on Rails at that point.

– Yeah, no, it was a great time, and honest to goodness, it was taking the things that we built together over those years, figuring out how to solve these big, complex problems across big, complex organizations, and beyond the boundaries of those big, complex organizations into our corporate partners, like you mentioned Equifax, and we talked earlier about Bank of America and others. Taking those ways of working and going into a new organization into Fiserv and implementing that system, realigning the organization, getting it built around what are its primary capabilities and products, standing up this flow of decision making that connects all the dots from strategy to execution, and taking the organization from struggling to move quickly enough or impactfully enough to serve the markets that it was serving into really high-performing teams that were innovating and creating new products.

– Well, so, you had two classes of challenges. So, as you were advancing in your career, you were basically taking what you had learned in your business unit, and you were trying to apply those lessons learned into a much broader corporate ecosystem. Talk to me a little bit about some of the challenges with that.

– So, the first thing that comes to my mind is that it’s sort of similar challenges, in that we’re a company that has been in business at this point 26 years or something, have done really good work in the market, created whole new markets out of nothing, the company had. And so, of course it had ways of working that produce meaningful business results that led to significant growth. People knew how to work within that way of working. So it was deeply rooted, right? There was a DNA in the company that informed how people thought about doing their jobs. So, now we’re coming along and applying these Lean-Agile ways of working, Lean-Agile ways of designing the organization, Lean-Agile ways of connecting flow from strategy through execution, and it looks very different. So the challenges really start from there. The hard-wiring of the people and their understanding of what it’s gonna take to be successful is going this direction, and we’re coming along and saying, “Well, we need to go in this direction.” And what we did over those years was help figure out what stood in the way between the people doing the work and the customers or stakeholders who needed the results of that work. In just about every case, the things that had started to amass in the organization that were interfering with delivering at the rate that the company wanted to deliver or interfering with delivering the impact that the company wanted to create, were that the people doing the work had been moved back one step at a time until they were four or five or 10 layers away from who’s actually gonna benefit from this value that we’re gonna produce. So we started recognizing a pattern of needing to restructure the organization in some way to take these people that are gonna be the producers of value and move them much closer to the people that were gonna be the consumers of that value, and cut out the middlemen. We still need to have good architecture. We still need to have good business analysis and understand what’s really important to the market. Still needed, and more and more needed, super-effective product management. So all of that was part of the process, but basically, remove all of the walls in between the producers and the consumers so that they were talking about to one another, could share perspectives, share understanding, communicate clearly about goals and the best opportunities for achieving those goals and move much more quickly.

– So let’s pause there for a second. So I wanna re-anchor on where we are, right? So your crew’s taken off. You’re CTO, CIO. You have business partners that, you’re in effect running a business within kind of the Fiserv ecosystem. And so, you come in as the technology leader within that organization, recognize that people are too far away from the customers, that they’re not connected sufficiently to value. How do you as a leader begin to start moving the organization in that way, given how culturally entrenched it was in the way it had been working?

– I think it starts with being a little bit bull-headed.

– [Mike] Yeah, a little stubborn, yeah.

– A little stubborn, a little determined.

– [Mike] Fearless.

– A little fearless, yeah, but also, you know, an absolute critical part of it, especially in these first steps, was just happened to marry up really good with the business unit president, who had a clear understanding of what needed to happen and was willing and interesting and motivated to sit with me and talk through what we needed to do to make that happen, and then gave me the room to make the changes.

– [Mike] Yeah.

– Run the experiments, prove the results, built on those results.

– So we talk a lot about the importance of engaging the business. It’s the whole business agility movement. It’s what we’re doing with Elevate Agile, right, in a lot of ways. But this isn’t like, “Just get the product owner “to show up and write the requirements for you.” This is legitimately getting somebody who is running hundreds of millions of dollars of revenue to take this risk, right? So what did you do to build that kind of trust with your business partner?

– You know, it started with, I think a lot about this, because so many of the clients we’re working with today are suffering from exactly this thing. And it really started with, I understood, or quickly understood, what was important to Pat, and I was obsessed with what was important to that business unit president. What his few hundred million dollars of revenue was became my goal, and as quick as we could make it so, then he would understand that I was gonna do absolutely everything possible, and then a little bit more, to achieve that goal. Like, that was the goal, whereas the conversation that he’s used to having was something about some technology problems or some risks or some reason why we’ve gotta spend this much money on this technology, ’cause it’s gonna make a neat product, versus, you know, “Here’s our revenue objective. “Here’s our expense objective. “Here’s the organization that we have to align with that. “Here’s where we’re gonna pull the levers “to drive that revenue. “Here’s how we’re gonna align the organization then, “exactly at that target.” And so we flipped the conversation to those business outcomes from just about day one, and then just partnered together on what are we gonna do.

– It’s a fascinating observation, ’cause one of the questions I get asked when I do live talks or if I’m talking to a user group or something is like, “How do you get your executives bought in,” right? ‘Cause a lot of people want to do Agile at this point, and they’re even funding it, but it’s like, they just don’t feel as committed. And that’s the first piece of advice I give ’em, is you gotta care about what they care about.

– That’s right, care about what they care about. And I think for me, it just happened to be that I’m so wired to care about that, those business outcomes. There’s a lot of stuff that’s important in business. Most businesses, they care about their employees, they care about their customers, they care about their community, they care about the markets they’re serving. They care about a lot of things. But no matter what, when you break it down and get down to it, at the end of the day, what they have to care about the most, people argue with me about this, but what they have to care about the most is, “Am I positioning my business to be successful? “Am I generating the revenue? “Am I generating the profit that I need to be successful?” ‘Cause if I’m not doing that, all these other things that I care about, I’m not going to produce them.

– So I’ve got a funny aside for you. A couple years ago, I had somebody working with me on the leadership team, and I guess I was being a particular jerk that week or something. I was being pretty rough, and she goes, she goes, “If you keep acting in this way, “you’re gonna kill our culture.” And I’m like, “Well, if you guys “can’t figure out how to fix this stuff, “we’re not gonna have a culture to kill.”

– [Brian] Not gonna have a culture to kill. Yeah, yeah. And so, there is. It’s a funny chicken and the egg, because it’s like, all those things around employee satisfaction and work environment and empowerment and autonomy, all that stuff is critically important, but if it’s not delivered within the context of an economically viable company, you don’t get to answer the second part of that question.

– Yeah, that’s right. You don’t get to answer it. So it started there. I think right behind that, I had watched so many times in my career, teams, or even organizations and departments, sort of flirt with something that needed to happen, but never really go make it happen. They would just sort of buy time and ride it out and accept the constraints and stay in their box, and inevitably, because the thing that they wanted to change was likely stuff that needed to change, inevitably, the time would run out, and somebody else would change it, right? Eventually, something would become a big enough problem to leadership in the company that they’d just come along with a really big hammer and knock stuff over and move walls around, do major renovation. My wife and I have done a lot of renovation over the last 10 years, and when we think about renovation, it’s not, “I’m gonna put a new coat of paint on the wall.”

– Yeah, you like, break things down and put in new beams and things like that, yeah.

– I’m gonna put, you know, some new trim up.

– [Mike] Yeah, yeah.

– Yeah, when we think renovation, it’s like, “Well, I know the builder put this wall here, “but that wall’s interfering with what I wanna do “with my dining table that’ll seat 20 people.” And so it’s in the way of me achieving my objectives. I’m gonna move the wall. So eventually, somebody would come along with the gumption to move the walls, figuratively speaking.

– Why do you think we’re so inclined as employees within companies to just see the walls as immovable? ‘Cause I think that’s the biggest thing. It’s like, people can’t see past the constraints to a better way of doing things.

– Yeah, I think you’re right. Why are we that inclined? Isn’t it mostly human nature?

– [Mike] I think so.

– I think that’s largely human nature, people willing to, or are more comfortable, seeing their sphere of control than their sphere of influence and not feeling emboldened to go out and add to the sphere of influence to create the opportunity to say, “Yeah, that wall “is in the way of us achieving our objectives. “Let’s do real renovation here.” So I think that was the second thing for me. So, start with what was important to him. Second was, if folks are gonna come move the walls, I’d rather be the one that’s moving the walls than waiting for somebody else to move them.

– Well, so, let’s pivot a little bit. So we talked about the fact that I used to work for you back in the day, and then at some point in time, I guess, like you said, 2010-ish, started at LeadingAgile. Pretty soon after, you hired us, and we came in and did some work for you guys within Fiserv. So, talk to me a little bit about what is it like to lead transformation work from the inside. Like, what kind of leader do you feel like you needed to be to not only orchestrate us, orchestrate your teams, to make the kinds of changes that you needed to make? So basically, this is your opportunity to give advice to other leaders that might be out there listening to this or watching this. What do they need to do? Who do they need to be maybe is the question I really wanna ask.

– Confident in your vision of what it is you want to happen and why and how you’re gonna be able to demonstrate that progress. The place where my mind went first in this conversation was, give the business unit president what he needs. Well, now LeadingAgile is coming in behind me, and they’re helping me to make that real. And so I created the space for it to happen, but now that’s only the start. Where we have to go from there is constant feeding up to that senior leadership team, “What we agreed to go do, it’s actually happening. “Here’s the results that we promised. “Here’s how you can measure in reliable and objective ways “that what’s important to you “is becoming more real in this organization.” So, direct traceability from the results of our transformation to the business results that were important to that person. So, to me, that’s where it starts. So being confident in that vision, being able to demonstrate clear results, demonstrable, measurable results, but then being absolutely hands-on so you understand the reality of what’s happening across the organization.

– So you don’t get to just hire a bunch of consultants and name a director of transformation and let it go?

– Yeah, I haven’t seen that work too good.

– [Mike] Haven’t seen it work yet, okay.

– This is almost too tactical, but I think it’s important. I would inevitably wind up sitting around a boardroom table and fielding some questions from a senior executive team about this aspect of the transformation, or most likely, the question started with this consideration related to their business results, and if I couldn’t connect the dots 10 layers deep into what we’re doing and why it’s gonna add up to what’s important to them, then I’m certain I wouldn’t maintain the credibility necessary to continue making the changes that I wanted to make and that I knew needed to happen.

– So the analogy I use a lot is I’m kind of an aspiring pool player. A pretty lousy pool player, but aspiring pool player. I talk about the idea of calling your shots, you know, the ability to say, “This is what we’re gonna do; “we did it,” and it doesn’t count unless you were able to say that you could do it before you did it. That kind of a thing.

– Yeah. Yeah, that’s right. And so, is there some way to build on that analogy to say, it’s “call the shot,” but also, the next three that are gonna happen.

– Yeah, sure, yeah. Yeah, the good pool players can actually run the table that way.

– Right, yeah. So I feel like that was, I think that was really important, to be able to call the shots and demonstrate control, but it’s calling shots three or four shots out in front. “I’m gonna do this, ’cause that’s gonna lead to this, “that’s gonna lead to that, and that’s gonna lead to that.” And then being able to, when something comes up, when some challenge comes up, which might be a legitimate challenge, something’s not going right, or it might be, and I think sitting here today, I feel like it was more often some misunderstanding that somebody had somewhere. So being able to participate in a conversation, to be in the place and participate in the conversation when that problem came up, whether it was a real problem or just a misunderstanding or miscommunication, and be able to understand for real what’s going on, and to be able to diagnose that and connect multiple dots across different parts of the organization to say, “Now, here’s what’s really happening. “Here’s what we need to do to all understand it better, “or here’s what we need to do to adjust it “so that it heads on the course that we need to do.” Being able to really roll up the sleeves and get into the weeds when it’s necessary I think is so important to sustaining change.

– You wanna go down a little bit of a rabbit hole with me?

– Sure.

– “Sure.” He looks skeptical. So, kind of a selfish question. So we did this Elevate Agile conference a couple weeks ago, and the one thing that we were trying to do as part of that conversation is, as the name implies, elevate the conversation, right, so we’re not incessantly talking about team-level practices or SAFe or process, ’cause what I was saying is ’cause, as the CEO of LeadingAgile, I get out and I kind of sell, right? I tell our story a lot. And what I was finding is that when I would start to tell the story, when I would mention Agile or even SAFe or something, people are like, “Oh, yeah, that’s what the teams do.” We need to have a conversation about what are we doing from a business perspective, right? And so, that was the backdrop for that conference. So we tried to orchestrate the content and get everybody, but it’s so difficult to talk about even Agile at scale or business agility. It’s difficult to elevate the conversation around Agile because it’s like, because you need to connect what’s happening on the ground to the business results, it’s like you have to have a conversation across the entire stack. So you start to talk down here, and you lose the executives, and if you start to talk up here, you’re not connecting enough dots into the how. So I’m finding that very personally challenging from a messaging perspective. It’s almost like, how to navigate the different layers of abstraction in the conversation and make sure that people are anchored in the conversation where you want them to be. So I imagine you dealt with that a lot, right? You’re dealing with a division president, but yet there’s a tension and almost like a pull to wanna talk about what this team’s doing over here, or if you’re talking about this team, how does that translate into the business objectives? I know I probably put you on the spot here, but talk to me a little bit about the tension between having that conversation at different levels as an executive in that company, any thoughts?

– Well, okay, so where my head first goes is sort of the same place where we were, was being tuned in enough.

– As the executive.

– [Brian] As the executive.

– Okay, sure.

– Being tuned in enough so that at nine o’clock in the morning, you’re sitting at the C table and having the conversation with the president and the COO and the CFO, and we’re talking about the performance of the business and our fourth quarter revenue and where we’re at, being able to walk from that nine o’clock conversation to a 10 o’clock conversation with a couple of the teams related to how their current release is performing and how they’re expecting to deliver against expectations or not, helping them to understand why it’s important and how the result of their release is gonna connect to these business outcomes that were just discussed in the prior hour, being able to go from there and have conversations with maybe the chief product officer or something like this about how we’re thinking about the next series of product releases across all of these products and how we can look at cross-cutting or synergistic opportunities that feed demand into the organization that allow us to accelerate. So being able to walk hour by hour into those different contexts and have sufficient situational awareness to understand what we’re really trying to do and why it matters and help the people that you’re talking to to reconnect with why I think is a super important part of it.

– It’s almost like the line of demarcation is almost like, at the business architecture level, because it’s like, you have the business capabilities, business architecture. Everything below that is teams and execution and performance characteristics and how you’re managing it. And then from the business architecture up, it’s more like a line to strategy. You think that’s a decent way of thinking about it?

– I think it is a decent way to think about it. I think there might be a couple of dimensions in play at the same time. You might have business architecture, and its current alignment to strategy, how that set of business capabilities or products or value streams is assembled to support execution against your current strategic imperatives. Maybe simultaneously, though, you have analysis going on in what’s important in the market and how likely, over the next 18 months, over the next 36 months, you’re gonna need to make big pivots in the market and strategically head in a different direction and be able to understand how that comes down through that business architecture and puts pressure on it to pivot in ways that it’s not currently designed to be able to pivot. And then maybe coming up from the other direction, you know, the raw, technical architecture that’s supporting that business architecture and being able to think about those cross-cuts and understand how those are put together and how they might need to change. So I’m just trying to think of, there’s about three or four different dimensions that you probably have to be able to think through and synthesize to make the best decisions.

– Even when we interview senior consultants, right, so like, a lot of times, I’m trying to get a handle on how they think about business architecture and team formation strategies and things likes that, and then everybody thinks I’m talking about team-level Agile or talking about Scrum or something like that, because I see the stack in its full dimensionality, and getting people to anchor on where you’re at in that conversation I think is really, really difficult.

– Yeah, right. Where in that conversation are you gonna anchor? What frame of reference are you going to look at it through, and who are you gonna participate in the conversation with when looking at it through that frame of reference?

– Yeah, so I have an interesting pivot for you now. So, so, as an executive, one of the things that was really awesome about working with you is that you just deeply understood this stuff, right? So you come from an architecture background, right, so you think in terms of services and business capabilities and things like that. So, as you and Dennis were working together, and as you and I would have conversations, this language was very native to you. You deeply understood it. So now you’re on the other side, right? So now you’re going in and you’re talking to executives that maybe are not, I don’t wanna say astute, right, ’cause they’re obviously super smart and have successfully led their companies, but they might not come from the same background that you do, right? How have you navigated that transition?

– Yeah, it’s tough. You’re hitting on one angle which is, you know, sort of the language and the depth of understanding, and sort of needing to pull the story up to meet an individual where they are. Now, that kind of meet them where they are has always been part of the process. I mean, we’ve kind of talked about that in a few different ways now. So it’s always been a motivation, but sometimes, where our clients are is a very different place than what I’ve had direct experience with, so trying to get inside their head and quickly understand how they’re seeing the world.

– Well, it’s a fascinating challenge, right? So, for anybody’s who’s followed anything that I’ve done for a long time, really going from project manager, Agile coach, Agile consultant, starting a company, growing our company up to 120 people or what have you, there’s a lot of marketing, right? There’s a lot of storytelling that goes into it. And if you bring the story too high, it just looks like everybody else, right? There’s no differentiation. “Aw, yeah, you solve business problems, “you align, you do this,” right? So the secret sauce is in somehow, there’s an operational model underneath it, right? There’s a changed management. There’s a way of thinking about business architectures. There’s a way of thinking about teams and governance and alignment and tying execution to strategy, but then at the end of the day, it is about strategy articulation, right? It’s about business value. So there’s a funny little dance that we’re trying to figure out how to do. It’s like you have to tie to those things that everybody else is talking about, but the how you get there is fairly unique, I think, how we’re thinking about it a little bit.

– No, I think so. It’s unique, and it’s, I mean, obviously, I can’t speak to this without some bias, right?

– [Mike] Yeah, sure.

– But I think exceptionally comprehensive.

– I think everybody listening knows what we do for a living, so it’s okay.

– Well, yeah, of course I think it’s exceptionally comprehensive. But it is, I believe. It’s so thorough, our way of thinking about what makes organizations high-performing and what has to get built, what has to get nurtured to make them high performing. We’ve talked a couple of different, we’ve made a couple different paths now at this multi-dimensional frame of reference. I need to assemble the parts thing, including the conversation, like to your very last point, a conversation with this executive who you’re trying to help understand what it’s gonna take to erect the kind of organization that they’re gonna want. And there’s 10 different dimensions and 30 layers of depth in each one of those dimensions, all of which can be part of the conversation at any one point, but choosing just the right thread through all of that for this one need, it’s tricky, and I won’t say I’ve got that all figured out. That’s certainly an area.

– Yeah, I don’t think any of us have it totally figured out.

– That I’m continuing to grow in, for sure.

– Well, so, maybe like final thing, and this is totally orthogonal to everything we’ve talked about so far, but kind of related to this last point. So I started writing, I don’t know if it’s gonna be an article of a blog post, or maybe it’s just a collection of thoughts, but like when you start to think about all the personality profiling stuff that we do to hire or help our clients build teams or whatever, I mean, we use emotional intelligence, intellectual intelligence, behavioral profiles, you know, are you logical or emotional, controlling, non-controlling kinds of things. The latest thing I’ve been thinking a lot about is growth mindset versus fixed mindset. I’m actually starting to wonder how any human beings ever share ideas or talk to each other at all. The amount of insight that you almost have to have about another human being sitting across from you is, it’s mind-numbing.

– [Brian] Yeah.

– I don’t know. So now that you’re kind of on this side, like, what’s been your observations around that, knowing how people tick as you get in and start talking with them a little bit?

– It’s obviously critically important, but it’s hard. But you made me think, you know, Mike, as you went through those emotional intelligence and intellectual intelligence and all these different considerations.

– Systems thinking/non-systems thinking is one of ’em, yeah.

– There’s that quote, something like, “All models are wrong; some models are useful,” right?

– [Mike] Yeah, yeah.

– So I try to keep that in mind. Even with the background that I have, or maybe because of the background that I have in architecture, in architecture, boundaries are really clear, right? You’re a producer or you’re a consumer. you’re sending this message, you’re getting this response. I mean, the boundaries, responsibilities are really clear. Nonetheless, when you start backing up and looking at the enterprise, you’re contemplating all of those boundaries in some sort of abstraction, hopefully an abstraction that is still adding meaningful value to the conversations that you’re trying to have, ’cause you didn’t carry all of the detail into that conversation. You’re using some abstraction. You’re using some model, and in that model, hopefully we’ve pulled up the right considerations that are most important and most impactful to what we’re trying to decide in that particular exchange. So when I think about all of those different tools that we use, I think about all of them as part of a comprehensive model that is absolute valuable, and it’s absolutely right, but it’s not 100% right.

– Sure, yeah. Well, I was thinking about it, right? So this is totally self-interested kind of just, you know, just an exploration, ’cause it’s something I think about all the time. And it’s almost a little bit like it comes down to what we call our influence-trust loop, right, where it’s like you have to have empathy. You have to have a point of view. You have to create safety, you know? So like, if you’re aware enough of those kinds of things, you can get close and build an influence relationship and then do what you say you’re going to do. That’s probably a lot of it, ’cause at some point, I think it gets back to what you were talking about with your division president at some point in time. At some point, you earned enough trust with him to be able to say, where he said, “Okay, I trust that you have my best interest at heart. “You’ve influenced me. “You’ve demonstrated that you can call your shots, “and we’re going to let you do it.” But I think at some point, you have to bust through that abstraction and just earn somebody’s trust and have ’em let you go do something, yeah.

– Yeah, I could agree more. What we see so often when we’re starting with new clients is the conversation is, “I need that boss to do X, Y, Z differently. “They’re approaching the organization wrong. “They’re asking for the wrong things. “They’re using the wrong measures. “They need to change that.” Like, but we’re not at any place yet to ask them to change anything. We’ve gotta meet them where they are right now, understand what’s important to them, understand how to start creating trust with them, because we’re calling our shots and demonstrating control, and in that, giving them what they needed. And as they get more of what they need, and as they see that we’re going to do everything possible to provide for their interests, then they’ll start to trust more, and in that trust, they will give us more influence. They will five us more ability to influence how they’re going to approach things, and that’s when we can start really accelerating change. But we can’t start with, “You need to change.” We have to start with, “What are we gonna do to change for them?”

– Very cool. Well, thank you for being here, and it was awesome. I really appreciate you spending time with me.

– Yeah, I enjoyed it, Mike.

– [Mike] Yeah, very cool.

– [Brian] Good to see you.