In this episode of PLATO Panel Talks, Mike Hrycyk delves into Managed Services as an engagement model with our experts Craig Fisk (Chief Growth Officer, PLATO) and Paul Holland (Principal Consultant, PLATO). With his background in selling and delivering managed services, Craig explains why a wide range of reasons, from risk mitigation to access to a wider range of expertise, might drive companies to choose managed services. Paul, who is currently working on a managed service, shares his insights on the day-to-day realities, the opportunities for Testers, and the keys to success in this delivery model.
Episode Transcript:
Mike Hrycyk (00:00):
Hello everyone. Welcome to another episode of PLATO Panel Talks. I’m your host Mike Hrycyk, and today we’re going to talk about managed services with our panel of testing experts. Managed services are interesting to me. We have done them across our entire history at PLATO, but they’re always something that we’re trying to move towards, and a lot of testers out there don’t even understand what they mean. So, part of our discussion here is to help us understand what managed services are. If you’re a tester, how does that impact your life? If you’re a customer, why would you ever do it? So, I think that’s going to be interesting and I’m glad to be taught about that. So without further ado, I’m going to ask Paul Holland to introduce himself.
Paul Holland (00:40):
Hello, my name is Paul Holland. I have been a software tester since 1995. I spent 17 years testing telecommunication software in Ottawa. I was working for Newbridge, then it got bought by Alcatel, which then merged with Lucent. After I did that, I ended up moving to New York City and I taught underemployed and unemployed people in New York City how to test software through a company called Per Scholas, which is a nonprofit. Keith McIntosh, the CEO of PLATO came and visited Keith Klein and I, who were essentially running a large portion of the program. Keith saw what we were doing and then took it back and improved on it immensely and it became the impetus of the training and employment program that PLATO Testing has become working with First Nation and Indigenous peoples. And then, after I left that role in New York, I worked in the medical field at a company called Metadata, and then I worked in retail at SACS Fifth Avenue. Then, I got hired to be a principal consultant with PLATO.
Mike Hrycyk (01:58):
Thanks, Paul. Welcome to the chat. Craig, tell us who you are.
Craig Fiske (02:02):
Thanks, Mike. I am Craig Fiske. I am the Chief Growth Officer for PLATO. I’ve been with PLATO for about two years. My background briefly is about 13 years at IBM, where I spent a lot of that time selling, managing, delivering, managed services, not necessarily across testing, but there’s a lot of similarities that certainly translate. And then was a co-founder at IT services company that had some identity management frameworks that we delivered across Canada. We also did that in a managed capacity. A really neat thing about my journey to PLATO was I was a customer at one time and fell in love with the mission and really what the team from coast to coast has accomplished and the values in this company. And when I had the opportunity to jump in two years ago, I took it. So, thanks, Mike, for having me on the panel.
Mike Hrycyk (02:50):
Thanks, Craig. No pressure, but you are the first salesperson we’ve ever had on one of our talks, to my recollection. I think you’ll represent well because you understand managed services from a unique perspective.
Craig Fiske (03:01):
I’m so honoured. <laughter>
Mike Hrycyk (03:03):
Okay, let’s jump in. So, I’m going to start in a place that we normally start in one of these, which is let’s define what we’re talking about. There’s a lot of confusion out there about what a managed service is, and what it means. I think some people have a clear idea, but I think a lot don’t. So let’s start again with our sales guy. Craig, tell us what is a managed service?
Craig Fiske (03:25):
Well I mean, so my experience with it is, it can come in kind of a broad range of just call ’em contractual arrangements, but generally speaking, it’s a delivery model where a partner such as PLATO delivers a specific function to the client. So typically, in sort of an outcomes-based scenario, rather than a contract that is based on time and materials where we are just trading hours for money, it’s really a model where we align with customer objectives. That could be within it, it could be at a bigger, broader level from a corporate perspective, but we’re delivering to outcomes that we’ve defined with the customer, and we’re reporting on those outcomes, and we’re measuring on those outcomes over the course of one year, three years, five years. And there’s a lot of reasons to get into it that we can talk about in a little bit, but it’s really – think of it as just a different way to share the risk with a vendor when you are looking to procure services beyond just time and materials or hourly rate.
Mike Hrycyk (04:26):
Paul, anything to add to that?
Paul Holland (04:28):
It’s doubtful that I can be more clear than what Craig was, but the way I was thinking of it is instead of hiring just workers that would report to the managers and the leadership of the customer (which is a common way of supplementing your workforce), in a managed service, you’re providing leadership as well. So, you’re providing an entire management team that looks after the area. So, currently where I’m at right now, we have a leadership team in place that’s looking after some of the testing, but there’s still other parts of the testing that’s being done by other contractors. So, in a managed service typically you have a leadership team in place that will look after all of the testing; the entire project would be handed to, in this case, PLATO to look after and be fully responsible for it, including identifying performance issues and replacing those people and things like that.
Mike Hrycyk (05:29):
I guess some people – or maybe a long time ago when I thought of managed service, I thought – maybe I thought this because the company I was at – they said we’re going to outsource all of it. Managed service doesn’t have to mean that some external body is taking over the entire function. It doesn’t have to be all of it. It can be a finite prescribed piece that just somebody else owns. Would that be a good way of looking at it?
Paul Holland (05:50):
Yeah. So right now the development side is looked after, not exclusively, but primarily by a different contractor. One of our partners is doing most of the development, and PLATO is doing most of the testing. So, they’re currently in discussions to have Deloitte look after the managed service of the delivery of the software and the maintenance of that software. And with PLATO, I believe the discussions are going on. Craig can answer that better than I can, being on the sales side. But having PLATO then look after the testing side throughout the remainder of the development and then the maintenance moving forward. So yes, you can have the managed service of just being a piece of it, or as you indicated, you could do the whole thing and say, we want to do this big project. And you get a company that does – or small project for that matter – that takes the entire thing and develops it, tests it, and then hands it back to you. So it can be as big or as small as you like.
Mike Hrycyk (06:47):
Craig, anything to add to that?
Craig Fiske (06:49):
Yeah, that was pretty good. The one thing I would add to it is particularly just about every environment we’re in is a multi-vendor environment. It’s with multi-stakeholders, so meaning Paul just talked about Deloitte being involved. There are other vendors. The governance and the managing of –if we define our service, and you sort of use a black box analogy – so the inputs and the outputs to what we do and what our team is responsible to do, taking time upfront to define what are the responsibilities of the client, what are the responsibilities of PLATO? What are the responsibilities of other potential vendors that might be developing the software inside of that organization? And then you actually need to come up with that governance model on who’s responsible for what. So, if there’s a hiccup on the customer’s end or the vendor’s end, you know how to handle it. You know who’s responsible for it, and you know how you’re going to manage that small mini – hopefully, it’s not a crisis, but that little bump in the road as things go forward. So they take time to set up, but when you have them set up correctly, and the communication flows, the impact to the customer can, in my experience, really be positive from what they’re trying to accomplish.
Mike Hrycyk (07:55):
I guess that’s sort of a big difference between a consultant who’s just in there in time and materials. Generally, you’re not saying, “no” as a consultant. You’re not saying, “that’s not my job, that’s not my responsibility”. You’re helping in any way that you can until someone asks you to do something that you completely – it’s not part of your experience. So, well, you’re just going to do whatever you can to help. That’s what being a consultant is. When you look at a managed service, it’s more along the lines of, “this is our responsibility area, we’re going to help you in this area, but we have a RACI that says when you ask me to do that, I’m not going to do that. That might impact my ability to deliver on what I have to deliver”. Would that be an accurate way of looking at it, Craig?
Craig Fiske (08:34):
Yeah, or here’s the scenario where you do. So if this is the thing and it’s outside of my scope, here’s the approval process to sort of get it done. And so there’s kind of an understanding that way. If you think about it, Mike, just to build on what you said, a time and materials model, if I’m on a time and materials contract, I’m being directed by the customer. It’s up to the customer to tell me what I’m doing day in and day out. In a managed service model, my activities are more dictated by the outcomes of the contract of what we have to deliver that particular output piece to the client. So, there’s a little bit of risk mitigation from a customer’s perspective if they can define that properly with a vendor on what that managed service looks like, rather than trying to keep a team of 10 or 12 people busy and hope they’re out doing the right things.
Mike Hrycyk (09:18):
That makes sense. Paul, does that fit your experience?
Paul Holland (09:21):
Yes. One of the – and not at all disagreeing, I fully agree with what Craig said, but one of the most interesting aspects that I’ve seen over a couple of these situations and whether it’s a full managed service or in the situation we are, where we appear to be working towards that, but we each still have our areas of responsibility in our roles, is in the first few months there was not much interaction between the testing team that I was leading and the development team. We were more working closely with the subject matter experts and not the developers themselves. And, that was, in my opinion, and looking back, a mistake because now that we are definitely working a lot more closely with the developers, we’re at the stage where we’ve already gone live with a partial scope, and as a result, the bugs that we’re raising were in bug triage meetings, and there’s a lot more close relationship and a lot more interaction between the development side and the testing side from PLATO. And that really picked up probably in the October-November timeframe. I joined in March and while we were trying to get stuff done in the summer and we didn’t have that really close relationship, it was a lot harder. There wasn’t really any personal relationships built. So there was no one I could just call. There was no, I guess, inherent comradery, with the exception of being on the same team, and going towards the same goal. But we were essentially different units. We weren’t on the same playing field. So one of the things that has really helped a lot is to have developed these relationships now over the last few months with the other vendors so that we are a lot more – it feels to me like we’re being a lot more cooperative. And, I’m sure there was a lot of cooperation happening in the background just beforehand, but now that I had a lot more face time and a lot more time in meetings and a lot more interaction, we’ve developed a substantially better and much, much more effective, in my opinion, relationship with the development team. And it’s really showed dividends in the last couple of months of what we’ve been able to get to make our go-live date.
Mike Hrycyk (11:38):
Paul, that’s a good segue into a question I was going to ask in just a second. So we’re going to jump to that. I was going to ask what does a managed service normally look like? And then I had a sub-question of is it like working with a bunch of strangers? I think you’ve already addressed that. When it’s working it’s not a siloed group of strangers that you’re talking to, right?
Paul Holland (11:56):
And that was something that I’ve seen in the past is people who are put in silos and don’t have the option of talking to people in other groups. If you’re on the development team, you’re not talking with the business unit. If you’re on the test team and you’re not talking to the developers or the business unit. Things being thrown over the wall historically end up being caught by nobody and just kicked around a lot. There’s very little empathy towards the other team members if you don’t have that relationship. And so, I’ve seen it so many times in the past where there isn’t a symbiotic relationship between all of the elements. And as a result, there’s more finger pointing, a lot less people just stepping up saying, “Hey, I’ll do that because it’ll help out Craig. And I like Craig, so I want to help him out. It’s only going to take me a couple of hours.” If I didn’t know Craig or Craig, I’d say, I’m not going to do that because it’s not my job, and there’s nothing in it for me. So it definitely behooves somebody to make the effort to learn who is on the other teams and try to build those relationships. And a lot of times as a more junior tester, you don’t have that capacity. I’ve been in companies where we’ve said, Hey, as the testing team, can we go talk with the end users or with anything like that? And the answer’s been, no, you can’t. So, it’s relatively more challenging and much more challenging if you don’t have that capacity and you’re not acting as one big team, but instead you’re a bunch of clusters of individuals.
Mike Hrycyk (13:34):
And some advice that I would feed back to the businesses engaging managed service providers is you need to be the facilitator. You need to set the understanding that you want your delivery people to talk to each other. But you also run the risk of people who are bitter, that they’ve potentially lost friends who worked at the company because their roles have gone to the managed services. And that can be hard to fight with too. Craig, anything to add?
Craig Fiske (13:59):
Yeah, I guess I would say not always do the roles get eliminated. Often the roles that are impacted by a managed service are maybe a little bit more transactional. And so, there’s often opportunity for people that may work for a company that brings on a managed service to get into other roles related to their field. The one point that Paul was making bang on that I’ll just add to was really around, so you talk about relationships and communication. When you’ve got that many stakeholders, you need to formalize that communication, and you need to formalize the roles within that communication from both the PLATO side, the vendor side, which could be an SI. And to your point, Mike, the customer has to be invested in this. You can’t – talk about throwing it over the fence, and that company’s going to manage this for us. That just doesn’t work. You need to have that formal communication governance where you are aligned. And that model can look different at each organization depending on how complex or not complex the contract is. But my experience is you can’t overcommunicate in a lot of cases when it comes to managing a service in a multi-vendor environment where there are big stakes on the line.
Mike Hrycyk (15:06):
Awesome. So I’m going to move into the questions about the rules of individuals, and etc, but I didn’t want to get too far past a question we skipped first. So, one of the truths about consultants is they’re expensive. Everyone’s always conscious of how much they’re spending and etc, for consultants. A managed service route is essentially a big package of consultants. So why would a company choose to go the managed service route, understanding that cost that might come with it? So let’s start with you, Craig cause you have to actually sell this.
Craig Fiske (15:36):
Well, I think there’s different ways on measuring the impact. So, if you look at consultants, you’re typically, you’re just measuring hourly rate times, whatever, 1900 hours a year, and you sort of get, that’s what this individual is costing me. With the managed service, there’s opportunity to bring in right size, different skill sets within that. So you could have a mix of seniors and juniors, so you can sort of offset a little bit of that financial model. You might also be able to bring in a tool or a platform to help drive economies of scale or output or shorten the time to market, all these kinds of things.
So, the important thing around a managed services, is what are we really trying to solve here for the customer? And what is that business challenge, whether it’s at a corporate level or just within IT and how do they do that today? What’s their cost model of doing that today and what does ours look like if we come in? And surprisingly, my experience with in my past selling and delivering managed services, it usually wasn’t to reduce cost for the customer, it was usually centered around risk or there wasn’t availability of resources. They couldn’t get there from here, you know what I mean? And so, the only way they could do it was to go to an organization where that was their core competency, and then they could build that into their delivery model and then, quite frankly, challenge that vendor or that partner over time to drive operational deficiencies, some optimization, and build that right into the contract over say a three or five year period and sort of look at that holistically. And that’s a different way to think about delivering versus grabbing a team of 10. By the way, grabbing a team of 10 is still a hundred percent valid. Managed services is just a different vehicle to get to the same way and it’s usually driven by other drivers.
Mike Hrycyk (17:22):
And I think you’ve captured one aspect of that, which is you’re bringing a big bucket of expertise. These guys know how to do that, whereas we don’t. I’m going to throw you an easy one here, Paul, which is the other variable here, which is the variability of that you can bring to a project as a managed service. Do you want to address that a little bit?
Paul Holland (17:40):
So, typically if you’re pulling in one or two people to help out, you’re looking at usually senior/intermediate principals, very experienced people, because there’s no one to supervise the junior people and the amount of extra effort that is required often to supervise junior people is an expense that the customers don’t have. If you’re bringing in a full team, you’re not only being able to bring in junior people because you have the supervisory/leadership built in, but you’re also bringing in the beautiful variability that having a mix of junior and senior people brings to a team. And it might sound a little facetious or condescending, but it’s not. The newer testers have built-in superpowers called being new, and they look at the world differently. They use software differently from me. I’ve been –I’m old, I’ve been doing this too long, I know things that can break historically, and I poke at those with a stick, and people say, wow, that’s really impressive. But because of my experience, I also have far more biases and far more predispositions to what I’m going to do and how I’m going to test that, essentially, get in the way of me finding things that most common users may just find by turning it on and using the product. So, the superpower of being new, the superpower of not being set in your ways or knowing things that historically work and don’t work, you’re going to gain those as a tester. You’re going to get the superpower of experience, but don’t discredit having a mix of superpowers of experience and the far more difficult to get is someone who understands testing, can write a good bug report, can understand that they’ve noticed a bug, but not having, I guess, as I’ve already said, the predisposition into looking for certain things. Definitely gives the managed service team a much broader capacity of finding defects and just bringing in one or two senior people.
Mike Hrycyk (20:02):
That’s a brilliant point. In addition to that, I think that if you have 10 people and they work for the company, for the customer, each one of those people has a finite set of skills. They’re good at X, maybe Y, but they’re maybe not good at Z, G and H, right? But when the managed service comes in, they’re not restricted to the same 10 people. They can look at where you are on the site of that project, and maybe you need a month of a performance tester. Well, you bring in that performance tester for the month or accessibility or data. And so, when you’re working with a managed service, it’s part of a larger company that has a whole bunch of more representative people in it, and they have a lot more freedom to shift the resources around without as much problem and complaint. Alright, so Paul, I’m going to give you a hard question. Is a managed service team a good place to work as a tester, and why?
Paul Holland (20:54):
Yes, but also working anywhere as a tester is just awesome. But on a managed service team, you are part of a bigger group. So, you may think, well, I don’t have as much chance to shine, I don’t have as much chance to stand out. But based on what I just said in my previous answer, you would have the capacity of being an integral part by testing differently to the other people. So, it’s also a great place to learn if you end up being on a team that has a little bit of extra time. Currently, we don’t. But if you’re on a team that does have a little bit of extra time, you may get the senior people being able to do some training. You can pair test with the more senior people. When senior people pair test with junior people, if they are open to it, they will also be learning. I know when I was at New Bridge, I had a university student who came in, and I pair-tested with him. I had been doing a very similar job for about five years at this point, and I thought I knew it inside and out, and he said, I’m going to do this. And he configured it in a way that I thought was illegal and not allowed. And I stopped him, and I said, no, you can’t do that. And he goes, I’m pretty sure I can. I said, well, let’s find out. And he could. And because he didn’t know that he couldn’t, he tried it, and he could. And so I went and talked to the developer, and the developer told me, oh yeah, we changed that two releases ago. We made it so it could happen. But no one told the test team. So, for two releases, we hadn’t been testing something that our customers would be doing intuitively, but this university student just did it. So, I learned something from the university student because he was willing to tell me when I said he couldn’t do it; he said, “no, I’m sure I can. Let me show you.” So that’s a good lesson as well. If you are pair testing with an experienced person, allow yourself the confidence to know that you can very likely know things that they don’t about the project and about what you’ve been doing. So, take advantage of being able to show off and don’t just immediately say – if the senior person says, you can’t do that, don’t just crumble and say, okay, sorry, and go into a shell. Even if they are right, at least you’ll get to experience it. And anybody who’s pair testing should not be making the other person feel small or inadequate. If they are, then if you’re the senior person, you’re not doing your job. And if you’re the junior person, then you’re probably just a bit of a jerk.
Mike Hrycyk (23:31):
Just like the developers who put in a feature and didn’t tell anyone! Anything to add there, Craig?
Craig Fiske (23:36):
Yeah, so what I’ve seen, and this is outside of testing, just sort of a mixed team of senior skill sets and maybe more junior skill sets. It’s a great place to be mentored, and it’s also a great place to become a mentor. So, as a team lead, you learn how to lead other folks, you learn how to help them with their skill development, and there’s growth that can happen in sort of a semi-controlled environment. The other advantage it has for it, I believe, is delivering a managed service you need good process, and that good process becomes good habits, and those good habits get ingrained in not just the juniors, but the intermediates and the seniors. And, ideally those habits would be taken forward into their next engagement, into the next managed service, wherever it might be. So all those things Paul said, and then I’ll just add that little bit of icing on top of his cake.
Mike Hrycyk (24:28):
I think that’s a really good point. If you’re a consultant who’s just sent to a singular – sent to a client, there’s this expectation that you know how to do all the things and you not say no, and you just learn on the fly. But you might not learn, and you might not represent very well. But at a managed service, we’ve talked about it, you have a lot of different specializations within that. You have an appropriate process. So, it’s a really good place to learn foundational skills and etc, so that later when you are put alone to a client, you have a much broader base of understanding and knowledge.
Alright, I got the two left that I’d like to hit. The one is, what is a good way of maintaining the domain knowledge that you’ve learned? We’ve talked about people are going to roll on and off these projects, they’re going to have to ramp up quickly or else why have a managed service? The managed service company needs to be an expert. So what are some good ways of managing that onboarding and continued knowledge?
Paul Holland (25:22):
Pair testing almost definitely is the most effective way to bring somebody up to speed in most situations. Being able to – personally, the worst way to bring me up to speed is to give me a 400-page document and say, read this, and then you’ll be able to start testing it. My brain doesn’t work that way. I will not be able to read a 400-page document, and then if I’m not playing with the system, if I’m not interacting with it or talking to people, I’m not going to be learning about it. And one of the things that I like to think I excel at, one of my strongest capacities is the ability to pick up a new system and to be able to talk intelligently about it. And I don’t get that by reading documents. I’ll reference documents. I’ll look up the Confluence pages or requirements documents, and I’ll reference them. If there’s something like I’m not sure what the response time is supposed to be or whether this rule is being applied correctly, I’ll go and I’ll reference it. But sitting down and just using the product, and if you can do it with somebody showing you along the way, which pair testing is the way I prefer to do it, that’s by far, in my mind, the most effective way of bringing people up to speed.
Mike Hrycyk (26:48):
Yeah, one of the ways we’ve always said to people is to run test cases, and paired testing makes that even accelerated.
Paul Holland (26:55):
I was going to say, I don’t like writing detailed test cases either. If you need a detailed test case to be able to test, then you should be pair testing until you learn the system well enough to be able to follow a workflow or scenario that has very vague instructions on it. So, right now, as an example, some of our workflows just say, create a policy. They may not even specify whether it’s an auto or a home policy, and to create a policy, it’s multiple pages in the system to create it. And we don’t have any of the detail of what you fill in. It’s just – unless that’s the important part of what that test is doing. But for the most part, things that aren’t specific are left open-ended so that the tester will not always create a single-family home homeowner’s policy at 123 Main Street. They’re going to be creating a complete variety of things. And as a result, we have found bugs that wouldn’t have been found otherwise. Just things that we found over the last few months that obviously have been fixed, but it’s – detailed test cases. I know that has nothing to do with the question you asked, but I did want to say I don’t like detailed test cases.
Mike Hrycyk (28:10):
It also supports the idea that you shouldn’t have the same person run the same test case over and over and over again because they use the same thing. Craig?
Craig Fiske (28:17):
Well, the only thing I would say beyond domain knowledge. So, if we’re delivering a managed service and we’re expected to deliver an outcome, I always like my teams to understand how they’re impacting not just the area that they may be contracted to, but the overall impact on the business. So, we’ve got folks working on autonomous mining applications for a company in Canada, and helping that team understand the impact of what they do to those machines underground and what that means actually to that business unit and to the company it adds an element, I think, of engagement to it. So for me, when we onboard folks, do they understand the impact that they’re having beyond their daily duties on how they’re impacting the business? And that would be the only thing I would add.
Mike Hrycyk (29:08):
And I agree if you dive too quickly into teaching people nuts and bolts without enough context, they’re not really going to understand.
Paul Holland (29:17):
Just one quick addition, Craig made me think of something. Pair testing with another tester from the managed service, or just even if you’re in a non-managed service, small group is great, but Craig had a very good point there. And that’s being able to work with the end users. Being able to work with the domain experts from the company is phenomenal. One of the testers that I worked with had spent quite a few months with the development team, and then when they transferred to working with the customers, doing more of an end-to-end, are we ready to release testing. They said they learned more in the two weeks than they had in the months with the development team. They were talking with an end-to-end user. And so they learned not just what the software is “supposed” to do by written requirements, but how the people use it and what they’re looking for and what’s important to them. So it completely changed how she did her testing because she was now focused on different things as opposed to just: it’s supposed to do a, is it doing a? It’s also supposed to be usable. And what are some of the problems that the software is supposed to be solving that the old software had, and is it better? I’ve worked on one project that I thought it was horrible. It was absolutely garbage, and when I showed it to the new end user, they said, this is so much better than what we currently have. I love this. And I just went, what? It completely blew my mind. So, talking to the end users might be a great way of making sure you’re focused on the right thing.
Mike Hrycyk (30:45):
Awesome. Okay, so we are really close to our line. So, short answer for this one – that might be challenging. So, I’m in senior leadership at a product company with internal resources. What are some signs that I should be considering a managed service? So we’ll start with you, Craig.
Craig Fiske (30:59):
This can vary a little bit, depending on your industry, depending on your maturity as a customer. But some of the common drivers I’ve seen could be as simple as retention. We just can’t find people in the region that we’re in. It’s impacting our ability to get products to market. If you’re in a high-risk industry, for example, like healthcare or something along those lines, and there’s reputation risk, there’s other risks associated with it, and you’re struggling to get your products or get your platform out there. There’s usually an underlying pain point or business driver from the client. And we like to think it’s always about driving out costs. I think I said earlier, often it’s not. Sometimes it is, but often it’s not. It’s usually related to the output of the team or risks associated with not getting products out there that have been properly vetted. So, kind of, maybe a wishy-washy answer, Mike, but it is a pretty broad question. And it’s up to us as an organization at PLATO to understand our customers and maybe where some of their challenges are, what they’re trying to accomplish before we show up and say, hey, you need to manage service. No, in a way, you kind of have to earn your way there, and you do that by understanding the customer and what sort of their specific challenges are. So yeah, I’ll close it at that.
Mike Hrycyk (32:21):
Thanks, Craig. So, Paul, your only goal here is to be shorter than Craig’s answer. <laughter>
Paul Holland (32:28):
The indication that you might need a managed service would, in my mind, often come down to either capacity. So you’re not able to meet your own goals and deadlines capability. You’re not doing it well when you release something. Or you’re building something. It’s either not doing what it’s supposed to, or your customers hate it or whatever. Or just a realization that we’re not going to get there with our current skill set. Looking in the mirror with, I guess, the right amount of judgment of your self-awareness to say, do we have the capacity of getting to the goal line with our current team, or do we need to either build upon it or go the next step to a managed service?
Mike Hrycyk (33:13):
That’s great. Good. I’d like to thank you guys for joining us for a really great discussion about managed services. I understand more now than I did before. Thank you to our listeners for tuning in. If you have anything you’d like to add to the conversation, we’d love to hear your feedback, comments or questions. You can find us at PLATO Testing on X, LinkedIn, Facebook, or on our website. You can find links to all of our social media and our website in the episode description.
If anyone out there wants to join in one of our podcast chats or has a topic they’d like us to address, please reach out. If you are enjoying our conversations about everything software testing, we’d love if you could rate and review PLATO Panel Talks on whatever platform you’re listening on. Thank you again for listening, and we’ll talk to you again next time.