Dave Burrill - Mastering IT communication

Today we'll be talking about the importance of good communication in IT projects and how to master IT communication. Dave, welcome to the show. It's great to have you with us today. Anything to add here?

Dave Burrill: No, not much, Tim, but you know, thanks for having me. It's a, I'm already sure we're going to enjoy this conversation.

Tim Butara: Yep. Yep. Likewise. And to start things off, to kind of set the stage, what is the role of communication in an IT project?

Dave Burrill: Pretty much everything. God, where do we begin on this whole thing? All right, well, you know, let's sort of set the stage, the importance of it, right? Without going through all of the reference sources, just kind of high level.

And let's just talk about big projects like those over a million dollars, over a million euros, right? So the failure rate for tech projects that are over a million bucks. The smoking crater rate is one out of three. So one out of three is just a complete disaster. You need to write it off and start all over again.

Almost two out of three have some material level of they're way over budget, way behind schedule, they're way under delivered. what they're supposed to. It's about one in 20 that are genuine successes. There's a guy named Bent Flyvbjerg out of Oxford. He's a professor at Oxford University. And he's one of the leading experts in the world on large projects.

And he doesn't specialize in technology stuff, but in projects overall, he's been retained by McKinsey to do a lot of research. And he found that if the project's over a million bucks, the odds of it going so badly it threatens to bankrupt the business are one in six. So the stakes are huge. So that's like playing Russian roulette with the life of your organization when you undertake, you know, a technology project.

Okay, so all of those failures, 75 percent of all those failures are directly related to non communication. It's all the stuff that the business forgets to tell the tech team. It's all the questions the tech team forgets to ask the business. And it's all the assumptions that they both make, but nobody ever thinks to confirm.

Right? So, non communication is responsible for 75 percent of all those failures. And the good news, in the U. S. it hardly costs anything at all, it's only like 1. 4 trillion dollars a year directly attributable to non communication issues. 1. 4 trillion a year being flushed down the toilet because we can't talk to each other.

So, at a high level, that's why I say it's almost everything. It's the ballgame. It's the biggest issue out there. It's bigger than all other issues combined. Let's put it that way. And I think one of the problems we get into is that words have meaning and we fail to realize that. So we call them it projects, but.

They're never IT projects and we, we all fall into it and I'm undoubtedly going to call them IT projects during this podcast, but it's a business project that just happens to be enabled by technology. And the second we lose sight of that, a couple of really negative things start to happen. Like the first one is we think we're dealing with a technology solution.

We're not, we're dealing with a business solution. So we're looking in the wrong place. The second horrible thing that happens is that the business people automatically wash their hands of it and say, hey, this isn't my responsibility. It's the it departments. So the only people that can tell the project team, the stuff that they need to know are the business people who understand the business, and they're the ones that have just mentally checked out and walked through the door and have said, it's an IT project.

I'm going to do the least amount of work I can possibly get away with. So that sets you up for failure right off the bat. The more, I don't know about the more, but certainly. Yeah. Equally problematic is it puts the IT department in a position of having to make decisions that they're not qualified to make.

They don't know the business. And since it's always a business process that it's, that is at the heart of the project or multiple business processes, if you've got the blind person that's trying to engineer that process, it's a recipe for disaster. So, it's kind of a roundabout way of answering the question, but it's, communications is the ballgame.

Yeah, I mean, even if you just take everything else away, it's at least 75 percent of, of such a project there. And yeah, they're a very good point about, you know, basically we treat it as business being a subset of IT in these projects, but it's actually, you know, IT is just one of the ways of achieving the business goals of realizing the project.

It might be a really important one, but it's still, you know subordinate to the business aspect.

And it's getting more important all the time. I mean, You know, whatever business you were in 10 years ago, today, you're also in the technology business, right? So even contractors, musicians, to pick up on a theme that we were on earlier, we're all using technology for everything.

And we've got to understand how technology plays in the delivery of that service or the product. So there are definitely a lot of negative consequences of poor communication on these projects.

Absolutely. I mean, yeah, absolutely. Not only the failure rates, but I mean, if you think about it, it's also the kind of collateral damage that happens on humanity, on the people that are working these projects.

Right. And I think that's kind of a, an under discussed problem. And what I mean by that is generally the way that these issues unfold is the very first thing that happens in a project. is the tech team wants to talk to the subject matter expert, right? Because the SME is the oracle. They are, you know, they're the god of the process.

They know everything there is to know and the SME will, everybody assumes, be able to tell them everything, be able to tell a tech team everything they need to know about the process. So they sit down for an interview and they ask the SME a couple of questions and the SME gives them the basic outlines of what they do and what the process is all about.

But it seems too good to be true because it's so simple and you're smiling because you already know exactly where I'm going with this. Right. So the tech team is like, really, that's it. That's all there is to it. Yeah, that's pretty easy. Okay. Well, then they go away and they develop what they think they're supposed to develop and they come back a month later, all proud of themselves because they've got this great thing that was piece of cake and they over delivered everything that they were supposed to do.

And the business looks at it and goes. What the hell is this? It doesn't do this. It doesn't do this. It doesn't do this. It doesn't do this. These are all these things that it's supposed to do that it doesn't. And the tech team looks at them incredulously, like, Wait a minute, you didn't tell us about any of that stuff.

And the response is usually, well, you should have known. Like, how am I supposed to know? I'm not clairvoyant. I can't read your mind. Right? So then this finger pointing starts. And the business says these guys are incompetent. They don't know what they're doing. And the technology team says these guys are incompetent.

They don't know their own business, right? And you get into this death spiral and people do more of the same. They just keep pointing fingers at themselves. And what. It sort of took a long time for me to realize what was actually happening is the problem, like I said, starts with the business. They don't tell, they don't share all the information they need to share, but nobody realizes that because the tech team doesn't know what questions they need to ask.

So they go off and build this thing and when they deliver their solution, quote unquote, that's the first time that anybody's aware of a failure or anybody's aware of a deficiency. Okay. And it's in that moment that all of a sudden The wagon load of manure gets dumped on the head. And I'm trying to be polite in the way that I described this, but right.

The dump truck full of dung gets dropped on the head of the tech team, because they're the idiots that screwed this up when they're just the poor guy that discovered the problem in the first place, right? So they have to work thousands of hours, long nights, 24 hours straight, trying to solve a problem, trying to fix something, trying to get a system operational.

When it wasn't their fault that the thing went south in the first place. But since they can't identify what really happened, there's no way to fix it.

Tim Butara: So what can we do about it? I mean, what does good communication look like? What are the elements of good communication that would prevent these kinds of failures from happening in these kinds of circumstances?

Dave Burrill: So I think that there's actually probably four elements of it. First of all, it's which is what we started the conversation. It's making people aware of the magnitude of the failures. And how frequently that they happen. The second thing that we need to become aware of, and this is something that neuroscience has only discovered in the last 20 years, our brains do not work the way we thought they worked.

When we were all young in school, we were taught things like, your brain is fixed at birth. You, you were born with all the neurons you're ever going to get. And if something happens to them, they're lost forever, right? You can't repeat, your brain can't repair itself. It can't change itself. So it's only downhill from the moment you're born.

That's not true at all. Our brain continuously reconfigures itself over the course of our entire lives. The other thing that we didn't realize from a neuroscience perspective is that We thought we perceived our reality exactly as it is. We don't. We manufacture our reality, which is something that we've only recently become very aware of.

Our brain is a pattern recognition engine that acts as a giant filter. So we each construct our reality based upon all of our prior experiences. So you're seeing something different right now than I am, but we both think we're seeing the same thing. But it's a little bit off. The other thing that we don't realize is how easily we're manipulated by forces outside of our control.

Like, there's a really famous experiment that I've always thought was hysterical. That if you get a room of a hundred people, you divide them in half and you put them in two separate rooms. And you say, I want you guys to think of a number between one hundred and 200. Then to the other group, you say, I want you to think of a number between 1 and 10.

Then you bring them all back together and you say, okay, guys, tell me how many countries there are in Africa. The group that you said, think of a number between 1 and 10 will come up with a number significantly smaller than the group that you said picking up between 100 and 200. And these sorts of things are proven.

So things that had, you wouldn't have thought it had anything, one had anything to do with the other, but it does. There's a bunch of experiments that have been done on your feelings toward people and what your state of mind is like when you encounter them. They found that if you're drinking a hot cup of coffee when you meet somebody, versus holding a nice cold Coke, you will later judge that person to be warmer and friendlier.

Wow. If you are sitting in an easy chair versus sitting on a hard steel seat, you will judge that person to be warmer and friendlier and easier to get along with. And less combative. The psychologists actually call us the iron ass effect or the hard ass effect. I'm not making this up. I mean, these are the sorts of things that impact us all the time.

And we have never had any idea those influences are happening. The other deal that we fail to realize is that we remember everything as a story. So when the subject matter expert comes up and communicates that very short little story about the process, what we haven't realized is that we summarize all information as these terribly short little stories in our head.

And from an evolutionary perspective, that worked just great! Because a hundred thousand years ago on the savannah, the only thing you needed to know is that there was a tiger in the bush, it was close, it would kill you, run. Right. Like five nuggets of information or four tiger close danger run. That's all they handle 150 years ago.

The only thing you needed to handle the most sophisticated story you had to deal with was hooking the horse up to the cart. Right. And now you've got to worry about putting in place a new ERP system. I mean, the amount of detail that's associated with that just exploded. So that's the other thing. In these stories, the only thing that matters is the big picture.

You don't care how many whiskers the tiger had. You don't care how much they weighed. You don't care what color the tail was. These are all the sorts of details that are critical in a IT program. There, I did it. In a technology enabled business, right? So, There's all these factors and influences, but perhaps the most damaging, and I'm still on the second set, so sorry for the long winded nature of this, but the most damaging is there's a paradox of expertise.

And what happens, and we've only become aware of this in about the last 15 years, the more of an expert we become, the more detail we internalize and the more information we forget. So the more of an expert we are, the more we internalize and the more we forget. What winds up happening is the human brain is a computer that runs on power processing and storage, like a computer, right?

Those three resources are always terribly limited. So what winds up happening is when you start learning a new skill, you're learning a new business process. All of the processing happens right up here in your prefrontal cortex, right behind the top of your forehead. You're sucking up a lot of power processing storage when you do that.

So we've also got what amounts to kind of a ghost in the machine of our brain or an operating system. It realizes that we're using up a lot of power processing storage. So it's, and it also realizes that we're doing something a lot. So it starts moving. The processing of that from the most high level human part of our brain, the prefrontal cortex, down to the lowest, lowest levels of our brain, the basal ganglia and the cerebellum, the, the lizard brain.

And it lays down these dedicated neural circuits, these almost like a system on a chip. that allows us to an expert to do things automatically. Now that's great because an expert can do something 3000 times faster than a layman and they can do it without thinking about it. But the downside is that ghost in your machine, after it's moved the processing from the conscious to the unconscious mind, it goes back and it flushes your RAM cache, wipes out all of the short term memory of all of the things you used to know.

So the more of an expert that somebody is, The least able they are to tell you what they know, they can't even explain it to themselves. So we've been going into these projects with a completely false set of assumptions that the people can tell us what they everything that they know they can't. So I think that's probably issue number two.

Issue number three, and we touched on this at the beginning of this conversation, is the idea that certain words have meaning, and those words are powerful. When we call it an IT project, it's a misnomer, but it's set the stage for disaster, like the priming effect when I talked about how many countries there are in Africa.

Right. Or what type of seat you're sitting on. If you call it an IT project, they start thinking one way versus it's a business project that's enabled by technology. They think of it another. So with all of that said, you've kind of got three groups of things that we've been completely oblivious to. We haven't known about at all.

It's only in the last 10, 15, 20 years that we've had a clue that this stuff is happening. So, and there is a solution to it, but it's one that we never think about. So the way to get an expert to remember something is to ask them questions. We store all information, humans store all information as mental models.

Think of it like a hologram in your head. And the way to make you move around your mental model is to ask, is to ask you a question about it. So you go from one place in the model to another. That movement equals thought. That's what happens when you're thinking. You're moving around your mental model.

The other irony to this is that thinking and movement equates to awareness. So there's another little trick that we've learned recently is that if something isn't moving, we don't pay attention to it. You think it's safe. You're not worried about the threat that's stationary. Even though it might kill you, right?

Because it's not moving, it can't be a threat. So attention is a limited resource and we only focus on the things that are moving. So I'm saying all of this as a preamble, and I'm sorry I'm packing about 50 pounds of stuff into a five pound bag. I realize that, sorry. The way to get the experts moving, and the way to draw them out, is to ask them questions about the process.

We've got to start using more in the lines of checklist, but a very specific types of checklist checklist that says, don't do this, then do this checklist that say, ask this question. Then ask this question and lead them through it. And there's a structure that we can use that's available to everybody and it's available right now, but we don't even think about it.

So let me back up for a second. We tend to think of execution as business execution is linear, right? You move a ball from point A to point B, whatever that ball is, to try and generate profit or try and generate some value. That's only a quarter of the story. Business execution isn't linear. It's a cycle.

And that cycle is the same for every organization out there. The cycle has two halves. Which happened to correspond to the only two types of software that are out there. And this is something else that we don't think about. There's only two types of software. You either automate the execution of a process or you report on the performance of one.

And that's it. Right? So in the first half of the cycle, you're automating execution. The second half, you're evaluating performance. In each of those halves, You've got two other halves, so you've got four quarters of the cycle, and the quarters are staffed by the only four types of work role that there exists in any business.

So you've got workers that do the work, which is what we tend to think of execution as being. But then you've got managers that supervise, schedule, coordinate, train the workers, and manage the work. The data that comes out of that first half of the cycle gets flipped over to analysts, who assess the information to try and figure out what it all means.

They give their reports to executives, who look at it and refine the process going forward. So you've got workers, managers, analysts, executives, and that cycle just keeps repeating. So as you continuously refine your business, you're still going through those four stages. Microsoft You can use those stages as a checklist for asking questions.

So, okay, worker, tell me about what you're trying to do, and why are you trying to do it? Now break it down a little bit for me. What are the interim steps in that process? Right, what did you, what are the, what are the workstations you have to go through to get to the end? And then the third question you have for the workers is, what's success look like?

What are the success criteria, right? So how do you know that what you delivered at each interim step is good enough to move to the next? And how do you know that your final product is good enough? So when you've asked those questions of the worker, then you go to the manager and you say, okay, tell me who's going to do the work.

Where's the work going to happen and how are you going to organize it? I mean, fundamentally, these are the big themes that each of these roles deal with. When the data comes out of that first half of the cycle, it goes to the analyst, and the analyst has got three more jobs. The first is to say, out of that process, what's most important?

What do we need to really key off on to be sure that the process is performing properly, and the business is going to succeed. So when you've come up with what's important, then you ask the next question. What questions you need to ask and answer about that, those important priorities, to know whether or not you're doing okay.

And then the final piece is, what data and metrics do you need to answer those questions? At the end of that, you flip all the results to the executives, and the only thing an executive ever cares about is what's okay, what's not okay, who's involved in each bucket, and how much does it cost. And if you ask those 12 sets of questions, you will be able to unpack any business process out there.

And you will have forced the subject matter expert to think about it in ways that they never would have thought about it otherwise. There's a really famous picture of Buzz Aldrin on the moon where he's got his arm cocked up at a weird, his left arms cocked up at a weird angle. Have you ever seen it?

You know the one I'm talking about? I've probably seen it. I've definitely seen it, but I can't remember it right now. Well, so it's just, it was taken obviously during Apollo 11. So, a little background. Buzz Aldrin is a PhD from MIT. You know, one of the best. universities in the United States. He was the guy that figured out how to rendezvous in space.

So he was the one, his nickname was Dr. Rendezvous. The reason that he was not the first man on the moon is that the NASA administrators thought he was so smart, he was a little bit too odd. He couldn't, he couldn't communicate with the common man.

Tim Butara: Oh, okay. Yeah, yeah, yeah.

Dave Burrill: So they picked the farm boy from Ohio who had the, you know, every man ah shucks mentality that could relate to anybody.

So Neil Armstrong became the first man on the moon because Buzz Aldrin was basically too smart. So in this incredibly famous picture where Buzz Aldrin's got his left arm cocked up at a weird angle, he's looking at his checklist. This is a guy that's one of the smartest guys on the planet. And he's looking at his checklist because he can't remember everything.

So if a guy like that needs a checklist to be sure that he doesn't screw up, what does that say about the rest of us mere mortals?

Tim Butara: Well, but I'd say that it's exactly because he is so smart that he knows that he needs the checklist.

Dave Burrill: Precisely. That's exactly it. I mean, really smart people acknowledge their limitations and work around them.

And I guess that's what I'm advocating that we do.

Tim Butara: So yeah, I was just going to ask. So this is, this is one of the key things that we can do to improve our communication skills. So it's, it's all about questions, all about knowing how to ask questions, basically.

Dave Burrill: Exactly, exactly. And that's what bridging business and IT does.

I mean, these are the things that we've been working on for researching and kind of talking about for the last, you know, three, four years now.

Tim Butara: You know, one thing that came to mind earlier was I'm wondering if there are any peculiarities, any specific differences between a situation where, where the IT is in house to the company and where the IT team is outsourced or is like an outside partner?

Dave Burrill: I think it becomes a little bit more difficult when it's IT is outside, only because they're lagging sort of the situational awareness of what goes on within the organization. But the problem is the same for the IT department as it is for the vendors.

My son's head of sales for a software startup in Silicon Valley, and he's done it a couple times now, and one of the biggest epiphanies for him was realizing, wait a minute, you mean the internal IT department has as much trouble understanding what the business needs to do as the external vendors do? I said, yeah, that's a dirty little secret that nobody understands.

They're every bit as challenged as the external vendor is.

Tim Butara: Do you have any interesting real life examples of how communication has really affected the success of a digital project? So like concrete examples.

Dave Burrill: I've got a couple and I feel like I share them too often, but you know, they're so good and they're so priceless and they're so burned into my mind that.

Tim Butara: That's why you share them so often.

Dave Burrill: Yeah, that's why I share them so often. There was this, yeah, I'm not going to name names because I'm not, you know, I don't want to embarrass anybody, right? But there was a CEO of a very large multi billion dollar banking operation about 10 years ago that had been introduced to me by a mutual friend because they had a reporting project, a data warehouse and reporting project that had been going on for about 18 months and they'd spent 2 million and they had absolutely nothing to show for it.

Nothing just, and these guys were following an agile development model, which meant according to them, these guys had no idea what agile meant, other than we're going to throw stuff against the wall and see what sticks. It was horrible. They had no training. They were just going to make it up as they went along, which is why they were 18 months in and 2 million flushed and had nothing to show for it.

So this guy was, working in Dallas, but he, he lives by me in Southern California. So we actually got together for lunch one Friday and he kind of told me about the story. And I said, well, let me just ask you some questions to understand what's going on. Let me try and get my brain around what's happening.

And my first question to him was, did you guys figure out the business questions you were trying to answer? And he looked at me with the condescending stare of disapproval that only a very high priced CEO can muster. That basically said, that's the stupidest question I've ever been asked in my entire life.

What's wrong with you? And he actually said, no one in my entire career, I've never been asked that question before. Like, why are you asking that? And just very much looking down his nose at me. And I said, well, this is a reporting exercise, right? He said, yeah. I said, well, the only reason to write a report is to answer a business question.

If you don't have a question to answer, don't waste your time writing the report. And really don't waste the time of your people to review the report that you don't need. Oh, I never thought of it that way. So, okay. Did you guys ever figure out the processes you were trying to evaluate? No, what do you mean?

And I went back to the line I've already used. I said, look, you know, this, this is pretty simple. It's about moving a ball from point A to point B to create value. If you don't understand what the journey of that process looks like, how are you going to evaluate the stages along it? How are you going to evaluate the process?

Oh, no, I never thought of it. I said, well, where did you guys start? He said, well, the two PhD economists that are running this project, the Agile enthusiast, who knew nothing about Agile, said, we need to, the first thing we need to do is get all the data for the entire organization cleaned up and put in one spot.

I said, no, you need all the data that you need to answer those critical questions cleaned up and put in one spot. Everything else is a waste of time. If you don't have a question to answer, don't get the data. Don't kill yourself to get the data. I said, so you probably didn't collect the, you didn't identify the data or metrics that you wanted to look at.

No, what do you mean? Like, okay, look, in any business process, there's really fundamentally only three types of metric. How much, how fast, and how efficiently did you move the ball from point A to point B? Think about any business process as a pipe. Stuff goes in, in the beginning, you have some crank in the middle of it where you do some work and something comes out the end.

Right. So you got input, you get output, you do something in the middle. Now, if you think about that metaphor, there's about seven objective empirical measures that you can use to evaluate any business process, and hence any project that automates the business process. So he's looking at me like, I've never heard any of this before.

I said, yeah, sure. I'm not surprised. So like, let's talk about inputs. How much had to go in? How much goes into the process? How fast do you transit the process? How long does it take you to get through it, right? How much comes out the back end? How good was the stuff that came out the back end? Is it no good anymore or is it better than it was?

How much did it cost to move it from A to B? Did you, how much profit did you generate going from A to B? And the last one is, Were your customers more or less satisfied? Did you guys get any of that baseline data? Did you ever look at any of this? Like, no, no, no, no, no, no, no. I mean, and this conversation went on for an hour and a half.

So I'm going to cut it off now, just not to drive you through an hour and a half. But after listening to this for all this time, I finally said, and this is where I'm just a little petty and I'll admit to being slightly vindictive and, and I'm not, I'm not proud. I'm ashamed of it, but I'm just confessing.

So I looked at the guy and said, okay, so let me get this straight. You guys fired a 2 million cruise missile. Nobody ever bothered to define the target. And now you're wondering why you didn't hit it? And he kind of sheepishly looks at me and goes, well, yeah, when you put it that way, that's exactly what we did.

So that's a really good illustration of the business never told a tech team what it was they were trying to do. They didn't know where they were trying to get to. They didn't know what they were trying to hit. And I think that's the single biggest flaw that we overlook. The, this magical thinking that technology is going to solve all your problems.

It won't. It's just a tool, right? You and I are both guitar players. We can have great guitars, but you know what? They don't play themselves. Right? A guitar doesn't play themself. You have to be able to do something with it. Right? That's the human. And if everybody thinks AI is going to save you, I got bad news for you.

It's not. AI is only as good as the detail that you feed it to work off of. If you can't tell AI what you need it to do, it can't do it. Does that kind of answer the question?

Tim Butara: Well, yeah, that was a great example and actually a great note to finish on. So yeah, Dave, this was a fantastic conversation. I think that I got a lot from it basically with this last example, basically not only did you show how poor communication has affected a project, but you also, you've also shown how your good questioning then affected it differently, you know, affected the mindset of the person that you were talking with in a positive way. And probably, I'm guessing that probably their future endeavors were more successful because of your conversation.

Dave Burrill: He asked me immediately to come to their offices and about four days later we had the problem fixed.

Tim Butara: Yeah, exactly what I was thinking, exactly what I said.

Dave Burrill: It's not rocket science. It's just basics. And if you understand the basics, you can go a long way. But I think what's sad is we're not teaching the basics. Which is really disconcerting. But anyway, that's for another conversation.

Tim Butara: But just a caveat here, this all holds true even for rocket science.

Dave Burrill: It does. Yeah, it absolutely does. Well, yeah, I mean, that's, I mean, that's a really good point. You know, the that picture that was signed out with Buzz Aldrin on the moon, that checklist was the culmination of half a million other checklists that had been put together over the prior eight years. which is pretty wild.

I mean, they did everything by the checklist. There's a great book called The Checklist Manifesto by Atul Gawande. Have you ever heard of it? Nope. He's a surgeon. He's a thoracic surgeon at Harvard. And the guy who's writing the book about how checklists can be used in medicine, in surgeries. And he gives multiple illustrations about aviation and construction and where checklists are used in all these places.

And the very long story short is that just by putting a checklist in place, cuts your air rate by about half immediately. Doing nothing else but just using a checklist to be sure you don't forget the stupid stuff.

Tim Butara: Dave, this was such a great conversation. As I said, I think I took a lot from it. So there were a lot of things that seemed mind blowing, but, but actually are just, just straightforward and just logical.

You just have to think of, to think about them in the right way. So if anybody listening right now would maybe like to learn even more from you or connect with you or reach out to you, what's the best way to do that?

Dave Burrill: Well, go to the website or contact me directly. So the website is bridgingbusinessit. com.

If anybody wants to watch a video about that execution life cycle that I was talking about, go to the top of the solution page and there's a video there that says how do you bridge business and IT and a little two minute deal and explains what that life cycle is all about. If you wanted to contact me directly, it's just dave at bridgingbusinessit.

com. And I'd love to hear from you.

Tim Butara: Awesome. I hope the listeners take you up on your offer. We'll put everything in the show notes for easy access. And Dave, thank you again. This has been awesome.

Dave Burrill: Oh, thank you, Tim. This has been a blast.

Tim Butara: And to our listeners, that's all for this episode. Have a great day, everyone.

Outro:
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agiledrop.com/podcast, as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes. And don't forget to share the podcast with your friends and colleagues.