How to shorten a six-month recruitment period to three weeks?

Stephen

Derek, good morning! Welcome to the Devico Breakfast Bar! Great to speak to you today. I thought before we got into some of the meat of our discussion, you might share with us kind of a bit about your role, your journey to where you are today, and some of your key responsibilities right now.

Derek

Thanks, Stephen. Really appreciate the invite onto the Devico Breakfast series. It's a great privilege. So welcome to my very colorful home office today. I am the Group Chief Technology Officer for Marcol, we are a private equity investor and operator based in London. The business has been trading since 1976, initially as a investor in real estate, but today we find ourselves investing in a bunch of different verticals, still with real estate as a large part of what we do, but I'm more focused on the healthcare side of the business.

I've been working in tech since the early nineties. I still remember when connecting to the Internet involved taking a device with lots of flashy lights on it and connecting it to your phone line. And after a weird handshake sound, you would get a really slow internet connection. Then as soon as, at the time your mum, or your dad, or your sister, or whoever picked up the phone line that would be it: your internet connection was killed.

I've been really fortunate in my career to have been able to work all across the world. I've spent time in Australia, Indonesia, Germany. I came to London in 1999, you can probably hear from my accent 'm not originally from here, I'm from Glasgow.

I worked in the city for a couple of years for a large Japanese bank, spent four years at Microsoft in the early noughties doing high-performance internet engineering for the MSN team, which was great fun. I spent some time working for the team on Xbox Live as we were designing and rolling out product in Europe, back in 2004 I think that was. I then spent time across three sort of smallish startups and scale-ups between 2006 and 2013 some really interesting businesses in there. And then I joined the BBC for a couple of years, which was really interesting, a fantastic organization. Lots of really interesting large-scale tech to be involved in and play a part in, including the myBBC digital personalization program, where I was one of the tech leads. I've been with Marcol since 2015, where we've been scaling across four primary healthcare verticals since then, including diagnostic imaging, B2C consumer pharmacy, telehealth, telemedicine, and with the real estate business continuing to grow in the background.

Stephen

It's a really extensive experience, Derek. So it's great to be able to share some of that with us. And we can sense the enthusiasm in your voice for your role and the things that you've done. But how about sharing with us something a little bit more about you around, something that you're really passionate about within the environment you work in.

Derek

I was working as an engineer, and as a Principal Engineer, and as a hands-on Chief Technology Officer for many years. But my role has changed quite a bit since then. I've got younger, brighter, and far more capable people in my teams today, my role is to support and counsel them. And actually, that's where, I think, I've probably found my passion and my niche in life, which is I really love helping other people succeed, and I'm super passionate about getting the best out of people and being an enabler as a manager and staying out of their way so that teams can do their roles to the best of their abilities.

Stephen

Okay, thanks. Now, here's a tough question. You've done lots of things, but how about telling us what you would say is probably your most important accomplishment as a CTO?

Derek

I think there's probably two here that stand out for me. One would be a technical accomplishment and the other would just be a team and a team growth accomplishment. As to a technical accomplishment, I was part of a team that built from scratch the world's first newspaper PDF to article business inside the Newspaper Licensing Agency. That was a transformative technology project using tech that we were developing along the way. It just simply didn't exist at the time. In doing so we revolutionized a particularly niche industry, the press cuttings industry. But it was a revolution in itself, and that's a business that's still growing and is very successful today.

I think, on a teams level for me, I've always had, certainly in my later career, a good eye for seeing the potential in others. I think I would recognize this became apparent to me when I worked at Microsoft, I was surrounded by engineering talent that was off the charts better than I was. No, I wasn't a bad engineer! I was very solid, I was capable. But there were people that I worked with that were significantly better than I was. I was okay with that. You know, that's great that we've got people like that, they really push the boundary. But for me, I think that exposed me to being able to spot that in other people and drive that potential in other people.

And that's what I've sort of developed over the last 10 to 12 years, which is that good eye for seeing the potential of and potential in others. And as a result of that, particularly in my role at Marcol, I've built a team around me, where, you know, the churn rate is almost zero, the performance rate is incredibly high, the levels of trust are really high, the engineering and technical capability is really high. And I like to think that a lot of that is because I've been that glue component that's identified that, and held all of that together through the years.

Stephen

Thanks. It's interesting, you referred a lot to seeing some significant changes from the very first time you started in the tech space to where you are today. How do you go about keeping up with those kind of significant and rapid changes in our space today?

Derek

When I first started in tech – probably dating myself at this point: that was the thick end of 30 odd years ago, 25 to 30 years ago – technology was a lot simpler. In some respects, it was more complicated. In other respects, it was simpler than it is today. I think it was more complicated because you had to be very detail-oriented. Historically, there wasn't a panoply of user interfaces to do stuff. Quite often you were operating in the command line. You had to genuinely understand what was happening on the back end in order to put systems together. At the same time, there just weren't as many systems. So actually, one person could have quite a lot of knowledge about quite a lot of things that were going on.

I think today there's an explosion of tech. There's tech for everything. It's embedded in everything that you do. Your refrigerator in your kitchen has tech in it. The mobile phones that you carry around today, I've got more tech in them than put the man on the moon. And I know it's a bit of a cliche, but it's very true. I think it's impossible to realistically stay on top of everything that's going on today. It's not possible for one person. For me personally, I rely very heavily on my teams to inform me and educate me on what's going on. I spend quite a lot of time reading. I read tech papers. I try to keep up with what the vendors are doing, what the vendors are publishing, particularly the likes of Microsoft, and on the infrastructure side guys like Amazon and Google.

Does that mean that I have a fully rounded view of what's going on? Probably not. But I think, like I said, it's very difficult for anybody to have that. Where I have developed a bit more of a focus is keeping my eye more on health tech and med tech. I think I've had to do that as a result of the businesses that Marcol have large investments in. I have to be able to provide support to the boards and the management teams of those businesses, and also my colleagues who are the CTOs in those businesses as well. Staying on top of that has become a sort of more of a focus for me over the last few years. But I think this is a problem that's not gonna get any easier. It's only going to get worse, as tech becomes more sophisticated, more complicated, broader in scope, and more heavily utilized in day-to-day life.

Stephen

Okay, thanks. And I think there's no doubt that in a rapidly changing environment, there's often times when we are getting involved in projects or making decisions where sometimes we might be trying to second guess the best way to go ahead. I wondered if you could share with us any funny experiences you may have had with a particular project or an experience as you've developed through your career.

Derek

A funny experience at work? Well, I'm trying to have them as often as possible! If you can't laugh your way through life you've maybe got a problem!

I can think of one of the big things in tech is to never make assumptions that you, you believe that the next guy knows what they're doing. I can think of two experiences. I wouldn't name the names or the companies because they were quite big mistakes at the time, but they were quite funny because they were both based on incorrect assumptions. We once took down the entire production site of a business because somebody hadn't followed a checklist and they'd literally made one small error. What they'd done actually is they'd put a smiley face on something, and somebody had misinterpreted the smiley face as a zero, and that ended up being put into a DNS change which killed the site. That was kind of funny…. but not!

Another one: there was a publishing platform where we were trying to get some content out last minute. I think it was either Christmas or Easter, so there was a special going on. And one of the devs who was using a picture of themselves as a test image and mistakenly published that test image of themselves onto the main site.This was a site that millions of people would have seen and had the picture of the developer on the front page for about five minutes before somebody realized the mistake and pulled it. Again, it's kind of, it's one of these things in hindsight, which you laugh at, obviously, at the time, but it was pretty serious.

Stephen

Let's get into some of the technical stuff, which I think will be very interesting for some of our listeners. Talk us through how you would go about making choices around what computer language or development framework you would use. And how much of a standard should it be?

Derek

That's a really hard question to answer. Every product, every team, every business, every end goal will have a different set of parameters, which will inform and educate you as to what your language approach is going to be, your framework approach is going to be, your testing approach is going to be, your quality approach, your infrastructure approach. All of these things will be different for every single project. What I always tell my teams though that I'm not religious about any of this.

I don't have a personal preference because, at the end of the day, it's not me delivering and implementing the product. It's the teams that are doing that. They have to self-assemble and determine what's best for them. But for me, it's about just driving a standard, which is to say if you are going to do this, here are the minimum standards for how you're going to do it, which is you'll write correct documentation, you'll do inline documentation, you'll do this in a continuous integration environment, you'll make sure that your code coverage is above a particular threshold, yadda, yadda.

And then it's up to them to kind of self-organize around that. Where it becomes harder and where I've and my teams have often, I wouldn't say struggled, I think it's just where it becomes slightly more complicatesd is we buy a bunch of businesses and as an investor, we'll quite often see interesting tech or interesting management teams, and we'll say: "We want to buy them" for their tech or their customers, we'll bring them in, and then we'll make them part of something bigger – classic private equity build and buy strategy.

Where it gets harder is where you have one team who's been used to doing one thing for one way for a long time and then bringing them into a team that does something potentially completely differently. Quite often then the discussion becomes, it becomes a bit more dogmatic between the teams, and quite often my role is to sit in the middle and say: "Okay, well, we understand why you've done it this way" or the team over here, same argument, and to arbitrate between the teams trying to come up with a position where both teams are happy. Now, that's not a process that happens overnight.

Quite often this is something that takes 6 to 12 months to bed in. Quite often the arguments aren't necessarily about the choice of language or how it's been done. Actually, it comes down to cultural differences between the teams and it becomes more of a kind of people-focused problem than a technology-focused problem. So again, getting to the kind of root of that is quite often what I spend my time doing when as we go through that kind of post-acquisition process when it relates to whose processes and technology ideas are going to win out in the fullness of time.

Stephen

Derek, what are the characteristics of a good software or IT system design? And how do you differentiate a good architecture from a bad one?

Derek

Have you ever gone to the dentist? You've gone to a new dentist, and you lie back in the seat and you open your mouth, and they look in, and they go, 'Ugh!" They start sucking their own teeth. I wouldn't have done it like that!!

That's quite often the problem that you find with IT systems, which is one chief architect's view of what good looks like quite often will be different from another chief architect's view of what good looks like. Now, there are common themes that would probably reflect something that people would say is high quality.

And I think that's generally applications that have been architected in a modular way where the code is readable and commented, where you understand without having to think too hard about what particular code blocks do. I can tell you kind of counterpoint to that, which is I've often been in the case where I'm looking at – and this was some time ago, admittedly, I haven't coded for many years – but I did spend some time looking at code, a code block, trying to get my head around it.

And I was actually thinking in the background: "What lunatic wrote this? It doesn't make any sense." Just, I couldn't get my head around it. It took me an hour before I realized that the lunatic that wrote that code block was actually me. And I just, I had forgotten it. And that's a really good example of what not to do.

If you come back to your own thing and you don't understand what you did, then you've probably got a bit of a problem there. Always use the analogy of being able to pull someone off the street who was a developer, and put them in front of your monitor, and say: "Right, what does this thing do?" and they can, after a few minutes, can say: “Well, it does this.” That's perfect for me. But it never works like that in reality.

To your point at the beginning, people are time-pressed. They are looking for the shortest path to get to the outcome they need, which quite often is not the optimal path. There are quite often multiple people competing on a particular thing. And whilst they're trying to work together, there's different ways of mentally solving problems. So people will come at this from different ways.

So you'll end up with inconsistencies through your work. That's actually why, Stephan, you have this idea of something called refactoring. And if you've not heard of refactoring before, and I'm sure people are watching this, but refactoring is weird. You go back and look at stuff that you wrote six months ago and say: "Well, we know that that wasn't optimal at the time. We're gonna go back and rewrite this the way that we know we want it to work today.”

And that's a constant process. If you look at how development teams spend their time, approximately two-thirds of development time should be spent on just looking at what you've already done, and making it better, and doing infrastructure support, and security updates, and patching, and performance improvements. Only about a third of what a development team do is actually building new product. And a lot of businesses don't get that percentage correct.

Stephen

Derek, what would you recommend for developers to learn who are wanting to expand their skills right now?

Derek

Hard skills are definitely teachable. And I think we're really fortunate that we live in an age where free education is available for almost any topic imaginable, in particular, technology topics. There is a panoply of choice for providers where you can learn how to do everything from coding to infrastructure, to testing. Wherever you want – it's available. These are all things that are teachable. You can sit, and learn, and reproduce, and be tested, and all in the comfort of your own own home. I think there's some other areas though where, and I really, I don't want to generalize here because it's very easy to generalize, but I think soft skills are actually more of a problem for technology staff than hard skills.

I often work with extremely gifted people who are technically expert but struggle to, for example, communicate in a way that a customer would expect them to, struggle to articulate themselves in a way that's understandable to their colleagues and understand some of social norms. I think that people expect when you're working in a group situation. If I think about how I hire, Stephen, I really, I'm looking for the basics, the kind of hygiene factors: can they do the job that we're hiring them to do? And that's very much, you know, technical interrogation of their skills and capabilities.

But that's only 50%, really. The other 50% is can this person work in a team? Can I trust them to communicate clearly? Will they be disruptive? Can they manage the relationships with other people? And I'll often reject extremely good candidates who are technically capable but can't deliver on the soft skills side because I can't tolerate in my team the disruption of having somebody who is not harmonious with working in that kind of group setting. So for me, I would always encourage people, if they're self-aware enough, and that's another challenge for people that often struggle. But if there is a self-awareness there, soft skills training for me is absolutely kind of key. Soft skills training is a key pillar for people to be able to move forwards and progress with their career.

Stephen

Good. There's that irony. The soft skills are the hard skills, right?

Derek

Correct. Yeah, yeah, yeah.

Stephen

And I think you described how important those skills were to you. I mean, how difficult is it to find a specialist, a good specialist, as you've described, these days?

Derek

I like the subtlety of what you said in your question.You said a specialist, then a good specialist. And I think there's people that call themselves specialists, and then there's actually people that are good specialists out there. It's a real challenge, Stephen. You know, I've been in this role for nearly eight years. Now, consistently, when I'm reporting up to the owners of Marcol, Terence Cole and Mark Steinberg, when I'm talking with them about the main concerns that I have is always around talent sourcing, talent retention, and talent management.

I can't think of a year where that hasn't been my number one kind of concern. I think, firstly, there is just a talent shortage. There always has been a talent shortage in tech, and it's a talent shortage that's widening because the drive to digitization globally means that there are, by definition, more people needed to drive that digitization. But we're not getting people through the education system quickly enough to fill the empty roles. I think the B word plays some impact here. I think Brexit has meant that there was a flight of talent who would have previously liked to have stayed in the UK have now gone back to their home countries.

And that's fine because their home countries are growing, and we should absolutely be supportive of that. But I think it would be disingenuous of us to say that Brexit isn't a factor here. I think the contractor rule changes in the UK I know that the Truss government flip-flopped on that, but the IR35 rule changes mean that a lot of flexible talent that was previously on the market is no longer on the market anymore. To the point that you made in the beginning and the subtlety of a specialist or a good specialist, there have been many tens of thousands of redundancies in the tech sector over the past six months.

In fact, I think I was reading an article yesterday where in the States alone there's been something like 120 to 130, 000 tech-related job losses since the middle of the year. There will be some really good talent in that. And again, I don't want to generalize. Quite often these companies aren't getting rid of their best people. I know that's a bit of a damning statement, but I do stand by it that quite often when you're downsizing you want to keep your best talent, and quite often you'll get rid of your average talent or the talent that isn't performing for you.

That's the States. I can only assume that's mirrored here as well. So even today, if I do want to find a particular specialist soon, I'll give you an example - Go. We're looking for Go Developers just now for one of our businesses. And it's incredibly difficult to find people with Go talent who want to work in our business for the rates that we can afford in the country where we're operating. So yeah, always a challenge.

Stephen

Interesting. Could you give us a bit more information around your team, in particular the kind of size, the blend of specialist' skills that you have in it right now?

Derek

Yeah, I'm in a slightly unusual position, and I work for the investor here. We ourselves, we don't have our own teams of developers and engineers. I'm the director of a few businesses. At Marcol, for example, Terence and Mark as individuals are the main shareholders in a technology services business that provides engineering and architecture support back to the businesses that are under common ownership. But that's a team of 25-28 people. Some of the bigger businesses that we've got, HealthHero, which is our telehealth business, that has about a hundred and sixty technologists in its team.

Our Atida pharmacy business operates across Holland, Germany, France, Italy, and Spain, and it has several hundred technologists working across all of these sites. These are reasonably big teams. These are teams of mixed specialists. Stephen. As you would expect, depending on what the business type is will inform what the technologies in use are. But these are end-to-end teams. So there's everything from people providing first-line support through to people architecting the backbones of the e-commerce platform or the logistics platform, and really everything in the middle from service management, quality management, systems design, UX, UI, development, engineering, DevOps. It's all kind of in there, and inside that there's a blend of staff.

I think the majority of staff, probably 80-85% are permanent headcount. And then, maybe 15 to 20%, roughly, the balance will be either contractor or augmented talent. And augmented talent plays quite an important role for what we do because sometimes we need to spin R&D up really quickly and we don't want to distract the core team or we've got a niche requirement for a particular skill set that we can't source locally, and we'll bring augmented team resource in as well. But generally speaking, it's pretty permanent heavy. But as I said, there is a very real and very pressing need to have a flexible resource pool available to us as well.

Stephen

Interesting. That blended use of augmented staff there, I just wondered if you could tell us what it was that actually brought you to the concept of utilizing IT outstaffing to help with your resourcing model.

Derek

Back in 2018, we were doing a replatforming in one of the businesses. This is a business that had an existing product and platform, which was end-of-life. It's always a big risk when you say: "We're going to build something net new on the side." It's probably the most high-risk way to treat a rebuild. Normally you would put a box around the old thing and then start to build new functionality on the outside of that box. And then over time, the contents of that box become less and less as you have more new stuff on the outside.

But this wasn't going to work in this situation because of just how old this was. It was going to, it would have been a nightmare. So we took a full replatforming decision. And some of the technologies that would form the basis of that replatforming. And going back to the question that you asked me earlier about what technology would you use to deliver stuff, in this case, we wanted React because that was going to be the right technology for us for the type of capability that we wanted in the new product that we were developing.

We couldn't find React developers in 2018. It was just an impossibility for us. React was not that new at the time, but it was new enough that there was a reasonably narrow number of people that knew the framework inside out. And we ended up using an outstaffing business, actually, a team augmentation business to help us with React developers. They had React developers. We needed React developers. They gave us their React developers. It was really that simple. And they were embedded with us on the project for, I think, about 18 months, actually. So this ended up being quite a long-term engagement where they were providing this specialist resource for us.

Stephen

Derek clearly an advocate of utilizing IT outsourcing and outstaffing for your resourcing model. I wondered if you could share with us a description of the key pain that you feel outstaffing resolves.

Derek

The typical amount of time to hire a permanent resource in the UK, a development resource, a senior development resource, is a minimum three months where that's the usual notice period for a senior developer. Then, in reality, it's not three months because you have to spend time finding these people first. So you can add at least sixty weeks to the beginning of that. You've got two months just to find a candidate, three months from you finding them, giving them an offer, they accept, them resigning - to them being able to join. So you are five months in at that point. And then it takes them another minimum two months to become effective. So you're actually not getting any value out of them until month seven.

And then by the time month seven comes around, they could be like, "You know what? I've had an even better offer somewhere else." And then they leave. I know I'm laughing there, but I'm laughing because this is actually a genuine situation that I've seen some of our businesses go through. And it's frustrating, and it's heartbreaking, and all of these kind of negative things, but it is a reality. So why would you do that to yourself if you have a need for a product to be developed quickly, so you can get it in front of customers, the customers can start using it, they can love it, and give you feedback about whether it's working or not.

So for me, outstaffing is I can phone my partner up, I can phone Devico up, and say: "I need a resource to do X." And they'll say: "Cool, give us two weeks and we'll find that for you," "we have someone now," or "It takes us a couple of weeks." And then there'll be a week after that and then they'll be yours. So I've already shrunk that five-month period down to three weeks, maybe four at worst. I haven't had to pay them to find this person for me. So all of that kind of cost is on them and all of the work is on them. But the expertise is on them, and the process is on them. So they know how to do this a lot better than I do.

So they're going to take all of that and take that headache away from me. I can then onboard that person really quickly. And that person then becomes effective for me probably after four to six weeks of them joining. And I'm not unreasonable: I don't expect somebody to join my team and for them to immediately be productive. That's a naive way to look at how people actually work. But it's a difference, Stephen, between that seven-month wait and the one-month and a further four to six weeks, whatever the number is, before that person becomes effective. So I'm saving five months in reality through that process. I think that's point one.

Point two: hiring resources through an outstaffing, team augmentation, staff augmentation business – it's a contract. It's not an employment contract. So the staff augmentation business deal with all of the employment law, the HR issues, managing and motivating their own staff. I only have to pay the invoice at the end of the month. And I don't have to worry about any of the legals and HR surrounding that. I'm also getting a predictable resource as well. Importantly, I'm getting a resource that when I need to turn them off, I can just say: "Thanks guys, that's been amazing, but we're done now."

And with a notice period, that's it. So I've got no long-term obligations, unlike in the UK, where if I've hired somebody, and my project takes 25 months, but at the end of that 25-month period I'm done. As soon as I go over two years, then I really struggled to get rid of people. And I don't like doing that apart from anything else. When I hire somebody permanently, I want to hire them permanently, and that's that. And we hope to have a long and successful relationship with each other. So I don't feel comfortable hiring people that I know I'm going to get rid of. So again, team, staff augmentation businesses really help with that.

Stephen

You gave us quite a lot of detail there, which is helpful around some of those pains. But if I was to challenge you and say to you: "Can you give us a number of bullet point headlines as to what are the true benefits of outsourcing?” Just bullet point headlines. What would they be?

Derek

Bullet point headlines for outstaffing. I think it's easy access to resources. I think you have either equivalent or lower overheads, and I think that's a really important point. You have a speed of onboarding win. You have known costs. You have a lack of permanence where that lack of permanence is important for you, so you can easily spin up and spin down. And I think you have very straightforward contracting. There's no HR overhead needed when you're working with an outstaffing business.

Stephen

Derek, every solution has pros and cons. Could you share with us your view on what are some of the drawbacks of IT outstaffing?

Derek

Outstaffing is generally a remote model. I haven't actually ever seen an outstaffing model where their staff are in your offices. I'm sure they exist, but I haven't come across them. So when the person that you're working with is always only somebody that you've ever seen on the other side of the screen, I think that can lead to a certain amount of social distance from somebody who's supposed to be embedded in your team. So I think it's really important that you recognize that as a drawback. You're never going to meet this person.

You're never going to shake their hand. You're never going to go for a drink with them. I think it's incumbent on the hiring business to make a greater effort to integrate those staff members. I think it's also important that you find a reliable partner that genuinely understands your business. I see too many outstaffing companies. Stephen, I get 30-40 emails a day with people selling me stuff that I don't need, particularly outstaffing businesses. And they don't care, they don't make an effort to understand me, or my businesses, or the problems that I might have. They're just selling me bodies, and they don't really care whether they sell me one body or five bodies.

Whereas a company like Devico, who we've worked with for five years, Oleg went out of his way to understand my business, understand the market, understand the team, understand what I was looking for, and the types of people that I wanted on the team, understood the kind of personality types that would be interesting for me, knew not to put particular types of people in front of me because he knew I would reject them.

So that trust where you find the counterparty going above and beyond to find out about who you are, I think, is really important. At the end of the day, there's always going to be occasional tissue rejection. I think that happens in any situation. I don't think that's necessarily a function of outstaffing. I think when you bring new people into a thing, sometimes it just doesn't work. Right? Everybody's made a bad hire. I've made many bad hires in my career.

And that's just life. You have to accept that it was a mistake, and you change, and you move on. And I think the same is for outstaffing, which is sometimes the person that you've got just doesn't work out. I think, having a good, honest, straightforward conversation with your partner to say: "Look, this person is wonderful, but they're not integrating into the team. We can't get it to work. Can you find someone else?" I think that's an important conversation that you need to be able to have with your partner.

Stephen

Thank you. Derek, I wonder if you could share if there's any specific examples where you've looked back and thought, you know, outstaffing that made the difference here. It worked really well for us in this particular instance.

Derek

I can give two examples actually. So our staffing worked really well when we were spinning up an MVP for one of our real estate businesses. We needed to build and develop a technology platform from scratch. This involved net new self developed functionality, so very bespoke, also involved a bunch of integrations with existing tech in the IoT, Internet of Things space, involved integration with a bunch of payment providers.

But the business didn't want to take on the responsibility of hiring and finding and managing a tech team. So we gave this all to Devico to do as the kind of V1 and MVP. We managed them remotely. I did quite a lot of management from that, but that was, again, it was a great example of where we just said we needed people to do a thing. They gave us a business analyst, developers and testers, and they went off and built the product for us.

Was it super smooth? No, of course it wasn't. But it wouldn't have been super smooth if I'd just built it up with my own team. And it would have taken me longer and probably cost more money. These things never work out with 100% satisfaction. But I was very happy with what the Devico team delivered, and as were the business.

Another example, actually I'll just refer to the example that I used before, which was we were struggling for particular technology skills.

We couldn't find them in the UK at the time, and outstaffing was the solution to find those skills. We had a long-term relationship with, I think, at one point up to five specialist developers from Devico over a period of 18 months. And they conducted themselves perfectly. The work was of a very high standard, and they integrated themselves really well into the team. And we would have been able to deliver on time and on budget, had it not been for the involvement of Devico's resources.

Stephen

Thank you, Derek. You have a longstanding relationship with Devico. I'd just be curious, because there are other choices in the market. Why did you choose Devico and how's that working relationship been over time?

Derek

For me, it came down to shared values, actually, Stephen. And we did go through a process, back in 2018, when we were looking at team augmentation, staff augmentation, and outsourcing in general as a concept. And out of all of the businesses that we spoke with at the time. We worked with businesses in Portugal, which was really hot at the time from an IT outsourcing and outstaffing perspective. We were talking to companies in Poland and Belarus, and other companies in Ukraine.

But the difference was Oleg, who's the Co-Founder of Devico.He was the only one that really went out of his way to form a relationship with me, understand what I was trying to achieve, align his own goals to what I was trying to get out of this, and then make it work for me. He was the one that made me feel like I wasn't just part of a kind of sausage machine process that once they got me signed, it'd be fine and the whole thing would just fall down because they wouldn't care because I'd already signed a contract. That never happened with Oleg.

He was on top of it every day. When we did hit speed bumps along the way, and there were plenty of them because, again, we all have to be adults about this. Stuff goes wrong all the time, particularly when you're dealing with people. Oleg was on top of it. It was dealt with professionally, it was dealt with quickly, and we moved forward. Oleg really focused on Devico as a business, really focused on not only the hard skills, but again – I keep coming back to this 'cause it's so important – the soft skills.

The soft skills really matter. I think in some level – Stephen, you could argue that – in an outstaffing arrangement whilst you're hiring them for the hard skills, their ability to deliver soft skills is probably more important because you're in this remote environment where you need to work harder to be able to have that kind of good integrated relationship with the other side.

But again, that's something that they focused on. And then there's the hygiene factor stuff. They're a stable business. They had at the time we're working with some really good enterprise customers as well. I had really good references from them and from their customers. And they were flexible. And I think these things all, when I thought about the things that matter to me, they were the ones that just had that little bit more on the kind of personal touch side to make the difference between whether they won or lost the process that we went through.

Stephen

Derek, what would you say to those who haven't yet dipped their toe in the IT outstaffing solution or indeed are considering it but still a little bit hesitant to have a go? What advice would you give them?

Derek

Find a project or a product where you don't want to distract your core team but you do have budget and a bit of flexibility. And find a partner that will give you a trial. I think any partner worth their brand and worth their reputation will give you a trial of their process and their resources: two weeks, three weeks, whatever the number is. You can go off and negotiate that yourself. But, see how that works out for you. It might not work every time. Thats - again - that's just life. Right? Your own staff might reject it. You might not like it personally. You might have made a mistake with the outsourcer, the outstaffer. They've given you a bad experience, whatever.

But I think find somebody where you at least have the opportunity to see whether this is going to work for you. One caveat to that, I would say that make sure that when you are doing this that you yourself have the right characteristics about you as an individual, and that your team and the infrastructure surrounding them have the right characteristics to bring someone in from the outside. It's not going to work if you bring somebody in, and then just leave them alone, and tell them to get on with it. That's not how these things work. You need to make that person feel like they're genuinely part of your team.

If you have a big stable team, where adding one person in isn't going to be a big deal, then that's a really good example for you to use. If you have established infrastructure and you want to spin up something new over here, again, that's another really good use case for you. If you're a scale up and you're adding 5, 10, 15 people a month to your team, this person might get lost and all of that. So I would maybe say that's not the best use case, unless they have very, very specific canned technical skills where you can measure and manage their output because you can see what they're doing at a technology delivery level. Then again, that would be a potential use case.

Stephen

Derek Colvin, CTO globally for Marcol. Thank you very much.

Derek

Stephen, thank you so much. Great questions. Thank you so much.