Constantly Evolving Technology

Welcome to Definitely Maybe 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 Maybe Agile with your hosts Peter Maddison and Dave Sharrock. How are you today, Dave?

I'm doing brilliantly. So and it was good, by the way, that we actually finally started meeting in the real world instead of just in the virtual world. But back again today to virtuals. So what are we touching on?

So today a topic came up. I was asking a few folks and uh they said, How about you do a podcast on constantly evolving technology and what that means for the business?

This is an interesting my first thought there is why should the business care?

Yeah, yeah. Like why should they care? Like technology's changing all the time. What's that matter to me?

Well, uh uh let me put it slightly differently. It does matter, of course, because our technology is changing all the time, we need to keep up with it. But when I look at it from the business perspective, they've got a partner in technology, in IT, whatever that department is called, that is an expert in keeping their technology up to scratch, keeping it future-proofed and looking for the latest technologies and bringing those to the table. So, in that context, if that partner is doing a great job, why should business be worried about evolving technology, constantly evolving technology? What drives that concern?

Well, and especially if we're all technology organizations now, and there is no technology department. We're really all just technology, and it's just that some of the people in the business happen to use technology to solve business problems. And so from that perspective, you also wind up in a in a very different sort of context of how we look at this as a technology evolves.

Well, and and um one of the I I always find this kind of weird in that IT is one of the few places where the stakeholder, the consumer of IT business, feels that they have a right to kind of challenge the decisions that are being made in a business context. If I go into a hospital to have my appendix out, I'm not going to sit down with the surgeon and talk to them about the technologies they're using or how they're going to do it, the process and so on. I'm just going to say, hey, wake me up when the appendix is out and uh get me out of here healthy and strong at the end of it. But I don't question are they using the latest technology? I don't question how they do it, what approach are they taking. I've read a book that says you should probably do it this way or anything like that. That's not there. And yet, so often when we have technology business conversations, it feels like we're going to separate out how we do things from what the business needs, first of all, and start challenging the how. But also now we start saying, well, no, we're not going to give you the money to change the technology that you have. We're not going to, you know, your operational costs seem to be high. We need to challenge that. So there's a whole bunch of discussions there which just don't happen in other contexts.

Yeah, it's really interesting, isn't it? Because uh there's this world where we're the it's almost as if a part of the system, the one that the people who are focused in the technology space, is kind of being looked at in a very different way to the rest of the organization. It's considered a the cost-centered view of the world where it's like technology costs us money, uh, but it's not necessarily being considered a part of what we need to do as a as an organization to operate um in in quite a lot of organizations anyway. And uh so there's this leads to some very strange behaviors. Um, and uh one of the the ways in which uh you have to see is we we do things like these temporary fixes to try and uh get us to the next level, that we we try to um put something in temporarily to see if it's gonna be the thing that the the business is gonna latch on to, and and as they say there's nothing as permanent as a temporary change, it's we put things into place and they uh and even though the intent is, hey, what do you think of this? It now becomes that's how we're doing it.

Yeah, and and it's a it's an odd one, but it's because we've got MVPs, minimum viable products, which are all about let's put something small, a small change in place, and and then the business is perhaps moving straight on to the next problem without kind of landing whatever the changes are, whether it's an MVP or some other change, but without really doing the kind of cleanup that is required or the sort of operationalization that is required to avoid legacy code, which is really what we're looking at, is how do we get away from legacy systems which become more and more prohibitively expensive to sustain and to support? Um, not because the technology was necessarily the wrong technology, but because the way we've used it, we've patched it and tweaked it and put a plaster here and a fix over here, and now we're in a system that isn't, we can't decouple certain functionality. We've got data in different places. So architecturally, this is going to become a headache as we go forward.

So, how do we avoid that? Yes, yeah. And then I think a part of that comes that there's this fear of rework, or it's sort of the sunk cost fallacy. So it's like we've we've invested this, we've done this piece, oh, it must work now. We've gonna we have to have got it right first time. It's this the the inability to necessarily experiment. I think some of that comes into this too. Um, and that that comes down as well into there's a couple of pieces here. I think there's the the unwillingness to challenge the initial assumptions and activities that we've undertaken. So we we do that's why that temporary fix becomes the permanent way of doing things. The the MVP becomes uh instead of being an MVP, it happens to end up being a very large chunk that's now there forever. Um and the or you run into uh the there's another side of this where we underestimate the cost of change as well. If something's been there for a long time, it now becomes much harder to remove. So there's that side of it too.

Yeah, I think there's there's an I mean it's easy, it sounds like we're maybe pointing the finger at business, and I think a lot of it has to be on the the uh shoulders of IT as well, in the sense that um, first of all, how did we allow the conversation about how you're gonna get the appendix out, what tools you're gonna use, come into that conversation. It just doesn't feel like that's required. Certainly not as you move to strategic partnership, that's a totally different place to be, right? But then the other side of it is so we've kind of allowed those conversations to be pushed in that direction. But one of the assumptions that we start looking at is the world around us is changing. In years gone by, I mean, we think back or look at technology, technology's had quite a long shelf life. You bring in, I mean, this is why we have COBOL programmers still, and we have legacy systems on mainframes, which quite frankly haven't been sold in the market for 30 years. And yet there are lots and lots of systems and lots of businesses built on these long-lived technologies. But we're now in a world where technologies change much more quickly. Those there aren't long-lived technologies that have lifespans necessarily of that length of time. In the time I've been in the market, if I just think of technologies around databases and how they've changed in the last, you know, 10, 20 years, that's a completely different space now to where it was back in the day when you had two or three vendors and a big ass kind of database somewhere, right? So that challenges how we price, how we how we look at operational costs, run costs versus build costs, and all of these things that come into it. And the analogy I always think of is depreciation of assets. You go into an organization, you can always tell how often they're looking at these things by how how many years they depreciate a laptop or a desktop over. Because if you go in, you know, some still do this over five years. Now imagine anybody using a desktop or a laptop that's five years old or even three years old is getting tight nowadays.

Windows XP and all the uh banks.

Uh yeah, let's draw a line under that. But but exactly, I mean, these this is that assumptions around technology and around how we use it. We have to kind of shake up how that is because things are changing fast. So we have the choice of being overrun by constant change because we're not taking the sort of medium, long-term view of how technology shifts and giving our technology partners the the what is it, empowering them to be able to shift and change some of those technologies without having to be questioned on every single piece and challenged on what they can and what they can't change. I think that's where it comes in.

Yeah, for sure. It's it's uh it's that tricky part where there's uh we we they've got a role to play and the job of understanding how do we maintain currency and we make sure these things are update and we're looking after and managing all of these pieces, but the the entire system's kind of working against them and partly because there's it's there's a communication problem here too, right? That uh we can't, yeah, there's not a clear understanding of the thing.

And a an ownership, an ownership piece that comes in there.

Yeah. Um so how will how should we sum all of this up? Um, I think I think we've covered some really good points, and uh what would be a good way to sum all of this up?

Yeah, and I'm going to challenge it like change the order that we did things. So I think where we start with is that great quote you said is nothing is uh as permanent as a temporary change. And that's maybe if we use that as the baseline where we start from, that recognition that um we've got to understand that the the technology systems have a massive influence in our ability to perform business-wise in an environment that is that we see around us today. And and we actually want to bring those partners together much, much more tightly. That requires a couple of things. It means we've got to kind of let go of or at least allow IT to be strategic, allow IT to come to the table and make recommendations that we listen to and follow. Now we need to give guidance to that for sure, but that is a second piece that comes in. And then the third one is there's a whole bunch of assumptions that we bring to the table, whether it's around total cost of ownership or build versus run costs, or just generally how we do things here, how we think about the costs and how we allocate those and how we work with our technology partners to do it, probably needs rethinking because the landscape's shifting way too rapidly for us to use some of the the models that we've used in the past.

I would agree with that. I think the only piece is that piece around communication, which is an age-old one where it's we we talk cross-purposes, yeah. And we we don't always communicate well because we're talking different languages across different areas, and that and this doesn't just happen between technology and other art parts of the organization, but it it does very much happen within those two, and there's very vested interests involved which guide those discussions, which uh it's very interesting. Well, thank you as always, Dave. I I love these conversations. If anybody wants to provide any feedback, they can at feedback at definitely maybeagile.com. And we look forward to uh talking again.

Always a pleasure, Peter. Look forward to the next one.

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.