How to Get the Best Out of Your Nearshore Team

So you already found your nearshore team: they have the best experience, they are in your same time zone, you already visited their office and know each member of the team, they gave you great rates and adopted your corporate culture. Just what you need to take your projects forward.

Now comes the important part: To start working and get the best out of your nearshore team.

After years of experience managing teams in Foonkie Monkey I have learned that you should achieve a certain connection, a certain feeling with your team, to successfully achieve your objectives. This does not mean that if you do not, you will not achieve the results you expect, but based on my experience, if you can achieve that connection you can achieve really outstanding results.

Following are some tips to help you to take your nearshore team to the next level.

1. The Basics

Although using DevOps is inherent to defining the individual roles and responsibilities of each member of the nearshore team, it is necessary to be aware of the exact moment to include them in order to maximize the commitment to the project and minimize risks due to a lack of knowledge of it. This is a responsibility of the project owner, and although each project is different, it is important to involve all the members from the beginning, even from the planning stage. There will always be opinions, with different perspectives, that can help improve project planning and help the team take ownership of the project.

Keep in mind that a nearshore team usually adds value in cases where an internal team has found limitations. Being outside of the company’s internal power struggles, and/or away from some internal, restrictive policies, gives the nearshore team an ‘outside-of-the-box’ thinking and provide an unbiased opinion of the situation, resulting in innovative solutions.

It is therefore recommendable to:

• Build trust in all team members by creating a learning environment and continuous improvement: We have had experience with project leaders who use disqualification practices as a means of pressure on developers who have made a mistake. Obviously nobody expects a developer to commit an error, but a good correction focused on learning and continuous improvement is much more effective than a million disqualifications.
• Include Ops from the beginning of the planning process. The earlier the DevOps tools are used, the more organized everything will be, and many headaches will be avoided.
• Lead the developers and QA testers (or XA professionals) to automate all the processes that are repetitive, which take time and end up being a nuisance for the team, such as testing processes, debugs, branch handling on Git, etc.
• Define each requirement with as much detail as possible and invest time in ensuring that each member of the team fully understands the objectives set. The largest amount of errors committed in a project are due to a lack of information.

2. Working on an Existing Product

Most of the time, the starting point of a nearshore team or member is staff augmentation. This means that in most cases, a group of developers (or a single one) will start to work on an existing project.

In those cases, it is recommendable to spend time to familiarize the nearshore team (or member) with the product and the project, the way the internal team works, the DevOps tools that will be used, and the process cycles. This will allow the team to be aligned with the product, the objectives and the expected results. Being familiarized with the corporate values, processes and tools will be the starting point to achieve credibility among the nearshore team, ensure synchronization in the objectives and create products that really stand out.

It is recommendable, in addition to sharing all the necessary documentation (and which is basic), to provide the necessary access to the project repositories, make a product demo and generate at least a couple of sessions to answer doubts about the product.

3. Encourage Professional Confidence Among the Team

A fundamental part of team leadership is constant and fluid communication. Try to talk regularly with your team either by chat or video call. Be kind and open to listening to what they have to say. If there is a problem that could delay the project, the last thing you want is a nervous developer about to tell you the magnitude of the incident. Issues in software development may occur every day, and what is really important is to solve them in the best way and as soon as possible. And to do so, you need developers that are not afraid to talk. It is important to make them feel comfortable enough to be able to express any problem or risk that they detect.

The team member with whom you need to be in most contact is the nearshore team leader. Develop a deep professional relationship based on trust and mutual respect, and which will allow for the creation of a solid base of clear guidelines and explicit expectations.

4. Constantly Supervise the Team, But Not Excessively

It is important to find that line that separates continuous supervision and micromanagement. Usually, when you start working with a nearshore team, the results are not immediately seen because there are certain necessary startup phases, such as familiarization with the project, the creation of development environments and repositories, etc. But do not despair, the results will come: A team that has just begun to work has a lot to prove and a strong desire to work hard.

It is important to hold regular meetings with the team to request status reports, and try to be available when required. Keep communication channels open.

If possible, take a member of your internal team (onshore) to work permanently at the location of the nearshore team.

Also, treat the members of the nearshore team as equal members of your internal development team (onshore), and make them work as an integral part of it.

5. Motivate Developers by Offering Them New Challenges

A friend once told me that there is nothing more dangerous (in the good sense of the word) than a motivated developer. Present new challenges to the nearshore team, motivate them to go that extra mile. Get to know your team and, when possible, delegate the tasks that are the most interesting for each member.

Although at the beginning of each project the team will be motivated to demonstrate all their abilities, presenting new challenges will always be a good way to maintain motivation within the team. Especially when they look back and see the results obtained.

6. Be a Friend of the Scrum Methodology

Request to be present at the sprint planning meetings scheduled for the project and be aware of user stories, constantly review the task backlog (access is synonymous of transparency), and be aware of the revisions of the sprints.

In conclusion: Be a good person, treat people well, base your actions on confidence and motivation toward new and interesting challenges, make sure your nearshore team is using the same toolchain as your internal team does, and correct based on learning and continuous improvement. Treat the nearshore team as well as your onshore team and be clear and precise in all instructions given to your team.