Latest / You've Been Heard / 406- Perfection Is the Enemy of Progress w/Michael Murray

Transcript

406- Perfection Is the Enemy of Progress w/Michael Murray · You've Been Heard

• 0:09
  Speaker A: Everybody listening to you've been heard. We're talking with Michael Murray today and we're supposed to be talking about scaling it in highly regulated industries without disrupting operations or compliance. Okay, what gets you so excited about it? What do you really love about it? Let's just start with that. I mean, what's like the thing that fires you up most about your role? And then we'll get to something.
• 0:31
  Speaker B: I. I've worked in a lot of industries, right. So yeah, I came out of college, I did civil engineering in Cork in Ireland. Came out of college and worked for a small IT startup, small consultancy, software development. Worked for two absolutely fantastic guys, the founders, Seamus and Teddy, who really gave me a great grounding. Like I was employee number four. And that gave me a huge insight into the sort of stresses and successes from a small IT company. And they're still in business, both still very well respected and successful.
• 1:07
  Speaker A: Please tell me what that was.
• 1:09
  Speaker B: So the name of the company was Client Solutions.
• 1:12
  Speaker A: No, I mean like, what was. So you said it was really like your employee number four. You really got some great insight. Mentoring. What's like the first thing that comes to mind that was like the big learnings.
• 1:22
  Speaker B: The big learnings really understand your problem, right. And understand the solutions that you're offering. Back then it was like Sybase Power Builder was the development language that we used initially. And really getting under the hood and understanding the tools, right. So not just using the tools, but fully understanding how the tool could be leveraged, what it was doing under the hood when you gave it instructions. Um, and I think that sort of stood to me going forward. The other thing was the important. It was a small company. We had great relationships with big banks in Ireland, bank of Ireland, Allied Irish Banks, Ulster bank, as well as folk like Pepsi and Intel. Elan Pharmaceuticals was one of our early customers. And really understanding the sort of trust and relationship basis that these larger organizations were taking by giving work to a small startup at the time and then just understanding that IT is an enabler. Right. The purpose of IT in an organization is to drive success in the company, not just to provide laptops and physical hardware. I think there are a lot of people in IT who are somewhat blinkered, particularly in larger organizations, to deliver their function and they don't tie what they're doing to the greater organization. I think those folks sort of miss out on something in terms of purpose.
• 2:49
  Speaker A: I'm intrigued by the understanding the real problem question because it's so simple and sometimes the most simplest. It sounds simple on the outside. Right, right. But the thing that it does very, very well is complicate the crap out of everything. And even though we're known as the department of no, we're really the department of yes. And trying to do every thousands of projects all at one time. So if there was like a saying in it that I kind of go against which is like, it, this is the department of no. I don't agree with that. I, I think it is the department of being afraid to say no and actually trying to do thousands of projects all at one time and kind of secretly hiding in their corner and trying to do it all. So.
• 3:30
  Speaker B: Right. I, I would say we're the department of why. So I've seen the we should be
• 3:35
  Speaker A: the department of why. That's back to your really good mentoring and from day one. But okay, so talk to me.
• 3:44
  Speaker B: So as the head of IT in three different organizations, we get requests. I probably have a list of 120 project candidates right now, and I need to understand why each of them is important, who it's important to, and whether that sort of elevates itself to be in the top three, four, five, however many concurrent projects we can manage the, the organization as a whole, like, why is this important? And one of the caveats I think is these are all project candidates. They're not projects, we may never do them. And I think understanding and publicizing that just because it's on a list doesn't mean we're ever going to get to it is an important piece of communication that's missed.
• 4:26
  Speaker A: Very, very important. And so how do we get differentiate who gets their AI app approved?
• 4:39
  Speaker B: So for me, it's relatively easy. You get your steer from the CEO CFO as to what the organizational priorities are for the year. And sometimes it's growth, sometimes it's stabilization, sometimes it's automation, sometimes it's revenue, profit, ebitda, whatever.
• 4:57
  Speaker A: You said something very simple. You said something that, that to me, from the way that you said it. Sounds like common sense to you?
• 5:03
  Speaker B: Yeah, I think so. I mean, it's important that it is aligned with the organizational goals. And if you know what they are transparently and they're clearly articulated, then you just sort of apply that scoring rubric to stack of IT projects you have in front of you.
• 5:19
  Speaker A: I'm afraid that you may not give yourself enough credit. But I don't know you yet enough. So I know that if you don't give yourself enough credit, I mean, you're saying this like it's like, well, yeah, of course, you just align Yourself with the C level. But how many IT leaders out there probably have no clue what the actual goals, real problems, challenges of the C suite are, even if they sit this exact same table as them.
• 5:40
  Speaker B: I would suggest then that they're not really IT leaders, right? They're maybe IT managers and delivering IT infrastructure and networking and comms and whatever other tools. But if you start asking why, pretty quickly the conversation changes. I think why is the probably most powerful way to surface underlying desires and priorities.
• 6:07
  Speaker A: I love it.
• 6:08
  Speaker B: Exactly.
• 6:09
  Speaker A: It's like when people are stumped and they don't really know what to do and they get tongue. They get, you know, tongue tied. I just ask why. It's easy, just go why?
• 6:18
  Speaker B: It's the iterative why. It's understanding it gets you down. There's several models, the five whys and the seven whys, but you really get to a root understanding of who's asking for what and why they need it and what they're anticipating out of it. It gives you your success criteria. It gives you your definition of done. It really just gives you so much information.
• 6:41
  Speaker A: That's another deep thought. The definition of done. Oh, I love this. Go talk to me. What's the definition of done?
• 6:49
  Speaker B: So it's very, very easy for an IT function to deliver a marvelous set of tools that nobody wants or have. Understanding the why leads to understanding what the And I hate the minimum viable product. Right? Because you don't want to be delivering.
• 7:06
  Speaker A: Isn't that everything in it?
• 7:08
  Speaker B: No, you don't want to be delivering the minimum product. You want to be delivering. Delivering the value product. Right. Like, of course.
• 7:15
  Speaker A: Why does that happen? Why do we deliver the minimum value? Why does that happen? Because we're checking the box off. Done.
• 7:21
  Speaker B: Well, it's partly checking the box off done. It's partly because it is often financially constrained. Right? We get.
• 7:28
  Speaker A: We're gonna say the. I was gonna say the cost center.
• 7:32
  Speaker B: Right?
• 7:32
  Speaker A: So we get the minimal amount approved for this project. It's done. It's the minimum viable thing. And then we don't do the upgrades, we don't do the bolt ons, we don't do the APIs, we don't do anything. And then they're like, ah, this ERP sucks.
• 7:43
  Speaker B: Right? Whereas if you start with understanding what success looks like from your customer's perspective, ask them, why is this important? I need an API to connect system one to system two. It's like, well, why do you need that? Well, because I don't want to be typing this. How many times a day does IT run? How frequently does it run? What are the data volumes involved? And it's like, well it's cheaper and easier to have a human do it or it's vastly superior to automate understanding why people need stuff and the value behind it.
• 8:21
  Speaker A: Your CFO doesn't want 47 Internet bills. We help IT teams consolidate multi location Internet into parent child billing with coterminous contracts while still buying wholesale from the best providers. It gets control, finance gets clarity. No disruption, no sales pitch. Just go to you've been heard.com and answer the seven questions to simplify, streamline and save. Okay, so we have why then we have the definition of done. But you solved so many people's problems just there after hundreds of episodes. You know how many people we've talked to? I mean we've dealt with issues or people have had problems in the past or if we talk about like nightmare stories from the past when people learning from failing forward and all of that. It sounds like you had a great mentor from day one and you were the fourth employee and you never had to deal with any problems. So that sounds great for you. But for everybody else in the world they learned through failure and trial by fire and all kinds of stuff like that. Whereas if they had just really, really defined for their executive team, got buy in and kind of had like a form that's like this. Once we check all of these things off, we will be done with this project and they create buy in around what that project is, then they might not be dealing with the struggles that they might have to deal with for, I don't know, asking for more money or asking for bolt on products or by the way, this project, like every project is not going to go what people say is in quotes, seamless. Every now and then it does happen and we need to be Ready for a plus or minus 10% contingency factor of XYZ. But at the end of the day, this is what done looks like. I love it. So not the department of. No, the department of why and what does done look like? This is all underneath the bolding of understanding the real problem. If we were to write an I and you said sometimes humans, it's cheaper to use humans or it makes more sense to use humans. Because why would we automate something that's very, very expensive and time intensive to do something that just requires someone to, I don't know, write an email and. And hit send.
• 10:28
  Speaker B: Exactly.
• 10:30
  Speaker A: Can we write a prompt for that? The irony is that if we were to write a prompt, it's about understanding the real problem and knowing what done looks like from like as a point solution or from an it iterative process and thinking process. Cause I'm really into this right now. Right. How would you write that prompt? This is going to be a new section of the show. I love it. So how would you write that prompt?
• 10:55
  Speaker B: I think that understanding that done is perceived by your users or perceived by your project champion. And it's a personal thing. Right. So I would suggest that, and this may be very unpopular opinion, but I would suggest that asking AI, which is largely based on whatever free information was available on the Internet as of about 12 months ago.
• 11:22
  Speaker A: Yeah.
• 11:23
  Speaker B: Do you really want the answer to that question to be provided by sort of theory of Facebook and Reddit?
• 11:31
  Speaker A: No, no, no. I do not want the answers. I'm the exact opposite. So I think we're saying the same thing, just differently. Yeah. I believe that AI should never be used with kind of like the information first. I think we should flip it. It's always about human process or human ingenuity first. And then you use AI to kind of like organize it and just help deliver it.
• 11:50
  Speaker B: Right. But I don't think you can have it scope it.
• 11:53
  Speaker A: But can you have it use your process or a system of questions to help break down or understand a real problem?
• 12:02
  Speaker B: I guess I probably once the problem's defined. But I feel like the definition of the problem, the pain is perceived by humans. Right. And so I think for it to successfully deliver the solution, they need to understand the problem that the humans are feeling. And the humans might be the CEO, the cfo, or it might be head of operations. It might be someone on the loading dock. Right. But I think AI can help frame and deliver the solution, but I don't think it can define the problem and it can't yet at least design the solution. It can certainly help with the automation and the delivery and some of the sort of vibe coding technologies are coming on in leaps and burns almost on a daily basis. But it brings a testing and delivery headache of its own.
• 12:59
  Speaker A: We have a third quote from the show that's it is not the department of no, it's the department of Hard no, it's the department of hard no. Yeah, because I just acted like an ignorant, hey, can we just use AI for that? That's a hard no, Phil. I think I'm going to push back and find a reason here. I'm going to say like, yeah, but can it. Can't AI say first go ask these people and then fill in this information here? And after talking with your end users and then do this as the next step and then do this. I'm trying to find a project that I used it on the other day. It was like for example, taking information from a human iterative process where we're doing maybe a needs assessment or something like that. So you take a doctor, he doesn't need his assessment. Okay. Then you've got to kind of like organize like all kinds of information and data into a process. I'm going to think about it, but let's forget that we're just going to take it as the hard no for now.
• 13:52
  Speaker B: Well, I think if you have a senior leader who comes to you and says, hey, I want you to use AI.
• 13:58
  Speaker A: Oh, I love this. Yep.
• 14:00
  Speaker B: Why?
• 14:01
  Speaker A: That never happens.
• 14:02
  Speaker B: No, but why do you want to use AI? Why do you believe AI is the best solution for this problem that you're facing?
• 14:09
  Speaker A: Yeah, I want to basically use a. This. I'm just going to role play this with you right now.
• 14:13
  Speaker B: Okay.
• 14:14
  Speaker A: Well, I just, I want to use AI to stop my insane life and all this extra work that I'm doing that I'm pretty sure I don't need to be doing for, I don't know, research. I want to use AI for I guess general research and sifting and sorting.
• 14:29
  Speaker B: I think that's one of the few use cases that I've seen AIB use successfully. Right. It absolutely can digest.
• 14:36
  Speaker A: Congratulations.
• 14:38
  Speaker B: But we've moved from I want to use AI as a blanket statement to I want to use AI to take large waves of textual information, do research and, and compress it into a usable answer. And I feel like that's progress.
• 14:53
  Speaker A: Right. Yeah, I want to use. Well, that's one thing that's like the general stuff for all of our users. I want our, all of our entire staff to. I want to have an AI rollout plan so that our entire staff knows how to use AI securely without linking our company data to everywhere in the world, that's probably another thing that would be concern. But if we are a manufacturer, so we have to think more deeply because I think there's people that are thinking we're going to have like agents that replace humans. I don't know if people get that. Do you think people get that request a lot? Can't we use AI to replace a third or staff? Do you think they get that?
• 15:24
  Speaker B: I. I would again go back to why. Right. So I think there will definitely be functions and areas of sort of professional life where AI replaces. I think at the moment it's largely limited to interpreting textual documents.
• 15:44
  Speaker A: But I got a recruiter one this morning that's recruit me. I know it was AI.
• 15:49
  Speaker B: The error rate I think is still sufficiently high that the human sort of supervision is still high. So it's like when we started using steam engines, right, instead of horses. Yeah. The stable boys lost their jobs, but mechanical engineers came to the fore. And I feel like we're on another sort of tipping point of an industry change and maybe we don't quite know where it's going to lead. I think some traditional positions will be eliminated, but there'll be different opportunities.
• 16:22
  Speaker A: You really snuffed me as the make believe CEO by the way, because that's exactly probably what's happening. Why we just need it. I just know everyone else is. I'm worried about it.
• 16:30
  Speaker B: Right. And there is a sort of fear of missing out thing. But I think a degree of caution is required. There's that famous MIT report from a few months ago that 95% of investment in AI returns zero value. Right?
• 16:44
  Speaker A: Yeah, but why I want to know the 5% that did. Were they actually using. Were they actually using agentic agents in AI or was it more like she said, the tips like the. The point solutions or was it more the point solutions and everything?
• 16:57
  Speaker B: 70% of the 5%, from my reading of it, at least 70% of the 5% got their successes by leveraging AI tools within their existing vendor stack. Right?
• 17:09
  Speaker A: Yeah, that's exactly. Okay, so isn't it amazing how many people read that article? What's more amazing to me is every single like who wrote that article? Is it just because MIT stamped it? Like everyone's quoting that article, everyone's rewriting that article.
• 17:28
  Speaker B: Yeah, I mean PwC published one a couple of weeks ago that isn't getting near as much sort of media traction. And that one was slightly more optimistic. I think the MIT one, it was very timely and I think a lot of people sort of latched on to it as a crutch almost. Right. This supports my belief that agentic AI or AI generally is potentially a bubble. And so people latched onto it as kind of. This supports my theory that AI maybe isn't as mature and as worthy of investment in my time as Gartner said.
• 18:02
  Speaker A: They're in Gartner magic Quadrant. They're in Frost Asia then. So why should I question that even though they paid them a bunch of money to be somewhere and if I didn't pay, I'm not in the quadrant. Not saying that Gartner has its place. It really does. I mean I don't think people are going to argue Sentinel 1 In Gartner, Magic Quadrant or Microsoft.
• 18:21
  Speaker B: Well, Europeans might argue both of those these days, but I think that's another interesting conversation.
• 18:29
  Speaker A: Well, it actually is because the. Why does the majority of the world or maybe a dozen, this is very, very typical Westerner kind of self centered point of view. Why does the rest of the world kind of revolve around the United States Technology stack and what would the option be? Google. What is Europe use? Lotus Notes. What are we doing?
• 18:51
  Speaker B: Yeah, not since, I mean I have used Lotus Notes but not recently. No. It's interesting. I think everybody, as far as I'm aware, at least everyone in Europe is still largely using Microsoft products. They're using Zoom, they're using Teams, they're using Outlook. But there is certainly a degree of caution being expressed about the dependency on us, right? I think it's safe to say that the dependency exists, but I think it was the French government announced recently that there was always the French. It is still from the French. Yeah, they certainly do know how to strike but I think they've said that they're going to for example eliminate Zoom was the one I read, I think over the last couple of days.
• 19:35
  Speaker A: Why
• 19:38
  Speaker B: that's it's a perceived external dependency. Conversational, much more deep value as conversation, right?
• 19:43
  Speaker A: Yeah, yeah. Really. I mean what other simple quotes and mantras or, or things that you have that you go by? I think what the definition of done is, it's already gonna make a big impact on my team and meetings tomorrow so get ready for it guys.
• 19:58
  Speaker B: So I mean I think one of the things that I hadn't anticipated when I moved to Boston was just what a hub of innovation it was in terms of process design and thinking. So there's a Agile and Scrum, like the Agile Manifesto. Ken Schwaber and Jeff Sutherland built up Scrum. Those two, I guess thought leaders. And having been aware of Agile and Scrum and Kanban and Lean and various other sort of philosophies, I guess it was amazing to have an opportunity to basically meet them. Right. So that was one big benefit I think of moving to Boston that I hadn't anticipated. And that's where my exposure to definition of done comes from. I think other than that there's a degree of just do it. Like there are situations where you could sit around and spend six months discussing or reading the manuals or you could just throw the CD in and showing my age now, but throw the CD and hit next next next and see what happens. Right. The server, whatever it is you're configuring, the service comes up and you realize that, oh, actually on the third next, I should have selected something different. You go back and you start again. Right.
• 21:20
  Speaker A: And you figure out things as you go, but that you've learned.
• 21:23
  Speaker B: Figure out as you go. And you know what? It's not perfect, but perfection is the enemy of progress. Right?
• 21:28
  Speaker A: Um, yeah. Done is better than perfect. That. That's. Yeah. And just the act of doing sometimes is really what creates so much learning or aha. Moments.
• 21:41
  Speaker B: Right? Exactly. It gives you the knowledge and it. It gives you the understanding of these sort of alternate paths as well. Right. This is how it's configured and this is why. Right.
• 21:50
  Speaker A: He. Cybersecurity as a business enabler. Want to talk about it? I. I've kind of caught the cybersecurity bug lately. I. I've. For years, cybersecurity for me has been kind of this, like, depressing entity where you can only fail, meaning it's just a matter of when. And I didn't quite really hit me until recently because I just feel like it's like, how do you measure success in cybersecurity? By never having an incident.
• 22:19
  Speaker B: Oh, interesting.
• 22:22
  Speaker A: No, but that's how I thought about it for years. I thought about the CISO as this job that's like. Like, I literally, like, I was thinking about it the other day, like, how do we measure your. I woke up and my sleep score was really, really bad, and I've got seven hours of sleep debt. I wear an OURA ring, or OURA ring is the best. Right. So. And it just dawned on me, like, all of a sudden, I was like, oh, what's your cybersecurity sleep score? Like, I'm going to do that. I want to know what everyone's cybersecurity sleep score is. But just that idea of that me was I used to think, well, the CISO job is just so unforgiving. It's like, when do they ever get a pat on the back? And just like, hey, thanks for not getting. Allowing any ransomware attached this month. And I just had a paradigm shift the last couple weeks, and it came from having to evaluate like a dozen MSSPs.
• 23:17
  Speaker B: Right?
• 23:18
  Speaker A: And when I started looking at the difference in abilities to not only just alert someone of a cyber event, but actually remediate it. Right. I started to realize that there's a lot of people that just love to talk security and love to map out security and love to say that, well, here's all your holes and you guys are really bad. But when push comes to shove, it's like, well, I mean, we'll alert you,
• 23:50
  Speaker B: but then you're on your own. Yeah.
• 23:53
  Speaker A: You know what I mean? It was like. And I, and I was like, just amazed at how many people showed up to the table, so to speak, looking really, really well, shining up really, really well. But then at the end of the day when you kind of get down into the nitty gritty and lurk and look at fine print and stuff, you're like, oh wow, you're not doing really anything.
• 24:18
  Speaker B: Right? So, I mean, cyber security is really interesting.
• 24:22
  Speaker A: So I got the bug. But long story short, but yeah, I
• 24:25
  Speaker B: kind of got into it a few years ago, so I did CISSP and ccsp. And to me it goes back to risk. Right. And why? Right? So as the IT leader, your responsibility is to protect the organization. And the way you protect the organization is by balancing investment in IT security and investment in systems against the threat and the risk of loss. Right. It's a trade off. And it's interesting because just last week I was having a conversation around the fact that my goals for 2026 don't include having zero cybersecurity events. Because while that is a simple aspirational goal, it's shockingly expensive. Right. And that's not necessarily in the best interest of most organizations. Most organizations, the balance of value ensures a focus on recovery as much as prevention. Right. Every audit you've ever sat through there, where are your controls? Where are your preventative controls, your detective controls, your remediative controls? And so I feel it's the same in cybersecurity. I feel it's the same in everything that it does. Right. You don't want to build a five nines network and a five nines data infrastructure if you have an organization that can function perfectly adequately with two nines or three nines. And so to me, cybersecurity sits in the same boat. Right? It's. Why do we want, like, what's the goal? The goal is to protect the organization and to deliver value to the organization.
• 26:05
  Speaker A: Okay.
• 26:05
  Speaker B: Everyone is focusing on the preventative controls. And it's easy to pass an order, it's easy to say everything's encrypted and everything's protected and we have the firewall and we have. The bottom of our list is denial. But if you get a capable pen tester and they've always been able to breach a network within minutes.
• 26:33
  Speaker A: In what way?
• 26:35
  Speaker B: Mostly minutes. Minutes. Yeah, minutes. So I feel like the greatest value in pen testing or in cybersecurity testing is starting on a kind of gray box. Right. I think you should start from the assumption that your users have terrible passwords.
• 26:56
  Speaker A: Yeah. You should start with the we're absolutely screwed.
• 26:59
  Speaker B: Right. Credential stuffing is a real thing. Everyone's sharing credentials, everyone's reusing credentials. So start from the assumption that your base users are compromised and then try and protect against elevation of privilege attacks.
• 27:14
  Speaker A: Just out of curiosity, how are the pen testers getting in? I mean, was it like, oh, we've got this off the dark web? We already know this, we already know that. Is it like a bunch of just similar tools and it's like, ah, this is just easy.
• 27:24
  Speaker B: So for the highest value I've gained from pen testers has always been this sort of like gray box. So we give them a base account, a standard user account, and within minutes they've managed to elevate that to a domain admin account. Yeah, fantastic.
• 27:44
  Speaker A: I mean, I had a statistic today that 65% of. It's like 65 or 64, whatever it is, it's. It's between 60 and 70% of all hospitals or healthcare industry experienced a ransomware attack in 2020. Do you believe that?
• 27:57
  Speaker B: 60%.
• 27:57
  Speaker A: Oh, not ransomware. A security breach. Sorry, Security breach.
• 28:01
  Speaker B: Right.
• 28:02
  Speaker A: That's high.
• 28:03
  Speaker B: That's very high.
• 28:05
  Speaker A: It's believable because hospitals are just such big entities with so many holes and really, really old infrastructure. I would imagine there's something everywhere for everyone. There's something for everyone.
• 28:14
  Speaker B: Such diversity of devices as. Well. Right. They probably have stuff that's still running old. 2.4 GHz Wi Fi protocols and all kinds of stuff.
• 28:23
  Speaker A: 10, 100 switches. Seen it. The same argument can be made for AI as well. On the opposite end is like, well, we don't really care that it's failing miserably as long as it's working 60% of the time. It's a win for us if we're making money on it.
• 28:39
  Speaker B: Yeah. I think one of the things that's interesting, if you say AI has a 10% hallucination rate or even a 5% hallucination rate once you start tying sequential steps together. Right. So let's say you have some sort of an agentic process that takes a customer's call, converts it to text, puts the text into a text field, adds it to a database, does some manipulation. If it has a 90% success rate on each iteration. Right. If there are six steps, you're down to probably 30% success. Right. I don't know what 09 to the power of six is off the top of my head, but it's going to be less than 50%. Right. And so your hallucination rate grows very, very rapidly as you add complexity. And I think people underestimate that, Tim.
• 29:33
  Speaker A: For sure.
• 29:34
  Speaker B: Round two, maybe.
• 29:35
  Speaker A: I don't know, ring her up, do an automated phone call, something like that. So finish this and match. We can finish this anytime and match this together as well. There's no problem. We edit things. But real quick under pressure. You've only got three minutes anyways because you got to go to another meeting. How do you make a decision under risk, under pressure? Accountability.
• 29:52
  Speaker B: Accountability. So one of the sort of eye opening books I've read I think is Daniel Pink's Drive. There's a fantastic summary of it on, on YouTube by RSA. Animated talks about autonomy, mastery and purpose. And one of the things I've always tried to do in the IT teams that I'm leading is trust people to do their jobs with the information they have available to them at the time. So empower people to make decisions. That's why you gave them the position in the first place. Support their decisions after the event and commit to supporting their decisions. And that way you get people who are free to make mistakes without fear of repercussion. They'll react quickly and responsibly to events that are in front of them.
• 30:39
  Speaker A: Yep.
• 30:40
  Speaker B: And I think that's how you, that's how you build successful teams.
• 30:43
  Speaker A: Autonomy, mastery and purpose. It was a great last sound bite. Just one little quick follow up. We've got one minute. What about when you give them all that trust and everything and they do it their way and it's awesome and everything, but it's gotta be tweaked. Is that okay? Or do you support them the way that it was? Or we needed to make the changes or how do we reiterate as we make these changes?
• 31:03
  Speaker B: You can always improve. Right. You can always iterate. But there's a way of doing it without sort of apportioning blame or coming down heavy handedly. Right. So if you trust someone to do the job, often it's because the requirements weren't specified correctly or the why wasn't clear or the definition of done wasn't clear. Right. So if they completed the task, why do you need to modify it in the future? Do you really need to modify it in the future? And if so, let's make progress. Goes by perfection. Perfection is the enemy of progress. As well. Right.
• 31:36
  Speaker A: Understanding the real problem, the definition of done, and getting busy doing work. Those are like your three things to Recipe for Success. Michael Murray, you've been heard. Thank you very much for being on the show today. It's been a pleasure and very eye openening for me.