Nov 19 2020
Agile Unplugged EP04 | Mike Cottmeyer and Matt Van Vleet
Welcome to our latest episode of the Agile Unplugged podcast with host Mike Cottmeyer, LeadingAgile's CEO. In each episode of Unplugged, Mike and a special guest 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 in the real world.
We’ll hear about Matt’s background and reveal our roadmap for building the new LeadingAgile Studios, our newest offerings to enable clients to use their capabilities to gain the strength, Agility, and craftsmanship to take on digitally native organizations in the marketplace.
Remember to subscribe and listen to Agile Unplugged on Soundcloud, Apple Podcasts, Spotify, and Podbean—and watch each and every episode on YouTube, IGTV, and Facebook.
Transcript
- Everybody welcome. We are doing a LeadingAgile Unplugged and I have a special guest here, Matt Van Vleet. Welcome Matt, how are you doing?
- Great.
- Yeah. Awesome. So Matt just recently joined us. He is helping us build our technology transformation studio. And we're gonna explore a little bit about what that is going to look like. And, but what I want to talk about a little bit is, let's just talk about your background. Like what have you been up to for the last 10 years since we worked together?
- Yep. Yeah, so I, I spent about 18 years at Pillar and eventually sold the company to Accenture. And in that we grew the company where originally, we did a mixture, as you know, between transformation and building custom software solutions. Over time, we grew to focus more, mainly on customer soft, custom software solutions, and eventually Accenture purchased us. And then I was, helped for a couple of years and in that transformation and getting them up to speed on what we did and I was out exploring what to do next and we reconnected. So---
- We reconnected, yeah. So we first worked together, I guess it was probably back in like late 2009, 2010. I had joined Pillar for a little bit. 'Cause that was when Pillar was thinking, that I guess I wanted to be a transformation company.
- Yeah, one of the challenges we had is we wanted to do, be a transformation company, but a lot of what we did was from the bottom up and we really weren't in position to affect some of the things we needed to, for transformations to be successful. We could affect in our, in our pocket. So we could set the conditions so that we could deliver a great product, but it wouldn't continue to change the overall organization without being engaged at the right level of the organization.
- So let's explore that a little bit because that was actually one of the things that I struggle with a little bit back in that time was trying to figure out because I've been, as everybody probably knows, like super passionate about this space of transformation and trying to figure out how to get companies from A to B and really always kind of took what I called, like a top down, bottom up approach, right? Where you have to have engagement at the lower level, right? But if you're not doing it with like executive support and with an integrated strategy from beginning to end, it's really difficult to sustain momentum. Talk to me about some of the challenges that you had taking it straight from a software development perspective.
- Well, when you're trying to build software and the software we were building was, was very innovative and kind of leading edge for organizations. So sometimes when you were on the proper project, you could get some of the dependencies and constraints or some of the rules, you know, waived for your project, which is great for certain projects. But if the, if you're always breaking the way the organization is designed in order to effectively write software, then it's very hard for it to be sustainable. So things like, you know, dependencies on other departments or groups where we may have been allowed to do that work ourselves and just review it with them, that wasn't standard operating procedure or our project was important enough that it had the funding set up such that it could make decisions around where to move and how to do things in the marketplace without needing to fit into the overall portfolio directly. There were a lot of exceptions that were needed in order to put software out quickly.
- Interesting. So basically if you tie it back to like the talk that I gave, what seven, eight years ago, "Why Agile Fails and What You Can Do About It", one of the things I hypothesized was that one of the reasons why Agile was failing in a lot of transformations was because you would do this thing off to the side and you'd give it all of the conditions that needed to be successful, dedicated teams and a ton of autonomy over what to build and the ability to really massage it's CICD pipeline or get all the different things in place and then wrap it in Scrum or XP or whatever. But then when you took those practices back into the rest of the organization, they would actually fall apart because you didn't have all those exceptions that you were talking about.
- Right. And so, you know, ultimately, there were a lot of needs for those types of projects. So we were very successful and grew and so forth, but that's why we somewhat got out of the transformation business because in the end we were great at building software and we weren't engaged at the right level with the right expectations in order to change the way organizations were structured or the way those processes worked by default.
- So it's interesting. So, on the other side of that, so when I left Pillar and started LeadingAgile, we approached it from a pure play transformation perspective. I wasn't actually trying to help anybody get better at software development per se, or product management per se. That was kind of part of it. But we were trying to help people figure out how to form teams and how to get backlogs and governance aligned and to be able to just even, conceptually get to the place that you could produce a working test and increment of software. So I think where this is kind of interesting is that we kind of hit a wall, right? So in our model, we talk about base camp one, base camp two, three, four, and five. And we got really, really good at getting companies to base camp two. And we could do some of the things that you guys did around base camp four and five, but getting people to bridge through two to three to four, by breaking those technical dependencies actually became quite a bit of a challenge.
- Right, and I think, you know, as you talked about it, there's this, you need to balance the top down and the bottom up and in base camps, one and two, the bottom up are more like, you know, getting predictability and getting, you know, batch sizes down. So they're more the management type practices than they are the technical practices.
- [Mike] Yeah.
- And so now, the technical practices need to come much more into the forefront from the bottom up perspective, as you're going to base camps three, four, and five, because those dependencies aren't just organizational, they're software and some of the tasks around how do you refactor code to break dependencies, or how do you automate build pipelines are pretty complicated things for our clients, but they need some help and support in doing the first time so that we can then help them accelerate their transformation to those higher base camps.
- Yeah, it was actually kind of interesting because, you know, we would hit the market and we would talk about base camp one, two, three, four, and five and then a lot of our focus would be around base camps one and two. And so the kind of, the first aha moment was we actually had worked with a couple of clients long enough to where they're like, "Okay, now base camp three, base camp four." And with base camp three, we realized that there's actually quite a bit of technical runway that had to be established. And then with base camp four, there's quite a bit of product runway that had to be established. And we actually tackled the product side first. And so we started to build a product practice within LeadingAgile and started pulling some of those core skills that we needed for base camp four into base camps, one and two, and started laying the foundation for that. So talk a little bit about the kinds of things in an early stage transformation you might want to lay the foundation for. So you can do some of that technology refactoring once you get past base camp two.
- So when you're thinking about base camp one, and you're wanting predictability, there's a set of practices that give you that predictability. You know, if you're trying to produce work in tested software, first of all, do you have an automated build? Do you have a build pipeline that's getting you things between environments smoothly? Are, you know, are things being done the same way from a technology, just basic standards perspective? Then as you're trying to get to smaller batch sizes and in the base camp two, there's a lot of things where if I do it twice as often, or if I'm doing it five times a year, instead of once a year now I've got to look at that overhead costs and reduce it. So anything that I'm doing manually, that's not value added and getting the value density of the software up, I need to look at it as waste and say, "Well, right now me moving between environments, "I only do it three times a year. "The fact that it's manual is not that big of a deal. "If I'm doing it every day, every week, every month, "now I need that automated."
- Yeah.
- And those are technical practices that are the foundation for some of the higher level technical practices that we need in base camps, three, four, and five. So as we look at applications or products that are needing to move to those higher base camps, we'll engage in some of the fundamental technical practices in the earliest stages of transformations to make sure those teams are prepared to keep moving up the base camps.
- Well, so talk to me a little bit about, because you know better than most that it's much easier to build it right the first time than it is to kind of refactor it and to try to get it into a state where you can do some of these more advanced deployment kinds of things. So what kinds of skills have to be established within the team to get to the point where they can start to break the dependencies and start working on encapsulation?
- Yeah.
- Yeah.
- So, you know, so the basics end up being that we have an automated build and automated scripts to move things between environments. And then we're starting to look at test automation, where I want to make sure that what I'm doing doesn't break something that used to work. So taking an area of the system that I now want to be able to work on independently so that, you know, every team or every need doesn't have to go through the same team. I want different teams to be able to work on different parts of the system. I need to wrap that area of the system with some tests, with some source of truth, to make sure that I know that I didn't break what used to work. One of the things we're going to do in the studio, is do some of that initial work where we can split up the application, we can put those tests in place. And that kind of gives a blueprint for teams to now know how to take that going forward. Because one of the hardest things to do is to take a legacy application, find the seams in it, find the ways to break that architecture and make it more componetized, find a way to get those tests in place because it wasn't designed to be testable.
- Right.
- So we're going to take some of that heavy lifting and take it off of the transformation teams so that they can continue to learn and grow. And our technical coaching, that's in the team room will help define and, get the organization ready to take that now, that new application with reduced dependencies to take that on and continue to move that forward for future development.
- So let's explore that a little bit. So if you think about a LeadingAgile engagement, like one of the things that we start off with is an engagement called Define The End State and really what we're thinking about during that stage is we're looking at the business architecture of the organization. And we're looking for alignment between what I might say, like the business architecture or the technology architecture and the organizational architecture. I want an encapsulated business problem, an encapsulated technology solution and a dedicated team. Right, so you talked about the seams in the organization. So like early on, we're actually looking for the seams in the organization, so we can start grouping people around dedicated business problems. So, so what, you said something that was kind of fascinating. So it's like, while the, while that part of the transformation is happening, then the studio's practice is going to start going in advance and start to do the decoupling work on the backside. Like, explain that to me a little bit, what you had in mind there.
- Yeah, so, what tends to happen right, is your application ends up looking like your organization. So if you have an organization that has a front end team, a middle tier team and a backend team, then your application is going to be focused on that. Instead of if you have your organization focused on business areas where you may have one overall solution that needs to solve, you know, payment issues or, or pricing, or what have you. So a lot of times when we're going into the transformation, we want the payment team and the pricing team to have everything they need to be successful. But the applications weren't designed such that the payment people could be changing their part and the pricing people could change their part. And there's not a whole lot of coordination of those in between that. So what we want to do is first get a foundation in place where the things like builds and deployments and versioning are automated, so that if one side changes their piece, the other side doesn't have to be in lock step, that the application can be deployed and built. And then we'll validate that what used to work on one side still works so that teams can now work independently. So as we reorganize the organization and refactor the organization around these business areas and value areas, we need to make sure that the application infrastructure and the environment is set up to support that. And that starts early on by getting some of the underlying technical craftsmanship, you know, practices in place. And then as we reach those higher base camps, you know, we can help prepare the applications to do that.
- Yeah, very cool. So this isn't a new concept for us. Back in, we've actually had studios on our website since about 2015, right before we did our Collective Soul Concert in Atlanta. Mentioned we ever did a collective soul concert in Atlanta? One of my best moments in my life. So Google might Mike Cottmeyer Collective Soul and you'll get to see me doing some awesome guitar reffing on stage with those guys. That was a lot of fun. But we kind of hypothesized this. So we hypothesized studios, we talked about a training practice. We talked about a talent practice. We've talked about actually a media company, and we've talked about labs. Those are some things we can explore in a little bit, but we've been noodling on this for a long time. And so for the last couple years we've been bringing in technical coaches working on the team room. How do you see these studios offering that you're going to help us build advancing past where LeadingAgile's been over the last couple of years?
- Yeah, I look at the technical coaches that are working directly with the teams and the studio as providing kind of a one-two punch. When you're in the team room, you understand the process, the application, and you're mostly about helping the people transform. The studio can help the environment and the code be transformed. So the output is going to be, you know, more testable code or more, less code with less dependencies, or what have you. And the challenge is, is that, you know, ultimately a lot of what we do at LeadingAgile is we teach people to fish, but you can't teach people to fish if they're starving. So the studio can help get some of the things done, make sure that the business is continuing to get value, that these things are broken up. And, you know, one of the dichotomies you run into is the hardest type of code to work on when learning these new practices is legacy code.
- For sure.
- That it wasn't designed and has these dependencies in it. So if the studio can help break those dependencies, get it in a state that's better, in a better shape than the technical coaches are going to have a more successful time when they're doing things like mobbing and other things with the teams to help the teams get better. The teams are going to not have to learn, they're not gonna have to start with advanced calculus, right? The hardest thing to do while they're trying to learn some basic algebra, right? The teams are gonna be learning algebra, or they're going to be learning how to do these practices and tasks and so forth, but we need them to do it in an environment where they're set up for success.
- Yeah. Cool. So talk to me about why this is so difficult. Why don't teams do code like this naturally?
- It's interesting. I think---
- [Mike] That stump you?
- Yeah. Well, you know, teams are more and more, so a lot of these practices, you know, we've been doing them for years, but a lot of them, they're not as old as the software industry. So it took a while to really figure out, like, you know, the automated unit testing and the refactoring and so forth, to get those into the mainstream of how people built software. I'd say like an automated build pipeline, if you look at, you know, new teams being formed, it's almost like, it's like breathing to have an automated build pipeline.
- Yeah, sure.
- It's like, it used to be that having a compiler that would build your entire application was an optional thing. And now people, like would never think of like building code without a compiler that was real time, or what have you. New teams, would never think to not have a build pipeline anymore. Like and it's, so it's more and more common with green field applications. But now you've got these teams who have really valuable software that's been out there for 30 years and it keeps getting, growing and solving new problems. And it wasn't designed from the ground up with some of these things that you would do today, if you started it. So it's hard, now you've got to go retrofit that while you're trying to add new value to the organization. And it's just a specialized skill to help them get caught up.
- So this might be a little bit of a rabbit hole. I want to see where this goes. One of the things that I think about a lot, and I don't think about it just with code, but I think about with organizations, and in any kind of like systems of people or what have you, but I don't think most people think like architects and I know in Agile, a lot of times we don't necessarily talk about having architects, although a lot of us do, right? Do you think the principles of encapsulation, the solid principles, things like that, do you think those are well understood and like deeply internalized by a lot of developers out there?
- Now you stumped me again. No, I think, you know, one of the interesting things is that if you build software the way we advocate, right? You know, it's test driven. There's a test around it. So ultimately we want is any component you build to be self validating, and, so that if one team changes it, they can know whether they broke something that used to work.
- Yeah.
- Ultimately building software that way naturally forces you into those solid principles.
- Okay.
- Right, so, those principles end up becoming an outcome based on how you build things.
- Ah, fascinating. So what you're basically saying is that when you build using the, like the software craftsmanship kind of things, using TDD and continuous integration deployment and such, that you naturally get an effect encapsulated standalone modules?
- [Matt] Right.
- That's how I'm thinking about, yeah.
- 'Cause you can't test a module if it's dependent on everything else in the organization. So it kind of forces some of those things, but instead of needing to learn all of them and then do that, if you really fundamentally, as a team embrace some of the automated testing, automated builds, like, you know, kind of a microservice architecture or a similar architecture, those things are going to become, you know, you're naturally going to implement some of those things.
- Cool. Interesting. So, you talked about the idea. So, now we're dealing with systems that are not built that way, right? They weren't built from the ground up and now you're looking for seams and ways of breaking them apart, so you can begin to wrap them in tests. Is that an art or is that a science?
- I think it's a little bit of both. So it takes people with experience to do it, at times, but ultimately knowing that, you know, what we tend to teach people is you can't just go look at a million lines of code and say, "Well, let's just spend the next year "writing tests."
- Yeah, sure.
- So if you just take a disciplined process to say, whenever something changes and I need to make a major change to it, I'm going to go in there and make that area more testable. And I'm going to put those automated tests there and I'm going to explore that area of the code, or whenever something breaks. So whenever there's a defect, I'm going to create a test to repeat that defect and then implement it. What happens is that over time, you're going to end up with the most tests in the area that it is that you're changing the most, which means you are investing in them or that break the most, which means you need to get them more solid in the, that investment self prioritizes. Now, so that type of a process and an approach, building that into your organization, I think is a bit of a science, right? We can lock that in. Now, over time, people get more and more experienced of figuring out, right, now that I need to test this because I'm making a major change or because it keeps breaking, what's the best way to do that? And that, you know, some of those things you need experienced people, especially when it's, when it's, you know, legacy code, that could be pretty complicated.
- So why is it hard to do the people side of transformation and the technology side of transformation simultaneously with the same group of people?
- Well, ultimately, you're trying to take a person, you know, it's like teaching someone how to walk on the moon on the moon.
- Okay.
- Right. You know, you're,
- I have no firsthand experience with that one, Matt, so yeah.
- Neither do I, so maybe I, ultimately there's some, fundamentals to go, "Okay, well, let's, "let's help the teams get uplifted "and let's look at the constraints and make sure "that we're not trying to have them solve a problem "beyond where they're at." It may be a problem that only needs to be solved once for the organization, right? So once your application is split up and some of those technical dependencies are removed, you don't have that issue going forward. So sometimes, rather than trying to take my team and teach them all of this heavy lifting of how to split it apart, it may be better to just get someone to split it apart, so my team can focus on creating businesses modules.
- So the group that's being transformed doesn't necessarily need to learn how to split the code, do the legacy refactoring, they just need to know how to maintain it after it's already been split apart. Is that what you're saying?
- I would say maintain it, but then if it's a base camp three or four or five team, it's enhance it and add lots of value to it.
- Continue to extend it using the same principle kind of a thing.
- Right, yes. Extend it using the same principles. So, you know, ultimately this is in a sense, a one time effort that I need to break it apart. Now, a lot of organizations have a lot of these legacy code bases, but for a team or a set of teams that need to work on an application, we can help get it split apart and then let them focus on, how do I build and enhance this code going forward using these practices so that it never ends up again, back in the state it was in.
- Okay, cool. So as you've been hypothesizing this, has been working together to define this offer. So there's four areas I recall that you think that you'll see LeadingAgile evolve into.
- Over time, there's a different set of problems. We've been talking a lot about coming along side of transformation and helping with technology uplift. So we would help, you know, break dependencies, add tests, or what have you. There are times where clients are gonna come to us and say, "I have this base camp three, four or five problem. "I just need a team to build this application "because I have to get it done. "And I don't want it to distract my transformation, "but I want to make sure that whatever's built, "won't have the issues I have in some of my other areas. "So one is I just want value delivery. "The second is that technology uplift. "The third is really a team uplift. "So, we have a team that has a certain level of capability. "There's some of the practices that we're doing "that aren't once a week things "that you need to learn to do, or once a month things, "they're things that change "how you write every line of code." And for those getting into an environment or a dojo where I can then, learn how to do those things, working against real code with a real business problem is an effective way to build up those things. And then the fourth is the technical coaching. Again, providing that one, two punch that says, "Great, you're giving me an application "that now has reduced dependencies, that now has tests, "but I have an existing team "that needs to know how to build on that "and needs to know how to build new features." I don't want to just provide this application into there. And then I could have atrophy where it just gets, like the value goes away because we didn't learn the practices along the way.
- So, basically it's like, it's like everything from, okay, we've got this one offer over here that basically says, you guys are over here transforming. We're going to help you build stuff in the right way. And then we've got another piece that is okay, we're going to help you split this apart so that when your team is ready, that we can, they can continue it forward using these solid practices. And then it's like, we're going to develop the skills within the team so that they can sustain it. And then it's like, we're going to work side by side with you coaching along the way to help you actually do it. Is that a good summary of it?
- Yeah.
- Yeah. Okay. Awesome.
- And I think that's kind of, what I'm actually interested in, so that ultimately it's very hard to move to these higher base camps, especially with an existing set of applications and we need to provide that wealth of things, right? It's actually interesting back in 2015, when you prognosticated the need for studio and these other practices or business units, what was the thinking about how that all would fit together? Is this kind of going down the direction?
- Yeah. Well, so it's kind of fascinating, right? You really have almost have to go back to like my early days. Like when I launched out, so prior to working with you at Pillar, I was at Version One and I had this idea that I wanted to go out and be an independent Agile coach, right? And had no idea, right. 'Cause I'm not, I mean, a degree in computer science, right. I've written code, I understand code, understand architecture and things like that. Like I'm not a guy that can go actually like do this stuff, right? And so in the early days of this, like I was, you know, out solving problems that I was qualified to solve, candidly, which were mainly around organizational design, project management, governance, right. And what I would do is I would spend a lot of time with teams back in the early days when I was on the ground coaching. And I would say like, "Look, you guys have to be able "to do a build every day. "You have to be able to get the testers integrated. "You have to be able to write unit tests. "You have to be able to do these things." And what I found was that for the teams that I was working with is that most of the time they knew what they needed to do. And they knew how to do these things. They just needed permission, just needed time. They needed ground cover and things like that. And so we probably spent the first four or five years building LeadingAgile within that frame, that as long as we create the right conditions for the developers to have permission to do these kinds of things, that they would do them, right? And then as the company grew and the size of the engagements grew, right, and we're trying to do this thing at scale, even sometimes thousands and even tens of thousands of people, what you start to recognize is that not everybody actually has those skills and sometimes permission wasn't sufficient. And so what we started to think about, or what I started to think about is if we were going to become a full service change management transformation company, we had to have the methodology for change, right? So a big part of what LeadingAgile has built over the last 10 years, isn't really a better, deeper understanding of Agile, what we've done is we've built a better, deeper understanding of change management and how to orchestrate change and how to create safety for change and how to measure change. Because one of the big things about our engagements is that we can walk in and we can say, "Here's the kinds of changes we're going to make. "Here's the hypothesis on that return on investment. "Here's the leading indicators that demonstrate "that we're moving in that direction. "Here's what you want to measure "in terms of lagging indicators. "And this is how all that's going to translate "into business results, right?" And so, and so what we started to find is as got better and better at telling that story and doing that kind of work, the barriers to actually getting those measurable results, as you might imagine, are in the technology transformation and uplift side. And then, and actually, and on the product management side, some of the base camp four stuff, because what we were really good at early on was helping organizations unlock their delivery pipeline. So, you know, there's this challenge it's like, when you can't build anything, is the conversation, are you building the right thing or can you build anything at all? And so base camp one and two in practice in the early days ended up being a lot of, "Okay, I'm not trying to tell you what strategy. "I'm not trying to tell you what to build, "I'm not trying to tell you what your customers need, "I just want to unlock your ability to build anything." And we got a lot of companies to where they could build stuff really predictably, but they were building some of the wrong stuff, right? And then, so we moved into the product space and then it was like, well, we know that in order to be able to move faster, they're going to have to unlock some of these technology problems that we had kind of punted down the road a little bit. So that was what was going on in my head at the time. It was this evolution and what the market was showing us was that there was indeed a need to be able to unlock. It was like gridlock in these organizations, right? To get rid of the gridlock. But then once you got rid of the gridlock, you know, the constraint moves and it moved into some strategy conversations, some product conversations, some technology conversations, sometimes it was training and skills transfer conversations, sometimes it was change management communication conversations. It was all over the place. And so the market revealed to us that this is what the next step was. I think we took the right first steps in those early years, but it became really, really clear. And so why the gap between 2015 and 2020? Well, it was like, we just took off. It was like, we started getting large clients and we doubled the size of the company. And it was like, there were so much of the base camp one and two work that really difficult to get the right level of investment and intention in doing some of the technology stuff and the product stuff necessary for four, five, three, four and five. That makes sense?
- Right, yeah. Makes lots of sense.
- Yeah, so it's kind of funny, right? It's like, you know the answer to the question at the beginning, but you have to kind of, we're a very agile company, right? So you have to go to market with what you can do, right? You have to go to market with what the customer is willing to buy from you. And then the market tells you what's next. Right? And it was really kind of a funny thing. It was like, when you were wrapping up your last gig, we were just at the place where we were encountering some of these challenges in a real way. And it was very timely, you know, to be able to take this leap during this COVID shutdown and all these different things. And yeah, it was just very timely, the way it all came together because I think we've gotten so effective at getting companies started and moving and into base camp one, base camp two, and we had danced around the base camp three and four problem enough, that it just got really, really crazy clear that now was the right time to go do all that. So, welcome.
- So no pressure.
- You got a big job ahead of you, man. You got a big job ahead of you.
- Exactly.
- Cool. So let's talk a little bit about the offer, right? You've been thinking about this quite a bit. So one of the things that I've really appreciated is as you've joined us, is that you've really kind of snapped a grid, right? You said you've gone to school on all my talks and presentations and things like that. So you've been walking our team through this, why, what, how, who kind of framework? So talk to me a little bit about why. Why studios, why now from your point of view?
- Well, and when I talk to people about why for an organization, there's always three components of it. So why for LeadingAgile and we just covered a lot of that, right? We understand what we're wanting to do. So why for our clients? You know, again, some of those constraints that are preventing them from getting the higher base camps and some of the unique constraints when you're, when you've got a lot of legacy code that some of the digital native new companies don't have. So that's a big why for our clients. And then there's also a why for our people.
- Well, so why don't they just go build it themselves? I mean, we talked about this a little bit, but let's just put a fine point on it. Why wouldn't they just go build this capability themselves?
- You know, some can, but there's, you know, there's a lot of, of work and know-how to know how to build that. And a lot of what we do is help build that capability for our clients and help them get there. But in the end it will become a capability that they have, and we will be an extension of that capability when they need it.
- Cool.
- And then why for our people. You know, we have technical coaches, who are great on doing that technical coaching, but they also would like to move into building things and creating once in a while. Our great consultants like to do three things. They like to create, they like to learn and they like to teach. And if they're only in a teaching mode, then where do they learn, right? And letting great technical people move between a studio context and a coaching context without even leaving the organization, I think is a great why for our people.
- So let me just see if I can summarize, right? So, we talked about how LeadingAgile needed to fill some gaps in our mission of being able to be a world-class transformation company, right? So we realized that unless we closed this particular niche in the market, that we weren't going to be able to realize our full brand promise, right. And then from the client's perspective, sometimes it makes a lot more sense to have somebody help with this aspect of it, because it's not something that they need to do forever. It's something that they need assistance and kind of a heavy lift. And then once everything's refactored, split apart, you know, test harness continuously integrated and deployed, then they need to have the skills to maintain it and to evolve it. But they don't necessarily need to make the investment in their people for the heavy lifting. And then the last bit, right, is a little bit about us and our people and having the ability to move across these domains and make sure that everybody's skills are fresh and that people are doing what they love. And they're able to engage in a lot of different aspects of the things that make work fun to do.
- Yeah, exactly.
- Yeah, cool. Awesome.
- And then kind of when you go from that why to the what, and we touched on this, so in order to solve those problems for clients, we need to have those four different capabilities, right? We need to be able to help a client, just get something built when they need it. We need that to be able to help them transform their technology environment, to make it a more conducive to these types of base camp three, four, and five team needs. We need to help their teams get to a position where they know how to build on top of these code bases, as well as extend them and maintain them. And then we need that coaching, that gets there on a daily basis to help get those things successful during the expeditions that the teams are going on.
- Cool. So, loaded question. What do you think we can bring to the market that makes us different than anybody else? Like why LeadingAgile?
- The number one thing is to having the things integrated into the model, right? We don't just decide that everyone in the organization needs to get to the same level, right? We talk about base camps and different base camps have different outcomes. And some of those outcomes can be better achieved by having these technical practices in place, and helping solve and affect the metrics or the outcomes. Right, so, so this integrated offer that helps, you know, large organizations look at, where do we need to make change, prioritize the investment in those changes, align both the organizational aspects, like government, governance and funding and so forth. What's the technical aspects that need to change, and being able to do that, you know, within one system of transformation or one system of delivery, I think is a huge advantage.
- So let's talk about that a little bit, 'cause that actually will dovetail probably nicely into the, the how conversation, right? So, one of the
