from Celia Fässler at
Nearshoring always sounds so easy, doesn't it? I worked almost exclusively in such project constellations for three years and learned several important lessons. Working with nearshoring teams requires special attention, especially on an interpersonal level. In our last blogs, we already went through the diselva Nearshore Excellence Framework and looked at the 4 pillars. Now it's all about how collaboration really works. So what have I learned over the last few years?
1. Involvement and empowerment vs. conducting
At this point, I cannot emphasize enough how important it is to see the nearshoring team as more than just an extended workbench. Very often, I have experienced that important project decisions and the set-up of the project (and possibly also the go-live) have already taken place and the project was then simply passed on as a further development project.
I see involvement as a crucial point here, not least to promote motivation. This is not to say that there should be no appropriate sparring by the local team. Careful coaching and code reviews are highly appreciated and important, especially for more junior nearshoring teams. But here too, paternalism should be avoided and cooperation and collaboration encouraged.
2. The importance of face-to-face meetings
Working from different locations promotes a certain anonymity and it can happen all too quickly that appreciation suffers as a result. The other person should be perceived as a person with all their emotions and idiosyncrasies and not just as an “executing machine”. With the danger of this resulting distance, it also happens more often that the frustration that arises is passed on to the team all the more quickly and with all its unfiltered force.
To counteract this as far as possible, appropriate visits and team events should be promoted - with a focus on getting to know each other personally. This should also include discovering the prevailing culture. It is crucial that customers are also involved, as this has a significant influence on the project climate. Attention: Be sure to observe any travel restrictions.
To ensure that this does not go unnoticed, regular intervals between visits should be introduced and prioritized. Otherwise, the distance will increase with every week that passes.
3. Working language and exchange
Avoiding language barriers - easier than it sounds. When working with nearshoring teams, the working language is often English. If the customer's language skills are insufficient in this respect, this team combination should be avoided.
If there is a match, it is important to provide appropriate communication channels. The casual conversation with colleagues over coffee does not exist in these constellations and it is therefore all the more important that daily updates take place and, if possible, are not always strictly limited to work. Updates should also take place as video calls with the camera switched on instead of phone calls.
Regular feedback is also important - in agile setups, this can also take place with the help of review meetings at the end of each sprint. The mood within the team as well as with the customer and corresponding expectations should also be discussed.
And last but not least and always neglected - documentation, documentation, documentation...
4. “Bulwark” function, but why?
In my work as a Product Owner Consultant, I have often taken on a certain “bulwark” position. Since, as described above, a certain devaluation takes place very quickly (both by customers and internally), unfiltered “affect criticism” very quickly ends up with the nearshoring team and, in the worst case, leads to a further lowering of esteem. If you only see each other infrequently, it is all the more difficult to put this into perspective and classify it personally.
My aim was therefore often to act as a single point of contact for the customer and to convey any criticism received to the team in a differentiated manner. Constructive rather than destructive is the motto here.
5. Last but not least - self-care
While I was in this role at my old job, I worked almost exclusively with nearshoring teams and therefore often had very little contact with my local colleagues. To avoid becoming isolated, it is important to establish and maintain local contacts. From a professional point of view, it also makes sense to keep in touch with people who are facing roughly the same challenges, even if they are working on other projects.
With this in mind - good luck getting to know the team. These years have given me many wonderful moments and I was able to get to know incredibly great people - so I can only recommend that you follow the same path. Don't forget: Be nice to each other, regardless of the setup, otherwise the project won't be a success ;)
What else is needed?
The next step is to ensure that the technological integration is also right. Because without the right tools and a smooth infrastructure, nothing works when working with remote teams. But don't worry, it doesn't have to be complicated. In our next blog, we will show you how the technological onboarding of nearshoring teams works really well with the right technologies. And if support is needed - we are of course ready to help with our expertise and get the whole thing on the right track right from the start.
