Why Your Offshore Dev Team is Failing, and How You Can Fix It

It’s been almost 20 years since globalization created access to new labor markets around the world. In the early 2000’s, the industry for outsourced software development talent in India exploded. Since then, countries around the world have been graduating countless software engineers. The promise was that you could get high quality talent at a fraction of the price. In some cases that held true, but for many companies the short-term cost savings were lost in long delays and constant rework.

Companies face many challenges managing a team on the other side of the planet. They find they have to create exhaustively detailed specifications, otherwise they won’t get the product they expected. Even when the product was delivered to spec, they later find the code quality was poor and needed to be reworked. With little to no legal recourse, many companies have lost their entire investment when things went wrong.

In my consulting practice, I regularly meet CEOs who are ready to pull the plug on their offshore development team and bring operations back on shore. I found that in the long run, paying the premium to have some or all of the engineering team onshore results in a much improved return on investment. Let’s talk about some of the reasons why I think the offshore model is failing us.

You Have a Communication Gap

The most obvious challenge, that anyone who’s managed an offshore team knows, is the massive time zone difference. When the product and development teams are separated by more than a few time zones, it becomes very difficult to maintain communication. Simple clarifications can take a day to resolve. It’s difficult to gather everyone for meetings, so the teams become misaligned. This results in the product manager having to provide incredibly detailed specifications, ensuring no detail has been missed, which goes against agile development principles. Couple this with a language barrier, and teams are very likely to misinterpret requirements and deliver a product that is not what the product manager intended.

They Don’t Understand Your Users

As I’ve emphasized many times in my talks and articles, the more your engineers understand the user’s journey and perspective, the better they will be able to make intuitive decisions about the product. I’ve found very few companies who include their offshore developers in high-level discussions around the company mission and the users they serve. The shared vision and purpose that leadership cultivate in their company culture are lost on these outsourced teams. This again requires product management to specify every minute detail, which they typically don’t have the time or energy to provide. Product leaders grossly underestimate the time it takes to convey this context to a group of people from another culture.

You Don’t Know What You Want

Great product managers are incredibly hard to find. Most companies have a general idea of what they want to accomplish, but they get lost in the details. They have a difficult time articulating clear technical requirements. They often lack a clear strategic plan, and typically only think one or two moves ahead. This creates requirements churn and rework in the best of circumstances. This challenge is amplified by the other factors of an outsourced team.

You Don’t Truly Understand How to Build Technology

While the value of solid architecture and DevOps is obvious to strong engineering teams, they are often overlooked in companies that have an entirely outsourced development team. Without strong technology leadership in the core team, the product becomes a cobbled together mess of features. While the product may work long enough for the developers to get paid, the system will inevitably break down as usage and complexity grow.

This is typically when my clients find me, as the teams productivity grinds to a halt and they lose customers due to poor performance and inability to release new features quickly. The problem with good architecture is that it is a significant investment that does not have the appearance of immediate value. It is a long-term investment that becomes increasingly expensive to retrofit as the product matures.

You Treat Them Like Outsiders

What makes a successful engineering team is a culture of connection and reflection. By connecting the engineers with the company’s mission, vision, culture, and purpose, they become more motivated, more creative, and more productive. If you treat your outsourced developers as service providers instead of an extension of your team, they will not be invested in your company’s success. When the going gets tough, they will not be there to support you beyond their own immediate financial gain. They will not provide creative solutions outside of what you specifically tell them to do. They are simply tools, not teammates.

You’ve Created a Team of “Yes Men”

To a service provider, the customer is always right. They have no incentive to challenge you if you’re making the wrong decision. Perhaps they’ve tried to convince you to invest in solid architecture and devops, but after being shot down several times, they’ve decided to simply do as they’re told. They allow you to steer them in any direction as long as they continue to get paid.

Unless you have strong technical and strategic leaders on your team, who are willing to challenge the CEO and fight for the agile development principles, you will end up with a mountain of technical debt that will eventually bring your platform to its knees. You need someone on your team who can stand up to you and make sure that you’re paying the true cost of software development.

There are Solutions

First and foremost, you need a strong product manager and CTO on your team. As a CEO, you need Generals who understand these pitfalls and principles. If you are a solo founder, I urge you to find technical leaders to help you manage your outsourced team.

Ideally you should have at least a core team of developers on site, and leverage outsourced talent when you need to flex or to build prototypes that are outside of your core product. Your core team should be driving the critical features and technology, while your outsourced team build components that are lower in value.

If you can’t or don’t want to manage an internal engineering team, I recommend using an onshore or nearshore agency, where at least the project manager and chief architect are on shore or even local to you. This way you’ll have someone with whom you can build a strong relationship of trust, and who has experience getting great results from outsourced talent. They can typically provide a blended team of onshore, nearshore, and offshore developers to provide quality products at a marginal premium. So far, all of my clients who have come to me with an offshore crisis have found great success with this model.

If you must use an offshore team, you absolutely should pay for a development manager. It adds some overhead, but it saves you the trouble of trying to keep the developers on task when you have no ability to do so in real time. This is the only way I have found success with offshore teams.

Do all of your collaboration online. If you have a mix of local and remote developers, there is a tendency for in person communication. It’s only natural. This leaves your outsourced team in the dark. If you use outsourced talent, you must capture communication and context digitally and make it available for all. Tools like Slack, Confluence, Jira, Aha!, and inVision will allow everyone to have access to the same information.

Let your outsourced team own an entire component. It is incredibly difficult to manage a mixture of on-site and offshore developers in the same code base. The work you give to an outsourced team should be wholly encapsulated, and interface with the rest of your product via an API.

Treat them like an extension of your team. Invest in sharing your vision, purpose, and culture with them. Build personal relationships. Send them care packages. Make them feel invested in the success of the company. If you make them truly care, they will be more likely to give you their best work, provide creative solutions, and challenge you when they think you’re making a bad decision.

How I Can Help

It’s become a big part of my consulting practice to help companies deal with or migrate away from their outsourced development teams. In the process I’ve built some great relationships with outstanding development agencies who share my principles and have a track record for quality. If you think your situation is too far gone, I can find you a match and help manage that transition.

As I mentioned earlier, in order to effectively manage an outsourced team, you need strong technical and strategic leadership on your side. As a Fractional CTO, I can help you build a solid roadmap, development process, foundational architecture, quality standards, and engineering team culture. Check out my other articles and head over to my website. Let’s connect and do great things!

If you’d like to read more of my articles on product development, leadership, and software development process, follow me on Medium. You can also find my conference talks and podcasts on my media page.

I Guess This Clapping Thing Is Important, so If You Made It This Far, Please Click Furiously!