Ep. 110: Redefining IT-Bus Relations

Peter: 0:05

Welcome to Definitely Maybe Agile, the podcast where Peter Maddison an d David Sharrock discuss the complexities of adopting new ways of working at scale.

‍Dave: 0:21

Okay, I'm not going to say anything about the weather. It's the lens of the country, different expectations, I think. Around the weather, there we go. So what's the topic for today? We were going to chat a little bit about that crossover between IT and business.

Peter: 0:37

Yeah. So there's this problem that and I've got it with a well, I wouldn't say got it, but there's this challenge that often arises where we've started working with the technology parts of an organization and we need to bring this into the line of business side of the organization, which, in some organizations, has never really encountered some of the concepts that we're talking about. And it's how do you get the VPs on the line of business side to understand the value of some of the concepts which we've spent so long explaining to technology parts of the organization, and how do you do that translation?

Dave: 1:16

Well, and I do wonder if it's even possible. I mean, there's a little bit of the not invented here syndrome right where. How can you come from the technology group into the business group and expect to sort of suggest how they may need to operate is not going to get taken.

Peter: 1:32

Well, yeah, and that definitely needs to be sufficient to air cover from high enough up in the organization that's saying this is a good idea, that maybe we should collaborate on this. It's very hard to just walk into the room with somebody who's coming from a totally different space and totally different understanding of the world and start to say, well, hey, we really want you to do things differently, because it's hard for them to necessarily buy into what you're trying to talk to them about.

Dave: 2:01

So I'm thinking back to 2010,. I was working on some abstracts for talks and so on and looking at the current thinking and, in my mind at least, 2010 was when agile DevOps were a bit too early for DevOps to be kind of front and center in the conversation, but agile became a dominant conversation in IT circles. Cios were expected to know and be implementing agile in the biggest organizations. I don't mean the sort of areas where a lot of agility had been done in a decade before, and so that gives us sort of 12, 13, 14 years of really implementing it in the bigger organizations and obviously for early adopters, even longer. And it's always come from IT needs to deliver better, because the problem has always been a delivery problem on the IT side and of course those of us working in it recognize that that wasn't. It was a perception of a problem in delivery, but there was a sea change in how delivery was being worked and we've seen that all go through and we've discussed it many, many times in our conversations. But it's interesting where business has been somehow insulated from recognizing that as delivery shifts and changes, morphs into something which is more responsive, much tighter connected to what customers are looking for. There's going to be a move into the business side where there is a consequence for that improvement on the delivery side.

Peter: 3:29

Yeah well, there's no point in having this capability of being able to understand the customer's needs more if you don't also have the people along with you who can help you interpret those customer needs. Or how are we going to tie that into other aspects of how the organization needs to deliver? Because it's not technology on its own, it's the organization as a whole that needs to create value from the products it's delivering.

Dave: 3:53

Is it not a shift in mindset? From IT as a service delivery partner, I need you to whatever stack the shelves metaphorically to IT as a strategic partner. Which is, what should I stack the shelves with? Is it shelves at all, or is it something else? Or whatever it is, but some sort of a strategic partner versus a service delivery partner.

Peter: 4:15

Yeah, exactly, and there's an element of that, too, where IT also comes back and says well, have you thought about stacking it with these, because we can do this much more easily? We've got to. We can foot, create shelves that now look like this or do these pieces, or where we can automatically put QR codes on all of the shelves so you can find the things that you need faster, or put RFID tags onto things. So it's like that combination of technological ideas which might help accelerate what we're looking to do as an organization, and so it has to become that two-way street, so that we're not just trying to push down potentially even old ideas into a technology group, and so I mean that's definitely that sort of more strategic view, seat at the table type role that has to be played.

Dave: 5:07

And I mean so when we've talked about digital transformations. There's a lot in the digital transformation space which sort of we touched on addressing some of this, and if you're in a digital product area, you probably or service, you're probably already very well aware of it. But I do wonder there's a lot of organizations which are struggling to justify maintaining that focus on delivery on the IT side. That is beginning to come up in terms of either softening let's say, just softening in terms of commitment to DevOps and agile practices, and one of the things that I wonder about there is I think there's. You know, if you ramp up the horsepower of your delivery capability but you have no way to go and use that horsepower, you're going to naturally drop down again if you don't know where you're going basically where, what, how to use that additional power.

Peter: 5:56

Yes, yeah, exactly, so there's. It's one thing to develop the capability as an organization to be able to deliver rapid changes into your products, but if you don't actually know where you want the product to go or what where the market is going, and you're not aligned to that strategically, then then it becomes less valuable.

Dave: 6:21

We talked a lot about this when we discussed digital transformations, which is strategically knowing what the benefits are. If you can deliver something more quickly, you can be respond to changes in the market really, really quickly. You can have a better, deeper understanding of your customer behaviors and what they need. How do you leverage that? How do you turn that into something which is going to give you a market position or increase your profitability or, whatever it might be, increase your market share? How do you turn that strength into real bottom line value creation?

Peter: 6:52

Yeah, and I think for that that that's where this, how do you start to communicate that value Like, hey, look at what we can do now and take that to those line of business VPs to say, look, here are some practices we've seen work well, right, and and we, we? There's certain things that we've learned over the years. We've learned that if we try to do too much all at once in knowledge work, that all the context switching in between different topics Ends up with us and not getting anything done nearly as fast as we want to. This is this, by the way, is why the project you ask for is like six months late, because we're we're busy Context switching between all of the different things you're asking us to do at the same time and we just don't have and that's taking us longer, whereas if we could be much more focused and deliver more incrementally and smaller pieces of value, then we'd be able to get you stuff faster. You'd be able to tell us whether it's the right stuff and change directions If we need to. If we learn that this isn't the right way to go, then then we suddenly have the benefits. But there's a. It's communicating that message in language that can be understood by the person on the other side of the table so that they can buy into this as okay. I can see that I need to change something about my behavior in my organization.

Dave: 8:10

Yeah, so let's turn that one around. I feel like we're kind of pointing fingers at various things or at least Identifying the chasm, the gap in between what. What do you want to see change?

Peter: 8:21

So the the change very often Comes from what they, what they've seen as potentially they may even have seen as successful, would be say hey, we had a large program, we delivered this large program and we got what we wanted, not necessarily having had visibility into what needed to happen to get that to where it was. And there's this understanding of some of the fundamental principles and practices that we think of in the sort of the agile and dev-op space and that we things from the systems thinking space or from other practices where it's. We know this and we we look to see how do we apply it. But the person who's sitting over here, who's been in a, a role that's been in, say, marketing, for their entire career, they've risen up to be a VP and now they're looking at how do we Start to? How do I take this, all of this knowledge, and communicate it in such a way that this person can understand that this is what needs to change about their organization to help try to support what I.

Dave: 9:28

I was just thinking, as you were describing that, peter, that I feel like there's I'm always reminded of the lean. I think it's the lean discipline Optimize the whole, and there's that. What I like about optimize the whole is it doesn't. It doesn't say this bit's wrong or that bit's wrong. It says let's come together and understand how the whole thing is working Together and see where basically where we can help one another and how we can navigate that. And I think that's sort of a starting point of that side of things, which is is bringing people together to discuss where what the impact is. If you've got that new digital capability or improved horsepower, how is it being used and what can you do with it.

Peter: 10:08

Yeah, and this is where that conversation starts to open up, to be able to say Well, we, these are some of the things that we can do, what we can do. These are some of the things that we can do. What direction should we go in now, if we like? What is the strategy? What? What is the direction that we want to go in? What are we looking to try and go? How can we collaborate more closely on Working out what these solutions are and creating sufficient feedback loops so that we can start to understand and innovate and Move the organization forward?

Dave: 10:36

and and I think one of the topics has to be how can we help you in a sense and I think of this as business as usual or you know faster stuff because typically when you talk to business partners, they're struggling with the pace of delivery or they're struggling with the volume of delivery and they don't necessarily own or recognize that the influence they have on that. But all of that is okay, because what you can start immediately is just tell me your biggest pain point, let's go fix some of that, so they start seeing some benefit. I think that's a big piece of it is just how can I reduce your pain or increase your delight with whatever it is that we're able to get to you.

Peter: 11:15

And some of the concepts that are things like ruthless. Prioritization is a key piece to this, where often one of the biggest problems is that there's just too many asks, too much stuff queued up and too many things have all been started at the same time and nothing gets finished as a consequence, and so some of the first bits is helping them understand why is it important that we stop starting new work until the old work is finished and that we start working out how do we break this into small enough pieces. That gives you the next bit of information you need to learn from, but that takes some learning or education to communicate as to why this is important and some careful questions and things like this.

Dave: 11:58

So I'm just thinking about two out one in heuristic that we've talked about in the past as well, where it's at least able to stabilize where things are and gradually reduce the load on the teams. But all of that is around that business as usual stuff. The thing about that is I don't think that gets us away from the service delivery mindset. No it's almost like our business partners are going. Finally, you've been listening to the feedback we've been providing over the years and now we're beginning to see conversation about that, whereas I think there's another element to it, which is how do we start exploring areas where we can innovate, we can create additional demand, and the headache there is. It really requires both sides coming to the table, because without seeing the sort of places those lines of business are working in and what the opportunities are in the markets going, it's difficult sometimes from an IT perspective, to see how some of the digital solutions that we're seeing and being very readily available can be leveraged in those areas.

Peter: 12:58

Yes, exactly, and of course this then takes us into we're making an assumption that we've got all of our ducks in a row and once I before we're having that conversation to actually be able to implement some of those, because, as we know, sometimes the barriers to bringing some of those new capabilities to the table don't exist on the business side. They exist in other, more technical parts of the organization that are either risk adverse or having difficulty getting their own house in order to enable them.

Dave: 13:25

Yeah. So in closing, how would we kind of summarize the conversation or set up some next steps?

Peter: 13:31

So I think there's a there's a couple of key points that pull out. One is making sure you're communicating in the right language for the people that you're talking to, that you're avoiding technical jargon and technical language, because because which can be hard to do, it can be very hard to if you're coming from a technical background, or even if you're in the situation where you're just walking from one meeting into another. One Just came out of a highly technical meeting and you're walking into the more business meeting, then you're going to bring that language with you. It's going to take some time to shift gears. So, making sure that if you, if you know you're going into one of these conversations, give yourself the time to decompress, go for a walk, figure out what it is that you need to talk about and make sure you're thinking in the right way before you start to have conversations like this. I mean that's a key part of it for sure, and I think the one of the other pieces there was. The technology is the strategic partner piece and I know it's been said many places as well, but it is key. It's that it has to be a two way street. Once you enable these capabilities, they're only valuable if you're having the conversations about where are we all going, not just being, hey, we've got a bunch of new capabilities, go implement all of these things, even if from a technology side you're going, that's not going to work. I can hear what our customers are saying and that's not the biggest pain point. Why are we doing this, whereas if the feedback loops only go so far and they're not getting right back into business and there isn't that open conversation and dialogue, then that's going to cause problems too.

Dave: 15:10

I think I'm going to add something to what you've been saying, peter, and it's really about conversation, because I think it's very easy to send the email that says shift from service delivery mindset to strategic partner mindset. That's all well and good, but the reality is there needs to be a relationship there where there's mutual respect and trust. And sometimes I think I would say there's two things. One is we need to be super careful about just walking in and saying, hey, we've got a digital solution. You're not listening. This is what needs to be happening and it's a two-way conversation. It really is. Let's understand the challenges on both sides and talk about some of the opportunities and just begin building rapport and some conversation there. And I think the second bit is I mentioned right at the beginning of this chat 2010 watershed and that was my recognition of when the watershed was. I know you talked to different sources. They have different understanding of when the watershed was, but that was my kind of recognition of the watershed and that's like 12 or 15 years ago. And the thing to bear in mind is there's a lot of understanding and learning and micro conversations built upon micro conversation. That gets us to the position where we can confidently, in the IT side, talk about strategic partnership and the delivery, you know horsepower that's been created and all of these things and it's not necessarily happened yet on the business side. We've got to give them time to go through that recognition and the same journey that IT has gone through and I think sometimes we forget it's been a decade or more of these conversations and we have the same challenges with software delivery and with operations and with the IT departments and those sets that we talked to.

Peter: 16:47

I think it's worth possibly clarifying as well, though we do see these issues arising in your organizations, and on occasion, it's typically the organizations that have been around for a while and been delivering for a while but really run into these sorts of problems. Well, with that, I think we can wrap up for the day. Send us any feedback at feedback@ definitely maybe agile. com, and don't forget to hit subscribe. A pleasure as always, Dave, always. Thanks again, Peter. You've Definitely Maybe listening to the podcast where your hosts, Peter Maddison and David Sharrock, focus on the art and science of digital agile and DevOps at scale.