blog shutterstock 203981407

When starting up a nearshore IT team it’s important to set up properly from the start because restoring malfunctioning constructions afterwards can be a really tough job. We see a lot of companies attempting to find high skilled labour at a low price abroad. During implementation of their offshore construction, companies run into all kind of cultural, social and linguistic issues. A solution for this is sourcing labour at lower cost in a nearby country called nearshoring. When using a nearshore construction, the cultural, social, linguistic and time differences will be minimal. Even though in order to be successful, it’s essential to manage the startup phase well. In this blog, I will explain 5 powerfull tips for setting up a nearshore construction.

1 - Actively work on building trust

In order to have an effective cooperation, it's necessary to build trust as well as building the relationship.

The best way to build trust in the relationship is to spend a lot of time together during the start-up phase and continue to meet often afterwards. Small talks most often are neglecting when having a videoconference, but they are key to building the relation. So cater for enough social events to fast track this.

For enforcing the confidence of individual team members, it's necessary to let them experience success. This will mean you have to gradually increase the difficulty of the development work. Pushing for a level too high in an early stage is devastating for motivation, and will damage the trust team members have in their own efficacy. You cannot dictate the learning curve of your team. In the ideal situation, learning should be demand driven.

Next to having a senior developer on-site on the nearshore location, it's necessary to arrange fulltime support during the start-up phase. Missing out on this will set the basis for an insecure team that has trouble reaching out for help.

2 - Make sure the team has a good mix of seniority

A good way to have committed and motivated employees is to attract them when they are younger and to support them in their growth path. In order to be able to provide the necessary support, you will need to pay attention on how the team is build up. The best mix is to have one senior, one medior and one junior developer. If the balance moves to a more junior team, the senior developer will not be able to provide support on an ad hoc basis and eventually this will impact the motivation of the junior developers.

Next to this, the senior developer will spent too much time on coaching and lack time for making technical designs and developing the most complex software himself. Having a good mix of seniority in the team, will also enable you to divide the work based on complexity. Thereby you can gradually increase the complexity of the work the junior developer in the team can pick up. This way you prevent the junior team member gets stuck too often.

3 - Create explicit user stories with a lot of technical details

When starting up a team in an agile development environment, it's necessary to have sufficient time and attention for technical refinement. Insecurity will drop in time because developers become more familiar with the application they are working on. At the start, there will be an increased need for explicit user stories with enough technical guidance. The technical lead of the team will have to dedicate more time than usual on adding technical details to the user stories and coaching on technical implementation. This will feel unnatural for most senior developers, but will take away insecurity from junior developers and boost their efficiency. Over time you can gradually reduce the amount of technical details and implementation guidance up till a point where user stories are mainly functional.

4 - Remove barriers for communication

When building up a team it's important to optimize communication and cooperation. The best way to do this is by sitting in the same room often. If this is not possible it's still best to be able to see each other. Since 55% of communication is body language, having video conference capabilities is very important. A lot of emotions will not show directly through words or intonation.

blog shutterstock 290643572

Next to doing individual and team sessions including video, it's good to have a continuous stream between the locations. By seeing each other, you know whether the other is available and it will lower the barrier for reaching out. Next to feeling proximity, it's essential to build trust in the relationship. People must feel free to reach for help whenever necessary. All of the above will help in making this as easy as possible for them.

5 - Prevent long struggles on complex issues

It's eminent that it's not good to have people struggling on complex issues for too long. Sometimes there is too much time between the time that people encounter an issue and come to the conclusion they can’t solve it themselves. Key is to have your team members start communication as soon as possible after encountering issues. For most technical people this will be difficult since they will have the tendency towards trying to figure out things themselves instead of seeking help. So help the team members get inside their own behaviour. Especially when this behaviour is causing productivity and learning curve to drop. Also having a regular status updates with the team will force team members to reach for help earlier since their stocking progress is visible for everybody.


So in order to have a happy and productive nearshore IT team, it’s very important to provide the right support by giving explicit instructions and having senior developers involved. Next to this it’s essential to spent enough time together in the startup phase and focus on good communication. Even though the tips in this blog will get you way ahead of the rest: Accept it takes time to build up a good working team.

About Bas

BasFotoKleinI am a result driven BPM Consultant with experience in business consulting, project management and business analysis. In my current role I combine being scrum master and business analyst. I always look for improvements and like to work towards the implementation of these. Read more about me on LinkedIn.