By Philippe Peron, our Chief Delivery Officer.

Having built and scaled successfully distributed IT teams in Ukraine for such giants as ricardo.ch and Just Eat, I’ve learned invaluable lessons that I’d like to share with a broader audience. I hope my tips will help you make the right choice between going with a managed (turnkey) project and building your own distributed IT team, and avoid the most critical failures down the road.

Software Team Distribution

The distributed team model implies that at some stage (after reaching a certain team size), it’s crucial to hire a “local authority” (e.g., Site Manager, Delivery Manager, Head of International Engineering, or Product Manager) to manage and coordinate teamwork on-premise. Indeed, remote collaboration relies on the solidity of the virtual bridges that you build across locations. Addressing distance and obstacles between the distributed teams is one of the critical aspects of it. Hiring the right profile offshore, as a trusted and radiating proxy of your company’s culture is undoubtedly another vital aspect of this process. 

As a customer, you are the primary influencer, actor, and motivator. You and not your outsourcing/technology partner! You need to inject your corporate DNA into your distributed team(s) to ensure that you are getting the expected value for the money you are investing in. 

How to avoid failure when building a Distributed Team?

It depends on what you’re trying to achieve. If you come with a long-term need, this is when you have to think about the effort you’ll need to invest in your extended or distributed team to make it a success.

Again there’s no miracle. I’m not talking about money here.

You can have a lot of money but end up having a complete fiasco. You need to make sure that when you’re engaging in a long-term relationship (12 months plus) with the company that will be operating your extended team, they understand your culture, as it’s crucial for your team’s success.

As a client, you need to make sure that you have enough capacity internally to connect your remote team(s) into your corporate culture and environment in general.

As surprising as it sounds, very often, companies realise while suffering from their extended team integration that they have no corporate culture or at least not as adopted internally as expected. Or what they discover is that problems they may be having with the extended team are mirroring existing internal issues.

Unfortunately, your onshore team might be quite resistant to what could be perceived as a threat or unfair competition. Honest and transparent communication from management on that topic (real reasons, plans) is mandatory to get buy-in from all employees, or you’ll set yourself up for failure.

I had a similar situation at ricardo.ch, but it went well, thanks to my status as their former colleague (although they didn’t like me that much when I was growing the team in Ukraine – pun intended).

As ricardo.ch was growing and thriving, they needed more tech resources to ensure their roadmap achievement. However, top management didn’t want to invest 100% of the company’s R&D budget into the French team (I was part of). In 2011, I was tasked with going to Ukraine and meeting with a nearshore provider that appealed the most to our CTO compared to other providers in the shortlist. That CTO was young, agile, and pragmatic, he didn’t fear to outsource and go East. He asked me to go and explore the opportunity in Ukraine and help him make the final decision.

After I visited the provider in Ukraine and talked to some of their developers, I was impressed with their passion, open mind, and willingness to be real contributors to the project’s success. I really liked that spirit and told my boss I was OK to move forward with outsourcing development to Ukraine. As I started traveling every week back and forth from France to Ukraine, the decision was made to relocate me permanently to Ukraine to work closely with the team. I was building a team from scratch between 2011 and 2014 and grew it up to 35 resources, consisting of .Net, some JavaScript, some BI and QA guys as well as some mobile developers.

I also had strong support from my CTO and other managers who helped convince the team that their extension would be good for the company and for them. Very soon, the Ukrainian side was considered as part of the family, the French team bought into this engagement and had no more concerns about their future. 

Before embarking on a team extension journey, you should be ready to go through some painful moments, from something going wrong with recruitment to onboarding the newcomers to having to dismiss someone along the way.

All these points have to be anticipated and clearly discussed with your service provider.

Be focused and persistent, be fair and supportive, and don’t let any walls separate your teams. Communication is the cement that builds a strong foundation.

Consider your distributed IT organization as a product. Like any product, you build it, inspect it, and adapt it.

When to choose a Managed Project?

It all depends on what type of need you have. If you have a project in mind for just 6 months, it’s OK to go ahead and hold your provider accountable for your project delivery. Check their portfolio, ask for references, review their existing products and solutions. Find out how many projects they’ve delivered and how they’ve delivered them. Find out if there were any delays.

Beware of the fixed-price paradox: when you aim for a fixed cost, but can never reach it for some reason. You either have to pay more, or your provider has to inject more resources at their own expense or both. 

However, there can be an engagement evolution from a managed project to an extended team. If you’re a startup and only have funds to build your first MVP that needs to be delivered in less than six months and can’t have a long-term roadmap because of financial unclarity, you need to start somewhere. So you can engage a third-party provider for MVP development, and later, when you attract more funding, you can convert your managed team into your permanent extended team.

Also, check out my article for YFS Magazine on how software team extension helps startups solve their product development challenges.

Are you looking to hire a professional software company to help you build your technology solution? Let's talk!