Technology business decisions

Welcome to Definitely May Be Agile, the podcast where Peter Maddison and Dave Sharrock discuss the complexities of adopting new ways of working at scale. Hello, and welcome to another exciting episode of Definitely May Be Agile with your hosts Peter Maddison and Dave Sharrock. How are you today, Dave? Excellent, Peter. Been a good week. So how about you? How's your week been? My week has been fantastic. It's been one of those weeks where we've felt very productive. It feels like we've made some good progress. Lots of things have got out the door. So yeah, it'd been a good week. Excellent. So maybe highlights from this week. Anything that kind of stood out? Highlights from this week. Well, I would say that we've managed to uh win some very interesting uh business. We managed to work uh through some very complex problems. Uh and I think some of the more interesting parts of that uh actually lead into our topic today, which is uh helping guide helping understand and guide the decisions that occur within an organization um with relation to technology and how we spend money from a technology perspective. I think that's um an interesting concept, like the these kind of technology business decisions and when these two things get baked off at each other. And and sometimes as technologists, we get very invested in wanting to spend money on the new shiny toy. Um, but it's not always the right thing to do. Right.

So how do you I mean this is an interesting one because it it we talked about this recently, that imbalance between quote unquote the general view of business and technology? But what we're really looking at is I need to do something for our customers. We know we need technology to deliver that because we're in a digital space now, a digital world, and pretty much everything needs technology. But now, how do we align the decisions made in technology with the goals and the opportunities identified on the business side? Um, you mentioned shiny objects, I think, earlier on, or we're thinking of shiny objects. How do we avoid that sort of magpie technology buying piece that we I mean we so often have experienced? I would say I'm not gonna say we see it, but I've certainly experienced it. Technologists want the latest technology, they want to be involved at the cutting edge. That might not be what the business needs.

Yeah, and it and it's this this interesting piece. I mean, that there's a number of models, and we've we've talked about some of these in the past, but uh, and and understanding where do we need to go next overall as an organization? Where does it make the most sense to invest? Which which which parts of our of our organization are we looking to move forward? And then from there, understanding, well, how can we best support that? Uh, and is it is a technology solution the right solution here? Uh, is updating or changing or modifying how we're using technology to deliver this service the right way to go? Or are there other ways in which we could achieve the same set of outcomes? Um, and the I mean the one that we were talking about earlier is uh, and this is probably maybe a little contentious, but the the the conversation around uh say Amazon leaving a package on your doorstep, and they there's a couple of ways that that could be handled. It's like you could train all of the uh of the drivers to always ring the doorbell and make sure that the package is received, um, or you could uh pay them based on how quickly they can deliver packages so that you get the packages to the place, but not bother ringing doorbells or telling anybody about it, and then if the packages go missing, uh it's cheaper to just replace the number of packages than it is to spend all of that time and money and effort to ensure that uh the package is delivered. And this kind of there's a decision that gets made there. And uh we were talking about whether that was a uh an a decision that was consciously made that hey, we're not going to invest in technology to ensure that uh the package gets delivered and in training and technology and uh to make sure that happens, we're going to it's cheaper for us as an organization just to pay for the replacements, the breakage.

Yeah, that it's um so what you're describing there is there's definitely uh a working relationship between business and what they're trying to achieve, getting packages to everybody's door versus technology and what they can do. And of course, there's a price associated with perfection or with a certain performance bound that you're trying to each achieve, level that you're trying to achieve. Uh, and whether it's an unintended consequence or a a directed strategic move is is maybe one for for us to debate a little bit. But what I I I think what's I mean, the first thing that strikes me is you need technology at the table. Technology is no longer you know an ingredient to a successful business, it's it's it's strategically, it's often the lever that opens up doors that were not there before. So I think that one becomes really interesting, first of all, is just that shift in a relationship really to a peer peer-to-peer conversation. But and what you're describing here is quite interesting because the technology coming to that table for that conversation will say they can solve the problem. But the question is, are we solving the right problem? Because maybe they don't need to solve that problem. There are other problems that they need to solve. And if speed is of the essence and you can live with a small fraction of your customer base not getting the products they thought they were going to get and replacing them and so on, at the you know, then that that that's a solution, right?

Yeah, well, what they replace it with is a that you instead of investing the money into the delivery side of it, they invest the money into a uh uh a really good um service to give you a new version like it's really easy to like go on and say I didn't receive it, and then they'll send you a new one. So you make that piece easier.

And uh well, and and I think this is the this is really where it gets very um intriguing because you're the technology group can't make those decisions without input from the business, and the business can't make them without input from technology because there's an element of speed as which is the solution which will solve the problem quicker. There's an element of strategy in terms of do we really want to build the sort of robust technology, technologically rich solutions that may eliminate the lost packages, but have other impacts, whether it's cost in terms of operational cost or whether it's just you know the opportunity cost, the amount of time spent building that system compared to building other systems that will give us other opportunities. There's a you know, it isn't each department taking care of its own problems, these are combined peer-to-peer conversations.

I I think uh a less contentious perhaps version of this is the uh if you look at something like an SRE model, like site reliability engineering, where you're looking at improving the reliability of systems in the organization and services within the organization. So when when you think about what you're trying to achieve, what you're also within that, where should we invest? Like which services need more investment than others, where is it, does it make sense to build additional resilience in? What matters? The kind of the lean approach, which we've talked about before, and like if we if you look at Toyota, understanding every one of the hundred thousand parts that go into making their car, but they because they understand exactly how many of those get used and where they're sourced from and what their relationship is with those vendors, they know exactly which five or ten parts they need to stock extras on, and and how many extras to stock about, so that if they're assured, they can continue to operate or they can recover faster from shocks to the system. So there's there's all of there's that kind of deeper understanding, like where do you invest? Because you can't necessarily invest everywhere. So that's uh another aspect of this.

Yeah, it so there's the scarcity thing, right? So you if you have unlimited resources, unlimited budget, and unlimited time, you can do all of the things that are in front of you. Uh the reality is you don't have any of those in an the sort of quantity that you need uh to be able to take everything on. So there's always a trade-off, there's always a priority. I I think that's a really interesting um place to sort of wrap things up, if you like, because it brings us back around to what has changed, why is it so important today that 20 years ago it wasn't, or 40 years ago, or 10 years ago, or whatever. And that is that that you know, when things around us are changing so rapidly, when the competition is as high as it's ever been between different entities, when you know all of the sorts of things that we see out in the marketplace means we bring we draw people more closely together to to have those trade-off decisions. So I always think when we talk about resilience in an organization, whatever that resilience is referencing, resilience is by definition a conversation about trade-offs. You it to be resilient in one place is to be not you know fragile in another, by definition. We're going to have to kind of make trade-offs, and that means bringing people together to have informed, data-rich conversations about what's going on and where to work, where to not work.

Yeah, and and that's I think that's an important piece. It's the interconnectivity of all of the pieces that creates a lot of that complexity, which is what's what's causing it. So it's we don't build software that we're used to. It's not all built in one isolated organization, never talking to anyone else in an island. It we build software and what and it's part of it, we build it by interconnecting lots of moving parts, um, and like coming from different libraries, pulling in different pieces of software, accessing um SaaS services by a component of the overall system rather than building it ourselves, is all of these pieces interconnect to each other, and you've got to understand the complexity of those different parts to see what that end-to-end system looks like.

Wrapping things up, what would you pull out? Two or three things there that uh you want our listeners to really focus on.

Uh so I I I like the the piece that we were talking about around um that there's a balance to be struck and understanding that technology is a strategic partner of the organization. You need to work together to understand how technology supports the services that you offer, but and it's a two-way street to understand when and where to invest, and what are the pieces that it's most critical to invest in because there is a scarcity, we we can't invest everywhere. So that's like the but I think that kind of covers a lot of those are the main points I think I'd want to pull out of all of that. Um, the yeah, that that's I think one of the other main pieces is that it's not always obvious from a technology perspective. Um, that a solution that may look obvious from a technology perspective may not necessarily be the right solution from an organizational perspective. And there may be another way of solving this um without the next shiny object or changing the system. And that can in turn, of course, of course, have other impacts where it can be um have consequences of being frustrating or frustrating for the technology department. Is there anything you would add to that?

No, I as as you were describing that, one of the sort of takeaways that jumped into my mind is um look to your technology group to find the sh right shiny objects. We need to give them guidance as to what they, you know, what the next shiny object should look like or what problem it should solve. But uh I I definitely want us to make sure we focus on getting shiny objects out there. I think you need to nowadays to be much more attuned to that. Uh so there is I I would just maybe close with that. It isn't uh don't chase the shiny objects, it's how do we identify which ones are going to do what we need them to.

Yes, I agree. I think that's uh a very good point to close on. So thank you as always. Always enjoy these conversations. As always, you can reach out to us at feedback at definitely maybeagile.com. And I look forward to the next conversation. Until next time. Thanks again, Peter. You've been listening to Definitely Maybe Agile, the podcast where your hosts, Peter Maddison and Dave Sharrock, focus on the art and science of digital, agile, and DevOps at scale.