What are the requirements for your company to successfully nearshoring?
In our daily practice, we talk to companies that are interested in the topic of nearshoring. Often the companies are aware of the benefits of nearshoring but find it difficult to assess whether they have the prerequisites to “go nearshoring”.
However, the right framework conditions play a decisive role in determining whether such a project will be successful. It is not without reason that nearshoring is a topic that many shy away from with the opinion that “it can’t be done”.
Our experience has shown that nearshoring is successful when companies meet certain requirements and follow certain principles. There are critical factors that are decisive.
Based on our many years of experience in nearshoring projects, we know these success factors and present them to you in this article. Based on this overview, you can check in a first step whether nearshoring is an option for your company or not.
Nearshore teams are located abroad. Communication can therefore only take place in English. It is unrealistic to assume that enough IT specialists can be found who fit the project in terms of their skills and experience and who also speak fluent the language of your home country.
Accordingly, employees working with the nearshore team must agree to communicate 100% in English.
Tasks and internal processes
If all employees work in only one country and the whole team is in one room, then tasks can be distributed on-demand. You can also discuss topics on an ad hoc basis. Coordination is relatively easy, and you get a lot of important information over the grapevine.
On the other hand, if you are working with a distributed team where some or all the employees work remotely, then it is a completely different situation. Here, the following things are important:
Requirements must be recorded in a tool
The individual requirements for the software must be described in a system that works with tickets. This can be Jira, Trello, or something comparable. But it should be more than just an Excel sheet because that can easily lead to confusion.
The description must be short and concise, yet complete enough that a software developer can work with it without having to ask several more times.
Fixed team meetings
It is very important for team morale that team meetings always take place at the same time and are not canceled. It must become a ritual. Agile methods such as SCRUM generally provide for this as well.
When a team sits in one room, it generally doesn’t matter much if meetings are postponed or canceled. There would still be the corridor radio and you can communicate with each other through the short official channels.
But at a distance, it is important that everyone adheres to defined processes to achieve a flow of communication where information is not lost. This consistent and disciplined execution of rituals has a motivating influence on employees. In addition, it has a positive effect on the corporate culture.
Software development and testing
In Eastern Europe, there is usually a separation between testing and developing an application. This makes sense for various reasons. The roles are also separated from a financial perspective, because the salaries of testers in Eastern Europe, for example, are lower than those of programmers.
On the other hand, it contradicts the original SCRUM idea, where every team member can do everything. However, it tends to be the case that a software developer who tests their program code themselves finds fewer errors than a third person because they are overoptimistic about their own work.
The labor market in other countries “turns” much faster than we are used to. Contracts can be terminated with one month’s notice, depending on the region, and the length of time an employee stays with the company is generally shorter. This has far-reaching effects.
For example, the recruiting process must be much faster than is usual in countries such as Germany. This is because a (good) candidate almost always has several offers on the table and does not wait too long to receive an acceptance or rejection. This means that the review of candidates must be carried out quickly on the company’s side.
A candidate should receive an acceptance or rejection letter approximately one week after the interview. Otherwise, you must expect that a good candidate will drop out because another company has simply reached a decision faster.
Those who approach the topic of nearshoring with a purely cost-based perspective will not be successful. The motto must not be to save money wherever possible.
Great IT professionals have alternative job opportunities all over the world. They don’t stay long in an environment characterized solely by cost-cutting. Developers want to deliver good work in a reasonable environment. To achieve good results with a team, the following steps are therefore essential.
At least every 3-4 months someone from your country should visit the team or at least 2 members should come to you. Usually, this is done during the planning of milestones etc.
Regular, face-to-face meetings make it clear to the team that they are important and taken seriously and are not just a “cheap workbench.”
The hardware and software should be industry standard and not low-cost. No engineer likes to work with cheap and bad tools.
Personnel management and development
Employees want to feel that their performance is being noticed and that they are expanding their skills. Likewise, they want to see that their feedback and suggestions for improvement are heard. That is why feedback discussions and employee appraisals are important.
Technology Stack & Maintenance Projects
Every IT specialist has an interest in continuously expanding their knowledge. Therefore, they go to those employers who allow them to use new and in-demand technologies.
This has the following consequences: If you work with old technology, you will have a hard time finding suitable developers.
If you want to move maintenance projects abroad, you will have a hard time finding programmers because those projects rarely allow anyone to really train.
Of course, this topic should not be seen in black and white. In a maintenance project, you have to be prepared for the fact that the search for personnel takes longer and appeals to a different category of IT specialists than projects with cutting-edge technologies.
Programmers, for example in Eastern Europe, usually work with SCRUM or Kanban or a mix of both. Other methods exist, but it is recommended to experiment less here and rather stick to the methods that every team member already knows.
What certainly doesn’t work is ad-hoc development, where you are supposed to “quickly” add this or that feature.
This style is often found in small digital or advertising agencies. In an international context spanning several thousand kilometers, this holds great potential for misunderstandings – especially when it comes to priorities, exact features, and deadlines. As described above, internal processes and task descriptions are important.
Nearshoring will only be possible if the management level is fully behind it. Especially the CIO/CTO.
If they are not on board, there will be conflicts sooner or later. Sometimes the costs are criticized, and sometimes the capabilities of the nearshore team are fundamentally questioned, which may even be perceived as a foreign body.
Other countries, other customs. Tolerance of other cultures is a basic prerequisite for nearshoring. Companies should recognize and appreciate the advantages and potential of the other culture.
Don’t expect everyone to think and act the way you are used to. Nor is it always the case that the usual way is the ideal.
There are also differences in experience between individual countries. While nearshoring is new territory for many German companies, it is much more widespread and successfully implemented in Scandinavia.
In this blog post, we have compiled the essential and most important criteria that are crucial for success in nearshoring.
For a more in-depth assessment of nearshore readiness, we are available for conversion at any time.