The Nonobvious Line Between Business Agility and AI Readiness

What if we told you that the things that enable business agility in your organization, are the same things that enable you to deploy AI in a way that actually leads to better business results.

Video Transcript

Eric Flecher:

That’s what we’re doing at la. We’re making AI accessible, right? Because we are addressing the core fundamental first principle problems that have to be solved to bring these outcomes and these solutions into your scaled business operations.

How We Help Our Clients Achieve AI Readiness

Mike Cottmeyer:

If you were at a conference and you said, Hey, I work at Leading Agile and I’m the AI data practice lead for Mike, and they said, oh, tell me more. How would you talk about, you have two minutes or something like that, or maybe it’s even pier than that. How might you describe what we’re doing for companies in the AI space?

Eric Flecher:

We’re making AI accessible, much like those, that mobile experience I shared when I was doing a lot of mobile work for enterprises, we would get called in, Hey, a lot of excitement at this business layer, the leadership layer, the individuals that are deciding these strategies and purchasing and bringing teams in to help. And then there would very quickly be a false summit because then they realize the second they get to the spreadsheet of the really cool things they want to do, they realize they can’t get to those things because of technical debt, because of organizational structure, because of compliance burdens, whatever it may be. And there’s this, it’s kind of that trough of disillusionment that we see in these hype curves. And what I would say is that’s what we’re doing at la. We’re making AI accessible because we are addressing the core fundamental first principle problems that have to be solved to bring these outcomes and these solutions into your scaled business operations.

And then we’re making it so that you have a cycle, a feedback loop, so that you can size and focus on the things that matter. Going back to that two by two that we referenced earlier, there’s a lot of things an organization can do with AI and data, but there’s also a lot of things on that list they shouldn’t do. They have unique data sets that might be proprietary to them. They have unique knowledge that might be proprietary to them, and they have a marketplace that they’ve carved out where they’ve created a business. We need to go through a reductive exercise to figure out what you don’t do and where do you focus so that you could utilize the best of these tools to put you in a position that is unique in the market that is defensible, and you don’t want to invest work in areas where when the next model comes out or the next SaaS platform comes out where all that work evaporates because somebody else can just do it better because they found that niche and they exploited that niche better.

Mike Cottmeyer:

One of the ways that I took leading Agile to Market, it was kind of around this idea of why Agile fails and what you could do about it. And so what I could do when I walked up to somebody is I could say something to the effect of, tell me what your experience with Agile is or something and they would say, oh, it’s going well, or it’s doing this and whatever, and we’re making progress. And I go and I just knew all the problems that they have. I knew the pain that they were experiencing. They were doing process first transformation. They were doing culture first transformation. I knew in my bones that the problems they were having were teaming strategies. I knew they were having problems with technology encapsulation. I knew they were having problems with over orchestration and lack of clarity and all the cognitive load that we talked about. And so if you put that in the AI lens and you walk up to somebody, what’s the pain they’re experiencing? How would they experience that pain? How could you connect to that pain, just pain they have? How are they experiencing the pain of not doing this the right way maybe is what I’m hunting for?

Eric Flecher:

Well, chances are they’ve probably experienced similar pain, but in a smaller, let’s say dose with their previous technology initiatives when they’re trying to create some sort of new product or system, there was probably an opportunity or there was probably an experience where they asked for X but they didn’t get X, they got something different or they got less than that.

The Challenges of Technology Extraction and Process Modernization

Mike Cottmeyer:

So one of the things I’ve characterized leading Agile as over the last couple years as we’ve really refined our methodologies for doing enterprise transformation is we’re really a technology and process change management organization. The idea is to be able to make these changes quickly and systematically, predictably in a way that is connected to business value. So a lot of our methodologies really come into a generalized change management framework for technology extraction and business process optimization. What are the barriers that you see in companies to introducing this kind of change?

Eric Flecher:

The barriers, some obvious barriers that come out first of all would be around making sure that when you set up a team to work on a set of initiatives that are focused around business outcomes, that is the interesting intersection where the opportunity lies. Because what you’re actually asking of your organization is to be able to operate with a lot of polyglots, someone who’s a business matter expert, who understands that industry better than folks outside the organization, but wells inside the organization, these folks that have the intuition and the knowledge of how that industry works and how to create value within it. You’re intersecting that with all these other technical disciplines. Now you’re basically saying that person also has to understand the raw materials that go into that and how you deliver through technology. Because every business out there, whether they say it or not, needs to have technology into it to how they deliver.

But you’re bringing now those technology concerns up into the business layer where there used to be a separation where you say those folks are over in IT making sure my database is up and running and my APIs are available. You’re now bringing those people and those decisions, strategy, technology, prioritization much closer to the business problem, which is what we want. We don’t want distance between these things, but to do that requires right now individuals, leaders, managers, product managers, analysts to be able to understand these other spaces that they were traditionally walled off from and make decisions at these intersections to be able to prioritize work at these intersections and to not create additional debt, whether it be a business debt, bad decision on a strategy or a technology debt, bad decision on how you architect or organize your data For examples. These things all need to be done in unison kind of as an orchestra. All the instruments need to be playing together now conducted by a orchestration strategy around these business domains and domain division design.

Mike Cottmeyer:

A partner of ours said about a year and a half ago to me, and it really stuck in my head, is that this move to AI is going to force digital transformation to become real. And what I think he was really saying in that is there was a lot of space for technology leaders to move to the cloud or do other modernization initiatives and claim victory and say, yeah, we’re digital, but this next wave of digital transformation is really about we have to get these systems optimized and aligned so that they’re solving business problems in a much more rapid way. I don’t know any thoughts on that comment?

Eric Flecher:

Yeah, I think we can look at the history, some history, some near term history and learn from that. So back to the mobile example. So when the first set of enterprise mobile apps came out, there were mostly marketing driven, flashy, interesting, and fun. Then the next phase of these apps came out where you started connecting them or seeing them connected to different business processes. Maybe I can go online and buy something on my mobile app, but I couldn’t do that on the website or I couldn’t carry my cart from my mobile app to my website in a journey that omnichannel journey. So if you look at retail 10 years ago, they had to go through this realization and start to rethink their organization in terms of how you deliver value using technology through the surface and the channel of technology. So they do, they started building different types of channels, both crafted for the internal employee, the backstage operations, as well as the front stage operations that interfaced with customers, but they ran the constraints, the inventory of how you manage your stores.

If I am a retail organization, selling TVs might be different than the inventory management systems that’s running my e-commerce system. And if I have a mobile app and a website that needs to have access to each of these things and I want to go buy something and just get it delivered to my house, how do I do that? So they started interfacing and creating open API infrastructure. Then they started making continuous experiences across these because now you have APIs set up and I have access to data. Now I can start to build craft experiences that are forced around business functions and outcomes. Well, even those became transactional because now the business realized you can do these things and there’s a lot of value in delivering these solutions. But the question came about, wait a minute. Well, if I have an e-commerce solution and a warehouse in the middle of the country and I have individuals buying products that are located on the other side of the country or that e-commerce warehouse, why don’t I just deliver from the stores?

So now I have to unify inventory management and I have to figure out how to reconcile those systems which might have different data sets and different data models and different processes. I’m sure they do. They did and they do. So how do you start to fuse those back operations? Then how do you build and extract value out of building efficiencies into those systems? Don’t ship the product twice, ship it once and then do the last mile delivery. These are all things that retail had to solve and is still working to solve. I think that’s a really nice kind of example of what the broader, let’s say business industry now, anybody working in large enterprise that is looking for AI opportunities, they could look at those past playbooks and say, okay, how might I learn from those things? Because effectively you’re doing a very similar exercise at a much broader scale now, and you’re also giving the opportunity to automate that mental labor, those small decisions made throughout the system.

The Power of Creating Nested Autonomous Business Objects

Mike Cottmeyer:

So I’ve kind of thought about this hierarchy a lot. It might’ve even talked about it on video at some point in time is I almost see in an idealized state, a nesting, and we’ve had a lot of internal conversations around this, and the outside nest is like the business object, and then underneath that is business capabilities and product capabilities and up underneath that are teams and people process that deliver that business or the product capability Underneath that team are what we might call technical domains, something that we’ve struggled with internally to go like, are we going to use domain language all the way at the top or are we going to only use domain language at the bottom? Those kinds of things. That’s an interesting conversation. And then those domains, they break down into subdomains and ultimately into objects and data encapsulation and all that kind of stuff. So in that frame, what’s been your experience with us so far? What are the challenges to extracting objects and data that way such that we can wrap organizations or teams or tie them up? What makes this so challenging?

Eric Flecher:

I think it goes back to what we’ve been talking about. We’re starting with an organization in a system that was designed for the right reasons around the constraints that people have with their ability to process information and network and work. How many things can you keep in the forefront of your mind as you’re working through things? All of these, I think the emerging, the organic emerging of these organizations all build around those structures. And at the same time, we now have this exponentially growing capability that’s every day it seems like it’s getting cheaper and more accessible and every day it’s getting more capable. And so the incentive and the value of deploying those outcomes into my business is growing every day. So you’ve got a great pool to say, I want to use these systems. I want to deploy these systems at scale with confidence.

At the same time, we now have to look at the organization and be honest with ourselves. This is a system of people with responsibilities, with inertia, with motions that all have been designed over time and refined over time in order to make that organization successful. So one is understand the best practices and the patterns that are emerging in this new space and it’s changing every day and it’s exciting. The other big piece of this though is we still have to find a way to redesign the human architecture and the delivery architecture around these new capabilities. So it’s not as simple as saying, let’s go find the latest technology and just plug it in because we haven’t addressed the actual system that needs to use it. So the challenge is how do you actually go to an organization and walk them through the steps so that they can reorganize how they deploy their very smart capable teams and peoples to create outcomes with these new tools? And that’s really interesting about this challenge, and that’s why it’s not as simple as making sure you have the fastest model or access to the best AI tools. You have to pair that with a methodology and emotion that knows how to change a human system and optimize that community with those technologies.

Mike Cottmeyer:

You actually pulled a really interesting thread, and this kind of connects us to a little bit of the agile stuff. At the end of the day, it’s almost like a cognitive load problem

On the individuals and the teams. There’s only so much a given human can wrap their head around. And one thread that I want to pull that I think is interesting, and as having run a consulting company for the last 15 years and worked with literally hundreds of companies in some form or fashion, whether in biz dev or an actual client account or whatever, part of what I’m hunting for is that when we’re able to create a complete cross-functional team, they operate off of a clear backlog. They don’t have any dependencies between them and they can produce something of value at the end of every sprint. So anybody who’s been following our stuff for a while, it’s like teams, backlogs, working tested software. We call it three things. And there’s almost something implicit in that that says, we’re going to create this team of people that work together. We’re going to limit their problem space and we are going to reduce the cognitive load. Where you see challenges in some of these complex systems is that when there’s too many dependencies between things, people don’t know how to negotiate those dependencies or those interactions at scale because they can’t keep the broader part of the system in their head.

And the net effect is you get local optimization across the system. I don’t know if that’s a good lead in for you, but it’s like what do you think about when I say that?

Eric Flecher:

I really like

Mike Cottmeyer:

That. How does that dovetail on what we’ve been talking about?

Eric Flecher:

It does. It does, and here’s what I like about that a lot. So there’s a couple ways to approach this. So if you think of all the refinement and maturity around agile and agile transformations, those tools are I think more important than they were when these concepts were novel and new. And then one of the reasons why is what we’re able to do now is let’s say we encapsulate, let’s say we address technical debt. Let’s say we make data available and we make infrastructure available, and all those things are set. So we we’re pulling those off the space for a moment, put an a pin in that and say, we’ve solved those problems in a given targeted vertical business domain. The next challenge is exactly what we described. You have cognitive load, you have humans with only so much ability to carry in their minds like so many things on top of mind.

And that is what’s really interesting about this is when we look at this, what we need to be able to do is say, how do you actually build trust in whatever these new probabilistic systems are? Because departing from deterministic systems, rules-based systems, if this and that retrieve data from a database displayed on a web form with this set of rules, let a user enter data into a form field or into whatever it may be. We’re leaving that space and we’re going into a space where we’re going to trust a system to make decisions that previously have been done by people or software development. We can go and generate a lot of code, but do we trust the code that we’re creating to create the outcomes we’re targeting? So what we have to be able to do is find a way after we address those technical hurdles to be able to build trust into those cycle times as we release new capabilities so that all folks with their given responsibilities up and down the stack can trust the outcome of those systems.

For an executive, it’s my key dashboards that show the needles and the numbers and are they moving in the right directions for a technology team? Can I generate a system or can I use these new tools to be able to create software that previously would’ve taken me a much longer time, but can I trust that so I can build something on top of that? I don’t want to build my next house on sand. And that is the trick and the reorganization, the ability to encapsulate the ability to use agile principles and bring that up and down through all the decision making at each of those levels you described. That’s why this is such a unique opportunity for organizations that understand how people work and how to change people in processing systems and to ensure trust and predictability remains as you bring more probabilistic decisions and capabilities into your system, that creates value.

Connecting Our Hypothesis to AI Readiness

Mike Cottmeyer:

When we think of an agile team, the way I’ve often described it, right, six to eight people that have clear direction from the business around a problem to solve and they have ownership over whatever piece of the technology is, and that team is able to take the direction from the business and deliver something of value for feedback every two weeks.

And it’s really difficult in most of the companies that we work with is that the way the technology stacks are architected, they don’t necessarily lend themselves to the team owning something, something that they can deliver against, that a customer can touch and feel and use. And so I’ve had this hypothesis for 20 years now at this point, if we can break down the technology architecture into composable chunks, technical term, right, composable chunks, and that technical component can have a team that’s dedicated to owning it, and then that team is funded consistently over time in a way that the business is willing to pay for it, it sees the value prop of that team continuously iterating against that object, and then I can get that team and that technology object aligned with the business and get it to deliver in a reliable, predictable way, right? That’s like what’s been underneath what we’ve been trying to do around here for 15 years now. It’s been in my head for probably almost 25.

And so that was what kind of took us down this path of asking the question, because historically, what LeadingAgile had done is we had taken and looked at organizations through a business capability lens because something that the company wants to pay for and putting teams around it and then feeding those teams work through our governance models and stuff. So my hypothesis is, is that if we can get teams and technology and the underlying data encapsulated pointed at business problems and get it to deliver those value props in a reliable, predictable way that somehow underpins AI readiness. So one of the clients that you’re working with right now, we’re going through a big kind of extraction modernization exercise, and as we extract and modernize the applications, we form teams around them, we tie them to value props, we encapsulate their data. How does that, since you’re our AI data specialists on that account, how does that process of extraction modernization team alignment to organizational objectives, how does that help us exploit the AI use cases that this particular client wants to explore?

Eric Flecher:

Let’s say if you look at organizations that exist today, especially large ones at scale, you could probably make a pretty strong argument. The way they’re organized and structured goes down to the first principles of how humans have to organize and structure in order to keep predictability and dependability right in place. And those systems hierarchical or matrix based, whatever it may be, are organized based on the constraints that humans have in terms of the ability to know domains or certain areas of their subject matters or to their responsibilities or their ability just to purely network with others and maintain state and status across these teams. So these systems of people and management structure exists and emerges, and then it naturally would be the technology that supports these things organically grows inside of those structures. Now, that may have been fine up until a point where that AI line was crossed a number of years ago.

And the reason why that shift change is so dramatic now and so loud in the marketplace is all of those decisions around your technology, around who owns the data that supports those technologies around the governance, around these systems to make your systems legal in certain regions and countries and states, et cetera. All these things emerged because of those systems being in place. Now we have the power of ai, the ability to take an expert in a space or a team of experts in a space and give them the collective knowledge and capability of society and work. It’s now a very strong function, a forcing function to say, well, I need to be able to deliver in a certain business domain data from this team, a transactional system from that team. I need to plug into KPIs and metrics that the management team requires. Or maybe I’m going to reinvent new metrics that best fit my business for where I want to grow it to.

And that slicing doesn’t usually fit in the structures that have emerged organically over time. So what we’re doing with my client now is what we’re doing is we’re slicing off these business domains. We’re understanding what needs to be true in that business domain from an executive at the top that wants to put a dollar of funding into the system for an initiative or a goal or a strategy to the factory, four at the bottom that needs to create that value. Being able to draw a string or a line to say, how do I measure the effectiveness of that system and how do I improve it to do all this work? There’s a number of things that have to take place. We have to grab the playbook of an organizational transformation of delivery transformation. We have to think about how we plan and slice that work.

But we also need to think about how do we rea architect the business and all of those key elements, those assets the business has so they’re available and they don’t break the business while you’re making these changes. There might be a table or a database at my client that has rich data that I could use to create the next horizon of smart outcomes that they want in their business space. However, that data might have compliance burdens associated with it. There might be sensitive data that they don’t want from one organization or one team inside that organization for the other teams to be able to get access to. But in order to be able to make these systems, I need to have access to that data. So as we go and organize around these domains, we’re also going to encapsulate these systems and transform data into a product or a service.

And when you package it like a product, you’re also considering the things that need to happen around that data so that it can be used safely at scale. So that could be a la carte type experience for whoever or whatever initiative gets spun up after our initial work. So each time we take a slice, we encapsulate the things that are important, we productize it, we make it interfaceable, we make it easily consumable, and then we push those up into that service layer, and then we start again. And each time we do that, we encapsulate more so that we can add more velocity in the system and move faster and have more access to a wider variety of use cases where that is all in service of business objectives.