Mastering Nearshore Outsourcing: Expert Tips from Two+More

Matt Hallman: Hi everyone, welcome to Around the Product Development, our weekly show on hot topics in digital product creation. In 25 minutes, we cover everything from monetization to innovation with actionable insights from Agile Product Builders, a community powered by Boldare. This week, our guests are Siobhan Child and Matt Pollitt, co-founders of Two + More, specializing in nearshore development partnerships with UK-based product and design leadership. Today, we’ll discuss nearshore software outsourcing and its top five challenges and solutions. Siobhan, Matt, welcome! Please introduce yourselves.

Matt Pollitt: Hi Matt, by the way, I think it’s good to stay generic because otherwise we’ll spend 25 minutes telling you our whole backstories and where we come from. But you kind of hit the nail on the head. We set up a business that facilitates nearshore partnerships in the UK, but I guess what makes us slightly unique is that we have design and product resources in the UK. So I think the main subject we’re going to be talking about today is how to deal with cultural differences in scaling remote teams and some of the issues that are there. We kind of work as a business to help facilitate that, stop a lot of those issues from happening in the first place, and basically make sure that we get to a better product faster, more efficiently, and build better relationships.

Matt Hallman: Sure, it sounds good. Just a brief follow-up question: How did you start this business, and what was the reason behind it? I imagine you two started it some time ago. Was there a specific need you identified or something in your previous jobs that triggered the idea to start this business?

Siobhan Child: So we kept identifying the same gap in the market time and time again, and we worked together under different guises, approaching projects together. I had experience in managing nearshore development teams, and Matt comes from a product support and design background. What we felt we kept trying to do was put a square peg in a round hole. Rather than forcing a fit that didn’t work, we came together to create our vision. We identified a gap in the market: many businesses provide introductory services, introducing UK clients to nearshore development teams and houses, and sometimes offering design services through those partners.

However, we identified problems in those collaborations that could be easily overcome but were often missed because people were so focused on their day jobs. Communication and cultural differences would arise, turning small challenges into bigger issues, and what could have been fruitful collaborations sometimes fell apart for simple reasons. Essentially, if processes were managed more effectively, the collaborations would work much more smoothly.

So, rather than just providing these introductory services, we wanted to manage those collaborations more effectively and provide onshore design services and leadership. It’s a different approach.

You might be also interested in the article:

From One CEO to Another: My 4 Tips for Choosing a Product Development Company

Matt Hallman: Makes a lot of sense, very logical and reasonable. So, to get to the topic of nearshore software outsourcing, can you explain what we mean by that? Many might be familiar with the term, but for those who aren’t, could you give a brief explanation of nearshore software development?

Matt Pollitt: Interestingly, we’ve just traveled around three different countries in Europe. If you ask people in those three countries as well as the UK what nearshoring is, they will come up with different answers. And I think that’s one of the big issues, right? Outsourcing and nearshoring can be loaded words with specific terminologies. When we talk about nearshoring or outsourcing, we’re basically saying we’re helping to build teams, and teams need to be integrated to build good products. So, really what we’re talking about is the ability to completely bring in a team to build a product from zero to something, or with bigger companies, to bring in additional teams, resources, or specialists in specific technologies to augment existing teams. This helps them gain more capacity, become more scalable, and deliver better and faster.

Siobhan Child: We look at time zone differences, so when we say nearshore, there can be farshore as well. Offshore is kind of a broader interpretation of that. So, usually outside of your own country, it’s the very obvious meaning of that word. But like Matt says, there can be negative connotations with it, unfortunately.

Matt Hallman: It’s good to understand that many people have mixed ideas or don’t fully understand nearshore or farshore concepts. It’s crucial to have a baseline understanding. Matt, you mentioned the idea of a team. What are the challenges with client-supplier relationships when creating a unified team, and how do you address them?

Matt Pollitt: So it’s really interesting. I’ve been building digital products for about 15 years now and have been really fortunate to work on some significant projects inside big companies. Whenever I see things fall apart, it usually comes down to communication. Sometimes it’s cultural differences, sometimes it’s not having a good fit, but often the root issue is communication.

About ten years ago, I worked on a project for seven or eight years. Anyway, we were working on banking software and providing design consultancy to the bank, specifically for an iPad application for one of the national banks in the UK. The development team was partially outsourced. We frequently found that the designs we sent over would come back different. The special nuances that make a product delightful were often missing. Overpromising and underdelivering were common issues we faced.

And I think that’s the thing we’ve talked about a huge amount, isn’t it? 99 out of 100 times, if one of these relationships hasn’t worked out, it’s due to the proper level of communication, setting expectations, and effective management, and the willingness to actually try. Everyone talks about being “one team,” but it’s challenging to achieve this in a supplier-buyer relationship. Successful collaborations often involve continuous communication and a close working relationship.

Instead of handing off work and disappearing for weeks, it’s crucial to adopt agile practices, hold regular ceremonies, and have someone act as a buffer between the team and stakeholders. This intermediary manages the situation from both sides, ensuring issues are addressed before they escalate. Sometimes the team won’t want to say anything, and sometimes the buyer won’t speak up until things go wrong, turning everything from amazing to terrible in a heartbeat. This is where we feel our approach works.

Matt Hallman: Those are my questions. How do you get people to be that honest as well? At some point, maybe, let their guard down a little bit. Right. Is it just about communicating, or is there more to it?

Siobhan Child: Yeah, I think you need to be very careful not to make assumptions that can be overly simplistic, as that can be a big downfall for a lot of people. This often comes down to cultural differences. Being very blunt about what you want, setting expectations, and ensuring that when you select a supplier, you’ve got the same cultural alignments is crucial.

Businesses work really hard to create a company culture, and you want to find a partner that reflects the same cultural aspirations that you have for your own business. Get everybody in alignment, working towards the same goal, understanding that it’s about shared success, and striving for a one-team approach.

Implement stringent account management processes, ensuring from the outset that you’ve agreed on communication tools, account management processes, and expectations. Standardize those processes and try to create a true one-team dynamic.

What’s really important, if you don’t have a company like ours involved, is managing a lot of that internally. I often joke that my business is a bit like being a marriage counselor. I go in and say to our engineering teams, “I’m not a client, so you can tell me everything.” If there are issues internally, let me help solve them dynamically, honestly, and openly. We say the same thing to our clients.

If you don’t have a company like ours managing the process, it’s crucial to put stringent account management processes in place from the very beginning and set a standard of expectations. Be honest and frank with each other and hope for the best.

You might be also interested in the article:

How to choose a product development partner in a VUCA era

Matt Hallman: If I may stay with the marriage metaphor for a second, working with another team is also like a relationship. You have to get to know each other. When we talk about nearshore, offshore, or farshore, we often discuss cultural differences, as you mentioned before, but there’s also the aspect of time differences or different time zones. How do you manage those? Just like in a relationship, it’s challenging enough when you’re close to each other, but it becomes much more complicated with a time difference.

Siobhan Child: If you’re a UK client, we often find that having development partners in Europe with a one or two-hour time difference can be advantageous. Your development team is already working a couple of hours in advance, so you can manage those time zones to benefit you. Make sure that by the end of your working day, the team knows exactly what’s expected of them the following day or has a plan in place. By the time our UK teams wake up, their engineering teams are already one or two hours ahead.

Schedule meetings to ensure overlapping times so that you’re not expecting people to work too much outside of their working day. If extended hours are necessary for project deadlines or certain situations, recognize this and adjust working days slightly for those affected. This way, you’re not expecting people to work 14-hour days because they are trying to accommodate the time zones of both their country and the country they are servicing. Be aware and manage it to your benefit.

Matt Pollitt: People often talk about the negative aspects of time zones. I’ve experienced the extreme: I had a contract with an Australian company, which is about as big a time zone difference as you can get. It’s hard - communication is hard, and it’s difficult to achieve that sense of cohesion. One reason why nearshore works better is the smaller time gap.

One of the advantages, especially for team members who have different work styles—designers, developers, etc.—is that time zone differences can actually provide some dedicated work hours. Some team members are outgoing and want to engage in meetings, while others prefer to work quietly. Time zone differences give those who prefer quiet work some hours of uninterrupted time, especially in organizations with lots of meetings or ceremonies.

However, the biggest part, which you really promote, is getting together in person during the year. Even though you’re remote, it’s important for people to meet face-to-face. There’s only so much that can happen through screens—waving hands around isn’t the same as direct communication. In longer projects, such as multi-year delivery cycles, having teams build personal relationships is crucial because it enhances remote collaboration.

We’re big fans of kicking off projects with in-person meetings. There’s a cost involved, but we feel that with the potential savings from the nearshore model, it’s a really good investment because it sets the project on the right path.

You might be also interested in the article:

The Agile Product Builders Community: a network for professionals

Siobhan Child: Many companies are now predominantly remote, and you could be a UK-based organization, but your employees are spread all over the UK. They could be anywhere. Pre-pandemic, you’d be trying to convince people that a remote or hybrid working model could be effective. Now, everybody has bought into that. Many companies are downsizing their offices, getting rid of office space entirely, and using shared office spaces.

Another advantage we’re seeing more and more is that our development partners have amazing office spaces. You can bring your internal teams over to the development houses and make use of their spaces. These are bright, modern environments where teams can work together and engage, providing a much nicer working environment. There’s an actual physical office you can use, which becomes a benefit. This is opposed to the pre-pandemic era when everyone had their own office space and didn’t see it in the same light.

Matt Hallman: I heard you say a couple of things that are interesting to me. Matt talked about projects, sometimes multi-year projects, which can be very long. We also discussed time differences and remote work. So, how do you retain talent during all of these changes? Especially for long-term projects, how do you retain talent if your team is located in many different areas? How do you find and retain talent physically and remotely? I can imagine there must be challenges, but perhaps it’s a bit easier now since everyone is working from home or various locations. How does that look for you?

Matt Pollitt: It’s a really interesting, really, really interesting question. I think we’ve gone through different cycles where, pre-pandemic, it was all about having a fun office with a ping pong table that nobody used, and a kitchen that was always empty, along with other kinds of perks. Fundamentally now, you can try to overcomplicate this kind of stuff, and we can all use lots of clever business words and things like that. But fundamentally, humans like to work with other humans where they feel valued and believe they are doing good work. I think if you put structures in place and create an environment where people feel they are bringing value, are listened to, and can do the best work of their lives, that is fundamentally how you retain talent.

Some of the best places I’ve worked haven’t necessarily been the ones that pay the best, but the ones where I felt the projects I’ve worked on have touched hundreds of millions of people around the world, or where I’m proud to show the work I’ve done. The kind of stuff that Siobhan was talking about, building that culture internally, is so important. You mentioned at the beginning that finding partners with the same cultural alignment as you is really important. If you’re a big bank in the UK and you don’t have a culture of creativity and spontaneity and free-flowing development work, and you hire a really creative, small partner, that might not be the right fit for you. The partner will find it hard to integrate with the corporate side of things, and that kind of relationship might fall apart.

If you can find companies that align with your values, the type of business you are, and the way you treat your staff, that carries across. It’s one of the reasons why we only work with partners where we go out and visit them. You can say a lot of things online, use lots of stock pictures, and do many things, but actually getting into the office and seeing how people interact and work with each other is usually the best litmus test of how those partnerships will work. Perks, money, all that stuff falls aside. Really engaged, really good people—the kind you want to retain—want to be working on meaningful projects in an environment that feels like more than work. They would do it even if they weren’t getting paid for it.

Siobhan Child: Yeah. And I think engineering houses have an advantage because they can offer a wide scope of projects to their teams. They can also allow their staff to work in a really supportive way with each other. They can bring fresh eyes. You could be part of an engineering house, working on a project, and if you get blocked or challenged, you’ve got a whole set of other people working across different projects that you can speak to and lean on for support. They can give you insights and help unblock you in ways that wouldn’t be possible if you were solely working on one product within one company.

Expanding on what Matt said about career growth, people want opportunities to work on different projects and with different people. Engineering houses have to invest in staying ahead of technology curves, so many have their own academies and training programs. The cost for a UK company to train and retain top talent is high. We see it all the time: top engineers are often contractors and consultants, chasing the highest pay, typically working with banks and the fintech industry in the city.

Matt Hallman: Where the money is.

Siobhan Child: Where the money is. And actually, what people want is to retain and work with resources where that knowledge is retained. So, you work with an engineering company, you invest in retention, and you can often work with those same resources for years. Even when they leave your project, they stay within that engineering house, so they can help onboard new people, and it works really seamlessly. It would take a lot to convince me that it’s better to have a huge internal engineering team and not have the scalability and flexibility that comes with a partnership.

Matt Hallman: And then a short question before we go to the last topic. We’ve talked about retaining people, right? Retaining talent and keeping them engaged. How do you ensure they’re onboarded effectively? That seems like an important topic as well, because you want them to get started with the project quickly. Are there any best practices or lessons on that, Lauren?

Siobhan Child: Yeah. So again, it comes back to really stringent account management processes. Quite often when we work with our partners, we put in buddying systems, like shadowing systems. When you onboard somebody, they partner with someone who has been in the team for a while, which could be client-side or within the engineering team at the development house. They shadow their buddy for a certain amount of time until they become very comfortable with the project. In the early phases, it’s crucial to have lots of feedback, creating a continuous feedback loop to ensure they know what they’re doing and are comfortable with any issues that arise. Issues only become significant problems if left unresolved for too long. Therefore, it’s essential to maintain open lines of communication, implement effective tools, and establish account management processes to mitigate problems before they escalate.

Matt Hallman: Yeah, I made the last topic, which is really interesting to me. We talked earlier about projects, right? And Matt mentioned multi-year projects as well. I can imagine that the demand changes in these multi-year projects. I keep coming back to this, but I can imagine the relationship might change as well. The demand might change, the project might become smaller or get a lot bigger, it might scale up or downscale. How do you deal with that? If a customer needs fewer people or more people, if they scale or require flexibility, what are the main challenges around that topic?

Matt Pollitt: Actually, I think that’s one of the main advantages of working with nearhose. If you build a UK team, and let’s say you did that seven years ago and wanted to build a mobile app with an iOS team and all the support that goes with it, I guarantee you that the next problem that comes along, you’re going to try and fix it with an iOS-shaped solution.

The whole advantage we talk about when bringing teams into the UK is that you can have some core senior people in the UK, maybe from an architectural or design point of view, but by bringing in and working with multiple partners, you can change the technology and approach truly agnostically. These teams can scale up and down dynamically.

Commercially, this is often set up with a minimum retained level of resource, with additional flexibility that sits above and beyond that. This can be a nice way to handle it. By having this ability within these companies, you avoid situations where you’re sitting on a project, billing time and materials, but there’s not enough work to do. This can disengage talent, as they feel they are not delivering value.

And then other people on the other side start to realize it and everyone starts to get quite awkward about it and it falls down. So I think being realistic and being, you know, able to build those scalable elements into contracts is actually the way the kind do it. And it works really nicely. It can mean some people can come off for a break and work on another project and then come back if the demand ramps up. It tends to be you’ve got more people up front, maybe a little bit less in discovery, but at least the initial kind of kickoff and starting to work on main sprints and then that can be like ramped up and ramped down depending on other commercial factors and the scale of the problems.

Siobhan Child: Yeah, we see that in different projects with different types of resources, you often don’t need a designer’s time consistently throughout the lifecycle of the project. That’s quite often the case for QA and testing as well. If you had these full-time teams internally, you’d have to have FTEs, and like Matt said, they wouldn’t be fully utilized. You don’t need to do that. You can arrange with your partners that you need design resources at 80% capacity for the first month of the project, and then you can scale back. That flexibility is invaluable for both sides and for the person working on the projects as well.

Matt Pollitt: Did we answer your question?

Matt Hallman: Yeah, I think you did, actually. It sounds very reasonable to me, so that’s fine. And I think we are also out of time, so we have to end it here. So, thank you so much. Unfortunately, our time is over. It always goes really quick. It was very interesting, and your answers to my questions helped me a lot to understand this world better. I think the audience feels the same. Thank you again for joining, Siobhan and Matt. It was a pleasure to talk to you.