Prerequisites for starting a near shore team.
Why does near shore teams Fail? Probably there are many reasons, but I think it can be summed up as unpreparedness!
Hiring and running a near shore team takes preparation, patience, commitment and involvement. Of course there are many practical issues to be solved, such as infrastructure, security, legislation issues, company policies and many other items. But in the end it is all about people and the preparedness on both sides, in your company and in the near shore team.
So when starting a near shore team it is of vital importance to have the practical aspects in order, but more importantly have commitment from your employees, responsible person(s) appointed and committed a clear view of the purpose of the team, efficient communication tools and a strategy for implementing the team.
Running a near shore team - some practical experiences.
I have had the pleasure of running a Ukrainian near shore development team for 7 years and during that time I learned what work and what does not work.
My key learnings were in no particular order:
Culture, strange how even small distances can change culture and the way we perceive the world. Just think of your family from the country or the big city - and they are relatives! How can we then think that employees from another country will understand and accept all our ways of interacting immediately, and that we know how to handle their culture?
Cultural differences can/will play a role in how to cooperate with the team. In many eastern European countries there is a very hierarchical organizational structure, humor if definitely not as in Denmark, relationship between the sexes can be different, how to communicate your ideas or tasks should be considered, work culture is different etc. I remember when my Ukrainian team visited Denmark for the first time, they got the idea nobody cared about them. The reason was that at 16:00 everybody more or less left for home, leaving them back. In Ukraine the team would care for each other and in many ways act as a “technical” family.
Hierarchy can also be tricky. The first planning meetings I had with my Ukrainian team were very short. In the typical Danish way I had allocated ample time for discussion of the plan or proposal, but often ended up sitting alone after 15 minutes because nobody would comment on my plan, as I was the boss. So we had to teach the team that it was OK to comment and come with suggestions rather the keeping silent about their insights and my short comings.
As mentioned Danish humor J is a tough one. What I learnt was that most non Danish people do not understand our use of “unsaid things”, “implied words”, “irony”, “understating things” and probably a lot of other issues. But I also found out that when we got to know each other, you can re-introduce these very fine aspects of the Danish language…..
Obviously culture is important and both sides must be aware of the differences. That said, if you use common sense and a have humble approach you will end up having a truly intercultural team, where you can get the best from both sides.
Communication is not just about setting up the objectives, it is much more. If you are working with agile tools and use scrum techniques, mail is definitely not enough. Use tools like Skype or other collaboration tools, but most importantly meet. In my experience it is important to visit and work with team at least 5-6 times a year. This way you can get a feel for the atmosphere in the team and get to know the team members better (and they get to know you). Go out together and do social things, this one of the best ways of bonding.
Invite the team, or part of it, to participate in project kick offs. That will give everybody a possibility of meeting the “giraffe”, this helps to avoid any “us and them” issues.
Communicating clearly about projects, tasks, deadlines and maybe most important expectations are major part of your team’s success. The 3 first items should be obvious in any project, but I found out that, at least in my team, it was important to state what we expected in terms of involvement, skills and commitment.
Communicate why the team is part of a project, tell everybody what the success criteria are and very important celebrate successes.
The third learning is Commitment. This may in many respects be the most important one, if you and your company are not committed, you will fail.
The commitment I am talking about comes in 3 areas:
- Company preparedness to invest time and effort in getting the team up and running.
- Buy in from employees.
- Having a dedicated person to run the team.
When I started working with the team, they had been neglected for a long time. It was a management decision to outsource, but the decision had never been anchored in the organization. So the team was randomly feed tasks, there was no responsible person. Basically the team was seen as a nuisance that someone just had to keep busy. On the team side, they felt that they were not heard, that they did not know the purpose of the tasks, they did not know who to ask and finally they had a feeling that their production were never used. All of which were more or less correct.
Basically we were at point zero, so we started establishing the new way of working. First of all I told the team, that from now on all communications would go through me and that half of my time was set aside for helping them.
We started a long process of building trust, set up ways of collaboration, templates for tasks etc. I made it a virtue to always be available even for the smallest issues, i.e. having an account unlocked, provide as clearly described tasks as possible, visit the team often and spreading the word in my own organization that these are skilled and clever people.
At first we meet resistance in the organization, why should I work with people who doesn’t speak Danish? What do they know about our business? Are they any good? Are they stealing our jobs?
But slowly when results started emerging, the attitude changed and the team was accepted.
All the way through this process I had the commitment from my boss, who frequently visited the team telling them about company issues and the value of their work.
The key to the success, I think, was my commitment in being their anchor person, but also the fact that we had a very competent team manager with the right people and technical skills. And finally the willingness of my company to invest in the process.
What to remember? The three words Culture, Communication and Commitment.
About the team.
So what did we achieve? The team had the highest retention rate of all the teams in the near shoring company. What started out as purely ETL coding ended up as a team working with different departments and with areas as database design, JQuery frameworks, system interfaces and much more. They were widely accepted as competent project participants throughout the organization and actually projects often wanted specific members to participate.
The team comprises of 12 people working mainly with SAS in areas like ETL (Using DI studio), reporting using web based front ends and SAS Stored process, databases like Netezza, DB2, SQL etc. SAS version upgrade and change of platform (Windows to Unix), interfaces between business systems and SAS and different business related analytics.
What is near shoring?
“Nearshoring is "the transfer of business or IT processes to companies in a nearby country, often sharing a border with your own country", where both parties expect to benefit from one or more of the following dimensions of proximity: geographic, temporal (time zone), cultural, linguistic, economic, political, or historical linkages. The service work that is being sourced may be a business process or software development.”
as opposed to offshoring
“Offshoring involves shifting work to a foreign, distant organization in order to reduce production costs. Offshoring is subject to several different constraints, however, such as time lag between the parties, differences in local employment laws and practices, and oversight.”