How to choose between in-house development and IT outsourcing?

Oleg

Hello, Joe! Welcome to our Devico Breakfast Bar! I appreciate you’ve found the time to join me today. Could you please tell me a bit about yourself and share your journey in digital space?

Joe

Sure. Yeah. I am a product person. I've been doing that for about 30 or so years, but I started perhaps as a developer and then software architect. And along the way, I've also run sales teams. I've also founded a couple of businesses. So, a relatively wide set of experiences, perhaps more than an average product person. And I guess my career and my life has been in sort of three chunks or three kinds of work. I've done a fair amount of blue chip stuff: big corporates like eBay, Thomson Reuters, GSK, and every. Also, I've done some consulting principally in the UK into UK tier-1 retailers, so people like Argos, Homebase, Devons, Maplins, New Look, et cetera. And then also, as I say, I've been a startup Founder. I've done that twice actually. Once in 2000 and once in 2017. So yeah, three different kinds of stuff, lots of different industries, lots of different experiences, but I like to think product is the thread that runs through it.

Oleg

Great. You have worked in various industries, as you mentioned, including retail, eCommerce, automotive, pharma, publishing, banking, logistics. When I was searching, I was a bit shocked by the variety of industries. How do you leverage your diverse industry experience when approaching new challenges in the digital business space?

Joe

Sure. Yeah, you're right. I have been in a lot of different things. And I guess I like to learn. I like to compare and contrast. And I think maybe that's kind of the value is that you get to understand quite quickly what's common between industries and between companies and then what's different in different industries. And I'm always fascinated to learn how certain industries are very cost-led, certain industries are very long-term, R&D focus. So, pharma is a good example. And so, you know, that causes you to operate differently, to behave differently, and to understand what's going to be successful in each kind of organizational culture, each kind of industry context. But it also means you can sprinkle from one industry to another. So, retail was pretty early into eCommerce and into digital things, and they have a pace about retail because you report your numbers every Monday or whatever day it is, which you can then bring into other organizations. At the same time, as I said, pharma is much more strategic, much more long-term. So, you can bring some of that thinking, and some of those techniques, and best practices into retail. So, yeah, I'd like to think that there's a lot to learn from different places.

Oleg

Definitely. Thanks. Are there any common trends or principles that you find applicable across different industries when it comes to growth and transformation in digital business?

Joe

Sure. Yeah. I guess, as someone who's mostly about digital transformation, that's just consistent from industry to industry. Everyone is attempting to be much more customer-centric, much more product-led, much faster, much more innovative. So, those trends are consistent. Wherever you go, you'll talk to someone who's interested in being more customer-centric. What I find interesting is how different industries think about that, and where they are in that spectrum, and how used to talking to the customers they are. In retail, for instance, again, you're very close to the customer, you're engaging with them daily, and they're always telling you what they want. In other industries, you could be much more internally focused. And I think, you know, my learning would be that it's always about culture. Really, if you're trying to get a digital transformation done, you need great tech partners, great tech capabilities, but it's really about how do you orientate your culture. And some cultures are much more externally focused and some are much more internally focused. So, yeah, but those trends are pretty much consistent.

Oleg

Got it. Are there any key lessons or principles that have been particularly instrumental in your career that you would like to share with our audience?

Joe

Yeah, I mean, I think, building on that point around culture, I think it's always about meeting the organization or the individuals. So, people like me are always learning about best practice and understanding how it works really well in Silicon Valley and how Google, Meta, Apple, and Amazon all do this stuff. The question, though, is how do you make it pragmatic and digestible and how do you consume those best practices in the right way at the right time for your company and for your role within it? I think for me, that's also been a personal learning. I've had to learn over my career and I'm still learning how to not just talk about what the best practice should be or to try and force people to do the right thing and instead recognize what's practical and possible at that point in time for the company, or for your boss, or for your team.

Oleg

Yeah, I totally agree with you. Sometimes C-level leaders, they confuse, they just use best practices and apply it everywhere. They don't understand that it's even applicable here. I noticed this a lot of times during my career. Could you mention any professionals or leaders from your network who inspire you in your professional journey?

Joe

Yeah, I guess, as a product person, there seems to be no shortage of gurus. You know, there's the obvious people like sort of Marcy Kagan, Teresa Torres, Melissa Perry, John Cutler. There's a very long list of people who have become quite famous for understanding how to do product really well. I've definitely benefited from reading all of their stuff. But as I say, the question is how much of it you can use. But I think actually at a more personal level within my own career, there's probably been sort of two or three people that really stand out as having shaped me and how I work. And one of them, you know, a chap called Andrew Hughes. I worked with him. He hired me twice. And what I loved about him is he's operating in cliches. So, he would forever just use cliches and phrases. And that was very easy to learn and understand. I use the same cliches now with my team and people I work with, and I pretend they're mine. And in fairness, he probably stole them from somebody else as well. But it just becomes easy then to tell stories and to get people to come along on the journey. So, he was very influential on me.

Oleg

Okay, great. In addition to your professional life, do you have any personal interests or hobbies that you're passionate about and how do they complement your work or provide balance in your life?

Joe

Yeah, I'm not sure they provide balance necessarily. My sporting habit, so my major interest apart from my children and watching them play sports, which I very much enjoy, personally for me, I'm a triathlete and tend to do Ironman and so long-distance endurance events. What I would say about that is it teaches you how to do things that are long, hard, and painful, and where the payoff is quite a long way away.And maybe that's a lot like the work that I do as well, isn't it? Sometimes it can feel that way. It's a bit of a slug. It's an endurance event, I think, digital transformation and product management. But the trick also maybe is to find quick wins along the way and things that make you feel the opportunities to celebrate. And the nice thing about triathlon is it is three different sports. So you can, as soon as you've done the swim, you're like, 'Great! I've done that.' And you feel really good about finishing that. And then eventually you get really bored with the next bit. And then you're like, 'Okay, finally I've done the bike.' So, you can find things that reward you along the way. I think that definitely helps. That's my weekend activity.

Oleg

I used to be a triathlete in the past too.

Joe

Yeah, you'll recognize some of that. I'm sure then.

Oleg

Yeah. I didn't do Ironman, but still I had been doing it for three years, I think, three or four years.

Joe

Well, and the other thing that maybe compliments it or that's nice is if you're not succeeding through your training or anything else, you can go out and buy a faster bike and that also helps. And then, so you can cheat your way to success sometimes.

Oleg

Yeah, I noticed that you can code in five languages and have a background of building algorithms. How has your technical expertise influenced your approach to product management and strategy? Because for me, like, two different things, globally. But maybe you can find common things.

Joe

Yeah, I think, it's changed actually. So when I was first starting out in product management, sort of 30 years ago, as a former developer, what was really useful is I'd have conversations with the development team and I would just be able to call them on the BS. So, if someone was saying something was going to take weeks or was terribly complicated, I could just go, 'No it's not.’ And, you know, I’d sketch something, and here you go. And I used to think that was really useful. In fact, it's not, it just makes you annoying. And you second guess people and you rarely understand people's complexity. So, it was helpful for a while because I could get credibility and I could get the team to perform better and to be more honest with me. As I got older and kind of worked with frankly much better people, I found my technical skills just allowed me to establish credibility faster and allowed me to establish empathy better. I have much more understanding of actually why something might be hard or why, even if it's not hard, it can take a while.

And I have a better appreciation that cutting the code might take two minutes, but then you've got all the stuff that surrounds that if you don't have a great CI/CD or DevOps type capability or you don't have automated QA.So, I understand much more holistically why something might be more complicated than just simply changing one word on a screen or whatever it is. So, I'm more empathetic, I think now. But hopefully, it also means I can think a little bit more architecturally about some of the choices we're making and understand why servicing the tech debt matters and why sometimes we need to do things slower in order to then go faster later on. Because I can understand the logic that's being proposed to me by an engineering lead, rather than just saying, 'No, no, no, no, no! I want it quick and dirty and fast and done this way.' I have to ask my developers and engineering counterparts, whether they appreciate my background or not, I don't know.

Oleg

Okay. In the next step. In today's digital landscape, how do you see the role of technology and data evolving? And what impacts do they have on the success of digital initiatives?

Joe

Yeah, I mean, I guess in terms of how is it gonna evolve, I will talk in cliches and so on. I think everybody knows that AI is going to fundamentally change the way we all do our work, whether it's how we do the work or the kind of work we produce. So, whether it's customer facing or just the tools that we use, that's clearly going to have a massive impact on our work. I think in general, everybody, whatever role you're in, needs to be much more technology savvy, much more aware of what the art of the possible is, much more data savvy. Again, that's obvious. I think everything, everybody appreciates that now.

And I think a lot of the ways that we as technologists approach problems in terms of very rationally, very data-led, very test and learn, very kind of experimental in the way we go about things, those kinds of behaviors, the whole agile thing, you see much more of that coming into business more broadly and people adopting agile principles, a way of working. And in some cases, they even set up Scrum teams to do marketing or whatever it is. So I think, technology ways of working in our mindset, our culture is gonna really shift the way other parts of the business work. That's what I would see as the kind of evolution in the coming kind of 10 years.

Oleg

Okay, great. Thanks for that. Could you please comment on the problems associated with the lack of qualified specialists in the IT sector – developers, business analysts, QA engineers, DevOps – particularly in relation to the industry that you have operated in?

Joe

Yeah, so there's a few things that are obviously true, right? And you'll know this very well. Good people are worth many times poor people, right? You know, a good developer is so much better than a poor developer. And there just aren't that many good people available. And you need to fuel those people with good, exciting work, give them the space to operate, and empower them work in a very what I would call a product-led kind of way so that those developers or those people generally can express themselves and bring their full, authentic capability to work. And I think psychological safety is critical for how people work effectively. So, the problem then is finding these good people, creating environments for them to be successful. And too often, I think we end up hiring average people, and then they get in the way of those people. So, if you don't use qualified people on your team, they end up just upsetting everybody and everybody recognizes. In any organization, we all know who's good and who's not.

So, if there's too many of the less qualified people around, then the really good people, the stars, start to think why are they having to carry those people. And this is particularly true of exceptional developers and so on, that they are arrogant. Basically, they're not very tolerant sometimes. So, in general, my philosophy in hiring has always been to try and get the very best people you possibly can because it just makes everything easier. If you've got the best people on the bus, then, particularly as a manager, you just do so much less work. You just give people a direction and give them some guardrails, and then they just figure stuff out for you and they just get the job done. And the overhead of having poor people is really substantial.

Oleg

Agree. Could you share how the development team is usually structured in your projects? And have you ever outsourced your tech needs to an external vendor or you're only hiring internal resources?

Joe

So, I guess what I would say is that mostly the development organizations I've been in, or I have been the partner to a CTO or a Head of Engineering, so it's his or her, his mostly, responsibility to structure that team and so on. But I have often influenced and guided that, particularly in some of the more traditional businesses. And I've tended to move quite quickly or try and get us organizationally to move quite quickly to a classic kind of squad model with an embedded product trio. You know, sort of a designer, a product manager, and a tech lead. And then with a small number of engineers associated with that squad and then probably a QA, either in that squad or across two squads, and DevOps, either in the squad or across two squads. So, it's a relatively classic but what is becoming now a well-established kind of model. And then how you structure those according to your business objectives. How many squads you need, how they're configured in tribes, and so on is different. But that's typically how I've thought about things and tried to influence my colleagues to think about it in similar ways.

In several roles, I've basically walked into organizations where the developers don't have that alignment to a business objective and don't have a clear squad structure. So, they are moving from project to project, and they're basically project-led. They're feature factories, not owners of a roadmap and an understanding of an outcome that they're trying to get to. And I think every product person that you meet will always want to talk about outcomes, not outputs. And that tends to mean structuring your teams around clear North Star metrics and OKRs and focusing them in that kind of way. And maybe that brings us to the idea about outsourcing. Yeah, so I have myself organized outsourcing on a couple of occasions. The larger organizations that I've worked in have typically always had an outsourcing capability as well – some nearshore, some offshore. And it's been used in different kind of ways, so sometimes it's an augmentation of burst type capability and sometimes it's just your core team.

And indeed, in one recent organization, most of the development was actually in Ukraine, which clearly was problematic for a variety of reasons, sadly. I, in general, tend to favor in-house or nearshore because I think the relationship has to be really tight, but it depends on how good the organization is, right? If they understand the right models, if they themselves – and this is where culture comes in – if that organization is good at psychological safety and the developers, therefore, can engage with you properly as a product person and tell you whether they think your idea is stupid or whether they've got a better idea or, you know, raise the questions and the issues, then it can be pretty successful. In my experience, when you outsource to certain cultures, basically everyone just says 'yes' and you just don't get a result that you want. You get average developers who are unable to engage with you using their full creativity. And that's just a cost play. And I don't think it's very successful.

It goes back to the idea of, you know, good people are worth far more than cheap, poor people. So, I think you need to be really careful how and where you outsource. I've done it successfully when I've needed people to get a job done, a small job done. So, I've temporarily gone to a couple of organizations I've used with just one or two squads to build something very specific over a 12-month period or whatever, where I can work really tightly with them, but also where they happen to be cheaper than UK-based resource. So, one of my startups I built in that way. But as I said, I don't particularly favor the large-scale deployment to the kind of firms I'm talking about and the kind of countries I'm talking about. That wouldn't be my preference.

Oleg

What were the precise factors that prompted you to consider IT outsourcing, you or your development managers on the previous jobs? What are those factors?

Joe

Yeah, I mean, a lot of it always starts with budget. It's just about that kind of cost arbitrage across different countries. Some of it is definitely about availability to your earlier question. I think, in the UK, I'm thinking here about every, so one of my organizations that I worked in is based in Leeds, which is in the North of the UK. It's hard to get lots of really good developers. So, you have to think hard about, you know, where can you find the talent? So, lack of resource, lack of really good resource, and cost tend to be the primary drivers. But there's also something about augmentation and burst. There've been a few things that I've done where you've got a short-term project or you want some specific skills that you don't want to bring in-house. And that's when it can be quite useful to go outsource as well. So, for instance, in my last role – it was an app-based business – we had four internal app teams but we needed to also build some website capability. No one really knew how to do that properly. I mean, yeah, we had a couple of full-stacks, but it just made a lot more sense to use an agency to just build that capability for us.

Oleg

Yeah. They bring expertise and you don't have to dig into this.

Joe

Exactly.

Oleg

What are the benefits and drawbacks of IT outsourcing?

Joe

Well, so I think that benefit is the flexibility, the specific expertise, the ability to get quality. It can be the speed at which you can spin something up if you've got a relationship with the right kind of organization. The drawback, though, is that you have to have the right partners. You have to have the right kind of work, the right kind of projects, and you have to have the right cultural alignment between the two organizations so that you can work with them appropriately and manage that relationship well. As I was saying earlier on, I don't favor armies of faceless developers in a room somewhere. As a product guy, I need the developers to understand the mission, to understand the customer, to understand the objectives, and it can be hard to find that sometimes.

Oleg

Yeah, yeah, I totally agree. How do you measure the success of your collaboration with an IT outsourcing vendor?

Joe

Well, the same way I measure internal success, really, which is about the performance metrics. So, these frameworks like sort of smart frameworks, et cetera, to kind of measure what is your space frameworks in terms of measuring and what is your developer productivity and are they delivering well. So, I don't think it's too different from that. Obviously, there's a financial component as well, in terms of are you getting the ROI that you expect. Yeah, I don't think of them too differently from the way I think about internal teams.

Oleg

Got it. And finally, what advice would you give to other companies considering IT outsourcing but haven't started yet?

Joe

Yeah, I think be really clear on why you're doing it and what benefits you're expecting to get. And also be very clear then on what the downsides are really going to be. If you've woken up in the morning and gone, 'Well my UK team is just expensive. I want to cut costs,' then that is the wrong way to step into it, I would suggest. Whereas if you have the right kind of work or the right kind of requirements, then go find the right kind of firm to partner with that aligns with your culture and with your sorts of work and that has the expertise that you're looking for. And then you can have a successful relationship and you can use it well alongside what you're doing. And then, of course, you get into, you know, how do you make sure it is the right partner? A lot of us are about getting referrals and checking credentials and all the rest of it. But I would always start by thinking about what's your motivation. If it is simply a cost-based one, then that's going to be a challenging way of looking at things. I don't think that's the right way to approach this.

Oleg

Thanks. Thanks very much, Joe. You are the first product guy I’ve ever interviewed. Your input for sure would be valuable for our audience. Thanks for your time, joining me, and again, wish you all the best.

Joe

It's a pleasure, Oleg, and likewise, I wish you much success.

Oleg

Thank you, Joe.