In our daily practice we regularly see clients who would like to go nearshoring, but do not have the right prerequisites mitbringen, damit ein solches Vorhaben auch Erfolg hat. Nicht ohne Grund ist Nearshoring ein Thema, vor dem viele zurückschrecken mit der Meinung “das geht nicht”.
Our experience has shown that nearshoring is successful if the right conditions are met and certain rules are followed. So, there are kritische Erfolgsfaktoren die entscheidend sind. Wir haben aufgrund unsere langjährigen Erfahrung eine Übersicht dieser Erfolgsfaktoren zusammengestellt. Man kann damit grob überprüfen, ob Nearshoring wirklich in Frage kommt:
The employees working with the nearshore team must agree to communicate 100% in English. It is unrealistic to believe that one could find a sufficient number of suitable IT specialists who also speak fluent German.
Task distribution and internal processes
If you are sitting in an office in Germany and the whole team is in one room, then you can distribute tasks on call. You can also discuss ad hoc topics. Coordination is relatively easy and you can get a lot of important information over the "Flurfunk". But when you work with a distributed team, it's a completely different situation. Here the following things are extremely important:
- Requirements must be captured in a tool like Jira. The individual requirements for the software must be written down in a system that works with tickets. This could be Jira, Trello or something similar. But it should be more than a pure Excel sheet, because this can easily lead to confusion. The description must be concise and yet complete enough for a software developer to work with it without having to ask several times.
- Fixed Team Meetings: it is very important for team morale that team meetings always take place at the same time and do not fail. It must become a ritual .
Agile methods like SCRUM sehen das generell auch so vor. Aber wenn das ganze Team in Deutschland sowieso in einem Raum sitzt, dann macht es nicht viel aus, wenn man diese Meetings verschiebt, ausfallen lässt etc. denn es gibt immer noch den Flurfunk und man kann auf dem kurzen Dienstweg Dinge klären.
But at a distance it is important that everyone sticks to these processes to achieve a flow of communication where nothing gets lost. This consistent and disciplined execution of the rituals has a motivating influence and shapes the corporate culture positively.
- Development and Testing: There is usually a separation between testing and development in Eastern Europe. This makes sense for a number of reasons - also from a financial perspective, because testers have lower salaries than developers.
On the other hand, it contradicts the original SCRUM idea, where every team member can do anything. However, the tendency is that a developer who tests his own program code himself will find fewer bugs than a third person, because he is over-optimistic about his own work.
The labour market in Eastern Europe "turns" much faster than in Germany. Depending on the region, contracts can be terminated with one month's notice and the period of time an employee stays with the company is generally shorter. This has far-reaching consequences.
For example, the recruiting process has to be much faster than usual in Germany. This is because a (good) candidate almost always has several offers on the table and does not wait too long before accepting or rejecting. This means that the examination of candidates must be carried out quickly on the German side.
A candidate should receive an acceptance or rejection within about a week. If this is not done, many good candidates will drop out because another company has simply come to a faster decision.
If you approach the topic of nearshoring in such a way that you try to save wherever possible, you will not be successful. Good developers have alternative job opportunities all over the world. They don't stay long in an environment characterized exclusively by cost savings. They want to do good work in a reasonable environment. This is no different for German engineers. To achieve good results with a team, the following steps are essential:
- Visits: At least every 3-4 months someone from Germany should visit the team or at least 2 team members should come to Germany. Usually this is done when planning milestones, etc. This makes it clear to the team that it is important and is taken seriously and not just a "cheap workbench".
- Equipment: 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 perceived and that they are expanding their skills. They also want to see that their feedback and suggestions for improvement are heard. That is why feedback interviews and employee evaluations are important.
Technology Stack & Maintenance Projekte
Every IT specialist has an interest in expanding his knowledge. Therefore, they tend to go to those employers who enable them to use new and in-demand technologies. This has the following consequences:
- If you work with an old technology, it will be difficult to find suitable developers.
- If you want to push maintenance projects abroad, you will also have a hard time finding suitable developers, because these projects rarely allow anyone to really educate themselves.
Of course this topic is not black and white. With a maintenance project, you have to be prepared for the fact that the recruitment process will take longer and address a different category of IT professionals than projects with cutting-edge technologies.
Developers in Eastern Europe usually work with SCRUM or Kanban or a mix of both. You can, of course, use other methods, but it is recommended to experiment less and stick to the methods that every team member knows.
What certainly does not work is ad-hoc development, where you have to "quickly" add this or that feature. This style is often found in small digital or advertising agencies.
Dieser Stil funktioniert aber nicht in einem internationalen Kontext über mehrere tausend Kilometer, weil das Potential für Missverständnisse zu gross ist – insbesondere was Prioritäten, genaue Features und Deadlines angeht. Siehe hierzu auch weiter oben im Abschnitt “Aufgabenverteilung und interne Prozesse”.
Nearshoring only works if the management level is fully behind it. Especially CIO/CTO. If they are not behind it, it won't work because sooner or later the costs will be criticised, or the skills of the nearshore team will be fundamentally doubted, and it will be perceived more as a foreign body.
Other countries, other customs (culture). One cannot expect everyone to think and act in the same way as in Germany and it is not always the case that the German way represents the ideal. If you want to do nearshoring, you must have a tolerance for other cultures and also see their advantages and potential.
At this moment, we would like to point out that although nearshoring is a new territory for many German companies, it is far more widespread and successful in the Scandinavian region.
Here, we have compiled for you the most important criteria that are crucial for success in nearshoring. For a more in-depth assessment of nearshore readiness, we are available for a discussion at any time.