Embracing the Five Whys for Deeper Problem-Solving in IT

Mark Smith: 0:30
Welcome to the Power Platform Show. Thanks for joining me today. I hope today's guest inspires and educates you on the possibilities of the Microsoft Power Platform. Now let's get on with the show. Okay, welcome back to the show. As you can see, we've got a guest on the show again today.

Mark Smith: 0:49
I was reading this week and this quote jumped out of the book. And the book I'm reading is on how to be a good product manager, and it's authored by a chap. I forget his name, but he he specializes, for the last 30 odd years of his career, a lot of the products that we have in the software space. He's worked for the big companies and led the product development and he said something that resonated with me, which is fall in love with the problem, not the solution. And across my career in the Microsoft business ecosystem, I have often seen so many times we've jumped to a solution and many times we haven't become clear on what the problem is. And you know, the Toyota way came out with what they call the five whys, which is really to drill into and understand. Why is the problem we're trying to address really the problem? And just to add to this, to show how crazy it is when you don't do it.

Mark Smith: 1:45
I was reading recently about a jet in the US Air Force that crashed with loss of life of the pilot, and they carried out an investigation into it, and the official report from the military is that the loss was because of pilot error, case closed and the author of the book was called in months later to investigate as in from a? You know, did we really understand what the problem was? That it was pilot error? The reason the aircraft crashed into the ground is that the pilot was unconscious at the time and couldn't pull the aircraft out of a dive. So therefore, how can we say it was pilot error when he was unconscious? And so they said so. Why was he unconscious?

Mark Smith: 2:32
Well, in this aircraft, at a certain point, there is a lack of oxygen in the cockpit. Okay, why is there a lack of oxygen in the cockpit? And well, it was manufactured. There's a default in the manufacturing of this aircraft that caused this to happen in scenarios which were part of the operating envelope, of how this aircraft should operate. And so the whole thing was it wasn't pilot error, it was actually manufacturing error of an aircraft that had not. But as far as the case was closed, it was just pilot error.

Mark Smith: 3:09
And he went on to say you know, there's so many things that that we say are human error in what is produced. That is actually never really human error. It was actually product design error of whoever created the original. And I just love this concept of the five whys, and uncovering and falling in love with the problem forces you to go are we actually solving the right problem? And so why I bring that up is that I feel that in talking to the C-suite sometimes and I feel where we are in AI right now, there's a jump on the bandwagon of we need to do this because everybody's doing it and nobody's really said hang on a second, what is the problem we're trying to solve inside the organization. So with that, andrew, I'll throw across to you take us on our fearless journey on this podcast.

Andrew Welch: 4:02
So we have the soliloquy from Mark and then it gets passed over to me Great, great, yeah. So I think that this is interesting to me because, mark, when you were talking about falling in love with the solution, I thought back to all of the times, going back to, you know, when I would design a web page, right? So I'm going back to circa 2001 here, right? Or I would build an app, or I would do a whatever, and I would just it was new, and I could look at it and I would think, wow, that's really cool, I did something new, right? So I think it's easy for us psychologically to fall in love with solutions and want to run away from problems. But I don't think actually and I want to I've not read this book I don't think that that that's necessarily what the book that you're talking about is suggesting. Right, it's not fall in love with the existence of the problem, it's fall in love with, kind of the mental exercise of trying to unwind the problem it's not the end product, it is the unwinding of the problem.

Ana Welch: 5:10
Yeah, 100 but it's not. It's not. I don't know how you. You know how you yeah, 100% get a set of questions and you need to find the answer, and you write down the answer. It's easy to not be, to not fall in love with the problem, because being able to tame the solution, mold it into what you need it to be and coming up with the correct answer is so seductive and so powerful that us, as adults now you know, within the business world, it's easy to go back to that instinct and almost show power by being able to untangle the intricacies of the solution and say I do, ai, yeah it doesn't matter that you need it or not, and what's your problem, but I've got a solution and I know how to use it.

Andrew Welch: 6:34
So I, just I, just when, when Anna mentioned schooling, I thought of being in my ninth grade geometry class and having to go through the active right the active. Do you remember geometry proofs where it wasn't so much that you got the right answer at the end, it's that you had to demonstrate to the teacher how you arrived at the answer right. So, very quickly in my mind, I start to apply this to some of the work that I've been doing with executive leaders on building. We're not to the executing yet. I think that's actually right now. What Mark is trying to keep us away from is the executing. But how do you actually build that strategy? So I pulled up just in front of me a slide that I have to hand, which none of these come from any single one organization, right, but these are some of the. This is a sampling of some of the guiding principles that various of the execs that I work with have come up with through the courses of our conversation, so here's a few of them.

Andrew Welch: 7:40
We are Microsoft Cloud Platform first, building value by avoiding one-off point solutions. Power Platform is a key driver and enabler of our innovation initiatives. Return on investment is made by leveraging the Microsoft Cloud to its fullest extent. Risk is reduced as shadow IT moves onto a governed platform, and Power Platform empowers our colleagues and operating groups. So there were a couple Power Platform references in there, but that was just because you know the client that I was working with. So in my mind, I'm starting to pull out here, okay. So one problem that I think is really common in our world is that there's at least a sense that we, that organizations, are exposed to insane levels of risk by a lack of security or governance or order, usually in their data platform, right. So that's, the risk is reduced. Or, as I said in a previous episode, the legal client I had that said we want to keep our partners out of jail, right, you know.

Andrew Welch: 8:43
There's another one here about avoiding one-off point solutions. So a problem there, right, is that we're probably making a lot of investment. We're over-investing because we're not solving these problems as an ecosystem or as a lot of investment. We're overinvesting because we're not solving these problems as an ecosystem or as a network of issues. We're trying to solve them as one-offs. I feel like I've done a lot of talking, so I'll kick it over to someone else, but yeah, this is an interesting sort of thought experiment. What's even upstream of your principles? Your principles are driven by your challenges, or maybe the opportunities that you sit yeah.

James Joyce: 9:17
I'll jump in to offer my two cents. Thanks, Mark, for having me back on. You know you ask about the question about products and product ownership and building a product.

James Joyce: 9:27
I think we, unfortunately have a lot of different types of people involved in building a product and it kind of depends on, you know, your perspective. For example, we are diligently trying to increase our library of past performances and you know, if you ask one person on the team to write up a past for performance and let's say they're a technologist or an engineer their past performance will be on. You know this amazing microservices architecture that was scalable and it used all these different services and we brought it together and it was amazing. And then somebody else might talk about the user experience or talk about how good it looked and so forth.

James Joyce: 10:09
And somebody on my team recently said to me you know, early on in developing or working on a proposal with a client, we need to be able to think about what would the press release be when this thing is completed and what would that press release be highlighting as that amazing thing that was published? And I thought it was a good way of framing it that we often dive straight into. We work with a client. They say they've got a problem or they've got an outcome they want to achieve, and we dive into the solutioning part of it to figure out how we get to that outcome. And this idea of the press release or the celebration at the end of the thing, and what should be highlighted was an important way, I think, for me to think about framing that yeah.

Ana Welch: 10:54
I love the way you started with like unfortunately, there are many people involved in projects.

James Joyce: 11:06
Unfortunately, I just didn't do it all myself. Of course you need different expertise and different skill sets and that kind of you know combination of all those skills to produce the outcome. But it's interesting right to see the different perspectives that people will have on what that outcome was, that they delivered.

Mark Smith: 11:23
It's interesting. You used the word outcome there, and I feel that so much of what we do in business is around output. Output for sure Rather than outcomes. Yeah Right, yes, output for sure rather than outcomes. Yeah, right, and it's yes, you, you know when, when you talked about that scenario, then, of you know, look at this amazing microservices order. You know that we've created and we've done something, and I even feel that this is a problem in businesses general. We're always you've got to be doing something. You're showing output, we're showing lots and lots of output, but at the end of the day, is it moving the needle? Is it an outcome that's transformative, or is it being you've got to clock your 82% of hours for the week, that type of thing?

Ana Welch: 12:10
Yeah, but we've built 75 apps. What are you on about?

James Joyce: 12:15
Yeah, In everyday scenarios.

James Joyce: 12:18
Now I think you know, because of COVID we fell into a world of meetings, scheduling meetings for everything. We back up our calendars with meetings and we have task lists and just last week I had to send out a message to my entire business unit to start to reframe, kind of the way that we work, or at least an attempt. Everybody wants to complete the tasks and we rush in and we don't take a step back to think about well, what is, what are the important outcomes I need to achieve? We're just trying to check the list off as quickly as possible and I find myself kind of falling into that trap often and I have to remind myself constantly that think about the outcome. So that helps me prioritize what I'm trying to achieve rather than just rushing through. You know a checklist exercise. But I feel like across our entire organization, like across many organizations, I think we we've all fallen into that habit of check, check off the list as quickly as possible for the last 15 years I've worked on a model of GTD right, getting things done.

Mark Smith: 13:19
It came out in the I forget when it came out and so zero inbox became part of my lifestyle and life cycle for 15 years, and it was only at the start of this year that I've been challenging this whole thinking. Am I doing it just to check a checklist off and therefore get the? You know the dopamine hit from that? And I've now gone to I only go for zero inbox once a week and I've only look at my email twice a day and I only go on social media once a day. For a set amount of time I removed all the apps and I'm like I've become so free.

Mark Smith: 13:54
I had my boss reach out to me yesterday and say um, why aren't you on the meeting today? You know you're one of the invite and the meeting's not set up by him but somebody else, an associate partner in the business. And I said because I asked him to remove me off it. I've been attending this meeting for the last year and it has nothing to do with me. There's no point in me being here, apart from you get to have a bit of banter or joke with me. But I'm attending the and I like what you said there, james. It's a. It's kind of come off covid to a degree that we just lived in meetings and now I'm going, I'm starting to, you know, look at all those meetings and go I'm, I'm not contributing, there's no reason for me to be here, and I'm saying no. And then the funny thing is I'm not getting the clear justification of why I need to be there.

Andrew Welch: 14:40
And it's, it's forcing people, and it's because it's just a tremendous waste of time and brain cycles and yeah, I'm having a similar version of this discussion with with a lot of folks, as I've been launching cloud Lighthouse over the last, you know, couple of months and, and it's that when I started to do this, I've been really inspired by Vlad Sarov and Steve Mordew's model subscription model. With their, they have a Microsoft partner called Forceworks, and you know for those of you who are not, you know for those who are listening and watching, that aren't familiar. Basically, they don't charge their customers by the hour, right? They right size the team or what they think the effort is in order to achieve the outcomes that are going to be sought over the next year, and then their client pays a yearly subscription for, effectively, all you can eat, right, and there are some breaks on this model that they have. But I find that model to be so much friendlier to where we need to be going with the kind of technology that we're working with now, where, as the old model of charging by the hour or the day was very oriented around these, we're doing an implementation of a known quantity application. It's going to have a start and it's going to have an end and then, at the end, we're going to walk away from it.

Andrew Welch: 16:03
So I've actually been offering my prospective clients hey, here's six months or a year or a quarter of all you can eat of me working with you on these things to pursue these outcomes.

Andrew Welch: 16:19
And most of the folks that I'm talking with what they ask is well, I know it's a worse value to me to just have you charge by the hour, but could you charge by the hour anyway, because that's how our accounting is set up and we really need you to charge by the hour. So I've been really astonished by when you offer someone an outcomes based arrangement that is, by almost every measure, a better value to them, because I, you know, if I'm offering that outcomes based arrangement to you, I'm assuming some of the risk of that outcome not being met, or not being met in the amount of time we thought it was going to take. But people just sort of snap back to this. I want something I can quantify Tasks that are checked off, hours that are worked, meetings that are attended and I think we're going to have to get over this as I think a society and kind of a business society if we're really going to make the most of the technology that the four of us all know and love.

Ana Welch: 17:20
I think that the truth and the reality sits somewhere in the middle, because outcomes are great as long as they're guardrail, Like you know. You want to reach that outcome and that's your goal and you don't really focus on the outputs number of tasks, number of meetings, you know whatever. But it's so easy to get stuck in like indecision hell and cycle the moment you tell your customer, tell and cycle. The moment you tell your customer I'm gonna give you all you can for a year, it's gonna cost you this much, and these are the outcomes that you can achieve. You're putting it all on them and people just don't want to make that effort. They'd rather just check the task list, because it's not just them.

Mark Smith: 18:17
Yeah.

Ana Welch: 18:24
It's like talking to. It's like again, like when you're in school you know and you need to convince people that it's really better if we have a lesson outside, because the sun is shining and everything, everything's, you know, beautiful. But then, like you need to negotiate with your colleagues, and then with the teacher, and then with everyone else, and then now you grew up and you need to negotiate the same thing. You're like guys come outside, it's sunny and nice, and they're like oh man, but I need to convince. I don't know the power platform practice and the data practice as well.

James Joyce: 18:59
Can you just charge me by the hour? Yeah, procurement in organizations really, of course, feel more comfortable with that hourly procurement model, and it's a reality, right, that budgets have to be assigned to things, and so that really conflicts with the idea of agile, like an agile philosophy of. This thing is important to us and we're going to continue to work on it until we feel it's good enough. The good enough has to have some kind of financial bounds around it or understanding, and so you kind of have to still then understand the general bounds of the thing so that you know, in finance, uh, doesn't feel like there's an open-ended. You know, check here that to, to, to be leveraged.

James Joyce: 19:42
It's tough and, and I think trying to strike that balance is important, right, the, the idea that bodies and bodies times, number of hours, is not a good way to measure, you know, the, the capacity. But measuring the outputs, whether it's story points or some method of measuring the unit of productivity I think that's really important, but it's still. It's amazing how many organizations still really struggle with embracing that idea of measuring productivity rather than measuring the capacity that they're procuring.

Andrew Welch: 20:20
Productivity is notoriously difficult to measure right across an organization or across an economy, and even the very idea of.

Andrew Welch: 20:27
I've been thinking about productivity a lot lately because I think that AI presents society with a really unique opportunity to move the needle on what really has been lagging and shrinking productivity growth across most of at least the Western world over the last couple of years. Yeah, so this is a really interesting question, but the problem is that nobody really has a terribly good way to measure productivity when you're not producing objects, right? So as we've transitioned, as economies have transitioned to being more service-based, and therefore more of the people working in those economies and the firms in those economies have transitioned to being more service-based, at some point along the line we simply ascribed the hour, or, in you know, in in Britain, british Microsoft partners are much more into selling, like having a day rate, than an hourly rate, so there's a little bit of variation. But at some point along the line we ascribed filling an hour with, like being preoccupied with something, regardless of whether it's a pointless meeting, right? That's the like. Have I filled this hour with busyness? That must mean I have been productive.

Ana Welch: 21:45
Especially if you get to like check it off right, Exactly. I like something you said, Mark, about that dopamine hit your zero inbox gave you and how true is that right? Like checking off past sending out these many emails. Like it's really hard to fall in love with a problem where it may take you several days and weeks to actually understand the problem. And like dig deeper and people don't want to talk to you and instead, what's the dopamine hit when you just go in with, like this new emerging tech presentation? And I know I've been, like I've been working at microsoft. I worked at microsoft for almost three years being responsible of the emerging tech. My entire job was dopamine hits. I would just go there and show them like I fully drank the Microsoft Kool-Aid. It was great Outcomes. Well, not really my job. Someone else had to be in love with the problem.

Andrew Welch: 22:54
So one of my favorite moments sorry just as an aside, but one of my very favorite moments listening to a Microsoft person share the story of their particular technology was actually Anna, and when this happened I was in the back of the room at this session that Anna was giving at a conference and I was holding. There's the thing, thank you, apple, and I was in the back of the room at this session that Anna was giving at a conference and I was holding our baby while Anna was up presenting. And at the time Anna was doing most of her work with RPA. And I guarantee it's the only time that anyone has ever seen someone from Microsoft get up in front of a room and say the most important thing you need to know about the technology I'm going to tell you about is that you should use it as infrequently as possible. So I don't know if that was like a reverse dopamine hit, but it was a great dopamine hit for me.

Andrew Welch: 23:45
Like microsoft is telling me to use their stuff less, that's interesting, but so correct I mean not their stuff, that particular product that that, that that was back in the era right when people were saying and this actually gets to falling in love with the solution, not the problem, right? People circa, you know, 20, this was 2021, 2022, I was getting a lot of these calls saying, hey, I've got these folks and they want to talk with you, they want to lead with RPA, and anytime I heard the phrase I want to lead with RPA, I would say, well, I mean that's crazy, right, who says I want to lead with the most fragile and expensive integration option available to me? But that really, I think we were. That was a time for a couple of years when we were super obsessed with this idea that we could just automate the thing using this one technology that we've all gotten super into, even though it's a complete misapplication of the. I've got to turn that feature off. It's a complete misapplication of the technology itself.

James Joyce: 24:56
Well, I think you know when you, depending on who is standing in front of the client in that scenario where they say, hey, I want to build this thing, you're almost predetermining what the solution is going to look like, because that individual, from their perspective, is going to build the NET solution or the dynamic solution or power platform and so forth, rather than taking a step back and looking at the outcomes or the objectives first and then figuring out what the right solution should look like. And that's important, and of course, I think it's a challenge at times in the Microsoft ecosystem being introduced to a client by a Microsoft person and they have their own motivations for what that solution needs to be, and so it is a challenge to then kind of force that you know step back to happen, to have a real conversation with the client.

Andrew Welch: 25:46
This is a huge problem, I think, in the, particularly in the partner ecosystem, and it's that, as you know, years ago, when these solutions were all pretty well isolated right, you could have you know I was going to bring you a problem, and now my problem is that I need to automate my marketing, or my problem is that I need to improve the reliability of my supply chain. You could pretty well say oh well, I think the answer to your problem is dynamics for supply chain, or I think the answer to your problem is dynamics for supply chain, or I think the answer to your problem is dynamics for marketing, but now so so? The point, though, is that those solutions could be implemented largely in isolation of other solutions, so we have this entire ecosystem now of partners right that are organized around little pnls, little profit and loss centers, where, if you're talking to the guy that owns the data platform, p&l guaranteed the solution to your problem. I haven't heard the problem yet, but I guarantee it's that you have a data platform problem.

Andrew Welch: 26:48
And the same with Power Platform, the same with Dynamics, the same with Azure Infrastructure. So if we're going to get past this, if we're going to fall in love with the problem rather than the solution, one of the things that we have to do is we have to change the incentive structure and the organizational structure within these firms that incentivize obsession with the solution rather than with the problem.

Mark Smith: 27:14
I would like to pick up on something that James talked about last time that we were on the show and that was the awkwardness of the location of the power platform as in where it sits inside an organization. Does it sit inside IT? And I just want to, because what that's left me thinking about is I use a term when talking with customers that it shouldn't sit inside it. It should, as in whatever part of your org you create around this, it should be adjacent to it. They've got to have tentacles into it because of the tenant, uh, the access, the governance layer is an it construct, but it should sit adjacent. What I'm my question to everybody is where should it sit? And let's just size things, where should it sit in an organization that, let's say, are more around the 5,000, plus sizing of use of the Power Platform?

Mark Smith: 28:20
How would you advise an organization if they were like, particularly in the scenario that you know they had acquired their licenses, that they hadn't. It hasn't seemed to have landed, they haven't seemed to have scaled. You know they're told about software economics and the ability to grow. You know you built your first app that would cover the license. Now the 10,000th app, of course, is now just a fraction of a percentage of that original license. If you're going to advise a customer on setting their organization, forget about the tech piece up. How do you advise them?

Andrew Welch: 28:58
I have strong opinions and therefore I'm not going to go first. So, Anna James, there you go.

James Joyce: 29:06
I'll go first just to kind of maybe follow up on that question, mark, because you kind of, I think, hinted at part of the wealth problem and maybe solution these large organizations, right, that you're talking about. They grew to become large organizations around a very well-defined structure, very well-defined structure, and those structures have their areas of responsibility and it's very clear in a very traditional IT organizational structure. And so you don't, in a typical organizational structure, have a natural home for a power platform or we talk about a power platform center of excellence. If that's the direction that you're going to try to build that single organization, it doesn't naturally fit. I'll come back to my thoughts on answering, but I'm going to stop talking and hand it over to Anna or Andrew to pick that up, anna.

Ana Welch: 29:59
Oh man, where does Power Platform sit in a large organization? Well, frankly, I think it should sit with IT, but it's not. It's like the ugly sick cousin and IT doesn't want it. Because it's like toys for children and maybe it used to be, but right now it's pretty damn complex and I think they're a bit lazy as well they don't really want it.

Andrew Welch: 30:31
Not even James could build an app. He tried.

Ana Welch: 30:34
It was too complex for James. Honestly, it's not that easy Okay.

James Joyce: 30:39
I like to tell my folks in my organization that I am at a junior power platform developer level, folks in my organization that I am at a junior power platform developer level. I haven't advanced further, but I achieved that grade of efficiency.

Ana Welch: 30:52
Right, but I do believe it should have an IT overlord who is there in DevOps and all of the things together, like on their big dashboards with I don't know Datadog or whatever they're using. You know where they're monitoring where data goes and you know how it goes and what sort of processes are up and what's down, et cetera, et cetera. I do think that it should probably find a little bum bet in the IT department. Maybe I'm wrong.

Andrew Welch: 31:25
I'm going to chime in here and say that I 100% agree with Anna. I unequivocally think that Power Platform belongs in IT, However but right, We've never talked about this, by the way.

Andrew Welch: 31:42
We've never discussed this topic. We've never discussed this topic, but here's what I think the rub is Most IT organizations are not set up either from a cultural perspective, an organizational perspective or from a leadership perspective, to make the most of and it's not just Power Platform. I don't think that most IT organizations are set up to make the most of Fabric or the data platform or artificial intelligence even right. So the answer isn't let's pull Power Platform out of IT, because IT is not an effective steward of it. It's let's transform the way IT is done so that IT can be you can be a phenomenal deliverer and enabler of this new technology that we have access to. It's not power platform that needs to move, it's IT that needs to change, and the change is that IT organizations need to go from thinking of themselves as superintendents of utility companies whose job it is to keep the lights on and the phones ringing and the email sending, to really being strategic leaders of, and enablers of, the business. That's, that's that's the change that needs to happen here.

James Joyce: 32:54
That change, though, is very complicated, right, because companies are very comfortable with what they have, and this the philosophy that he is just the stewards of, of the platforms, of the infrastructure, of security and so forth, of licensing, and that's their entire scope is what they're kind of comfortable with, and the idea of building applications, building software, building products, is not traditionally with them, is not traditionally with them, it's with some other part of the organization, which is why I guess I would challenge whether it's possible for IT to fully embrace the idea of being the enablers of the building of software using technologies like this. That's fair.

Mark Smith: 33:39
I like it. I like it because I yeah. When I heard Anna and Andrew's comments, I was like woo-hoo, we've got a disagreement, and the fundamental reason is that I don't believe engineers are wired to think about innovation for people. They are much more. If, then yes, no binary in decisioning. Are we going to lock it down? Are we going to make it secure? Are we? Are we going to have support tickets? Are we they?

Mark Smith: 34:14
Once again, it's all around control, control, control. Not how do we solve business challenges, and I have never seen in an itn organization that have a hat on this. They've got a really creative CTO or CIO that go. You know what? We're here to empower the organization like never before. Most are all around governance, control, and this is why I've voiced so many opinions around the. The confusion around the COE starter kit and the concept of a COE is because it's all around control and lockdown and secure, like it's not about innovation. And so, where you want this thing to grow and empower and enable people and I don't believe I'll change my opinion until I see inside every IT team a full design department that focus on user experience and things like all that fluffy stuff that they go, oh man, until you address that and create for people.

Ana Welch: 35:21
Make a proposal and get to a person who's actually going to run the numbers and what do they exclude out of your proposal in order to cut costs? Ux, user research, user design right.

Mark Smith: 35:39
Change management.

Ana Welch: 35:40
Change management.

Andrew Welch: 35:42
So I'm going to say something, really I'm going to say something potentially incendiary here. Maybe the organizational change isn't that we need to move power, platform and some of these innovation-centric technologies out of IT. Maybe it's that we need to move governance and security out of IT and into the facilities management group. Right, Because as our facilities have become, as our buildings have become virtual, so too, maybe is the way we we used to think about our buildings Right? Like there's a difference between there's a difference between achieving a an acceptable level of security and governance versus having a forward looking strategy that is going to grow the business, that is going to return investment to the business, that is going to modernize the business and that's going to make the business more productive, or whatever those drivers are. I agree those aren't the same function, but IT needs to move in the direction of the latter.

James Joyce: 36:43
I'll answer this commentary because I think there is a shift happening. Think about the idea of traditionally infrastructure-focused people writing infrastructure as code. Several years ago that wouldn't have been considered a thing that an infrastructure engineer would do. Now they're writing code to automate the deployment and then, similarly, on the other side of the house if there's two sides of the house the application developers you know writing the software code for their solution are deploying infrastructure and cloud services through that CICD pipeline. So everybody's knowledge of each other or their worlds are slowly blending together of each other, or their worlds are slowly blending together. And the more that happens, I think there's an opportunity to kind of reshape what IT should be in the future. And you know who knows, when OpenAI fully is embraced in the enterprise space, you know what that will mean for the future of these IT organizations.

Ana Welch: 37:48
And. Mark, you said you told us okay, no, it does not belong in IT. But you did not tell us where we should put Power Platform. You just hated on our idea. I love it. I love it.

Mark Smith: 38:04
I don't actually have the answer yet, as in, apart from saying I think it's, I love it. I don't actually have the answer yet. I as in, apart from saying I think it's a adjacent to it that it should much more be around keeping the lights on uh, licensing, you know, providing the infrastructure. But I think the innovation on an infrastructure needs to happen outside of it. But unfortunately, because of the history of IT, when the CX level looks in the organization they go, hey, this is software or this is IT infrastructure, Bang, it automatically goes to that department and I think it needs to sit and we need to have a department of innovation inside business.

James Joyce: 38:41
I'll share my answer because I didn't share it earlier on. I'll share my answer because I didn't share it earlier on. Until an organization is able to reimagine how innovation is delivered when we've attempted to in smaller organizations you can put a you know, a power platform COE team in place and if the organization is small enough, they're going to be responsible for both the application development type work as well as the infrastructure and governance. But in large enterprises we found it necessary to really split the COE into two components that kind of complement each other, where the governance, information rights management and so forth, license distribution is managed out of the traditional IT organization. But there's a complimentary part of the enablement that is happening in a line of business type organization where they're really driving the use and the value that's being delivered from the platform.

Mark Smith: 39:35
I love it. Thank you everybody. We are well over time on this episode at 45 minutes in and, andrew, I know how you like to keep me to 30 minutes. Thank you everyone for joining us. It's been an absolute pleasure. We will see you all next time. Hey, thanks for listening. I'm your host business application MVP Mark Smith, otherwise known as the NZ365 guy. If there's a guest you'd like to see on the show, please message me on LinkedIn. If you want to be a supporter of the show, please check out buymeacoffeecom. Forward slash NZ365guy. Stay safe out there and shoot for the stars.