Vendors

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. It's another wonderful uh day for a podcast, and I've got my good friend Dave here, and we're gonna have a uh lovely conversation about all things to do with vendors today. And and I know, Dave, you've got some great uh great opinions on this, and I think there's some really good insights for people. So uh, do you want to kick it off?

I was gonna say I almost feel uh good to chat to you again, Peter. I almost feel like we should come clean and say, you know, we are both working as vendors in many, many scenarios that we're going to be talking about. So um there's a little bit of uh um uh yeah, pot calling the kettle black, or I'm not sure. Um, but uh what I've I think one of the reasons this is bubbling up or is a topic that is front of mind for both of us is uh in so many of the large organizations and digital transformations, agile, DevOps, digital, whatever that's that describes, uh of course there are significant investments and programs that are rolling out that you know have have um products, suites of services being integrated and configured and so on through vendor groups who are bringing those to the table. And I think maybe before we go into some of the headaches that can happen as a result of that, one of the first things I thought uh would be useful is just to understand that absolutely in in today's fast-paced environment, to stay ahead of the game, it's it's absolutely should be a strategic imperative to always consider what you can buy off the shelf, what can you bring in from outside. So vendors and vendor products have a huge role to play just in that clarity of you know, if they're solving a problem that they're not solving once for you, but they've solved hundreds or thousands of times for many, many other different industries and types of businesses, their understanding of that problem space is clearly much better and uh should provide a strategic advantage if you're able to work with the right products and the right vendors. Um, anything that you'd add there, Peter?

Yeah, I'd add it. It's yeah, for if you can find a product that's a good fit for the problem you're looking to solve, and it's uh not something that's necessarily completely core to the IP or the value that you're delivering. It's not something, it's something that's gonna operationally help drive your organization, but not necessarily be something that you're you're gonna want to expand and extend on, or there's the specific pieces that by being able to do something deeper with it, you would be able to drive even further value out of your organization. Then finding that someone that's already solved a lot of those problems knows what those problems look like, then that's almost certainly the right way to go. And typically when we're looking at like vendor assessments, that's what we look for, is like what are what are the internal skills in the organization? Do you even have the capabilities of doing these things yourself? Or can you go and can you do you need to go find somebody else who can do this?

And yeah, and uh I I think that whole strategic element is such an important piece. Sometimes you get into conversations where you can I I'm I'm actually I I've quite surprised at how eagerly some organizations will outsource their strategic strength. And so I completely agree. I think it isn't that you know, um even if the product is out there, if it's your strategic strength, you probably need to keep it pretty close to your business because it's proprietary, because that's what makes your business harm grow. Sure. Yeah, but if we put that to one side, I mean I think uh if I'm just thinking about some of the challenges that we've worked in, one of the ones that um I'm currently working with a client that is trying to unpick this piece is around um uh vendor product relationships that are outside of core IT. So, and of course, they you know I I've I think this touches a little bit to you know the the way um uh product sales people, let me say that it's not the vendors, the vendor the everybody involved in all everything we're talking about has everybody's best interests at heart, but they're going to have incentives which skew things in different ways. And one of the challenges you have with vendor products is that their relationship is often with the business. And if their IT sort of execution or implementation stays outside of IT, what you invariably find there's a number of critical things happening, just like dependencies aren't identified, so all of a sudden it's a flood of work around integration, around security or compliance, or any number of different things which are uh are well understood in core IT, but not understood or appreciated on the business side. Um, the other thing that can happen is just that um it imposes an unwieldy demand on core IT in terms of operationalizing it, in terms of maintaining it, in terms of licensing and costs and so on, hardware that may not be identified in those original conversations and the relationship building with the business. Um any other things that you'd add there, Peter, that you've seen?

I I I could add a I can add a specific example I I can think of, which is one that I've seen uh multiple times over in various different forms. Uh but you have a something like Salesforce, the the marketing part of the organization goes out, uh buys Salesforce, gets it all set up, starts integrated. They've been sold on this of solving all of their problems is absolutely wonderful. They get 75% of the way through it and then realize they need access to customer data stored in some other system, come knocking on IT's door, and IT say, You have Salesforce. Uh we've never worked with Salesforce. Oh no, we just need to integrate it over here. And we've got but we don't know how. Like we've got to go and work at, but we're also working on all the myriad of other things you already asked us to work on. And now uh you want us to try and work out how to integrate this product we've never worked with into all the rest of our back-end systems to ensure we've got the data that you're looking for, and you want this done by Saturday.

Uh it's it's interesting you're saying that because I'm just thinking, as you're saying that, that there's a a requirement to be able to prioritize in your prioritized backlog, because we're all working off a prioritized backlog of business initiatives, to include those pieces in there. So even if a lot of the work is done by a third party, and maybe it's even sort of broadly overseen on the business side, you still need to have that ticket, that placeholder in your backlog to be able to know have you got the right skills, what are the implications, and do all the things that we all know are the right things to do in those scenarios. So trying to get that um uh the the involvement of IT early enough, and also um, I mean, the way I always kind of look for this one is ideally IT are kind of managing the contractual side of the relationship. By all means, have a relationship from the business side, they're going to be sold on the many different services and strategic opportunities that open up by using a particular product, but someone has to kind of watch over the the um the contractual element, how is the work delivered, who's involved on the teams, how that's going to be integrated into the overall IT infrastructure.

Yep. I the the other element of that that I've I've seen on on occasion is where the the business doesn't understand the nature of the uh of the technical pieces that need to be done. So they go and sign a you know a few hundred thousand dollars worth of integration work, and uh you're looking at it, IT gets hold of and looks and said that this is like maybe half a day's work. It's like we we know how to do this, we we've got the prior art. So going the other way, it's like we know the prior art, we've got the integration systems, we've already got the the adapters we need. Uh, if you had asked, we could have set this up for you, and uh you needn't have spent all of that money um trying to work out how to get these complex pieces working.

Um so and of course that goes the other way around as well, right?

Yeah, so um and we're making the IT sound like the heroes and it does the other way too, because that you do still have that that constraint that you don't want to slow people down in being able to get things done and to learn and to drive value and deliver that value, but you you do want to make sure that there's enough of a conversation, collaboration going on that we we understand what's happening.

Customer collaboration over contract negotiation, right? I mean it's it's something like that. Have I heard that? Maybe we should write that down and uh yeah, yeah, it's only yeah, exactly. If only we could, it would be socially distanced and right. Uh but but um maybe if we extend, I think there's another recognition that that kind of comes in is um if I think of IT and business and the vendor as three parties in a conversation, and and uh we we have to recognize the incentives of each of the people at that table. And uh not not in a you know it's not a negative way of pointing fingers or anything, but it's a recognition that each of the parties at that table um have different incentives, and that might impact recommendations, conversations, and so on in there. And and one of the things I'm thinking of is one of the actually a really enjoyable project that I worked on uh involved uh integration with the vendor, and there was a vendor providing the design work and driving the development of a new web application and and so on. And they ended up providing a product owner uh for various reasons, and this speaks a little bit to that strategic ownership internally. One of the headaches that happened is the product owner working through this vendor agency had a slight incentive, let me say, to create an award-winning presence while the business had an incentive or a desire to be fast to market. And as you can probably imagine, those are two slightly uh opposing uh tensions there, and just because of the role that the vendor ended up playing, that caused a little bit of havoc. I mean, it was all uh amicably resolved and so on, but it caused that havoc, the pullback in terms of how things were prioritized, what work was being addressed, what the conversations were, and so on. So, even in a situation that's not to do necessarily with product vendors, uh, but even in a situation there where you've got people coming in and providing certain services, we have to recognize those three parties at the table. They have opposing incentives that may not all be on the table for discussion.

Yeah. I I I've seen uh things like that too, as with uh an example of uh large consulting company that also sells products, and the products were not um, they weren't fit and scalable enough, they weren't the right solution for the overall end-to-end program, but the they're the company providing the services to deliver the program to, so they're not incented to remove the licensing for their software, even if they know that it's the wrong software. So so the and because the keys have been handed over to them to deliver the solution, they're like you're you're now they've they've got, to your point, a perverse incentive. They're their their incentive isn't necessarily aligned with what the organization wants, uh and what would be the right way of solving the particular problems they're kind of and equally they're handcuffed to a certain extent.

I mean, I think this is an interesting it it's uh you see the same thing in different silos or different parts of an organization. It has nothing to do with whether the vendor is the party at the table. It can also be, you know, info infosec security compliance at the table with development with business, and they all have slightly different perspectives and views on it. But I think in um uh what I've seen in in the third party world is there's an optimization in terms of being able to you know leverage that that comes in with the vendors. I mean, quite frankly, they're very, very good. They hire excellent people who are really good at arbitraging that difference, who are really, really good at maximizing the opportunities because they're incentivized to do it, not because they're trying to be disruptive or you know, in any way um uh disingenuous, but the incentives are very clear often in those organizations, much more so than um, for example, when you're looking within departments in an organization, they tend to there's an aligning piece over the top of that as well.

Yes, it's uh when you're looking across departments, uh hopefully everybody in the organization is somewhat aligned to the direction the organization is going in, hopefully.

Well, for sure. Yeah. I could tell you some story. No, yeah, yeah.

That's a that's a different podcast. Yeah.

Now, uh Peter, you've been quite I I know you do a lot of work with vendors and and you've had lots of experiences there, and you've been quite quiet so far on the podcast. So what is it that what is the bee in your bonnet when it comes to or the thing that worries you the most or is something that you watch for when you're dealing and working with it?

Uh I think we we we've touched on a lot of these. The one that I think perhaps worries me the most is when I see an organization give over complete technical direction to uh some other organization. And uh at the point, similar to your product owner example, where somebody says, Well, I'm not just gonna bring this vendor in to deliver this value to these solutions to provide either the product or the service on top of it or the understanding of it, but I'm actually going to ask them to also, on top of doing that as well, provide me strategic direction. It's one thing to bring in somebody who's gonna help you um facilitate the understanding of that strategic direction, to provide coaching and guidance at the at that level. But if they're the same people who are also bringing in the services to deliver and the product that they're gonna deliver under that, then their incentives are very much to how can I drive the most amount of revenue out of this entire stack of things that I'm now doing, uh, not necessarily for the benefit of the organization. So I find that uh whenever I see that, uh, it it kind of makes me look very carefully at what are the decisions being made, uh, why are we doing things in quite the way that we're doing them? Uh are we making these decisions for the right reasons? Um, and start to look at like unpacking what that looks like. Uh that's that's a big piece of uh some of the pain points I've seen.

I think it's uh it's interesting that we're we're in previous topics that we've discussed, the the impact of what we're discussing is is felt over time. And I think the interesting thing when you're looking at vendors is the vendor solution is often brought in as an accelerator. It is it is um uh something that has outsized influence on the success and the robust resilience, if you like, of an organization over time. A good choice of vendors, good choice of products maximizes the the opportunity that an organization can take advantage of and also accelerates their ability to do it. But equally, poor choice often leaves you tied with a partner that is not really suited to where you need to go. So I think that's why you know your conversation, partly my conversation as well, is we're really tied on either how do you make that decision. I have you got the right people in the right place who have the authority, the ownership of things, uh, because they are these accelerators and they have a potential for sending an organization really in the right direction or really holding them back.

Yeah, very much so. Yeah, finding the right uh people you're gonna partner with to uh actually accelerate the organization is absolutely critical. Now, so how would you uh how would you sum this up if you were gonna give three points? How would you sum all of this up for us?

Well, I was going to say is that I wanted to kind of close on a high, if you like, because um the the just because of the role that we play, you know, myself at Increment One, you with Zodiac, is that we're often involved in um agile DevOps, sort of some sort of digital transformation. And the best experiences I've had, we I often get the question can you even do agile with a vendor rollout? It's mainly configuration, they've got a system and so on. And uh I think some of the most impactful and best um rollouts that we've been involved with, that I've been involved with, have involved vendors who come to the table. Um, a couple of things that are happening. One of them is is you know, managed in IT, and IT is driving that thing. We talked about that being one of the key pieces. Business is driving the relationship with the vendor. Clearly, they need the opportunities and get strategically what they need, but IT is front and center in that relationship. Um transparency around those perverse incentives, so it's not quite sharing contracts and what your bonus is and my bonus is, but is at least coming to the table and having an open conversation about what the good looks like and what is it that we're trying to achieve. And the closing point and the things that really stand out is vendor products nowadays, they're really well, there's a lot of good stuff out there, and they're highly suited to incremental delivery. But there's also this sort of overhang of coming in and not necessarily doing the incremental delivery piece. And the best examples I've seen of where incremental delivery was the way those things got delivered. It isn't just agile in terms of changing the requirements at a late stage or anything. It's you know, we're gonna do a month's worth of work, and then you're gonna be able to use that product, and you're not gonna use every single thing. We'll have a critical path outlined, and then we're gonna do this again, then we're going to do this again, and we're going to do this again. And that incremental delivery is immense because that you now get the power of incremental delivery from agile coupled with the power of the product that you're trying to roll out.

Yeah, and I I've seen the same thing. It's when and I I structure engagements that way myself too, is coming in and saying we're we'll structures based on outcomes on a period of time, we'll deliver to those outcomes, and then we'll make a decision at that point. Do we want to move on to the next set of outcomes, onto the next set, so that we're incrementally delivering value and that we're ensuring that we're providing opportunity to make sure we can course correct and make sure we're going in the right direction and delivering what we need to. And I agree, I've seen the same when working with vendors where that uh the ones that go best, those arrangements that go best, are the ones where we've been able to deliver incrementally in that fashion. So uh I think we summed that up. Uh well, I think we summed it up very well, but then I may be a little biased in this myself.

Uh that perverse insight. Well, there you go.

Yeah. So uh so uh we're open to any feedback if anybody wants to uh send us some. Uh we always like listening to our uh listeners or reading what our listeners say. And so thank you very much for your time today, always a pleasure, Peter.

Good to chat again, and I'm sure we'll do it again soon.

Awesome. 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.