Outsourcing Skill Gaps | DevOps Dialogues: Insights & Innovations – EP13

Hello, and welcome to a special edition of DevOps Dialogues. My name is Paul nti. I'm the practice lead for the app dev practice at The Future Room Group.

I am joined today by Guy and Scott. Guy, would you like to introduce yourself? Uh, sure.

I'm Guy er, I'm the CTO at, uh, visible Impact, which is the Go-to market advisory and marketing services division at Futurum. Thanks, guy. And Scott.

Hey, Scott King. I'm a managing partner at Sprinter Associates specializing in sales and commercial strategy for DevOps and business Intelligence. Excellent.

Thanks. Thanks guys for joining me today. This is a Yeah, you bet.

This a really great topic, really great, uh, area that we're gonna go over today. You know, a lot of organizations are trying to modernize. When I talk about my practice and I talk about, uh, you know, uh, a lot of the activities that are going on with regards to modernization, it's, it's that, it's that past, present future, right?

You have the heritage applications that really are trying to get modernized, and then you have maybe some even future looking applications and tech stacks that people are trying to, to deploy. But a lot of times, uh, I hear from organizations that they're met with challenges, and these challenges are complexity and, and tech stack issues, but also skill gap issues, right? And, and part of the skill gap issues is they don't have enough resources on their bench to do the job, right?

So when we talk to, you know, vendors and, and tech stack and, and the pieces, whether even if organizations are looking at using open source tools and such, they wanna use potentially a service delivery partner to, to get the job done. Oh, Yeah. A lot of them do.

Yeah. Managed services and, yeah. Yeah.

Yeah. I mean, that's definitely, uh, an area that we will talk more about that for sure, because I mean, that's an area for FASTA growth, but, but like, when we look at, uh, the service delivery partners, how would you enable an organization to, you know, get these service delivery partners up to speed? Yeah.

So from, from my perspective of the work I do, a lot of the work I do is to work with these vendors on, um, their, uh, positioning and the storytelling they do that highlights the value of their tool, their product, their technology. And I think that's a really critical element in, um, enabling this whole market. So if you as a developer application team, or IT team are working with a partner, um, it's really important for you that the partner understand the particular value and contribution and benefit of each part of the tool chain that they're presenting to you.

And that originates with, uh, the reason the product is designed, the way it's designed, there is core value. There's all kinds of contributions to that value, right? There's even just the culture of the vendor, the style that they have, the engineering style or the, the, the, the cultural way that they work together and work with the market, but also, of course, the technical issues and problems and opportunities they've identified.

There's a reason why the tool or product is the way it is. And that needs to be articulated in a way that can be move all the way through the channel, the partner, the managed service provider, so that it's not just a shiny object to get put in there to get your attention. It's something that has a place and a reason that goes all the way back to the original engineering.

Yeah, that, that makes a lot of sense. And then when we think about, um, those, those, you know, faster time to value and using these service delivery partners, I think a lot of challenges organizations have is how does the vendor enable these, these, uh, these service delivery partners, theis, how do they enable them? You know, when when we talk to DevOps and they say, look, hey, we want to get going and we wanna get these guys, you know, these, uh, organizations to help us.

How do they enable it? Yeah, I think, I mean, I think I guys said it. I mean, I think at the end of the day, as a, as a consumer of the products, you're looking to solve a specific problem, right?

So the idea of selling a specific tool in isn't necessarily gonna work. Your partners have to really understand the core of what you're trying to solve, what problems you solve, and how it plugs into the relationship that they're trying to build with their end user customer, right? So a lot of it is kind of thinking product first with the sell to, but the sell through.

They need to really understand what is the overall relationship as that client? How does it plug into the overall solution that they're looking to, uh, to work through, right? They're not just looking for a tool implementation as much as they're looking to solve a specific problem.

And you have to enable the partner to be able to intelligently speak and plug in, um, your product messaging or the problems that you solve directly into the messaging that they've built their relationships based on. Yeah. So many of these, these, uh, uh, tools are presented like technically yes.

Technologically, we, we say sometimes is horizontally. There is, um, some widget that is going to turn, you know, some bucket of data into something useful or something that can be pushed into a pipeline, right? That's the technical view.

But you, you really benefit. And, and the partner in particular, the, the service provider benefits from being able to explain why, why does it do that? What is the benefit?

And keep, sometimes the benefit is another layer to say what's the benefit of that? I mean, it all comes down to running an organization or running a business, but if you can put a little shape to it to say, this allows disparate work teams around the world who are sometimes disconnected to be more connected to a central work stream. That's something specific.

And it's not about the technology, it's about what helps the organization run. So I hear a lot about people process and technology and how it kind of comes together. I definitely, I know that's a, a mantra you kind of stand on and you talk about quite often, guy.

And I think it's a good thing because I mean, a lot of times people forget that it's you, especially on this channel here that we're talking about with, you know, it's, it's really heavily focused on DevOps. Um, it's about acceleration and, and faster time to value. Um, you know, one of the things we did talk about, and guy you brought it up is managed services, right?

And sometimes when we look at that, um, approach, some of these sis that we talk to and, and VARs that we talk to, and even vendors themselves, um, there's kind of several paths to get to where these application needs to be modernized, right? So, um, when I think about managed services, right? And I think about hosting environments, actually in our recent research, we see that 34% of of respondents indicated that they, uh, want, would like to use managed services over 17% using pure distribution.

And yes, you get more functionality out of pure distribution, but you have to have the bench strength to, to support that. Right? And, and Scott, you touched on a, you said a term that I'd like to kind of maybe double click a little bit down on is, and you said the sell to versus sell through.

Maybe, uh, if we can talk a little bit about that, because when we think about managed services, are we selling to somebody? Are we selling through To that? Yeah, no, I mean, I think it's important to kind of the sell to, for us, you know, to a certain extent is you're working with your partners.

Uh, if they are looking at managed services, then the value that they're gonna be receiving is what they're looking to make their profit on as they, as they roll through to their end customer, right? The amount of, um, feature rich or, or the problem set that they're trying to solve on their customer becomes very precise. Maybe it's not quite as big, but they are delivering.

When you think about direct sales, what we always talk about is, you know, I, I go to the store to buy a skill saw, but I'm not interested in buying a skill saw. I'm interested in the deck that I'm gonna build with the skill saw. And I think we have a tendency to forget that we're doing that, especially as we're going through partners.

We've built content, we built messaging, we built training to go direct where we're selling a skill saw that is not what a partner's selling. So if they can take advantage of your product to build a service around it and then deliver a very specific purpose built solution to the customer that gets to just consume the value, then they're willing to take a little bit less of a problem set, but they've got confidence that it's gonna be delivered. And I think the difference is the sis and your partners are responsible for delivering a solution.

And I think to a certain extent in the direct motion, we maybe have forgotten that we want to show our wares, we want you to take it on, we want you to buy it. Uh, but we haven't necessarily thought through are they going to receive the value that we sold or are we just implementing something and walking away, which is the big risk for DevOps implementations, modernization implementations, is there's a lot of organizational risk and taking on those projects, I think. Yeah, that makes sense.

And, and guy off camera, we talked a little bit about, um, go to market strategies. How does go to market strategies kind of align to this, this whole approach and, and thinking about it from the context of, you know, different, different ways to get the, the product to market for the audience to look at what we're talking about here and they're trying to say, Hey, we need to get, accelerate our development, our our business KPIs. What's a go-to-market strategy mean to them?

I think two things. Uh, one is, um, to take seriously the kinds of stories, I call it storytelling. 'cause a lot of times it's called messaging.

Mm-Hmm. That's such a marketing term. I feel like it carries a weight that it shouldn't.

So there's a story about whatever this technology is on the one hand, and there's a story about your partner, whether it's a managed service provider, the system integrator, solution provider, just a plain old reseller. They have a story and a value they're providing. It's usually a simplification of some kind, but not necessarily.

It may be a deeper implementation, maybe expertise. There's a lot there. Uh, the, the poor vendor of this product, the creator, the originator of it, is trying to both help you as the end benefit, end user of it, understand, um, what value it's gonna bring to your organization with the story, as well as helping the, the, the partner understand beyond just its value to you, the partner's customer, also the value to the partner themselves.

That's that whole sell to and sell through side. So what I would say is, this is one of the elements that seems to make it complex when you are trying to figure out how to take advantage of a new technology. I will say the word AI right now, sorry, had to come up here.

That is a typical example. Something of obvious value that can be extremely confusing, where you would want to turn to a partner to try and figure out where best to address it and to be able to address it effectively. But the partner's agenda and the partner's need from the vendor is part of that whole lens.

Just keep in mind the one simple truth, which is that whatever product or tool it is, it's been built for a purpose. It's built to save you, it's built to extend you, it's built to give you capabilities you didn't have before any of these things. And you might have a difficult time doing it, but if you keep that as your north star, then you helps you understand the different players involved and maybe make better decisions.

Yeah. I I, I like where you were going with that. And I, and I will actually bring us back to AI because you know, when I think about, sorry, no, I have to, it's, it's kind of top of mind for a lot of people.

But like, but when we think about the real data that's around ai, and I think about my research that I recently fielded about eight, nine months ago, I fielded a research study that showed, uh, 18% of organizations were using AI and production workloads. Okay? And I reran that, um, recently, and that 18% jumped to 54%.

mm-Hmm. So there is an acceleration of using AI and there's also an acceleration of using service delivery partners to get the job done, of course, right? Because of you can't in that short window of time to learn everything you need to learn.

And if you don't have those resources, you know, on, on the bench right now, it's almost impossible to get that up to speed that project. Well, and even from a vendor perspective, right? Yes.

So I think that's where sis and, and your partners are gonna be able to kind of plug your, your solution into a much broader story where they do have that expertise. And I think at the end of the day, as long as you're precise on the stories, they can understand what the value is that your piece brings to their broader puzzle, right? What you don't wanna do is build up a, uh, a services organization that's outside of your core, uh, function as a vendor to go and attack a new market.

If you can push that through a channel that has that expertise and maybe just needs to understand the value that your product is Bringing, and the inverse is true too, right? If you as a consumer and customer understand the core value of your organization and what you are doing, that helps you identify areas where a partner might be a better option. Yeah.

One of the things that you've said, uh, Paul that's really insightful is that there is a trade off, um, that end users are happy to make when they're working, especially let's say with MSPs, where their feature capability may be limited for a given tool set, but it's a simpler, uh, more, uh, a straightforward approach to adopting a technology. So that's the trade off. They're gonna get less out of it, but it's going to be more reliable for them that it does not make sense if this particular functionality or functional area is core to your mission as an organization.

Yeah. So this also helps you to differentiate where you should be working with partners or work with partners across the board, but where you're gonna take a more hands-on approach, where you're gonna train yourself up, where you're gonna learn as opposed to where you're going to want something that's more set it and forget It. Yeah.

Yeah. This, this is, uh, this is really great dialogue because I, you know, I, I, I was thinking of another data point, of course, that's what I do. 'cause I'm an analyst, right?

Uh, but you know, basically I had this, uh, observability study that came back from the field and it showed 52% of the respondents are using six to 15 different observability tools to gather data within their organization, right? Six to 15 tools. That's just for observability.

Not to mention security, not to mention development, not to mention the CICD pipeline or, or SDLC as overall, but that's a lot, right? So having those resources and those, uh, vendors available, or those sis and g and bars available to help you is important. Well, it's not only important, but it's sort of essential, right?

Because you're not gonna have the credibility as a single vendor to be able to speak that broadly, um, across a tech stack like that. So you do have to have somebody that does have the relationship or does have the market credibility to make those recommendations in the hope that you are a part of the solutions that, that get, uh, plugged in thereafter, right? Absolutely.

Absolutely. Well, as we're coming to our end, uh, guy, would you like, like to leave the audience with a final word? Uh, just be demanding of all your vendors, whether they are, uh, channel managed service reseller or the, uh, original vendor.

You can ask anybody. They are supposed to work with each other to help you. Thank you, guy.

And Scott, You know, I think I'm good. I mean, at the end of the day, I think when you look at a direct motion versus, uh, as a vendor going in and supporting your customers or your prospects, uh, and you're looking at direct versus the channel, uh, you know, it just becomes, from an enablement perspective, from a sales standpoint, you need to recognize that the motion is different. Um, and that you have to be a little bit more precise.

You can't just recycle what you've been doing with your direct and expect to have a successful channel and successful implementations. I think unless you treat it with a little bit more care. You're minding me of my original point.

I'll still give you the last word, but keep in mind that at the bottom or top of all this, the origination point of all of this is the core value that's been engineered into the tool or product, whatever route it takes to you. If you keep that in mind, that helps orient you through all of this. Yeah.

Well, I wanna thank both of you for your time and your perspective today. This has been really, really great. Um, the thing is, I want to give the audience also, um, you know, hope that there's help out there to help you get your projects and your initiatives done.

The, the intent of this session was to basically so show that there is a lot out there resources available to you to get the job done. So with that, thank you for your time. com to learn more about our research and our, our information.

Thank you and have a great day.