On this episode of DevOps Dialogues: Insights & Innovations, I am joined by Guy Currier, VP & CTO of Visible Impact at The Futurum Group and Scott King, Managing Partner at Sprinter Associates for a discussion on the impacts of outsourcing skill gaps.
Our conversation covers:
- Challenges and complexity, tech stack issues, and the impacts of skill gap issues
- 34% of organizations indicated that they would like to use managed services
- How vendors enable service delivery partners and enable them
These topics reflect ongoing discussions, challenges, and innovations within the DevOps community.
Watch the video below, and be sure to subscribe to our YouTube channel, so you never miss an episode.
Listen to the audio here:
Or grab the audio on your favorite audio platform below:
Disclosure: The Futurum Group is a research and advisory firm that engages or has engaged in research, analysis, and advisory services with many technology companies, including those mentioned in this webcast. The author does not hold any equity positions with any company mentioned in this webcast.
Analysis and opinions expressed herein are specific to the analyst individually and data and other information that might have been provided for validation, not those of The Futurum Group as a whole.
Transcript:
Paul Nashawaty: Hello and welcome to a special edition of DevOps Dialogues. My name is Paul Nashawaty, I’m the Practice Lead for the app dev practice at The Futurum Group. I am joined today by Guy and Scott. Guy, would you like to introduce yourself?
Guy Currier: Sure. I’m Guy Currier. I’m the CTO at Visible Impact, which is the go-to-market advisory and marketing services division at Futurum.
Paul Nashawaty: Thanks, Guy. And Scott?
Scott King: Scott King. I’m a managing partner at Sprinter Associates, specializing in sales and commercial strategy for DevOps and business intelligence.
Paul Nashawaty: Excellent. Thanks guys for joining me today. This is a really great topic, really great area that we’re going to go over today. A lot of organizations are trying to modernize. When I talk about my practice and I talk about a lot of the activities that are going on with regards to modernization, it’s that past, present, future. 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 deploy.
But a lot of times, I hear from organizations that they’re met with challenges and these challenges are complexity and tech stack issues, but also skill gap issues. And part of the skill gap issues is they don’t have enough resources on their bench to do the job. So when we talk to vendors and tech stack and the pieces, even if organizations are looking at using open source tools and such, they want to use potentially a service delivery partner to get the job done.
Guy Currier: Oh, yeah. A lot of them do. Managed services and yeah.
Paul Nashawaty: Yeah. That’s definitely an area that we will talk more about that for sure, because that’s an area for faster growth, but when we look at the service delivery partners, how would you enable an organization to get these delivery partners up to speed?
Guy Currier: So from my perspective of the work I do, a lot of the work I do is to work with these vendors on their 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 enabling this whole market. So if you, as a developer or application team or IT team, are working with a partner, 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 the reason the product is designed the way it’s designed. There is core value.
There’s all kinds of contributions to that value. There’s even just the culture of the vendor, the style that they have, the engineering style, or 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.
Paul Nashawaty: Yeah. That makes a lot of sense. And then when we think about those fast or time to value and using these service delivery partners, I think a lot of challenges organizations have is how does the vendor enable these service delivery partners, SIs, how do they enable them? When we talk to DevOps and they say, “Look, hey, we want to get going and we want to get these organizations to help us.” How do they enable it?
Scott King: Yeah, I think guys said it. I think at the end of the day, as a consumer of the products, you’re looking to solve a specific problem. So the idea of selling a specific tool in isn’t necessarily going to 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. So a lot of it is 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 work through? 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 your product messaging or the problems that you solve directly into the messaging that they’ve built their relationships based on.
Guy Currier: So many of these tools are presented like technically, technologically, we say sometimes is horizontally. There is some widget that is going to turn some bucket of data into something useful or something that can be pushed into a pipeline. That’s the technical view. But you really benefit, and the partner in particular, the service provider benefits from being able to explain why. Why does it do that? What is the benefit in 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.
Paul Nashawaty: So I hear a lot about people, process, and technology, and how it kind of comes together. I definitely, I know that’s a mantra you stand on and you talk about quite often, Guy. And I think it’s a good thing because a lot of times people forget that, especially on this channel here, that we’re talking about with, it’s really heavily focused on DevOps. It’s about acceleration and faster time to value. One of the things we did talk about, and Guy you brought it up, is managed services. And sometimes, when we look at that approach, some of these SIs that we talked to and VARs that we talked to, and even vendors themselves, there’s several paths to get to where these applications need to be modernized.
So when I think about managed services and I think about hosting environments, actually in our recent research, we see that 34% of respondents indicated that they 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 support that. And Scott, you touched on, you said a term that I’d like to maybe double click a little bit down on is, and you said the, “sell to versus sell through”. Maybe if we can talk a little bit about that because when we think about managed services, are we selling to somebody or are we selling through to them?
Scott King: Yeah, no, I mean I think it’s important to… The sell to, for us, to a certain extent is you’re working with your partners. If they are looking at managed services, then the value that they’re going to be receiving is what they’re looking to make their profit on as they roll through to their end customer. The amount of feature rich 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 I go to the store to buy a Skil saw, but I’m not interested in buying a Skil saw, I’m interested in the deck that I’m going to build with the Skil 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 Skil 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 going to 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, 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 in taking on those projects, I think.
Paul Nashawaty: Yeah, that makes sense. And Guy, off camera, we talked a little bit about go-to-market strategies. How does go-to-market strategies align to this whole approach and thinking about it from the context of different ways to get 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 business KPIs.” What’s a go-to-market strategy mean to them?
Guy Currier: I think two things. One is to take seriously the kinds of stories, I call it storytelling because a lot of times it’s called messaging. 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, a 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.
The poor vendor of this product, the creator, the originator of it, is trying to both help you, as the end benefit and user of it, understand what value it’s going to bring to your organization with the story as well as helping 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 it helps you understand the different players involved and maybe make better decisions.
Paul Nashawaty: Yeah, I like where you were going with that. And I will actually bring us back to AI because when I think about-
Guy Currier: Sorry.
Paul Nashawaty: No, I have to, it’s top of mind for a lot of people, but when we think about the real data that’s around AI, and I think about my research I recently fielded, about eight, nine months ago, I fielded a research study that showed 18% of organizations were using AI and production workloads, and I reran that recently and that 18% jumped to 54%. So there is an acceleration of using AI and there’s also an acceleration of using service delivery partners to get the job done.
Guy Currier: Of course.
Paul Nashawaty: Because you can’t, in that short window of time, to learn everything you need to learn, and if you don’t have those resources on the bench right now, it’s almost impossible to get that up to speed that project.
Scott King: Well, and even from a vendor perspective. So I think that’s where SIs and your partners are going to be able to plug 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. What you don’t want to do is build up a services organization that’s outside of your core 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.
Guy Currier: And the inverse is true, too. 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. One of the things that you’ve said, Paul, that’s really insightful is that there is a trade-off 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, more straightforward approach to adopting a technology. So that’s the trade-off.
They’re going to 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. 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 going to take a more hands-on approach, where you’re going to train yourself up, where you’re going to learn, as opposed to where you’re going to want something that’s more set it and forget it.
Paul Nashawaty: Yeah. This is really great dialogue because I was thinking of another data point. Of course, that’s what I do because I’m an analyst, but basically I had this observability study that came back from the field and it showed 52% of the respondents are using 6 to 15 different observability tools to gather data within their organization. 6 to 15 tools. That’s just for observability. Not to mention security, not to mention development, not to mention the CICD pipeline or SDLC overall. But that’s a lot, right? So having those resources and those vendors available or those SIs and bars available to help you is important.
Scott King: Well, it’s not only important, but it’s sort of essential, right? Because you’re not going to have the credibility as a single vendor to be able to speak that broadly 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 get plugged in thereafter.
Paul Nashawaty: Absolutely, absolutely. Well, as we’re coming to our end, Guy, would you like to leave the audience with a final word?
Guy Currier: Just be demanding of all your vendors, whether they are channel, managed service, reseller, or the original vendor. You can ask anybody. They are supposed to work with each other to help you.
Paul Nashawaty: Thank you, Guy. And Scott?
Scott King: I think I’m good. At the end of the day, I think when you look at a direct motion versus as a vendor, going in and supporting your customers or your prospects and you’re looking at direct versus the channel, it just becomes, from an enablement perspective, from a sales standpoint, you need to recognize that the motion is different 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.
Guy Currier: You’re reminding 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, at 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.
Scott King: Yeah.
Paul Nashawaty: Well, I want to thank both of you for your time and your perspective today. This has been really, really great. The thing is, I want to give the audience also hope that there’s help out there to help you get your projects and your initiatives done. The intent of this session was to basically show that there is a lot out there of resources available to you to get the job done. So with that, thank you for your time. I want to thank the audience for watching our session today and to learn more information, please come to the futurumgroup.com to learn more about our research and our information. Thank you and have a great day.
Other Insights from The Futurum Group:
Application Development and Modernization
The Intersection of DevOps, Platform Engineering, and SREs – The Futurum Group
Exploring DevOps with Futurum’s CEO
Author Information
At The Futurum Group, Paul Nashawaty, Practice Leader and Lead Principal Analyst, specializes in application modernization across build, release and operations. With a wealth of expertise in digital transformation initiatives spanning front-end and back-end systems, he also possesses comprehensive knowledge of the underlying infrastructure ecosystem crucial for supporting modernization endeavors. With over 25 years of experience, Paul has a proven track record in implementing effective go-to-market strategies, including the identification of new market channels, the growth and cultivation of partner ecosystems, and the successful execution of strategic plans resulting in positive business outcomes for his clients.