One of the recurring questions I get asked all the time is about how to setup successful and painless offshoring practices. 

I’ve been lucky enough to have been on both sides of the coin. I was Director of Technology in our Costa Rica office, and therefore I was responsible for setting up a technology practice that was 99% all about leading the tech work for our US-based offices and clients: New York, Seattle, Los Angeles, Cincinnati, Atlanta and Portland, just to name a few.

I moved to Los Angeles 6 years ago, and since then, I’ve been on the ‘client’ side of the relationship, working closely with my director counterparts in Costa Rica, Argentina, Brazil and Guatemala, making sure our offshore development teams are delivering up to my and our clients’ standards.

I’ve heard so many horror and discouraging stories from close colleagues. Their experiences went so bad and traumatizing that they just decided to abandon the idea of giving offshore a chance, even when the benefits are so clear, varied and well documented: lowering costs is the obvious one, but you can also find very bright minds without the limit of your local professional markets. 

So what’s the secret? I’ll share a few tips that have worked for me. 

Formalize your Vendor/Offshore Success & Evaluation Factors

This is all about removing assumptions out of the equation. Make it clear to your offshore and/or vendor partners what’s important to you, what means for you a successful relationship and how you would be evaluating the engagements and partnership to make sure it keeps improving. I typically concentrate on the following ones:

  • Skilled human factor & quality of product and services
  • Repeatable and predictable
  • Cost saving
  • Completeness of provided services
  • Responsiveness and communications
  • Efficient outsourcing relationship management
  • Master the language – but just enough
  • Appropriate infrastructure – enough resources to maintain large development projects

Skilled human factor & quality of product and services

Sounds common sense, right? Assigned resources should be good and professional. Sure, but again, remove assumptions. Level set on expectations of each one of the roles that are assigned to your projects. 

Does a Sr. Dev mean the same to you as well as to the offshore office? Do you expect a Sr. Dev to lead, mentor, estimate? or do you care only about that he/she is a guru in whatever platform/framework you need?

Make sure that the understanding is clear and written on paper, since you don’t want to keep having the same conversation for every single project. 

Repeatable and predictable

Enforce software development best practices across all projects and across all disciplines: Project Management, Dev, QA, Creative, etc. 

Also, eliminate the hero-based approach. Soon enough you’ll start identifying who you want to work with. You’ll start requesting a specific developer or QA, by name, to be assigned to your project. This is great and you should not minimize this level of success, but make sure that you give this feedback to your director counterpart. 

The idea is to make sure they understand what’s working, why is working with X or Y so easy, which characteristics you’d like to see in the rest of the team as well, etc. You’d like every single project to be a success regardless of who gets assigned (your pool of resources will also become larger). 

Cost Savings

This is an obvious one, yet it should not be the only reason you try offshoring. Remember, the knowledge worker market is bigger than your local market. You can find great and very smart resources regardless on where they live. Be open to that option. But of course, it still has to be somewhat economically attractive, if you are planning on investing on big engagements or for the long run. 

Completeness of provided services

It’s unlikely that you’ll need to work with offshore teams that only do X but not Y in terms of the full development pipeline and tasks. When I engage my offshore partners, they are responsible for: creative production, tech project management, development, quality assurance, release management, system administration, etc. It’s not likely that I would ask them to ‘just’ do Dev, but don’t QA it. 

Efficient and high quality teams work because they work like well-oiled machines, you would not want to break that flow without a very good reason. 

Be honest and careful about you need help with. Many times I have seen US-based clients request just a subset of work because 1) they want to keep costs down, and 2) they say they have that capability in-house. A healthy development project has a set of tasks and practices that need to happen, it doesn’t matter from where or which team leads them, but they NEED to happen. Countless times I have seen offshore approach break because a miss on the client side, and not on the offshore side. 

Responsiveness and communications

This is not about forcing your offshore office/vendor to deliver regardless of anything that might have happened after the project kickoff. It’s about communication practices, working together, working out change requests and implications, feature reprioritizations, etc. 

Software development is rarely static, things will happen, it’s the nature of the work.

Efficient outsourcing relationship management

Just like you have retrospective sessions, and postmortems in your projects, make sure you keep a formal cadence to complete the feedback loop between you and the offshore leads. It can be after every project, or set up a monthly or quarterly meeting. Don’t let this slip by. 

Master the language – but just enough

Don’t disregard a resource or a team just because they don’t have a perfect American accent. Communication is extremely important, and if a team member is not speaking up because they are shy or too concerned about their English fluidity, then of course that’s an issue, but if they do speak up and have no issues in doing so with an accent – accept it. You might be letting go a very valuable resource just because they lack 100% proficiency, specially if it’s only for internal conversations, it might not be that important. 

People in offshore locations typically speak 2-3 or more languages. 

Appropriate infrastructure – enough resources to maintain large development projects

Make sure they also have the capacity to grow and have a pool of resources, or at least a hiring process that allows for you to keep work coming in their way. 

Additional Tips

  • Look in the mirror – many times when something is not working it has nothing to do with the offshore/vendor, it might be that your internal processes, standards and roles are not set up correctly. 
  • They are the same team – I never think about any of them as a black-box, it’s always a team, build relationships, take the time to know them. Also, one practice that I keep telling everyone, and it’s specially easier today in Covid times when everyone is working remotely – imagine as if if they are just colleagues WFH. There is no difference. 
  • Asynchronous mode of working – by this I mean don’t expect everyone to respond a second after you send them something on Slack or Teams. If you need quick interactions and be always on top of everything (micromanagement), then my suggestion is to have someone assigned for that (like a PM on the offshore office), but don’t expect the rest of the team to be always ON and replying immediately on slack. Dev & tech requires flow and deep work. Work based on goals and prioritize outcomes/output and not IM responsiveness. I’m not suggesting it’s ok to disappear for days or hours, just don’t expect immediate responses. In fact, I recommend updating your monitoring & management processes to reflect this new way of working.
  • Trust the team – not only trust them, but empower them. I like giving team leads the opportunity to have a direct relationship with our clients. Don’t hide them, or block them, if you do, you are not showing you really trust them. 
  • Don’t expect perfection on day 1 – build the relationship, give feedback, correct issues, and keep moving forward. 
  • Eliminate the ‘client’ mentality – there are few things worse than having your US-based colleagues be just another ‘client’ to the offshore office. Remember, you should be a team, you should work WITH them. They are not here just to make your job easier, they are here to make better products. So, it will require changes on how you operate, and that means effort, but keep it going, believe me, it’s worth it. 

Francisco Martinez, MSc.

Los Angeles, CA - VP of Technology with over 18 years of experience in software development, enterprise architecture, product & delivery, and leadership & management. Major in Computer Science & Master of Science in Telecommunications/Electronics.