As an entrepreneur who brings top quality software teams together with clients who need great service, I’ve had many discussions with people about moving work overseas. If a company isn’t used to offshoring software development, it can be a challenge to help them understand how remote teams can work to their advantage. The force of inertia is strong, and they’re used to working in a certain way. Their concerns about reorganizing how they work often boil down to two recurring themes:
What work do I nearshore and what can be offshored?
In most cases, the rationale is to keep the ‘strategy’ part onshore and move the ‘execution’ offshore. In terms of software development: onshore will develop user stories and requirements documents; offshore will do the coding. There needs to be a ‘cut’ somewhere in the process.
What roles should I have onshore versus offshore?
This question is related to the previous one and usually the role decision follows the decision about what work goes offshore. The ‘strategy roles’, business analyst, architect, product owner, stay onshore. The ‘execution roles’, coding, testing, sometimes scrum master, move offshore.
What most people do is pick a project to start with and then move from there. In many cases this is a non-core project without too tight deadlines and risk, which makes sense. To keep risk low, it’s usually outsourced on a fixed price with a fixed delivery date. To make a good estimate of the workload, the onshore team needs to work out requirements in detail. This implies that the thinking is done onshore. Once offshore gets those requirements, they make an offer and agree to deliver. Onshore will just wait till the test project is delivered and evaluate the collaboration with that.
In my experience, this isn’t always the best way to start. I even think that it’s best to start with question number 2. Let me explain why.
The success of any project depends on the people working on it. By thinking about what work to move first, a CTO or owner must think about the process and everything that needs to be done in terms of deliverables. If the owner of the project does all this thinking, the team has less influence on how the work gets done. And who is accountable in that case?
Create talent profiles of workers that you need
Start with the people your company most eagerly needs. In a software product firm, these are usually programmers. Create a detailed profile of the role as you would do when hiring an employee. Remember that remote programmers can choose top jobs from around the world, so make your proposal attractive.
Recruit offshore talent as you would at home (or better)
No matter how you plan to hire the people on your offshore team (with the right outsourcing partner, as freelancers or in your own offshore captive), thoroughly screen everyone. People often use less rigorous methods for selection when they engage a partner offshore. I don’t understand why, unless you have worked with that partner for a longer period and know how they select and you’ve seen the results. But if it’s a new partner, get engaged in the selection of candidates as if your life depends on it. I wrote another post on how to hire a remote developer, which gives a step by step process to hire people offshore or nearshore.
Create support onshore
This is where I see a lot of offshore collaborations go wrong: the onshore team doesn’t fully support the initiative. Management decides that some work needs to move overseas and asks its people to manage the work. If the onshore team hasn’t been engaged from day one, they’ll most likely get resistance. And if the people responsible for the operations resist what they must do, your project might end up in failure.
Engage the onshore team early on in the decision cycle. Many people have experiences working with teams in India or other countries. It is usefull to hear their stories and find a way which everyone supports. Then make sure that the person accountable for the whole operation LOVES offshoring. The key guy should be empathic, curious about other cultures, patient and structured.
Let the team define the roles
Roles are never black or white. They evolve over time. You’ve created a profile of the developers as a start. These developers may have additional skills in management, testing or other areas. Your responsibility is to assign a group of people to the team which involves the remote people. The most important part here is to see it as ‘one team': a team that has onshore and offshore team members.
Then let the team figure out who does what and where. Trust that they will come up with the best way to distribute responsibilities, based on individual competencies and experience.
Let go, and let the team get work done
The team can also decide how they want to work, you don’t need to do that for them. Of course a CTO or product manager can act as a coach in some session to define the process. But let the team decide on the distributed work process. In most cases, the software development will be done with scrum. Scrum also asks you to give full accountability for results and process to the team. You decide what needs to be built, they decide how they will get it done. If the onshore team can decide on this, they will feel like the ‘owners’ of the whole offshoring adventure.
To get started with offshoring or nearshoring, don’t follow the path most people take (pick a project, outsource that on a fixed price). Start with identifying the painpoints in your capacity: what type of person would add most value to your company if hired tomorrow? Then create a clear profile and get deeply engaged in the recruitment process. Once you’ve hired your remote software development team, give the team accountability to decide on the onshore versus offshore roles. And let them decide on the work process. If you’re willing to be clear about your work expectations and let the rest develop organically, you’ll have a much more satisfying offshore experience.
Read Next >> How Managed Remote Teams Compare To Freelance Developers