5 Mistakes Founders Make Working With Offshore Development Teams

Leveraging offshore development teams isn’t the right strategy for every founder. However, given the rapid rise in domestic software development salaries, it is increasingly an important option even for getting V1 built. Having built software from scratch with domestic, near and offshore teams, I have seen or personally made a bunch of mistakes you can avoid.

Probably the most important mistake to avoid is working with the wrong software development company, but as that wouldn’t be a topic we can be objective about, here are the next five mistakes founders make.

1. Focus on cost above all else

Most US and EU-based founders choose to build software with offshore teams for one main reason: to lower their costs. We all know that when the cost is the main consideration in buying something, we often make tradeoffs that are “penny wise and pound foolish”.

Just as in any domain, software engineers, PMs, and testers aren’t all created equal–even if they live in the same city. With the global talent crunch driving wage inflation in tech, “low-cost” development isn’t as cheap as it used to be. It can be tempting to anchor on outdated labour rates and shop around until you hit an arbitrary rate.

Product development is just not a commodity product. Paying a reasonable premium to get excellent developers building your product offshore secures the massive discount offshoring gives you without dramatically increasing your risk of

• • 1. Slow delivery,
    2. Poor quality,
    3. Or misunderstood/incomplete features.

2. Unclear requirements

Offshore development has trade-offs, and the most obvious one is that you are usually working cross-culturally. You also have to deal with what my VP at Amazon called “chasing the sun” problems–low time-zone overlap. These challenges are totally manageable with detailed requirements and overcommunication.

If you haven’t worked closely with software teams before, this becomes a real challenge. Even if you have, it will always surprise you what you forgot to tell your dev team about your vision or feature. I always recommend that first-time software builders work closely with product experts and business analysts to ensure that their requirements are truly detailed in the right way.

There are a lot of features that, if you build them late in the process, can take 2, 3, or 5 times as much effort and lead to a complexity that has to be managed.

3. Special topics: Tech vs Non-Tech founders

Here are some mistakes that look different between tech and non-tech founders.

Non-tech founders don’t get outside engineers to vet the solution design

As a non-engineer myself, I am not the right person to do a scalability analysis on a proposed system design. I have tons of experience building software, but I always bring in an outside engineer to ensure that a new team’s plan looks good.

It is a powerful way to vet that the people building your baby aren’t going to end up painting themselves into a corner (and that you have chosen the right team). This is less important when you are engaging a world-class development company, but I still recommend it, especially if your future success hinges on serving a lot of concurrent users.

Here are some tips from NeoITO to find your technical co-founder.

Tech founders tend to micro-manage developers

Founders who have built core parts of their tech themselves but don’t have experience managing teams, this is for you.

If you have only built software as an individual contributor and you engage an offshore team, it is going to be very tempting to micro-manage the team. This is understandable because you will be dealing with time and cultural differences.

In the short term, micro-management often protects us from initial quality issues, ensures that things are standardized, and frankly just makes us feel more comfortable.

The problem is that the true leverage of an offshore team is just that–they can function as a separate team and parallelize important parts of the build. If you can make the switch to engaging on clear requirements, features and functionality, agile milestones, etc., you can really lever up the impact of the team.

Your technical skills add a ton of value to the project when you do occasional code reviews. If you work with a mature service provider and you are dictating coding approaches, solving every technical problem yourself, and overruling your engineers, you will have the same result with global teams you have with domestic ones: the best developers just won’t want to work on your projects. Global developers have lots of job options too!

4. Don’t prioritize ruthlessly

One thing I see with offshore software development projects is a shift away from agile to waterfall. When you create requirements, get an estimate, decide on a partner and start building with a team of a few devs immediately (one of the huge benefits of offshore teams!) at an affordable cost, it feels like you should just build your “dream home”.

Founders in this mode get into thinking that they have to have all their features baked in before they get users to try out what they have built.

If you think you are getting a deal on the service, you want to get all the bells and whistles. The problem is that features take time, and every moment you are not getting customer feedback is a massive cost.

Don’t let the lower cost of development stop you from prioritizing features ruthlessly. The success of the project will still depend on whether it actually gets traction with users. There will be time to build out the feature set later.

Every software development project I have ever been involved with–at Amazon with US and India-based devs, with near-shore devs for my own startup, and my clients’ building with excellent offshore teams–runs into delays.

It will be very easy to blame delays on your offshore team, but in my experience, delays are more often driven by a failure to narrow the features ruthlessly to get into the market.

Suggested read: How to Work Effectively with Your Offshore Development Team: A Detailed Guide

5. Don’t treat them like your own team

If you are a founder trusting a development team to build software that you are going to build a company on, you need to think about them as YOUR team.

You may not have hired each of them. They might sit thousands of miles away, speak a different language at home, and not share many of your cultural reference points. Even so, they are the people who are going to make your entrepreneurial endeavour succeed.

Successful founders always are keenly aware that they have to unlock the best out of their team to succeed. If your developers and PMs live 10-12 time zones away, that still means spending time with them.

The early days of a product are particularly important to get right, given that missed requirements and features become more costly to build later. It is critical to make yourself available to answer developer questions about your requirements.

I find that global teams need more time with founders than even they realize. They often want to be a turnkey resource that can “fly by wire”, but in all the product development processes I have been a part of, the scope for misunderstanding is always greater than you think.

Meet frequently during their workday. I tell founders working with India-based teams to carve out two evenings each week or more to be available to meet with your team. If you are Pacific Time, that means between 9 pm and 11 pm.

They will usually be available for meetings in the evening too, but there is nothing like sharing the evening burden with your team to drive their engagement and help them feel like they are a part of something.

Summary

Offshore development teams are a powerful way to make your funding stretch much further. That gives you more flexibility, more bites at the apple if you need to pivot, and makes profitability just that much easier to hit.

NeoITO has built a track record of serving founders, bringing their vision to life, and helping them create valuable companies. We are startup-grade. Get in touch with me if you want to chat about your product development strategy.