Mike Cottmeyer

Speaker: Miljan Bajic  00:29

Who is Mike Cottmeyer and what’s been your journey?

Mike Cottmeyer  00:33

Okay, well, that’s a big question, man, who is Mike Cottmeyer? Well okay, well, I’ll take it from a professional angle. So, I’m the CEO of a company called Leading Agile, started about 11 years ago, I’m based in Atlanta, Georgia. We’ve gotten pretty big over the last couple years, we’re about 160, almost 270 people, we focus almost exclusively on Agile Transformation. More often than not in kind of either the IT product development space or IT services space. We like to consider ourselves kind of a full stack consultancy in the sense that you know, obviously, you have to deal with the work surface levels and what the teams are doing but you know, how do you orchestrate teams across dependency boundaries? How do you go up into Portfolio Management? How do you go up into investment management, that kind of a thing? What do you do with audit and compliance? What do you do with planning cadences? What do you do with Enterprise Architecture like, the whole thing, right? So like, what we really do is, I like to think of us as like, we kind of refactor organizations to be able to operate with more business agility, right, in a nutshell. And then aside from that, you know, I’m a dad, a husband, I have three boys, you know, so it’s basically family and work for the most part, for me.

Speaker: Miljan Bajic  01:53

You got a lot of guitars and are those guitars in the background?

Mike Cottmeyer  01:56

I do, I play guitar. So I actually, as soon as I said that, I went well, it’s not 100% try skill at hand. I play guitar and I did jiu-jitsu and I’ve been kind of on a bit of a fitness journey for the last couple of years as well. So yeah, but the hobby is all kinds of very, guitars have been persistent in my life since I was about 12 years old. Yeah.

Speaker: Miljan Bajic  02:13

Nice. How did you get into this agile space? You said, you’ve been doing this 11 years but I’m sure it’s more than that. Like, how did you end up?

Mike Cottmeyer  02:21

Yeah, well, back in the early 2000s. Well, I guess, you know I spent the first 10 years of my career mostly in IT infrastructure. So like, literally like 19, to about like, 30 or so and then, so I guess 30 put us in the early 2000s. And you know, the manifesto had just been written and I was working as a project manager in a company called CheckFree here in Atlanta and squarely like in the PMO. But I had always kind of adapted practices, project management practices to deal with variation because like, my worldview was that things were not as certain as the Gantt chart implied, kind of view. And so, I was working on this company called Check free in the PMO, doing PMI style project management and I was working with development teams and there was a guy who’s on my team now named Brian Sondergaard, who I worked for. And we were going back and forth on some things and so I inquired, I like, what do you guys like, tell me, what do you guys formally doing and they were doing they said it was extreme programming at the time. 

But what they’re really doing was like scrum with technical practices and things like that, I ever more aligned, it felt like to me was Scrum. And so, I built a relationship with this dev director that I was working with and he and I would collaborate and I was reading books and you know, reading all the Kent Beck stuff, [unsure 03:48]. There were so a lot of guys writing kind of in the rough space and scale project management space, agile project management space, that time Jim Highsmith write on that kind of stuff. And then so the same guy, Brian Sondergaard, ended up coming in working for him in his dev organization and we just started doing some really cool stuff with Agile program portfolio management. We were inventing a lot of things, taking David Anderson’s work on Kanban and agile management stuff that he was doing and literally building like, what you would recognize now is like, early versions of safe, you know here frameworks and like flow based management systems at the higher tiers. And so, it’s that for a couple years, that group reorganized and I kind of find myself back in a regular PMO and I’m like, that’s not cool, right? 

At that point I said that, no disrespect to PMOs out there but it’s like, we’ve done so much cool stuff like I just couldn’t go backwards. Right? And then, so I ended up going to work for Version One for a little bit and that was like my first introductory to like a pure play agile organization and I was on the team that went in, trained and consulted. And what was super cool about that was and I know a lot of practitioners are listening to this, will recognize it, when you have a tool, the tools are typically designed to work in an agile way. And if you’re working with an organization that’s not really structured for agility, like you start to recognize there’s a lot of stuff that’s broken and you have kind of two choices. You either change the tool to accommodate the organization or you change the organization and unfortunately, most of the companies that we were dealing with, didn’t have agency or influence to change the organization. 

But I started writing a lot about what I would do and I started doing talks about what I do. And the cool thing about Version One is like, any talk, any conference I can get accepted to, they let me go speak and I was off speaking. Yes, going to conferences, building networks, you know, meeting with people I got to meet, you know, people who were like my heroes like, Jim Highsmith and Alastair Coburn and Christopher [unsure 05:55] and Joshua Kerievsky and you know, Kent Beck and like all these guys, right? And was fortunate to become friends with some of them through the years, right which is pretty cool to become friends with your heroes a little bit. Literally standing on the shoulders of giants, left out Mike Cohn, never really became buddies, duster dirty, you know, just all those luminaries of our field just consumed everything, right? And I was just writing and writing and speaking and stuff and then you know, when joined a company called Pillar Technology for about a year, ended up not being a great move for me personally but great company or fine. 

Sold to Accenture, I think and then loving years ago launched leading agile and stated goal is I wanted to make, I want to double my salary and work part time but I failed miserably. For 11 years, became a CEO and learned a ton about stuff I’d never want to learn about like, banking and [unsure 06:57], benefits and investment strategies and you know, growth and SGMA and cost of goods sold and all kinds of stuff like that, yeah. Trying to keep the company as agile as it can possibly be so like, we try super hard to organize in ways very similar to how we ask our customers to organize and manage their processes, empower the people and you know, distribute decision making and try not to be super commanding control. And you know, that kind of a thing so we try to do what we say to do, right and we try to be that way.

Speaker: Miljan Bajic  07:30

Yeah, that is awesome. I think you know, obviously I know they prior and you know, I’ve known other people that worked and it’s you know, from Leading Agile, at least what I’ve heard people that work for Leading Agile. Like, the way that you engage with your clients is, you know, focus more on coaching, focus more on meeting people where they are in companies. And I want to kind of go back to something that you mentioned which is, you said you refactor organizations. And I want to go to a topic, I haven’t discussed this with anybody on the podcast, I’ve done business architecture. And I want to start there and then we can kind of go down but from your perspective and you said something that’s related to this, you said, if your systems and capabilities are not aligned to your products and customers, your practices don’t matter. So, I want to come back to that but could you just maybe for those that are not familiar with what business architecture is, could you maybe just describe it?

Mike Cottmeyer  08:28

Well, so we’re in an interesting phase of Leading Agile where we have people that are deep experts in things that are not deep experts in. And so, like the Stevens who was one of my early, like, co founder kind of people, deep expertise in business architecture, I kind of think I’m just kind of a business architecture hobbyist, right? But in principle, what we’re talking about with business architecture, is we look at the organization not through the lens of what the people do or what their function is but more through the lens of what are the services that the business provides. And so like, the analogy I use, the reason why I talk about refactoring is because I think there’s like a really strong metaphor here. It’s like when you take like a legacy monolith and you want to like move to the cloud or do DevOps or something like that, right? 

You can’t pull the whole monolith up and put it in a cloud, right? What you end up doing is you’re pulling out services and you end up encapsulating services and you put encapsulated services, service boundaries and contracts and all those things, you move that to the cloud, right kind of thing? And that’s what a lot of organizations are like, but it’s people and structures and processes and org design and things like that. And so, what when we do an early stage transformation, I actually don’t bring typically agile coaches. I mean, everybody’s like very familiar with Agile and Scrum and things like that but I wouldn’t call them agile coaches per se. We typically do in early stage like a startup engagement where the business architect and somebody who’s like really, like a product person but probably a little different than most people would think. Like, so we go in and we will literally do like business capability models, heat maps at your organization.

Speaker: Miljan Bajic  10:13

And then I’m assuming this is somebody like pretty high up like, C.O.O. Like, because those are the people that have usually authority to make these type of changes, right or is it somebody like?

Mike Cottmeyer  10:22

Yeah. Well, that’s probably an interesting angle. Right? So, one of the things that I talked about as a company and just from us is we have to be incredibly patient in our sales cycle. Because like, it all comes down to span of control and so, you know, so if you’re dealing with like a division, right, it might be like a division head, it could be a divisional C.I.O or Senior Vice President or Vice President is working with a business partner on that side nav, span of control over like a piece of the organization. But yeah, absolutely right, the kinds of changes that you have to make, have to be sponsored at the top because they’re not process changes. 

Process is part of it but like, you literally have to create a hypothesis organizationally for what you’re going to group people around. Right? And so, let me take it from the other side, like one of the, like I did a talk for the scrum gathering in Vegas, it had to have been, you know, eight, nine years ago at this point. But I did this talk called, ‘the three things’ and it was like, the three things you need to know to transform any organization. And the three things are just really simple, team’s backlogs, working test, the software and the way Scrum works, we know this, right? The way Scrum works is you have to have a dedicated team of people that own the product that are interfacing with like, a product owner who’s responsible for the backlog and they have to have the ability to produce a working tested increment, the end of every sprint, like period, hard stop. Right? And if you don’t have those conditions, then what starts to happen, right is you get teams that are breaking the rules of Scrum because they kind of have to, right? And so like, at the lowest level of the organization, you have to ask yourself is what is necessary to form a complete cross functional team that stays together over time. And what it is it comes down to is that you have to have a capability or a feature set or encapsulated service with technology boundaries, a dedicated team, a service owner or product owner and you have to have the deployment capabilities to produce a working tested increment at the end of every two weeks and that’s just true, right? And so, you can either kind of take the scrum approach that says, okay well, we’re going to start doing Scrum and then your impediments will reveal themselves and the impediments will get resolved by the scrum master. But in practice, right, that’s too low level to address these systematic issues.

Speaker: Miljan Bajic  12:57

Exactly. Because I think what happens is like, then the dependencies are exposed and you start seeing all of a sudden, all of these dependencies, you still have delivery issues, right? 

Mike Cottmeyer  13:08

For sure, right? For sure, and that’s really, so you hit the nail on the head, right? It’s like, its dependencies in some form of fashion at the end of the day, they get away, because you know, the Scrum and this is where safe comes in, it’s kind of interesting, right? So, what scrum came along and said was, okay, we’re going to encapsulate the dependencies inside the team. And we’re going to give the team agency to how to resolve those dependencies in real time, that assumes that the dependencies are encapsulated within the team. So now, when you have multiple Scrum teams that have dependencies between them, right, what’s safe came along and basically said was, well, I’m going to encapsulate the value stream and we’re going to put the boundaries of the dependencies between teams, within like a release train or a value stream or big room planning around it or any string between things and we’re going to do this stuff, right? 

What we find is really complex organizations, the value streams are not really encapsulate very well, either. Right? So, what do you do with dependencies between value streams, right? Now, the last guys right, Bassford, and [unsure 14:15] you know, I think Dave actually got the model right. It’s like, you’ve got to break the dependencies, you got to put the right technical architecture and stuff but the challenge is that, it can take years in some of these organizations, right? That’s not a flip of the switch, even if you want to defund it, you couldn’t do it overnight, you couldn’t do it safely, quickly. It takes a minute, right. 

Speaker: Miljan Bajic  14:35

It also takes people like, I think maybe it takes a lot of people to understand what needs to happen. Then maybe just to kind of add another thing here, which is reference architecture. So, we talked about business architecture, business architecture, just for to keep it simple, it has to do with organizational design, policies, essentially, how do you architect your organization, right? Like, you know, where does reference architecture, we’re not talking about IT reference architecture but business reference architecture fit in and what is your?

Mike Cottmeyer  15:10

Well, let me tell you the way I usually use that word, right? So, there are organizational patterns that I think are universally true. Right? And I think safe and last, and maybe some other things like discipline, Agile Delivery, some of the stuff that like [unsure 15:28]’s done with met objectives and I guess now he’s part PMI. A lot of what those people have built upon are really sound foundational principles, like encapsulated teams at the work surface level, Kanban or flow based kind of governance models on top, right, at a lean agile metrics that enable us to measure improvement, things like that. And so, I think there’s like a reference architecture to organizational design that I believe is true and I think it’s [cross-talking 16:01]

Speaker: Miljan Bajic  16:00

But those are more like patterns, right? Like, they’re taking a bunch of, you know, patterns and just putting them together and viewing these frameworks around. 

Mike Cottmeyer  16:09

Yeah. Well, that’s where I was going, right? And so, that’s always where I preface it, this is how I use the word reference architecture, right? It’s like those base patterns, the base structures, the rules of operation, just the things that we just know to be inherently true. It might be like a design pattern, like if you read a design patterns book in code, right, and I’m not a coder because I can’t write a bunch of stuff off. But like, these design patterns are universally true and then they get implemented in an organization. Right? And then all of those patterns get instantiated into an operating model for that organization and this is my challenge with last and Scrum and some of these other things is, I think all of them are built on incredibly sound reference architecture but they’re overly specific in their reference implementation.

Speaker: Miljan Bajic  16:58

Correct. So essentially, instead of dealing with complexity, where like, instead of the reference architecture being fixed, which save has a picture and then all of these. Instead of like, leveraging those patterns and almost evolving that architecture, so that architecture has to be emergent, rather than fixed, right?

Mike Cottmeyer  17:16

Also, so Dean has like, a couple of, you know, for what he’s trying to build, right? The challenge with kind of going down the path that we go down is that it’s really difficult to scale. Right? The fact that I’m in 160 ,170 people is mind boggling to me, that’s really tough, right? But like what, so Dean kind of, at least this is my understanding from the outside of that organization, what they’ve really done is they’ve packaged a reference implementation that basically gives people guidance. It’s a little bit like the rough days, where it’s like, these are practices that are good for most people, most of the time, we fully expect you to tailor them, right? 

But the certification is around the implementation details and you know, like most people, even with Scrum, it’s like, you go to a certification class and it isn’t good practices that most people can do most of the time, it’s like, this is safe, right? And we don’t tailor it or we don’t [cross- talking 18:11] safe, right? And so, even if we do tailor them, sometimes we make bad tailoring decisions and it causes the system to break and all kinds of stuff, right? And so because Dean is trying to create certification, right, he’s codified all the stuff, right? And it’s a thing and it has released numbers and all these different things, more power to him, right? I mean, there’s good guidance in there and we work with safe shops all the time. Right? But it’s like, I mean Dean knows, right, I’ve had conversations one on one with Dean is that he knows that there’s an underlying organizational architecture required to support this, last I talked with him, it’s beyond the scope of what he’s trying to certify.

Speaker: Miljan Bajic  18:52

No. I mean, I spoke to him on this podcast too and I asked him about that specifically and he’s like you know, like you said, if you have you know, somebody that doesn’t know what they’re doing, of course, they’re going to you know and he’s seeing those patterns but?

Mike Cottmeyer  19:07

And he’ll come in and consult for you and customized model for you and do all those things. Right? So again, I think it’s high integrity but just like everything, right, in life it’s like, we take the surface level stuff and the biggest problem we see in the transformation space right now is you’re taking a reference implementation, overlaying on top of an organizational design that it wasn’t meant for, it doesn’t work or it doesn’t work as effectively as you would like it to.

Speaker: Miljan Bajic  19:33

And that’s why it fails, in a sense a lot of times, so maybe to tie this together, like you know, we’ve been saying or what I wanted you to kind of expand on is like, okay, organizational architecture is key. You have to have somebody on the business side, usually supported by the board to make a decision that we have to look at the whole organization and how it’s architected. Right? And then when we look at architecture, we have to understand that in order to deal with this type organization, the architecture can’t be fixed, it has to be contextualized for our own organization rather than just relying on a recipe, like treating say for any other framework, like a recipe. And then even though we don’t have half of the ingredients, we’re saying, let’s do the same, right?

Mike Cottmeyer  20:22

Yeah. Well, so sure, right? So, like the process, so like, one of the things that we’ve been unpacking for last couple years is we talk about the difference between like a system of delivery, right, that consists of reference architecture patterns and reference implementation details and then there’s a system of transformation. Okay, how are you going to implement it? There’s a third system we call, system and continuous improvement, which is, how are you going to sustain it and continuously adapt it? And then, you know, this is something that maybe, you know, a company wouldn’t put in but we call it, a system of engagement. 

But it’s like, how are we going to start to build mindshare over time to get the organization to converge into these patterns. And so, a lot of the process for us is getting everybody aligned around the reference architecture patterns, picking a slice of the organization that wants to go and do this, con expedition and then we move it to a defined steady state. And for us, a lot of times and this is another thing that I think is hard for people get over, I was literally just talking with some of our developers this morning. And it’s like, sometimes at an early stage transformation in the presence of dependencies when things are not aligned as well as we would like them to, sometimes we have to put in compensating controls and we use the metaphor of like, scaffolding. 

You know, I want to build a wall and I don’t want the wall to have a bunch of metal stuff around it. But while I’m building it and it’s hardening, I have to put some scaffolding around it. So, there’s a lot of things that we do in an early stage, depending on the organization that might be heavier and save as much grief as saved gets heavy and heavy. We’ll do things that are heavier than safe because they’re scaffolding. And then as we improve the systems underneath, there are systemic transformation, then you can start to dismantle the scaffolding.

Speaker: Miljan Bajic  22:11

I think I heard you talking, maybe you can expand on it here. Like, most of the organizations today, larger organizations are structured around capabilities. And a lot of times you might have to start with those capabilities and move them into value streams over time, rather than just quickly trying to organize by value streams.

Mike Cottmeyer  22:33

Yeah, so there’s an interesting journey that we’re starting to uncover, especially if we’ve been fortunate to work with some really large clients. And what you find is that, there’s a sequence to events that they like, A has to be true before b can be true before C can be true and so a lot of times you’ll walk in, and people aren’t even organized around business capabilities. 

They’re organized around functional silos and there’s project management that stitching processes and resources and things like that, right? So again, all this depends upon the complexity of the organization, the size of the organization, like if you can walk in and you can reorganize around products or feature sets and they’re discrete and you know, that’s awesome, right? I’d rather do that first but a lot of these mega organizations, a lot of times they understand business architecture, they understand what their business capabilities are. 

So as a first pass, you kind of think, okay, well, I’m organized around business capabilities because I can create complete cross functional teams are on those and I’m going to orchestrate the project work across, I’m going to deal with dependencies across business capabilities, it kind of becomes like a first pass. And then like on a second pass, now we’ve got a bunch of teams formed around business capabilities but the rub is going to be in and this is legitimate, that those dependencies left unchecked, drive orchestration costs up really high. So, because the orchestration is so high, it actually creates a business case for breaking dependencies and then as you break dependencies, you can regroup business capabilities into value streams.

Speaker: Miljan Bajic  24:15

So, it’s almost like you’re exposing the cost of dependencies and using that as a trigger or nudge to say, hey, you know, this is costing you.

Mike Cottmeyer  24:29

100%, yeah. Because like, you walk into organizations and I mean the numbers, I can remember 20 years ago when I first, maybe a little longer than that, when I first got into project management. You know, it seemed like if you were budgeting something like and again, I’m making this up, it was like maybe six developers, two testers, a project manager, maybe split across a couple teams or something like that. And now, it seems like you walk into places and like for every one developer, there’s two testers and three project managers and a BA and like, all this stuff, right? And it’s like, the complexity has gone up so much we have all these people run around managing complexity. And part of the challenge that we’ve got is, I think that’s just a function of bad org design, right and unnecessary complexity. So like, what starts to happen is that once you get the organizational design, right, you’re able to surface, not only the dependencies but the cost of managing those dependencies. And then what you can do is you can and I’m not saying that you have to lay people off but it’s like, you can redeploy those people into other higher value functions within the organization, rather than being scorekeepers. There’s just too many scorekeepers around in most companies that we deal with.

Speaker: Miljan Bajic  25:41

This is crazy, so like, what you’re saying is like, not almost but I think it’s exactly, like if your organizational structure policies is not aligned, that can cost you. That can almost like, you know, a lot of times, it’s going to force you to fail because that’s a lot of times one of the underlying issues or impediments to having a more you know, product value, whatever you want to call it based on organization.

Mike Cottmeyer  26:15

Yeah, the other fascinating thing and I literally just previous, our as talking, we have kind of an emerging practice within our methodology group. It’s kind of like, the broad arc is methodology and then we have kind of product and business architecture and kind of within product, there’s a specialty that’s starting to emerge around finance and financial management. Because what we see a lot and I know this will resonate with you, it’s like, as you start to build out, even if you’re building out these little expeditions that are like team, program, portfolio, right, that kind of thing. It’s usually a layer, an audit and compliance type layer, governance layer that rides over all of this, that is still looking at three to five year plans and 18 months cycles and annual funding and all these different things. And you know, I think that is indeed an artifact of an organization that struggles to make any commitments, right? 

So, they’re planning and scorekeeping and doing all these things, even at the highest levels of the organization and what’s been pretty cool. And these are some big names that we’re working with is that once you get the organization performance and it can make any commitments and it can deliver in small batches, then the next trick is to go up a layer and say, okay, how can we exploit this new organizational capability. So that we can make better bets and market, get faster feedback and be able to learn from what it is we’re doing because what my team is doing is, they were pitching a white paper they wanted to do with us. And you know, one of the things that we’re talking about was the idea that we’ve installed agile but we haven’t really and maybe we’ve even reduced costs and increase efficiency but we haven’t really maximized the product value or gotten to where we can actually put things in market and start selling them earlier. And again, that’s an artifact of the way we’re governing and doing audit and compliance and such is not congruent with the improved way that we’re doing software delivery or product delivery, you know right? 

So, what are the steps necessary to be able to bring those top level functions into alignment with this new deployment capability. And the way that you’re going to maximize value at an enterprise level is to take your multi year annual planning cycles and to break them into some sort of quarterly cadence with quarterly funding, right? Where you can fund a quarter or maybe two, right, I’m not being super dogmatic, it’s probably not continuous at that level but I can fund a quarter release and maybe by the end of the second quarter, realize that maybe I’m not quite on track. And maybe I have the opportunity to go correct something in quarter two or pivot into quarter three and I actually become more adaptive and agile at the senior most levels within the organization. And I think that’s where the and again, in a mega organization with value streams that are global, I mean sometimes that’s where you got to start attacking. 

Speaker: Miljan Bajic  29:15

That’s really interesting, I’m also interested to hear your thoughts, how do you move from funding capabilities or cost centers to funding value streams? Like, that also needs to happen at the highest level and that needs that shift, what have you seen and like, that’s working, that’s not working in that shift?

Mike Cottmeyer  29:38

Well, like I said, right? I mean, I’m dealing in a world where I have people that this is their specialty. Right? And so, that might be a topic for another podcast to put vows of it. Right? But this is literally what Larry and I were just talking about, right? They’re hitting me with all this detail, right and I’m like, well really like if you think about it what we’re really doing is we’re trying to get them to break big projects into small projects and run the small projects on tighter cadence. Like, yeah that’s exactly it, I’m like, okay well, then sometimes we just need to say that, you know because that’s all it is. Right? So, how do you get them too, right I mean, it all comes down to understanding what their constraints are and what they’re trying to accomplish. And to be able to build a system that gives them what they need, is agile is sometimes and this is a reason why we came up with this little quadrant model and our base camps and expeditions and things like that, is agile is a lot of times what we want is, we want everything to be adaptive and emergent. And you know, it’s just like, just going to park it really fast. 

Yeah but if I’m building nuclear submarines or I’m building cars or I’m building missiles or I’m building large scale financial services, infrastructure, things like that, right and these are differently building websites or consumer products and things. And there’s lots of things that have to come together in order for that to be able to happen. And so like, one of the things that I talk about and I’ve done this for a minute, like the earliest revs of our website, say this right up at the top, it’s like most the time, like people aren’t using or they don’t aspire to use agile for like, hyper adaptability and exploration. What they’re really using Agile for is because they believe it will help them become more predictable and that’s why that tends to be the first step on the journey is because when you organize complete cross functional teams and you get them to establish stable velocity against a known backlog. And they get to a really clean definition of done at the end of every sprint, that is a much more reliable indicator of project progress than you know, Gantt charts and progress reports and all that kind of stuff, right? And so, we can do is we can use Agile concepts to actually get to a place where we can make any commitments more effectively than our traditionally managed counterparts. 

Okay? And so now we have dedicated stable performance teams that we can count on, that are aligned to business capabilities or value streams or products, I can start to think about how to fund those things in a more stable way. Right? And now this need for predictability in control isn’t done by top down edict and rules and tight governance and things, it’s more like, fun, stable funding and periodic measurement of progress. And I believe, in order to have that conversation at the most senior levels, the necessary precondition is to be able to actually be a performance organization.

Speaker: Miljan Bajic  32:59

I mean, that reminds me of what you also described, like the almost the trust influence loop, it’s like, let’s deliver a first on let’s meet the organization where they are and meet that, you know and it’s almost like in order to help them evolve, you’re building that trust and you’re delivering them what they want and slowly. 

Mike Cottmeyer  33:20

The very first, the very earliest thinking this of this is like everybody, you know, this is like 15, 20 years ago, right? So like, everything I would hear would be like, you have to trust a team. Well, the ecosystems that they’re working in, their practices, their org design like, nothing lends itself to trustworthiness, right? And so, it’s like, what I would tell people is like, you’re asking these leaders to trust these teams but these teams have no track record of ever living anything on time. Right? And I was talking with one prospect one time and they’re like, well the executives need to stop asking us for dates, they need to stop giving a scope, they need to stop giving as much as you need to just give us a big pile of money and just let us do it whatever we want. 

They didn’t say quite like that but that was certainly what they’re saying, right? And I’m like, okay like, seriously, if you were building a house or doing whatever, would you just give the contractor half a million dollars and just say, just go for, just do the best as you can? You’re the guy that’s close to the ground, you know what kind of house I need, like no, right, you want to know what you’re going to get for your money. And there’s some reasonableness, right, there has to be some ability to deal with variation and respond to change and exchange requests and things like that but you want some idea what you’re going to get for your money. Business owners are no different than matter, executives are no different than that, they want some reasonable controls to know they’re going to get pretty close. And so, if you’re going to go up to the most senior executives with some form of, you need to trust the teams, my belief is that you got to get the team’s trustworthy first. 

You have to create the organizational design, you have to create the process, you have to create the metrics, you have to get instantiate, you have to be able to put stable inputs in and get stable inputs out. And this is all scrum basics from, I’m not saying I don’t think anything unethical, I mean, [unsure 35:01] was writing about this stuff in his earliest works about basically how to deal with variation and process control. I mean, that was like early stage stuff, I mean, David Anderson’s been writing about this and Kanban and has Agile Management books. 

Speaker: Miljan Bajic  35:16

I mean, that’s the whole lean, like in a sense, if you can manage the variance, you want to minimize the variance but sometimes, you know, right, it’s not as easy as you know, mass production plants and then things like that.

Mike Cottmeyer  35:29

So, what the trust influence loop came in and so what we’re talking as that little, like that little figure eight thing on the side and it’s been a while since I’ve talked about it but like one of the things that we were talking about earlier is consultants. And I would say this is 100% true of internal change agents as well, is that there’s an influence loop, which basically goes something from like, you have access to somebody, you have to have empathy for their problem they’re trying to solve, you have to have a point of view that actually they believe will solve their problem and then you create safety for them. A lot of times, what we do is agile is, we come in and we say we know your problem, this is what you need to do to fix that. And then they go well, not quite my problem and even if it is my problem, it’s not the problem that has my pants on fire, right? 

So it’s like, I’m not dealing with that right now and so this whole influence game is a game of access, empathy, point of view and safety. Right? So, you loop through that and then on the backside, the trust side is you get permission to do something, you have to do with integrity, you have to do with competence and you have to share results. Right? And so, there’s this virtuous cycle and so this is reason why part of what’s up underneath like this base camp model and the reason why we do incremental.

Speaker: Miljan Bajic  36:42

That’s what I wanted to hear, maybe you can talk about that next, which like, how does the base camp get the expeditions and how is it supported by that, trust influence problem?

Mike Cottmeyer  36:52

So, you think about it, especially from like a marketing perspective, a sales perspective, an early stage engagement perspective to piloting and to roll out and to growing like a large account. And again, right, all this stuff, I’m a consultant, that’s the world I live in but even from a practitioner perspective, you’re doing the same things, right? There’s marketing, you’re selling, you’re getting started, you’re scaling, right, all these things. And there’s an influence game that has to be played, right, you have to tell a story that convinces somebody that this is worth doing and then once you do it, you have to get the results you promised. Right? 

So if I say, hey, you’re going to get all this greatness from doing Agile and I train everybody on Scrum, I train everybody on safe and it ends up being a chaotic mess for three years. And you don’t get the results, like why would anybody continue to invest in that, right? It’s just a [unsure 37:38] system at that point, right? And so, what we recognized very early on was two things and again, this is through the lens of a consultant, running a consultancy, is if we didn’t demonstrate tangible value really quickly, we didn’t get to stay for very long, right because, no, seriously, right?

Speaker: Miljan Bajic  37:57

No, I’m laughing because I’ve been in many of those situations and I know you’re sure most coaches and consultants have.

Mike Cottmeyer  38:04

Yeah, and it’s like, you go in, everything’s great. It’s like, it takes a minute, it was six months and you’re like, yeah okay, I can’t get the next tranche of funding. It’s great, man, I appreciate you, see you later, right kind of a thing? Or maybe you have some success but it’s just not mind blowing. Right? And so, the evolution of these expeditions, the base camps and so just to put into software language, like an expedition is like a slice. So, I think of an expedition is like an increment of the organization and then base camp is like an iteration. If you guys go back to like, you think about like Jeff Patton’s, Mona Lisa metaphor, which I think is just brilliant, right? 

So for Dewey, he’s using it to describe incremental and iterative and he uses increments is like, okay, I’m going to take the Mona Lisa canvas, I’m going to split into six, I’m going to work on the upper left corner of it, right, that’s an increment. An iteration is like, taking it from like a sketch to a watercolor to an oil painting, kind of a thing. We’re making it more rich as we go and so like, we think of transformation incrementally and iteratively, as well. So, but we can promise typically and like a three to four month early stage engagement is we can take a slice of this organization, team level to portfolio, structure, governance and metrics, all the practices, culture, all that stuff and get it to a predictable state. And that’s what we promise and we can do that repeatedly in three or four months and then they go, wow, this is actually really working. And they go, okay, let’s do the next chunk and then the next chunk.

Speaker: Miljan Bajic  39:38

What do you do in a sense like, when you’re taking those vertical slices, there’s almost like prerequisite to what they need to have in order to create that vertical slice, right? So, there’s some type of expectations that you set you know, if we’re going to do this, this is what we need from our organization to create that vertical slice.

Mike Cottmeyer  39:54

Yeah, so remember, I talked about system of delivery, system of transformation, system of engagement? So, from a system of delivery perspective, you’re building on patterns, reference architecture, filling in reference implementation details, things like that, right? So, we have a hypothesis of what this is going to look like at base camp one. And then we might have some idea of the first couple of slices and then the system of transformation is all about how you run the expedition to base camp journey. Right? So, we have outcomes, based plans and a bunch of guidance that we’ve evolved over time, right? So we’re going to move this slice into this known state but on the system of engagement stuff, which I think gets to your question is, the way we do that is we’ll get like all the leaders in a room and we’ll walk through, here’s the reference architecture, here’s the things that you’re going to have to do, here’s the things you’re going to have to overcome, here’s going to be the nature of your dependencies, here’s going to be your challenges. Now, are we 100% right, I think we got 80 or 90% of them. 

The details of people in particular architecture issues are all going to be all over the place. I mean, there’s a lot of uncertainty but the patterns, the failure patterns are fairly known. So, we walk them through, we say this is your failure patterns, this is what’s going to happen, these are things we need to fix, this is how we’re going to do it. So, we start off with a workshop that brings everybody into a cognitive box and then we expand that box into a bigger piece of the organization, then you can go for breadth or depth or whatever and lots of different strategies. We do something called the find the end state, it’s usually about two months and we’ve got that scripted out too, we look at business architecture, technology architecture, org design, product architecture and literally create a team formation hypothesis. We put names in boxes, we help them figure out what tooling and instrumentation they’re going to use, we help them figure out what they’re going to measure, what they want to control, what success looks like, all those things, that takes a minute. And then what happens, then we create a plan for a pilot and then we’ll do a pilot and then the pilot is going to work back to all of those core things we’ve been talking about all along. And they’re going to see, okay, this pilot is going to go to Basecamp one and this is going to be the characteristics the organization, they’re going to build or make any commitments, they’re going to be able to deliver on quarterly boundaries, we’re going to be able to do it in a reliable, predictable way. 

We’re going to have dependencies managed, we’re going to have economics trade-offs dealt with, we’re going to get value, right? The risk in this early stage, right, is that you build the engine and you get really good at building the wrong product. I mean, that can happen, right? So, now you’re in the stance of like, okay well, if we focus on building a product but we don’t have a delivery engine, is that better than building a delivery engine and not knowing what the right product is? Right? So, as we’ve kind of advanced, there’s a little bit of a dance right and in early stage, we might literally help them get better at building the wrong product but now they have the ability to start to deliver on regular paths. Right?

Speaker: Miljan Bajic  42:53

The right product. 

Mike Cottmeyer  42:55

And then as they start realizing, okay, I’m getting data now and I start to realize that we’re building that then, that’s when we might start introducing more product management practices. Or if we know we have dependencies, that we need to do like product extraction, technical decoupling, things like that, we might start laying, bringing in some more like XP software, craftsmanship coaches and start laying the foundations and building the capability internally so they know how to do red, green refactor, things like that. And so, we just layer these capabilities as we move them from predictability to smaller batches to fully encapsulated teams and so that’s how it works. Right? 

Speaker: Miljan Bajic  43:32

So, maybe, just to pause on that because I think you know, we can take it lightly, like that’s how it works, that’s been my experience in a sense of how it works. But that takes a lot of effort on organization committing, the other big part that I would like to know from your perspective is, how do you make it sustainable? So, you bring coaches, consultants to help organizations realize this and then eventually, what you want them is, you want to work yourself out of the job, so they can do this long term. What are some of the things that you do and some of the challenges that you face because they think long term in our organizations to be able to deal with same type of issues that they dealt when they brought you in?

Mike Cottmeyer  44:17

Yeah. So, the metaphor that I use and they’re all systems metaphors, right? Is it leading Agile is like transformation in the cloud, right? And so, in an early stage transformation, you might subscribe to our services and we come in and we help you do all these things. But an any non trivial sized company, there’s two dimensions you have to deal with it, at some point they want to take that in the cloud service, they might want to make it like an on premise service, kind of thing. They might want to have their own instance of it. Okay? And so, typically on the lots of words but typically the word we use most commonly it’s like a setup like an Agile transformation office. And the Agile transformation office needs to have all the core services that Leading Agile has, right? 

So, we’ll help them identify a playbook, will get a coaching and development services, like a talent service, a way to manage the transformation and Expedition readiness service, right? All these different services that we’ve got that are in Leading Agile, will help our client build them and then we’ll teach them how to run it. And then, you know, obviously, we’d like to maintain a presence to help sustain it and nurture it and things like that. But what we found and I know you know this, there are not enough Agile coaches or technology coaches in this world to help the companies that need to be helped, right? And so, I don’t believe, I don’t think there’s any scarcity in this and so like, one of our largest, longest standing clients we’ve invented a lot of this stuff with them, which has been a very cool relationship is we built an Agile transformation office with them. It’s their transformation office, they run it and at one point in time, I want to say, I had 45 consultants on the ground with them doing senior level transformation, leadership, Expedition leadership, we would call integration coaching, some specialists around product and finance and all those different things. 

But at one stage, they had 250 coaches, they were on the ground doing team level stuff that were sourced all over the place. They were sourced from other consultancies, internal people and then over time, they started inserting their people in expedition leads and transformation and things like that. Right? As they started getting more confident in their ability to do it and then now it just kind of ebbs and flows, like if we’re going into like a gigantic company, right? So, you did the first 13,000 people and there’s hundreds of 1000s of people will have to go, right? And so, we’ll go into incubate another slice of the organization and we may be at this for 10 years or so. Because they want to go but what we’re leaving is we’re leaving behind the capability for them to sustain it themselves because we’ve instantiated the playbooks. 

Speaker: Miljan Bajic  47:17

But also, you’re kind of you know, essentiated the playbooks, you’re developing the skill so they can develop and maintain and evolve those playbooks. Right? And what’s interesting is that I think, you know, based on what you’re describing and that’s why like, you know, I wanted to talk to you is like, that’s what it takes for organization to transform. And if we look at the last 10 years and we look at you know, Agile transformations, like 99% of them failed. 

So, and that’s a huge number, it’s not like, you know, at least most of the organizations that I’ve been part of and the ones that have been part of, that have been successful is essentially what you’re describing. So, I’m curious to hear your thoughts you know, in a sense, like if that’s what it takes for organization to succeed and most organizations are not doing this. What are your thoughts? Like I mean, what do we need to do as a community, what do we need to do as coaches because it’s a big ask to do what you just described in here for organizations to be able to transform?

Mike Cottmeyer  48:23

So here’s the thing that I think is, there’s a couple of factors, right? So, there’s like a belief factor and then there’s like a pragmatic reality factor. And so like the belief factor and this is the one thing I’ve been, I’m a little too extreme on this and I’m going to acknowledge this. But it’s like so many people in the Agile world, they lead with culture and they say, well, it’s a culture change and we need to change mindset, we need to change attitude and we need to change the way people behave and stuff like that and that’s true, right? But the reality is that, people are operating in broken systems. 

Okay? And unless we get the systems that they operate in right and bring the process into congruence with the operating system or the structure this, yeah, right? It’s really difficult to ask people to change their minds, the way that I articulate is like, I have two salespeople and they’re both in the same region. And I want them to cooperate but I have them incented for, you get paid based on what you kill, I get paid based upon what I kill but they want us to cooperate. I can’t ask what to cooperate if our financial incentives are to compete. Okay? And so, we have to create the ecosystem, we have to change your org design, I have to change the process to encourage the collaboration that we want. So, I think leading with culture, it’s just the way I term to say but leading with culture I don’t think is a winning strategy.

Speaker: Miljan Bajic  50:01

I mean, it’s almost like, what less guys and what it’s like, you know, change the system, right? And changing the system will force you to change you know, the culture as a result of that you know, the practices would change. But here’s the trick, right, which I think is the biggest of them all. In order to do this, you have to have a leader with the mindset that is willing to change the system and if you don’t have that?

Mike Cottmeyer  50:30

That’s the chicken and the egg problem, right? But I don’t need to get to change their entire leadership style. So, like a little bit of the way that you flip that influence, as you say, look, I get you have to make any commitments, you have to be financially responsible, you have to be a good steward of the resources, you have fiduciary responsibility, your stakeholders, all these things. I’m going to build you a system that’s radically different than what you’re doing today, that is going to achieve better results. 

Are you willing to take a bat? Right? The other side of it is like, because and I’ve been in this world where there was a consultancy, where I kind of partnered with 10, 11 years ago. And this lady goes in and she’s like, telling all the leaders well, you need to change all of your behaviors, you need to be more empowering, you need to do this and they were just like, out, right? So it’s like, you got to like, it’s like the influence trusting you, you got to tell them the story they need to hear and then evolve their thing.

Speaker: Miljan Bajic  51:26

Exactly and I think that’s what’s so powerful what I liked, when I first heard about base camps and expeditions. It’s like, if somebody was asking me and saying like, Milan, you have to do this, I’ll be like, go fuck yourself. Right? 

Mike Cottmeyer  51:41

I didn’t know you could say that word on your podcast like I’ll be all down?

Speaker: Miljan Bajic  51:44

You can but you know, because in a sense like, you know that’s not, but if they’re actually walking me through and I say, this is what I want to do and they show me and help me and they say, okay, what do you, like it’s easier for leaders to do that. If they’re going through that type of and I think that idea of expeditions and base camps is?

Mike Cottmeyer  52:03

Yeah, I had a colleague in the industry and an Agile conference a couple years ago. Yeah, there’s a little bit of liquor involved, though, I’ll acknowledge that but we’re having this very intense conversations. She’s like we need to empower and trust your people and just let them decide and I’m like but it’s my money that pays their salary. If they jack up the account, I’m still paying their salary, regardless of whether they’re damaging your reputation and my economics and my family’s livelihood and all these things. And so like, a lot of it is like balancing between what’s sufficient control to make sure that we don’t lose the wheels on this thing versus empowering people to make local decisions. But you know, getting back to the question that you had asked me about like, what’s getting in the way? I lied with, we’re spending too much time on culture, right? 

There’s still a big problem 20 years later, I think the other thing is, you said, what do we need to do with the community? I think pragmatically, this is the challenge, is that most people if they’re independent, are in a small company, they’re trying to make a living and they’re doing the best they can within the agency that you’ve been granted. So, a lot of times, they don’t have the span of control. Sometimes they don’t know how to go tell those executive stories. I mean, I have my team, could not sit in a conference room of the C level suite and tell those big stories, right?

Speaker: Miljan Bajic  53:17

Which goes back to that access, you can’t influence if you can’t.

Mike Cottmeyer  53:21

Yeah, well, you don’t get access, if you can’t influence, right. Yeah, for sure. Right? So, they tell a good story to a director or VP and maybe they make some good local changes but they don’t get the broad base changes that they need. I mean, it’s taken us 11 years to even get to the place where, I think I’ve had a pretty strong story and market but it’s taken me 11 years and I mean, there are more people that used to work for Leading Agile in this world and currently work for Leading Agile in this world. Our hypotheses on like, what are the right kinds of consultants and what do they need to know and what kind of work designed I put them in? 

And what personality attributes do they need to have? I mean, like, we’ve changed everything, we reinvent this company every 9 to 18 months and it’s constantly evolving to solve this problem. And we were fortunate that we had enough early success and I was able to accumulate enough working capital that we can take chances and risks and build marketing teams, all these things go on, tell these stories. But what the thing that I actually can’t comprehend right now is why like the bigger consultancies don’t deeply understand the story because we, you know, obviously, almost anytime we go into an organization, there is a gigantic world class strategy firm in there or something like that. And what I find is that the strategy firms are making the same mistakes as small firms, a lot of times. 

And so, that’s the thing, it’s a little mind numbing to me because they have business architecture practice, they have product construction practices, they have the ability to do this stuff. So then I have to believe that it comes down to their beliefs about what to do and what’s in their economic advantage. So, I think that there’s some belief stuff, I think there’s some structural stuff that’s getting in the way but I feel very fortunate the way we built this company is that we generally get to do work on our terms and get in. And so like, what happens is we market and tell stories and you’ve clearly read a lot of our content and the companies that resonates with, they call us, right, our phones ring. I’m on three to five sales calls a week, I’m not going to close everything, of course, [cross- talking 55:26].

Speaker: Miljan Bajic  55:25

But like you said, there’s still more, there’s like you know, in a sense, there’s way too much work and there’s way too many companies that need the help. It’s just that like, that’s what kind of puzzles me too in a sense, where are we going to be like, in the sense that, you know, there’s been this whole buzz around Agile and it’s really failed, in a sense to really help organizations the way that the organizations need help. 

Mike Cottmeyer  55:52

The reason I think we’re still in the game and I think there’s still a conversation around it is because I think organizations recognize that it’s principally sound. And they believe that if they can crack the code, that will make them more successful and they’re right. But as a whole, we don’t have good operating models for how to get there. 

Speaker: Miljan Bajic  56:18

Well, unified voice.

Mike Cottmeyer  56:21

Or unified voice, well I’ll even say, you know and maybe this is you know, maybe somebody will get some nasty phone calls or emails as a result of saying this is, I actually think the Agile conferences are trending in the opposite direction. As I look at like, I’m probably not going to submit to Agile 2022 this year because I look at the tracks and you know, I mean these are important topics but it’s like a lot about it is diversity, equity inclusion, it’s about all these different things and again, all important stuff, right? And I’m not diminishing that in the slightest but I feel like the voice of okay, transformation and business architecture and doing this in a structure, I don’t think that’s what people want to hear. Right? 

And I think to some degree, they want to deal with the easier issues and this is tough, right? Because as an individual practitioner, it’s tough to take what I say and go do it because you almost have to, I mean, I hate to say it’s self-serving but it’s like, you almost have to hire us to do it. Or you have to be like, really deeply entrenched in it and like, really understand it and you might have a shot but like I said, I’ve got a lot of [cross-talking 57:24].

Speaker: Miljan Bajic  57:24

Well, that’s almost like, I use an analogy with the cooks and recipes and chefs, right? Like, it constantly has changing ingredients, so you can bring me in, if I’m a chef, you can bring me in to help you come up with the recipe. But what happens if you don’t have the ingredients, the same ingredients and I’m not there and you’re a cook that doesn’t know what they’re doing, you’re going to mess it up. So like, in a sense like, what we need is like, how do we develop more chefs in organizations and you know, that they can actually deal with whatever is given to them. Architect based on context, not just, hey, here’s a safe and we went through a four day training on safe or whatever, right? 

Mike Cottmeyer  58:05

So, here’s like, the interesting hard part, right? I have thought of the idea of like building a certification or building a program or something like that. But you think about it, you know, Jim kind of works with me and Jim was in the Scrum Alliance and really helped that organization make a lot of inroads into PMI and really took it from kind of a niche to and really kind of blew it up. And I think he would tell you directly, it’s like, people want to pay $1,200 or $800 now maybe and get a two day certification and they want for the resume, right and that’s a market and they want employment. And so, and I watched what the Scrum Alliance does with the advanced Scrum and things and it gets traction to a point but it’s like, the money is isn’t selling these [cross-talking 58:54]

Speaker: Miljan Bajic  58:56

Like, I said the money is selling recipes and training people on recipes not creating chefs.

Mike Cottmeyer  59:02

Yeah, I used to get onto the marketing team at Version One because they want to say, they weren’t saying marketing agile made it easy on them. No, this isn’t easy, it’s hard. Right? And then so, I think they said Agile made it easier or something. And I get it, right, because it’s like, you need to sell an easy but it’s not easy. You know? So I’m like it’s team’s backlogs, working, tested software, if you can figure that out, it’s super easy. But getting the team’s backlogs, working software is taking us 11 years to figure out of that. So yeah, and we’re still figuring it out. Right? 

I mean, I’ll be the first to say it’s like, I mean, I was telling the guys today we’re going to do a podcast and we’re going to just talk about stuff that’s just super exploratory. Because it’s like, we don’t have every answer, I think we’ve got the base patterns, right? And I think we have the principles right but the practices and the how tos are constantly emerging as we learn more stuff. You were talking to clients about using Agile to build the next rev of nuclear submarines and and you know, battleship and things like that and defense. Like, I mean, this is like cutting edge stuff that people want to use this for so that the industry still has poll, right? I mean, people want this, we just need more mature practitioners that understand how to apply these concepts in a less dogmatic way. So?

Speaker: Miljan Bajic  1:00:16

Exactly. And I think that’s going to be the trick, I know it’s been an hour and I feel like we could continue talking but I do have to go, [cross-talking 1:00:24]

Mike Cottmeyer  1:00:24

Yeah, we should do this again sometime. 

Speaker: Miljan Bajic  1:00:26

Yeah, definitely. What would you like to end with, like a message or invite or?

Mike Cottmeyer  1:00:30

No, I think where we left it is pretty cool, right? I mean, if anybody’s [inaudible 1:00:34], I mean obviously hit our website leadingagile.com, connect with me on LinkedIn. We’re super happy to answer questions and talk about this stuff. I mean, it’s kind of what I do for five hours a day is just talk to people, right? Whether it be my teams or clients or whatever and super passionate about this and if you’re in the market, you’re looking for a job, we’d love to have you reach out on our careers page. It seems like I got 20 or 25 open positions all the time and so for the right people, it’s a great place to be and we’re doing some really cool stuff. And I do believe we’re on the cutting edge of a lot of this stuff so hit our website and just check us out and if it looks like a fit either work together or to work here. love to hear from you.